Spec-Kit is a set of slash commands built into every Relipa Kanban workspace. It applies Spec-Driven Development (SDD): write the specification, plan and task list before the AI agent writes any code. The goal: turn the agent from a “code typist” into a “controlled architect” — clear inputs, in-scope changes, easy review, easy acceptance.

​
Why Spec-Kit

When you let an AI agent code without a spec, the usual problems show up:
  • Vague requirements → the agent guesses your intent.
  • The agent edits files outside the requested scope.
  • Code runs but doesn’t match the business rules.
  • Reviewers face thousand-line diffs with no context.
  • Tests aren’t tied to acceptance criteria.
Spec-Kit fixes this by enforcing a pipeline: spec → clarify → plan → tasks → implement → review.

​
Old way vs Spec-Kit

Old way (“vibe coding”)With Spec-Kit
Short prompt → AI generates code → patch by handDetailed spec → AI plans → splits tasks → AI implements
Code is the documentationSpec, plan, tasks are the documentation — code is output
Change a requirement = patch the codeChange a requirement = patch the spec, code is regenerated
Review a 1000-line dumpReview small tasks one at a time, against the spec

​
The 7-step workflow

Each feature goes through seven stages, each tied to a slash command. Don’t skip steps.
1

Set principles

/speckit.constitution — Define the project’s guiding rules (code quality, testing, UX, performance, security). Run once per project.
2

Describe requirements

/speckit.specify — Write the what and why (no tech yet). Output: spec.md.
3

Clarify

/speckit.clarify — Structured Q&A about ambiguous spots in the spec. Strongly recommended before planning.
4

Technical plan

/speckit.plan — Decide tech stack, architecture, data model, API contracts. Output: plan.md, research.md, data-model.md, contracts/.
5

Split tasks

/speckit.tasks — Generate an ordered list of small, reviewable tasks. Output: tasks.md.
6

Generate test cases

/speckit.testcase — Produce concrete test scenarios (precondition, input, expected output, pass criteria) linked to each SubTask, so the agent can verify itself during implementation. Output: testcase.md.
7

Implement

/speckit.implement — The agent reads tasks and test cases, writes code phase by phase, with self-testing and self-correction.

​
Slash commands

​
Core commands

CommandWhat it doesOutput
/speckit.constitutionSet project principles and dev guidelines.specify/memory/constitution.md
/speckit.specifyDefine requirements and user stories (what & why)spec.md
/speckit.planBuild the technical implementation planplan.md + supporting docs
/speckit.tasksProduce the actionable task listtasks.md
/speckit.testcaseGenerate concrete test cases used to verify implementationtestcase.md (or under checklists/)
/speckit.taskstoissuesPush the task list to GitHub IssuesGitHub Issues
/speckit.implementExecute the tasks to build the feature(actual code)

​
Optional commands

CommandWhen to use
/speckit.clarifyBefore /speckit.plan — clear up underspecified areas in the spec
/speckit.analyzeAfter /speckit.tasks, before /speckit.implement — check consistency across spec, plan, tasks
/speckit.checklistGenerate a custom quality checklist to validate requirements

Per-command guide

Prompt templates, filled-in examples, common mistakes and safety mechanisms for each command.

​
Spec-Kit in the workspace UI

Creating a workspace automatically scaffolds the Spec-Kit Markdown templates (spec.md, plan.md, tasks.md…) under .specify/. When the agent runs a Spec-Kit command, the system shows a Plan Panel with:
  • Context — what the agent is working on.
  • Target File — the file that will be created or updated.
  • Plan content — what the agent intends to write.
You have two choices before the agent acts:
  • Approve — accept the plan and let the agent proceed.
  • Request Changes — type feedback so the agent revises the plan first.

​
Parse Markdown into Spec-Kit

Once the agent finishes a file (tasks.md, checklist.md…), push its contents into the database so the system can track progress as SubTasks and TestCases.
1

Verify the file

Open the Markdown file the agent just produced and make sure it looks right.
2

Click Parse

In the SpecKit Panel (next to the file name), click Parse to DB.
3

Two-tier backend processing

  • Tier 1 — Regex (0 tokens): looks for markers like [T001], [TC-001], CHK-001. With ≥3 markers, it parses directly.
  • Tier 2 — AI fallback: if there aren’t enough markers, the backend calls an AI to extract JSON from the file.
4

UI updates

The backend stores SubTasks and TestCases against the workspace’s Plan, then pushes an SSE event so the UI refreshes automatically.
Clicking Parse to DB multiple times on the same file is safe — the system clears old data and recreates it (idempotent).

​
Plan and SubTask states

Plan:
StateMeaning
draftSpec is being written, not yet executing
implementingAgent is running the implement loop
doneAll SubTasks are complete
SubTask:
StateMeaningUI color
pendingNot startedGray
in_progressAgent is working on itBlue
completedDoneGreen
blockedStuck, needs interventionRed
skippedSkippedYellow

​
Safety mechanisms

When /speckit.implement runs, the system drives the agent in incremental execution mode: only 1–2 SubTasks per round, run unit tests, only move on when tests pass.
  • implement_max_loops — At most 5 self-correction attempts per SubTask (default). Beyond that the agent reports BLOCKED and stops instead of looping forever.
  • [?] marker — If the agent doesn’t have enough information, it leaves a [?] note in the Markdown rather than guessing.

​
Standard team checklist

Apply this for every new feature: Before you start
  • New branch off main.
  • Read constitution.md — know the project rules.
  • PRD/requirement from PM in hand (don’t make it up).
Specify stage
  • Run /speckit.specify with all 5 blocks (context → users → journey → requirements → success criteria).
  • No tech-stack mentions.
  • Run /speckit.clarify, answer every question.
  • Commit spec.md.
Plan stage
  • Run /speckit.plan with all 5 blocks (tech → architecture → integrations → non-functional → conventions).
  • Audit the plan for over-engineering.
  • Read research.md, data-model.md, contracts/ — sanity check.
  • Commit the plan files.
Tasks & Test cases stage
  • Run /speckit.tasks.
  • Run /speckit.testcase to generate verification test cases per SubTask.
  • Run /speckit.analyze to check consistency.
  • Click Parse to DB on both tasks.md and testcase.md after review.
Implement stage
  • Run /speckit.implement phase by phase (one user story at a time).
  • After each phase: run the app, hit the checkpoint manually.
  • Commit per phase, don’t batch.
  • Hand runtime errors back to the AI; don’t hand-fix unless necessary.
  • Open a PR that references spec.md and plan.md.
After merge
  • Keep specs/<feature>/ — it’s the “why” doc for whoever joins next.
  • Need a change? Edit the spec first, not the code directly.

​
Next

Per-command guide

Prompt templates, filled examples and common mistakes for each slash command.

Create a workspace

Spin up a workspace where you can run Spec-Kit commands for a feature.