workflow-next-plan

Work management hub built on the functional spec (SPEC file). Shows coverage, creates work-items, manages Git branches, and links completed work back to the SPEC. This is a Layer 2 skill.

See references/conventions.md for detailed rules on SPEC table structure, work-item format, versioning, and Git branch strategy.

Prerequisites

#	Check	On failure
1	.wiki symlink exists	"Run /wiki-init first"
2	SPEC file exists in .wiki/	"Run /workflow-idea first"
3	CWD is a Git repository	"Please run from a Git repository"

Workflow

0. Status check

Recover context when entering a new session.

1. SPEC coverage summary — Read SPEC file, show counts by status:

   Feature Coverage: {total}
   done:     {count} ({pct}%)
   partial:  {count} ({pct}%)
   pending:  {count} ({pct}%)
   deferred: {count} ({pct}%)
   

2. Find in-progress work-items — Scan .wiki/projects/{project}/work-items/ for files with in-progress status. Show their contents.

3. Collect Git metadata — Run only these 4 commands:

   • git branch — current branch and work branches
   • git log --oneline -10 — recent commits
   • git status --short — uncommitted changes
   • git tag --sort=-version:refname | head -5 — recent tags

4. Suggest next action — If in-progress work exists, ask whether to continue or start new work.

Prohibited actions

Do NOT perform these for status recovery:

• Reading source code files or recursive directory traversal
• Running git diff to dump full changes
• Using glob/grep to explore project structure

1. Plan work

Decide what to work on next and create a work-item.

1. Analyze SPEC — List pending items grouped by domain
2. Recommend priorities — Suggest top 3 via AskUserQuestion:
   • Dependencies (does this unblock other features?)
   • Domain balance (avoid concentrating on one area)
   • Quick wins (small scope, fast to complete)
3. Create work-item when user selects:
   • Determine version (see references/conventions.md)
   • Write work-item file (detailed instructions + references)
   • Record related SPEC IDs (which IDs this work-item maps to)
4. User review — Confirm via AskUserQuestion
   • If user has additions, add ### Additional instructions section
   • When satisfied, proceed to next step (start work)

2. Start work

Create a Git branch and begin implementation.

1. Detect base branch:
   • develop exists → use develop
   • No develop → use main
2. Create work branch: git checkout -b {type}/{english-name} {base}
3. Update work-item status to in-progress
4. Implement — Follow the instructions in the work-item

3. Complete work

Review, merge, and tag.

1. Verify work branch — If on main or develop, warn and stop
2. Find in-progress work-item — Locate file with in-progress status
3. Commit changes — Check git status, write commit message, commit
4. Request approval — Show work summary via AskUserQuestion, confirm merge
5. Merge to base branch — git checkout {base} && git merge --no-ff {branch}
6. Create annotated tag — git tag -a v{x.y.z} -m "{type}: {description}"
7. Update work-item status to done

4. Link to SPEC

Reflect completed work in the functional spec.

1. Update related SPEC IDs:
   • Status column: pending → done (or partial)
   • Work Items column: add work-item file link
   • If one work-item maps to multiple IDs, update all of them
2. Update the Updated date in the SPEC header
3. Report results:
   • Merged branch and created tag
   • Updated SPEC ID list
   • Updated coverage summary

Special commands

User input	Action
"defer" / "skip this"	Status → deferred, record reason
"partial" / "half done"	Status → partial, record remaining work
"add a feature"	Add new row to SPEC (auto-increment ID)
"add a domain"	Add new domain section to SPEC

Reference

• references/conventions.md — SPEC structure, work-item format, versioning, Git strategy