Skip to content
SpecifyDocs

Workflows

Connect planning changes to development with MCP

Plans change, but development uses an old copy. Keep requirements in a shared Specify document and reread it through MCP in Claude Code or Codex. Align changed conditions with implementation plans and tests.

If requirements change after a meeting while developers still implement an older copy, use MCP to read the shared Specify planning document.

When this is your problem

Requirements change in meetings and messages while developers work from an earlier copy or agent conversation. Even one cancellation rule can require coordinated changes to screens, APIs, and tests.

Solve it with Specify

  1. The planner records current rules, change reasons, and acceptance criteria in one Specify document.
  2. The developer asks Claude Code or Codex to read it through MCP and compare it with code to prepare an implementation plan.
  3. After a planning change, reread the same body and record implementation results and remaining questions in a development review document.

What you get

Organize requirements-to-code gaps, tasks and tests for changed acceptance criteria, and open questions in shared team context. Planners stay in Specify while developers work in their code editor.

Planning and development use the same document

Imagine a team building a booking service. The planner writes the screen flow, cancellation rules, exceptions, and acceptance criteria in a “Booking cancellation” document. The developer asks the coding agent to read it and compare it with the code. When requirements change, reread the same document to update implementation plans.

RoleWhere they workWhat they leave
Planner or PMSpecify editorCurrent requirements, confirmed decisions, open questions, and acceptance criteria
DeveloperClaude Code or Codex and the code editorRequirements-to-code gaps, implementation plans, code, and tests
TeamThe shared Specify document and a separate review documentReasons for changes, development checks, implementation results, and remaining questions

Before you start

  • Both planner and developer need access to the document in the same workspace.
  • Connect Specify MCP to Claude Code or Codex using Connect an editor or agent.
  • Start with read access to reference requirements. Write access is also needed to record implementation results in Specify.

From requirements to implementation

  1. The planner organizes the document. Separate the purpose, screen flow, confirmed rules, exceptions, and acceptance criteria. Leave unresolved items as questions.
  2. The developer reads the source through MCP. Find the document with search or browse, then read its body with read_document. Providing the exact document name helps.
  3. The agent compares requirements with code. Separate implemented items, changes needed, and questions for the owner, then prepare an implementation plan.
  4. The planner records agreed changes in the same document. Include the new conditions and reasons, and distinguish current rules from previous ones.
  5. The developer rereads the changed document. Compare it with the earlier content and identify code and test impacts before continuing.
  6. Return development checks to the document workflow. With write access, use create_document for a separate review or update_document for an agreed section. The planner reviews this to resolve remaining decisions.

Example: rereading changed requirements

The following is an example for a booking service.

ItemInitial planAgreed change
Cancellation cutoff24 hours before the booking12 hours before the booking
Unavailable cancellation UIHide the cancel buttonShow a disabled button with a reason
Acceptance criteriaCheck whether cancellation is allowedAlso test the time boundary and disabled-state explanation

After a change, ask the agent to reread the same document rather than continuing from previously copied conditions. It can identify API rules, screen states, and tests that need changes together.

Specify supports real-time collaborative editing. Coding agents read documents reflected on the server when they call MCP. Changes are not automatically pushed into an ongoing agent conversation, so request another body read after a change. If you know the document ID, read_document can read it directly without waiting for search indexing.

Prompts to copy

When preparing the first implementation plan

Find “Booking cancellation requirements” through Specify MCP and read the body. Separate confirmed requirements from open questions, compare them with the current code, and list an implementation plan and tests for each acceptance criterion. Leave policies not stated in the document as questions.

After requirements change

Reread the same planning document through MCP. Compare it with what you read earlier, summarize changed conditions, and identify impacts on the code and tests in progress. Check behavior that needs to change in already implemented parts too.

When sharing development results

Create a separate development review document in Specify. Include the planning source, requirements implemented, tests checked, and unresolved decisions. Leave the confirmed planning document body intact.

Collaboration checks

  • Separate confirmed decisions from proposals. Keep developer suggestions separate until the planner decides.
  • Keep the document name and ID. Rereading the same document helps avoid implementing from duplicate copies.
  • Reread before important changes. Check the current body before implementation, after requirements change, and before final review.
  • Review requirements and implementation together. Screens, APIs, exceptions, and tests should follow the same acceptance criteria.

See MCP tools for available tools and inputs.