Spec2Code
Turn a messy PRD into work a coding agent can actually sequence: unresolved questions, dependency-aware tasks, complexity, likely files, acceptance criteria, and optional GitHub issue drafts.
What goes in
Paste a PRD, feature spec, bug report, user story, or a Markdown or text export from Notion. If all you provide is a private Notion URL, the workflow asks for the page content instead of pretending it can read it.
- Product goal, actors, triggers, outcomes, constraints, and non-goals.
- Functional and non-functional requirements.
- Existing architecture or file-path context when you have it.
- Known integrations, data, authorization, migration, and release constraints.
What comes out
- Scope summary: goal, confirmed requirements, assumptions, and explicit non-goals.
- Ambiguity queue: vague terms such as “fast,” “secure,” or “integrates with Notion” translated into questions that can be answered before coding.
- Task matrix: task ID, dependency, Small/Medium/Large complexity, likely files, and an observable acceptance criterion.
- Suggested sequence: foundational contracts, data, auth, permissions, implementation, negative paths, and verification in dependency order.
- Optional issue drafts: one reviewable title and body per task, ready for GitHub only after you approve them.
It plans around dependencies, not document order
A PRD often describes the screen before the data model, the happy path before permissions, and the launch before failure handling. Spec2Code reorders work around technical prerequisites: schema before persistence, API contract before client integration, authorization before admin or sharing controls, implementation before integration tests, and instrumentation before relying on a dashboard.
That sequence is a proposal. The workflow labels inferred dependencies and leaves unresolved product or architecture choices visible for a human decision.
Acceptance criteria must be observable
Each task is expected to state something a reviewer can check: an authorized user can complete an action, an unauthorized user is denied server-side, invalid input returns the declared error, state survives reload, or a migration can be applied and reversed in the intended environment.
“Build the dashboard” is not a completion test. “An authenticated organization member can load the dashboard; another organization’s member receives no rows; empty and failed requests render defined states” is.
GitHub issue creation stays behind confirmation
The core planning pass is offline and does not need GitHub. If you request issue creation, Spec2Code first shows the proposed issue set, repository target, labels, and commands. It may use gh issue create only after explicit confirmation. It does not commit, push, or perform destructive repository operations.
Permissions and data boundary
The marketplace declares terminal, file-read, and file-write access. Reading local files is optional when the spec is stored in the repo. Writing is optional when you ask to save a plan. Terminal access is optional and reserved for confirmed GitHub issue creation.
The documented workflow requires no browser, network, or environment-variable access for the core plan. Treat every permission prompt as a fresh decision and limit the working directory to the specification and repository you intend to plan.
Known limitations
The result is an engineering planning draft, not an executable proof or a sprint commitment. Dependencies, file paths, and estimates are inferred from the text and any repository context you provide. Private Notion pages require pasted or exported content; images, diagrams, and embedded databases are not parsed. Very long specs may need to be divided, and direct Jira, Linear, Asana, or Shortcut creation is not included.
Review unresolved questions and architecture choices before handing the plan to a coding agent. Verify each task in the actual codebase as it is implemented.
Start with a planning pass you can inspect
The PRD-to-implementation-plan guide shows the complete manual method: normalize scope, isolate ambiguities, form vertical tasks, map dependencies, write observable acceptance criteria, and preview GitHub issues before any external action.
Questions
What input can Spec2Code use?
It accepts pasted PRDs, feature specs, bug reports, user stories, and Markdown or text exports from Notion. It cannot claim access to a private Notion page unless that content is actually available.
What does the implementation plan contain?
The plan contains a goal and scope, ambiguities to resolve, task IDs, dependencies, Small/Medium/Large complexity, likely files, observable acceptance criteria, a suggested sequence, and optional GitHub issue drafts.
Does it create GitHub issues automatically?
No. It drafts the issues first and requires explicit confirmation before using the GitHub CLI to create them.
What access does Spec2Code need?
The core workflow can work offline with pasted text. File reads and writes are optional for local specs and saved plans. Terminal access is optional and used only for confirmed GitHub issue creation. The documented workflow does not require browser, network, or environment-variable access.
Are the complexity estimates delivery commitments?
No. Small, Medium, and Large describe implementation complexity and risk. They are not calendar commitments without team capacity, codebase maturity, and delivery constraints.
What are the main limitations?
Dependencies, file targets, and estimates are inferred and require engineering review. Private Notion pages need pasted or exported text, images and diagrams are not parsed, long specifications may need chunking, and Jira or Linear issue creation is not included.
Give the coding agent a plan it can verify.
Current price and purchase option are shown on Agensi. Review the declared permissions and complete package there before installation.
Get Spec2Code on Agensi