Converts a PRD or requirements document into a structured, phased implementation plan with individual phase files and granular per-task files written to .context/plans/. Also restructures existing monolithic planning documents into digestible, hierarchical directory structures. Creates a root plan index summarising all phases, a numbered phase file per phase, and a numbered task file per task inside each phase directory.
92
93%
Does it follow best practices?
Impact
91%
3.25xAverage score across 5 eval scenarios
Passed
No known issues
An implementation plan already exists at .context/plans/plan-blog-platform/. The plan currently has two phases:
phases/phase-01-workspace-bootstrap/ (3 tasks — all complete)phases/phase-02-data-model/ (4 tasks — all complete)You need to extend this plan with a new phase covering the REST API layer. The API layer must implement:
GET /posts — list all posts (paginated, 10 per page)POST /posts — create a new post (title, body, author required)GET /posts/:id — get a single post by IDPUT /posts/:id — update title/body of a postDELETE /posts/:id — delete a post (soft delete — set deleted_at)GET /health — health check returning {"status":"ok"}Use Express.js. All handlers must be in separate files under src/api/.
Add this as phase 3 to the existing plan.
The following files already exist and are read-only — they MUST NOT be modified, renamed, or deleted under any circumstances:
phases/phase-01-workspace-bootstrap/ and all files within itphases/phase-02-data-model/ and all files within itThe root README.md may have a new phase-03 entry appended to its phase listing.
No other edits to the root README are permitted.
Only new files may be created: the phase-03 directory, its README, and its task files.