Hussh Planning Board Skill

Purpose and Trigger

• Primary scope: planning-board-intake
• Trigger on Hussh Engineering Core or Hussh Action Items board summaries, issue-backed board item creation, triage, and field updates.
• Board selection: board_ops.py --board engineering-core (default, Project 73) or --board action-items (Project 79, the Inbox → Accepted → In Progress → Ready for QA → Ready For UAT → Done lifecycle). Field differences are resolved against the live field catalog; see the per-board references.
• Avoid overlap with repo-operations and repo-context.

Coverage and Ownership

• Role: owner
• Owner family: planning-board

Owned repo surfaces:

1. .codex/skills/planning-board

Non-owned surfaces:

1. repo-operations
2. repo-context

Do Use

1. Summarizing board activity by date window or repository slice.
2. Creating issue-backed board work in hushh-labs/hushh-research.
3. Updating required board metadata and verifying the resulting project-item state.
4. Normalizing or updating issue labels when the user asks for label hygiene.

Do Not Use

1. CI, deploy, branch-protection, or PR-approval workflows.
2. Broad repo-orientation work.
3. Product implementation or docs-home governance.

Read First

1. .codex/skills/planning-board/references/engineering-core-board.md
2. .codex/skills/planning-board/references/action-items-board.md
3. docs/project_context_map.md
4. docs/reference/operations/coding-agent-mcp.md

Workflow

1. Resolve the issue and project-item state dynamically instead of assuming cached IDs.
2. Create the GitHub issue first, then attach and update the board item.
3. Re-read the issue and board state after editing to confirm the change stuck.
4. When reporting work back to the user, always use the stable task shape #<number> <title>.
5. When the user asks for labels, treat labels as a first-class part of the task update instead of leaving them implicit.
6. Do not move sprint or reset dates on existing tasks unless the user explicitly asks for that metadata change.
7. Do not use bare issue numbers in summaries, status lists, overdue lists, or change logs when the title is available.
8. Use In review when implementation is complete but PR review, UAT proof, dashboard acceptance, founder sign-off, or other external verification remains.
9. Use Done only when the work is accepted and the issue state or acceptance evidence agrees with completion.
10. Before and after broad cleanups, run board_ops.py audit-state and resolve drift deliberately.
11. For duplicate or redundant board tasks, consolidate the scope into the canonical issue, leave a traceability comment, then remove the duplicate project item with board_ops.py remove-task; do not mark duplicates as Done just to clear the board.

Handoff Rules

1. If the task is broad repo orientation, start with repo-context.
2. If the task is CI, deploy, or branch protection, use repo-operations.
3. If the task becomes product coding or docs governance, route to the correct owner skill for that domain.

Required Checks

python3 -m py_compile .codex/skills/planning-board/scripts/board_ops.py
python3 .codex/skills/planning-board/scripts/board_ops.py summary --from 2026-04-01 --to 2026-04-07
python3 .codex/skills/planning-board/scripts/board_ops.py audit-state