notion-spec-to-implementation

Spec to implementation

Translate requirements into verifiable work while preserving constraints, acceptance criteria, dependencies, and traceability to the source spec.

Workflow

1. Select the requested outcome. Distinguish a plan, task creation, implementation, and a progress update. Complete the requested combination. A plan alone does not require task pages or an “In Progress” status. If actual implementation is requested and code tools are available, continue through implementation and appropriate validation; do not stop at planning.
2. Read the specification. Fetch a supplied URL directly; otherwise search by project or title. Resolve ambiguous matches. Extract functional and non-functional requirements, acceptance criteria, constraints, dependencies, and unresolved decisions. Preserve explicit out-of-scope items. When code is available, inspect relevant implementation and repository instructions before choosing an approach. Label assumptions and estimates; do not invent commitments.
3. Plan at useful granularity. Choose independently verifiable deliverables and identify prerequisite work. Use phases only when they help coordinate the work. Preserve requirement-to-task coverage, including validation. Fit estimates to the team's conventions when requested or useful; do not force a task count, number of phases, or 1–2-day duration. Reuse an existing plan when updating it.
4. Create tasks when requested. Fetch the supplied task database directly or discover it if unknown. Read its schema once; identify the correct data source, title, status options, and relation targets. Check for existing tasks covering the same spec before creating duplicates. Each task needs an objective, source requirements, testable acceptance criteria, and dependencies. Use supported batching for independent creates when it reduces calls; link task dependencies after IDs exist. Do not guess assignees, dates, or relation values.
5. Implement or track progress within scope. Update statuses when work actually starts or meets the team's completion criteria. Record meaningful changes, blockers, decisions, and links to tests, PRs, or deliverables. Reuse existing notes; avoid repetitive updates with no new information. Compute progress from observed task or requirement coverage and explain the denominator. A created plan or task is not evidence of completed implementation.
6. Verify and report. Check created/updated pages, requirement coverage, schema values, and links. Read back writes when their result is unclear. Return links and distinguish planned, created, implemented, verified, and blocked work. If a batch partially succeeds, retain successful IDs, inspect uncertain outcomes, and retry only missing work.