Tuskway vs specs in the repo
Spec-driven development, for the whole team.
Tools like GitHub Spec Kit and Kiro made spec-driven development popular: write the requirements, the design and the tasks before the agent codes. They keep those specs as markdown files in your repository. That works for one developer on one branch. Tuskway takes the same idea to a team.
Side by side
Tuskway vs specs in the repo
| specs in the repo | Tuskway | |
|---|---|---|
| Where the spec lives | Markdown files in the repository, on a branch. | In Tuskway, outside any branch, reachable from every tool over MCP. |
| Collaboration | Pull request review of the files. | Line comments, suggestions and editor approval on the spec itself. |
| Reaching every agent | Read from the files in whichever checkout an agent has open. | Read from one shared place by every agent, whatever branch or tool it runs in. |
| Tickets | A task list in a file. | Ticket briefs with dependencies, published to GitHub Issues, GitLab, Linear or Jira. |
| Parallel work | Up to you. | Tuskway shows which tickets are ready and which would touch the same files. |
Choose specs in the repo when
You work alone, on one repository, in one tool, and want the spec versioned with the code.
Choose Tuskway when
A team builds the feature, with different agents, and the spec needs review before anyone codes.
Is Tuskway spec-driven development?
Yes. The workflow is context, then design, then tickets, then code, with people reviewing the spec before the build.
Can I move an existing spec into Tuskway?
Yes. Ask your agent to run /start-epic with the existing files as context, then /write-design to split the design into sections.
Try the team version of spec-driven development.
Connect your agents, run /start-epic on your next feature, and review the plan before anyone writes the code.