---
name: planning-board
description: Use when inspecting, summarizing, creating, triaging, or updating work on the Hussh Engineering Core GitHub board.
---

# Hussh Planning Board Skill

## Purpose and Trigger

- Primary scope: `planning-board-intake`
- Trigger on `Hussh Engineering Core` board summaries, issue-backed board item creation, triage, and field updates.
- 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. `docs/project_context_map.md`
3. `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

```bash
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
```
