A finished specification still needs to become work someone can execute. notion-spec-to-implementation extracts requirements, acceptance criteria and constraints, then creates a plan and tasks linked back to the source. It is useful for preparing a project and keeping its delivery status understandable afterward.
Install and prepare
This guide covers the standalone Skill retained in openai/skills. That repository is deprecated and current examples have moved to openai/plugins; the instructions here describe the linked standalone version, not the latest plugin.
Enter this line in the Codex conversation, not a terminal. If the installed Skill does not appear, restart Codex.
$skill-installer notion-spec-to-implementation
- Local Codex with an available Notion MCP connection
- A Notion workspace authorized through OAuth
- Access and editing permission for the destination page or database
If no connection exists, add the following to ~/.codex/config.toml, then run codex mcp login notion in the terminal and complete OAuth. Current Notion documentation does not require the old Skill’s rmcp_client flag. Reuse an existing working connection instead of configuring it twice. [4]
[mcp_servers.notion]
url = "https://mcp.notion.com/mcp"
Try a first task
Replace the destination Notion links, then start with:
$notion-spec-to-implementation
Turn this PRD [paste URL] into an implementation plan. Task database: [paste URL]. First list requirements, acceptance criteria, dependencies and open questions. Aim for tasks around one or two days of work, with estimates labeled as suggestions. Preview the plan and task list before creating linked records. Do not invent assignees or deadlines.
Work through the task
-
Read the specification. Extract requirements, priorities, acceptance criteria and constraints. Surface ambiguous points before converting them into implementation assumptions.
-
Sequence phases and tasks. Use a short plan for a small change and phases for work across systems. Give each task a goal, inputs, acceptance criteria and dependencies.
-
Create and maintain the links. Inspect the real task schema before writing records. Link specification, plan and tasks, then update status and blockers from actual progress.
Move from a PRD page to executable tasks
Provide the exact Notion spec link and destination task database rather than saying “break this down.” A useful request is: “Turn this user-export PRD into an implementation plan. Read acceptance criteria, permissions and failure states first. List missing decisions for my confirmation. Then split work into tasks of roughly one or two days and link them to the PRD.” If search returns multiple specs with the same name, compare project and revision date before planning from one.
The plan should state phase order, cross-team dependencies and migration or rollback points. Each task needs an action verb, scope, input, acceptance criteria and upstream dependencies. “Export CSV” is not a complete task: specify who may trigger it, maximum volume, field format, user-visible failure state and how permission boundaries will be tested. An estimate is a starting point for discussion, not a team commitment.
Check Notion relations after creation
Open the spec, plan and a few tasks to confirm that links or relation properties point to the intended records. Status and assignee should not be invented. On subsequent runs, update task states from actual code progress rather than assumptions made when the plan was drafted. A completed plan is not a shipped feature.
Check the result
You should be able to trace a requirement to its tasks and a task back to its acceptance criteria. Review ordering, duplicates and unassigned work. A completed status needs a real deliverable; generating the plan does not complete implementation.
Common blockers
The PRD lacks acceptance criteria. Define observable success before scheduling the work.
Database fields do not match. Use current destination properties, including status options and relations, instead of copying an assumed template.
Tasks are too small or too broad. Group them around independently checkable outcomes. The Skill’s one-to-two-day guidance is a sizing aid, not a delivery promise.
Choose an existing plan template
Choose a quick or standard implementation plan based on change size and dependencies. If an older example points to a missing reference/templates.md, open the shipped quick-implementation-plan.md or standard-implementation-plan.md. Every task should trace back to an acceptance condition in the spec and name unresolved dependencies.