Toolkit to help you get started with Spec-Driven Development

You can use the Specify CLI to bootstrap your project, which will bring in the required artifacts in your environment. Run:

Or initialize in the current directory:

You will be prompted to select the AI agent you are using. You can also proactively specify it directly in the terminal:

The CLI will check if you have Claude Code, Gemini CLI, Cursor CLI, Qwen CLI, opencode, Codex CLI, or Amazon Q Developer CLI installed. If you do not, or you prefer to get the templates without checking for the right tools, use --ignore-agent-tools with your command:

Go to the project folder and run your AI agent. In our example, we're using claude.

You will know that things are configured correctly if you see the /speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, and /speckit.implement commands available.

The first step should be establishing your project's governing principles using the /speckit.constitution command. This helps ensure consistent decision-making throughout all subsequent development phases:

This step creates or updates the .specify/memory/constitution.md file with your project's foundational guidelines that the AI agent will reference during specification, planning, and implementation phases.

With your project principles established, you can now create the functional specifications. Use the /speckit.specify command and then provide the concrete requirements for the project you want to develop.

[!IMPORTANT] Be as explicit as possible about what you are trying to build and why. Do not focus on the tech stack at this point.

An example prompt:

After this prompt is entered, you should see Claude Code kick off the planning and spec drafting process. Claude Code will also trigger some of the built-in scripts to set up the repository.

Once this step is completed, you should have a new branch created (e.g., 001-create-taskify), as well as a new specification in the specs/001-create-taskify directory.

The produced specification should contain a set of user stories and functional requirements, as defined in the template.

At this stage, your project folder contents should resemble the following:

With the baseline specification created, you can go ahead and clarify any of the requirements that were not captured properly within the first shot attempt.

You should run the structured clarification workflow before creating a technical plan to reduce rework downstream.

Preferred order:

Use /speckit.clarify (structured) – sequential, coverage-based questioning that records answers in a Clarifications section. Optionally follow up with ad-hoc free-form refinement if something still feels vague.

If you intentionally want to skip clarification (e.g., spike or exploratory prototype), explicitly state that so the agent doesn't block on missing clarifications.

Example free-form refinement prompt (after /speckit.clarify if still needed):

You should also ask Claude Code to validate the Review & Acceptance Checklist, checking off the things that are validated/pass the requirements, and leave the ones that are not unchecked. The following prompt can be used:

It's important to use the interaction with Claude Code as an opportunity to clarify and ask questions around the specification - do not treat its first attempt as final.

You can now be specific about the tech stack and other technical requirements. You can use the /speckit.plan command that is built into the project template with a prompt like this:

The output of this step will include a number of implementation detail documents, with your directory tree resembling this:

Check the research.md document to ensure that the right tech stack is used, based on your instructions. You can ask Claude Code to refine it if any of the components stand out, or even have it check the locally-installed version of the platform/framework you want to use (e.g., .NET).

Additionally, you might want to ask Claude Code to research details about the chosen tech stack if it's something that is rapidly changing (e.g., .NET Aspire, JS frameworks), with a prompt like this:

During this process, you might find that Claude Code gets stuck researching the wrong thing - you can help nudge it in the right direction with a prompt like this:

Claude Code might be over-eager and add components that you did not ask for. Ask it to clarify the rationale and the source of the change.

With the plan in place, you should have Claude Code run through it to make sure that there are no missing pieces. You can use a prompt like this:

This helps refine the implementation plan and helps you avoid potential blind spots that Claude Code missed in its planning cycle. Once the initial refinement pass is complete, ask Claude Code to go through the checklist once more before you can get to the implementation.

You can also ask Claude Code (if you have the GitHub CLI installed) to go ahead and create a pull request from your current branch to main with a detailed description, to make sure that the effort is properly tracked.

Before you have the agent implement it, it's also worth prompting Claude Code to cross-check the details to see if there are any over-engineered pieces (remember - it can be over-eager). If over-engineered components or decisions exist, you can ask Claude Code to resolve them. Ensure that Claude Code follows the constitution as the foundational piece that it must adhere to when establishing the plan.

With the implementation plan validated, you can now break down the plan into specific, actionable tasks that can be executed in the correct order. Use the /speckit.tasks command to automatically generate a detailed task breakdown from your implementation plan:

This step creates a tasks.md file in your feature specification directory that contains:

Task breakdown organized by user story - Each user story becomes a separate implementation phase with its own set of tasks Dependency management - Tasks are ordered to respect dependencies between components (e.g., models before services, services before endpoints) Parallel execution markers - Tasks that can run in parallel are marked with [P] to optimize development workflow File path specifications - Each task includes the exact file paths where implementation should occur Test-driven development structure - If tests are requested, test tasks are included and ordered to be written before implementation Checkpoint validation - Each user story phase includes checkpoints to validate independent functionality

The generated tasks.md provides a clear roadmap for the /speckit.implement command, ensuring systematic implementation that maintains code quality and allows for incremental delivery of user stories.

Once ready, use the /speckit.implement command to execute your implementation plan:

The /speckit.implement command will:

Validate that all prerequisites are in place (constitution, spec, plan, and tasks) Parse the task breakdown from tasks.md Execute tasks in the correct order, respecting dependencies and parallel execution markers Follow the TDD approach defined in your task plan Provide progress updates and handle errors appropriately

[!IMPORTANT] The AI agent will execute local CLI commands (such as dotnet, npm, etc.) - make sure you have the required tools installed on your machine.

Once the implementation is complete, test the application and resolve any runtime errors that may not be visible in CLI logs (e.g., browser console errors). You can copy and paste such errors back to your AI agent for resolution.

Post a Comment

Previous Post Next Post