Project Status Phase

Use this skill to move a GitHub issue or pull request through the next truthful project-board phase.

Workflow

1. Read the board readme and field names first.
2. Inspect the issue body, checklist, labels, linked PRs, and comments.
3. Compare that with the repo's current main state and any relevant docs or TODOs.
4. Decide the next phase from evidence, not urgency.
5. Move only the status field unless the user asked for other board changes.

Phase Rules

• Inbox: raw intake, not enough context yet.
• Spec: planning, requirements, design, research, or umbrella work.
• Ready: actionable and unstarted.
• In Progress: actively being worked right now, only if the board expects an active lane and there is real evidence.
• Review: implementation exists and a PR or equivalent verification path is ready.
• Blocked: progress is prevented by a dependency or external blocker.
• Done: the work is merged, shipped, or intentionally closed.

Guardrails

• Do not use In Progress as a proxy for importance.
• Do not move to Review without a real PR or verification path.
• Do not move to Done unless repo state supports it.
• Do not rename board fields or change sequencing fields unless asked.
• If the board policy says to keep In Progress empty, honor that.
• If evidence is unclear, stop and ask for the missing repo, board, or PR context.

When to Split Instead of Move

• The issue is an umbrella tracker with multiple unresolved subtopics.
• The work is mostly planning, cleanup, or docs, not implementation.
• The issue is carrying more than one distinct deliverable.

In those cases, move the item to the correct planning phase and suggest splitting follow-on work into separate issues.

Reference

See references/status-phase-rules.md for the decision tree and evidence signals.