Reconcile delivery progress with ak:project-management

Use ak:project-management to understand and preserve the state of multi-phase work. The Skill reads durable plan files, mirrors remaining work into a live task surface when one is actually available, reconciles verified completion back across every phase, and produces traceable status reports for the next session or handoff.

Choose ak:project-management for oversight and continuity

Use ak:project-management when

• You need status across one or more implementation plans.
• A session must resume from remaining plan work without trusting ephemeral runtime state.
• Completed runtime items need to be mapped back to phase checkboxes and plan status.
• Dependencies, blockers, or parallel ownership need coordination.
• A milestone needs a concise session, completion, or multi-plan report.
• You need an explicit decision about whether changed behavior requires docs.

Choose another workflow when

• You need to create or validate an implementation roadmap. Use ak:plan.
• You want to implement the next phase. Use ak:cook.
• You need to diagnose and repair a concrete failure. Use ak:debug and ak:fix.
• You want chronological reflection rather than current project status. Use ak:journal.

Prepare the plan state

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Open the project containing the target plans/ directory.
• Preserve plan.md and every phase-XX-*.md file; they are the durable source of truth.
• Provide verification evidence for work you expect to mark complete.
• Identify the target plan when several plans overlap or share files.
• Make the ak CLI available when possible so the Skill can consult live ak plan --help before using CLI-managed status operations.

Request the oversight operation

The Skill accepts a task such as status, hydrate, sync, or report. These are workflow intents rather than published mode flags.

/ak:project-management "Sync verified work back to the active plan, report any unmapped completed items, then create a concise session status report."

/ak:project-management "Sync verified work back to the active plan, report any unmapped completed items, then create a concise session status report."

$ak:project-management "Sync verified work back to the active plan, report any unmapped completed items, then create a concise session status report."

A good request names the target plan, the session or milestone boundary, known completed items, verification evidence, expected report type, and any runtime work items that may not yet map cleanly to the plan.

Understand what happens during a run

1. The Skill reads the durable plan. It loads plan.md and every phase file, parses existing frontmatter, and identifies checked, unchecked, and blocked work.
2. The Skill discovers runtime tracking. It uses a live task-management surface only when runtime discovery confirms the capability. It never infers support from the client name or a cached tool list.
3. The Skill hydrates remaining work. When the live view is available, it mirrors only unchecked work with dependencies, ownership, acceptance criteria, and a durable source-plan mapping.
4. The Skill tracks progress. Items move through pending, active, blocked, and completed states when supported; otherwise the active plan is updated directly. Parallel ownership stays non-overlapping.
5. The Skill performs full-plan sync-back. It sweeps every phase, maps verified completed items, backfills stale earlier phases, recalculates progress, and updates plan status only when checkbox evidence supports it.
6. The Skill reports project state. It summarizes progress, achievements, blockers, risks, tests, and next actions with metrics and tables.
7. The Skill evaluates documentation impact. User-visible behavior, public contracts, architecture, security, or recovery changes are routed to the smallest owning docs surface; mere task completion is not copied into evergreen documentation.

Keep plan authority intact

• The Skill never marks only the current phase and ignores stale earlier work.
• If a completed item cannot be mapped to a phase file, it is reported as unresolved and the plan is not claimed complete.
• Existing plan frontmatter is preserved. The Skill does not invent fields for a particular runtime task system.
• Status changes require acceptance criteria, test or review evidence, and intact dependencies; runtime state alone is insufficient.
• Documentation updates are a separate authority surface. A docs workflow may edit files only after a confirmed documentation-impact decision.
• Reports and plan updates are local file effects. Commit, push, publication, external task-system mutation, and deployment remain separate approvals.

Verify the result

A complete run should give you:

• The target plans, frontmatter state, phase counts, and calculated progress.
• A list of hydrated runtime items and their source-plan mappings when a live surface exists.
• Reconciled checkboxes across every phase, including backfilled earlier work.
• Plan status derived from real checkbox state: pending, in progress, or completed.
• Verified acceptance criteria and the evidence behind completed work.
• Blockers, stale dependencies, unmapped items, and risks kept visible.
• A concise report with achievements, next actions, and unresolved questions.
• An explicit documentation-impact decision and any routed follow-up.

Treat sync-back as complete only when every completed item maps to a durable phase entry and the plan status agrees with the full checkbox sweep. Treat the runtime view as disposable once that durable state is current.

Troubleshoot or continue

Continue with ak:cook for remaining implementation or ak:journal for a chronological session record.

Know the current limits

• Progress quality depends on accurate plan checklists and fresh verification evidence.
• Runtime task-management capabilities are discovered dynamically and may not exist or persist across sessions.
• The Skill coordinates and reports work; it does not itself prove code quality without test and review evidence from the owning workflows.
• Cursor slash invocation is user-verified evidence, not proof of full runtime parity.
• Stable and beta package the same ak:project-management hydration, sync-back, and reporting references.