seaworld008/notion-spec-to-implementation

Spec to Implementation

Convert a Notion spec into linked implementation plans, tasks, and ongoing status updates.

When to Use

Use this skill when the user wants to:

• turn a Notion PRD or feature spec into an execution plan
• create linked implementation tasks from a spec
• keep spec, plan, and tasks synchronized over time
• move from product definition to engineering delivery inside Notion

Use a different skill when:

• the main task is documenting research or summaries → use notion-research-documentation
• the main task is capturing a meeting or decision artifact → use notion-knowledge-capture

Quick start

1. Locate the spec with Notion:notion-search, then fetch it with Notion:notion-fetch.
2. Parse requirements and ambiguities using reference/spec-parsing.md.
3. Create a plan page with Notion:notion-create-pages (pick a template: quick vs. full).
4. Find the task database, confirm schema, then create tasks with Notion:notion-create-pages.
5. Link spec ↔ plan ↔ tasks; keep status current with Notion:notion-update-page.

Usage

Typical artifact chain:

spec page
-> implementation plan page
-> task database entries
-> recurring status updates

Default output should include:

• requirements summary
• assumptions and open questions
• phases or milestones
• concrete tasks with acceptance criteria
• relations between spec, plan, and task records

Workflow

0) If any MCP call fails because Notion MCP is not connected, pause and set it up:

1. Add the Notion MCP:
   • codex mcp add notion --url https://mcp.notion.com/mcp
2. Enable remote MCP client:
   • Set [features].rmcp_client = true in config.toml or run codex --enable rmcp_client
3. Log in with OAuth:
   • codex mcp login notion

After successful login, the user will have to restart codex. You should finish your answer and tell them so when they try again they can continue with Step 1.

1) Locate and read the spec

• Search first (Notion:notion-search); if multiple hits, ask the user which to use.
• Fetch the page (Notion:notion-fetch) and scan for requirements, acceptance criteria, constraints, and priorities. See reference/spec-parsing.md for extraction patterns.
• Capture gaps/assumptions in a clarifications block before proceeding.
• Separate hard requirements from inferred implementation detail; do not silently invent acceptance criteria.

2) Choose plan depth

• Simple change → use reference/quick-implementation-plan.md.
• Multi-phase feature/migration → use reference/standard-implementation-plan.md.
• Create the plan via Notion:notion-create-pages, include: overview, linked spec, requirements summary, phases, dependencies/risks, and success criteria. Link back to the spec.

3) Create tasks

• Find the task database (Notion:notion-search → Notion:notion-fetch to confirm the data source and required properties). Patterns in reference/task-creation.md.
• Size tasks to 1–2 days. Use reference/task-creation-template.md for content (context, objective, acceptance criteria, dependencies, resources).
• Set properties: title/action verb, status, priority, relations to spec + plan, due date/story points/assignee if provided.
• Create pages with Notion:notion-create-pages using the database’s data_source_id.
• Prefer fewer, clearer tasks over copying the entire spec into every ticket.

4) Link artifacts

• Plan links to spec; tasks link to both plan and spec.
• Optionally update the spec with a short “Implementation” section pointing to the plan and tasks using Notion:notion-update-page.
• If the spec already has implementation links, update them instead of duplicating sections.

5) Track progress

• Use the cadence in reference/progress-tracking.md.
• Post updates with reference/progress-update-template.md; close phases with reference/milestone-summary-template.md.
• Keep checklists and status fields in plan/tasks in sync; note blockers and decisions.

Common Pitfalls

• turning ambiguous ideas into tasks without calling out assumptions
• creating tasks before confirming the correct task database schema
• making tasks too large to track
• not linking spec, plan, and tasks, which breaks traceability
• updating task status but forgetting to update the plan summary

Done Criteria

Spec-to-implementation is complete when:

• the source spec is identified and linked
• a plan page exists with phases and risks
• task records exist in the correct data source
• tasks have usable acceptance criteria
• spec, plan, and tasks link to each other
• progress can be reported without rereading the whole spec

References and examples

• reference/ — parsing patterns, plan/task templates, progress cadence (e.g., spec-parsing.md, standard-implementation-plan.md, task-creation.md, progress-tracking.md).
• examples/ — end-to-end walkthroughs (e.g., ui-component.md, api-feature.md, database-migration.md).