# Notion Spec To Implementation

> 用于把 Notion 规格转成计划、任务和进度跟踪。

- Skill: `seaworld008/notion-spec-to-implementation` (Agent Skill, multi-file: 19 files)
- Install (CLI): `npx skillmds add seaworld008/notion-spec-to-implementation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/seaworld008/notion-spec-to-implementation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: seaworld008 (https://skillmd.com/u/seaworld008)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/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:

```text
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`).

