workflow-status

You are guiding a project through an RFC-driven development workflow with these stages:

#	Stage	Artifact	Command / Prompt
0	Document an existing codebase (instead of stages 1, 3 and 4)	PRD.md, FEATURES.md, RULES.md	/document-existing (document-existing-prompt.md)
1	Create PRD	PRD.md	/create-prd (interactive-prd-creation-prompt.md)
2	Verify PRD	PRD.md (improved) + PRD-REVIEW.md	/verify-prd (prd-comprehensive-verification-prompt.md)
3	Extract features	FEATURES.md	/extract-features (prd-to-features-prompt.md)
4	Generate rules	RULES.md	/generate-rules (prd-to-rules-prompt.md)
5	Generate RFCs	RFCs/ folder + RFCS.md	/generate-rfcs (prd-to-rfcs-prompt.md)
6	Testing strategy	TEST-STRATEGY.md	/test-strategy (testing-strategy-prompt.md)
7	Implement RFCs (each once its declared predecessors are done)	Code	/implement-rfc <id> (implementation-prompt-template.md)
8	Review each implementation	reviews/REVIEW-RFC-<id>.md	/review-rfc <id> (code-review-prompt.md)
9	Manage changes (whenever requirements move)	changes/CHANGE-REQUEST-<nnn>.md	/manage-changes (prd-change-management-prompt.md)
10	Status check (anytime)	this report	/workflow-status (workflow-status-prompt.md)

Stage 6 comes before stage 7 deliberately: a test plan written after the code is a coverage audit, not a plan.

Inspect the current project to determine workflow progress. If trace-check.py is available -- in a scripts/ folder beside these instructions, or in the project's own scripts/ folder -- run it on the project first (python3 <path>/trace-check.py .): it checks IDs, coverage, RFC dependencies and review records mechanically, and its FAIL lines belong in your Inconsistencies section.

1. Which artifacts exist: PRD.md, PRD-REVIEW.md, FEATURES.md, RULES.md, RFCS.md, RFCs/ folder, TEST-STRATEGY.md, reviews/, changes/?
2. Which RFCs are implemented? Start from the Status column in RFCS.md, which /implement-rfc and /review-rfc keep current, then verify it: spot-check the acceptance criteria of every RFC it marks Implemented or Reviewed against the actual code, and report any status the code does not support. Do not assume an RFC is done just because code exists, or because the column says so.
3. Which RFCs have been reviewed? Check reviews/ for a report per implemented RFC — an implemented RFC with no review is the most common real-world gap, and reviews are exactly what gets skipped under deadline.
4. Are there open change requests in changes/ whose decisions are still pending?
5. Any signs of drift: code that contradicts the PRD or RULES.md, features in the codebase with no RFC, an RFC implemented before its declared predecessors, deviations in code that the RFC's Implementation Notes do not record?

If you cannot inspect files directly, ask me to describe or paste the artifacts before reporting.

Then report:

1. Status table — each workflow stage with its artifact and status (Done / In progress / Missing / Stale)

2. Per-RFC progress — implementation and review status side by side, one row per RFC:

   RFC-001  implemented ✅   reviewed ❌
   RFC-002  implemented ✅   reviewed ❌
   RFC-003  implemented ✅   reviewed ✅
   

   A single "reviews done" row hides which RFCs were actually reviewed. Report them individually.

3. Inconsistencies — anything drifted, skipped, or contradictory, with file references

4. Next step — the single recommended next action, with the exact command or prompt to run