Nova Accountability

Manage accountability items on a Monday.com board. Use when creating new accountability items, checking on existing ones, running work sessions, or when a cr...

Security Scan

This skill genuinely targets Monday.com board automation, but the manifest, docs, and runtime instructions disagree on what it needs and what it may do — notably missing declared env/binaries and broad runtime authority (spawning agents, messaging people) — so review before installing.

Purpose & Capability

The skill's name/description (manage Monday.com accountability items) matches the included code and SKILL.md which use the Monday GraphQL API. However the package metadata claims no required env vars or binaries, while the SKILL.md/README/scripts clearly require a MONDAY_API_TOKEN and MONDAY_BOARD_ID and rely on curl and jq. That mismatch is inconsistent and should be corrected.

Instruction Scope

The SKILL.md instructs the agent to read all active items, create sub-items, write updates, and run an hourly 'real work session' that can 'execute the plan' including code work or 'config changes, research, outreach'. It also explicitly tells the agent to 'orchestrate others' (spawn Cursor Agent or other coding agents) and 'message anyone who can help' without enumerating required messaging credentials. The helper script reads ~/.openclaw/.env (to find MONDAY_API_TOKEN) and performs GraphQL calls to api.monday.com. The scope instructions therefore permit broad external interactions (spawning agents, messaging people) that are not reflected in declared requirements — this is scope creep and raises operational risk.

Install Mechanism

There is no install spec (instruction-only), which is low risk. The included script will be written to disk as part of the skill bundle. The script uses curl and pipes output to jq, but the manifest lists no required binaries; the skill should declare curl and jq as required or handle missing binaries gracefully.

Credentials

The SKILL.md and README require MONDAY_API_TOKEN and MONDAY_BOARD_ID, yet the registry metadata states none are required. The script attempts to read MONDAY_API_TOKEN from the environment or by grepping ~/.openclaw/.env — reading a user .env file is a notable behavior (it reads only to extract the token, but that file may contain other secrets). The skill does not declare or request any messaging/notification credentials even though instructions encourage contacting people and spawning sub-agents, creating a gap between capabilities and declared credentials.

Persistence & Privilege

The skill is not always-enabled and does not request elevated or persistent system privileges. It suggests running on a cron schedule (expected). It does not modify other skills or system-wide settings in the files provided.

What to consider before installing

Before installing, confirm and correct the missing declarations and limit runtime scope: 1) Expect to provide a Monday API token (MONDAY_API_TOKEN) and board id (MONDAY_BOARD_ID) — the manifest should list them; 2) Ensure curl and jq are available or update the script to avoid jq; 3) Note the script will look in ~/.openclaw/.env for MONDAY_API_TOKEN — review that file for other secrets and consider placing the token in a dedicated env var instead; 4) Decide whether you want the agent to be allowed to 'spawn sub-agents' and 'message anyone' — if not, restrict the agent's permissions or remove/modify those instructions; 5) Run the skill in a constrained environment (limited network access, least-privilege token scoped to boards read/write) and review logs for outbound communication; and 6) If you need high assurance, ask the publisher to update the skill metadata to declare required env vars and binaries and to clarify exactly which external channels (email, Slack, etc.) the agent will use and what credentials are needed.

Accountability Skill

Configuration

This skill is config-driven. All board IDs, column IDs, and names come from plugin config (see frontmatter above). For this installation:

• Board ID: {{config.board_id}}
• Owner Name: {{config.owner_name}}
• Agent Name: {{config.agent_name}}

Column IDs

Column	Config Key	Default ID	Type	Purpose
Status	columns.status	color_mm0yr4nm	status	Active / Done / Blocked
Check Frequency	columns.check_frequency	text_mm0y6b8r	text	How often to check: 1h, 2h, 4h, 8h, daily
Last Checked	columns.last_checked	date_mm0y8p9j	date	When agent last reviewed this item
Details	columns.details	long_text_mm0yce5e	long_text	Full definition of done, context, blockers
Assigned By	columns.assigned_by	color_mm10z99x	status	Who created/assigned this task

Completion Rules

• Owner-assigned tasks ({{config.assigned_by_labels.owner}}): Only {{config.owner_name}} can mark them Done. Agent may suggest completion but must NOT change status to Done.
• Agent-assigned tasks ({{config.assigned_by_labels.agent}}): Agent can mark them Done independently.
• Always check "Assigned By" before changing any status to Done.

API Setup

• Token env var: {{config.api_token_env}} in ~/.openclaw/.env
• Endpoint: https://api.monday.com/v2 (GraphQL)
• Auth header: Authorization: <token>

---

Hourly Work Session (Cron-Triggered)

This is the core loop. Every hour, a cron job fires and the agent runs a real work session — not just a status check.

Phase 1: Review & Plan

1. Read all active items from the Monday board (including sub-items)
2. Assess each item: What's the current state? What changed since last check? What's blocking progress?
3. Pick what to work on — prioritize items that are unblocked and can make real progress
4. Break work into subtasks — create sub-items under the main accountability item on Monday
5. Write the plan in the Doc column of the sub-item: what you're about to do, approach, expected outcome

Phase 2: Do the Work

6. Execute the plan:
   • For code work: Follow the product-dev process — Cursor Agent writes code, test, iterate. Never code directly.
   • For non-code work: Do it directly (config changes, research, outreach, etc.)
7. Write an update on the main accountability item in Monday (Updates section) with what was done and results

Phase 3: Handle Being Stuck

If stuck, blocked, or unsure what to do next:

8. Reassess the whole project fresh — don't keep banging on the same approach
9. If it's code: Read ALL of it. Understand the goal. Reflect on everything as if seeing it for the first time.
10. Create new tasks as needed (sub-items on Monday)
11. Orchestrate others:
    • Sub-agents: Spawn Cursor Agent or other coding agents for implementation
    • People: Message anyone who can help — {{config.owner_name}} or others. Don't limit yourself. If someone else has the context or ability to unblock you, reach out to them directly.
12. If you genuinely need the owner: Message them with specific context — what you tried, what failed, what you need from them

Phase 4: Wrap Up

13. Update "Last Checked" date on all reviewed items
14. Update statuses: Move items to Blocked/Stuck if appropriate
15. For owner-assigned items that look complete: Write an update suggesting it's done, but do NOT change status to Done — only {{config.owner_name}} can do that

---

Workflow: Creating New Accountability Items

1. Create item on board {{config.board_id}} with create_item mutation
2. Set Details column with: goal, definition of done, current state
3. Set Check Frequency (e.g. "1h")
4. Set Assigned By: {{config.assigned_by_labels.owner}} or {{config.assigned_by_labels.agent}} depending on who initiated it
5. Write first update with current status
6. The hourly work session cron handles all items — no need for per-item crons

Workflow: Daily Summary

Every day at 9:00 AM, review all active items and write a consolidated update to {{config.owner_name}}.

---

Monday.com Sub-Items

Sub-items are used as subtasks under each accountability item. They represent specific work units.

Create sub-item

mutation { create_subitem(parent_item_id: PARENT_ID, item_name: "SUBTASK_NAME") { id } }

Read sub-items

{ items(ids: [PARENT_ID]) { subitems { id name column_values { id text value } } } }

---

GraphQL Snippets

Replace BOARD_ID with {{config.board_id}} and column IDs with values from config.

Read all active items (with sub-items)

{ boards(ids: BOARD_ID) { items_page(limit: 50) { items { id name column_values { id text value } updates(limit: 3) { body created_at } subitems { id name column_values { id text value } } } } } }

Create item

mutation { create_item(board_id: BOARD_ID, item_name: "TITLE", column_values: "{\"DETAILS_COL\":{\"text\":\"DETAILS\"},\"FREQ_COL\":\"FREQ\",\"ASSIGNED_COL\":{\"label\":\"OWNER_LABEL\"}}") { id } }

Write update

mutation { create_update(item_id: ITEM_ID, body: "<p>UPDATE_HTML</p>") { id } }

Update Last Checked

mutation { change_column_value(board_id: BOARD_ID, item_id: ITEM_ID, column_id: "LAST_CHECKED_COL", value: "{\"date\":\"YYYY-MM-DD\"}") { id } }

Change Status

Status labels: Working on it (1/orange), Done (2/green), Stuck (0/red)

mutation { change_column_value(board_id: BOARD_ID, item_id: ITEM_ID, column_id: "STATUS_COL", value: "{\"label\":\"Working on it\"}") { id } }

Helper Script

Run scripts/monday-api.sh for common operations:

export MONDAY_API_TOKEN="your_token"
export MONDAY_BOARD_ID="your_board_id"

# List items
bash scripts/monday-api.sh list
# Add update to item
bash scripts/monday-api.sh update <item_id> "<html body>"
# Set last checked
bash scripts/monday-api.sh checked <item_id>

---

Messaging Etiquette

• Never message people outside {{config.messaging_hours.start}} – {{config.messaging_hours.end}} ({{config.messaging_hours.timezone}}) unless it's genuinely urgent
• If you need someone's input and it's outside hours, note it as a blocker and follow up when hours resume
• {{config.owner_name}} can be messaged anytime if something is truly urgent

Critical: Read Before Working

Before doing ANY work on an accountability item, you MUST read the full Document/Details column on that item first. This contains important context, constraints, and explicit instructions about what to do and what NOT to do. Skipping this step has caused the agent to undo previous decisions. No exceptions.

Sub-Agent Context Rule

When spawning any sub-agent for work on an accountability item, you MUST include the full text from the item's Details/Doc column in the sub-agent's task prompt. This includes constraints, warnings, history, and explicit "DO NOT" instructions. The sub-agent has no memory of previous sessions — if it doesn't get the context in its prompt, it will make decisions that contradict prior decisions.