Your agent reads the accepted spec over MCP. A human says yes to every change. The pull request is checked against that exact version — with evidence from CI, not the agent's word.
Free for one developer · no token metering · EU-hosted · your code never leaves GitHub.
/plugin marketplace add SpeckyContractCheck/specky-plugin /plugin install specky@specky /specky:init
Requirements live in a chat history, a stale spec.md, or the last prompt someone remembered. Every new session starts from whatever it finds.
The agent "clarified" the requirement with itself. A month later nobody can say who accepted what, when, or in which version.
Agent pull requests arrive bigger and faster than anyone can review. "Done" is the agent's word, not a fact checked against the criteria.
84% of agent-authored pull requests get no human review at all — or are reviewed only by other agents.
33,596 pull requests, arXiv 2605.02273, 2026.
Five moments from one session. Press play or pick a step. Nothing here calls a model.
01M3…EDK v1.0 "Mark a task as done" — accepted by Mario, 2026-09-24 · 2/3 criteria verified in CI · hash current
test_done_task_moves_to_bottom passed in CI (4f1c9a2)test_done_task_strikethrough passed in CI (4f1c9a2)specky: crit marker01M3…EDK — hash stale: you built against 7b2d0e4 (v1.0), current is a9f3e1c (v1.1)get_work_queue → drift_after_code_ready. The agent's next session starts there.The spec is not a document you write once. It is the record the agent reads every session — and the thing the PR is checked against.
Every requirement carries acceptance criteria, a version and a content hash. The agent reads the current state over MCP — never a chat history — and a new session asks only what_changed.
One source of truth, served to the agent, readable by humans.
New requirement, reworded criterion, deprecation — all arrive as proposals. You decide in the conversation or in the web app; Specky records who, when and which version. Done, to-fix, collisions and open questions are human decisions too.
Attribution by construction. No "the AI decided" in the history.
Tests marked with the criterion they cover, a commit trailer with the hash, a GitHub App that reads the JUnit report from CI. Per criterion: passed in CI, waiting, agent's word only, confirmed manually, failing.
A status, not a gate. Blocking is up to your branch protection.
A requirement changed after code_ready, a failing check, a criterion edited after its test passed, a requirement untouched for 60 days — each lands in the work queue with a reason. Contradictions between requirements arrive with a suggested clarification.
Specky knows what stopped matching. Before the reviewer has to.
Your agent gets a spec it cannot misread and a queue it cannot forget. You get a record of every yes you gave.
One record of what was accepted, by whom and in which version — readable by the people who build and the people who pay for it.
Markdown in the repo is the right place for conventions — /specky:init writes there itself. Spec Kit and Kiro write the spec. Specky is for what happens after: versions, owners, drift, proof.
| CLAUDE.md · spec.md | Spec Kit · Kiro | Jira · Linear | Specky | |
|---|---|---|---|---|
| Agent reads the current spec | yes — as a file | yes — as files | yes — via MCP | yes — current state + delta since last session |
| Criteria with version and content hash | git history only | git history only | no | yes — v2.1 @a9f3e1c per requirement |
| Human acceptance with attribution | no | review gate, by convention | status change | yes — who, when, which version; agents can't self-accept |
| Drift after the code was declared ready | no | no — specs are static | no | yes — back in the agent's work queue |
| CI evidence per criterion on the PR | no | no | add-ons | yes — GitHub App status and comment |
| Works with any agent | yes | Kiro: its own IDE | yes | yes — MCP; plugin for Claude Code |
Specky doesn't replace your tracker, your IDE or your repo files — it is the contract between the agent and the people who accept the work.
Specky writes no code and stores none. The GitHub App reads pull request metadata, the specky: crit markers in your tests and the CI results — it keeps the verdict, not your repository.
No model in the loop. Reading, proposing, accepting and checking are deterministic. The one optional model call, the spec review, runs on your own key (BYOK) or a small included pool — never trained on.
Hosted in the EU (Hetzner), under GDPR, with a full change history per requirement. Export everything as Markdown at any time.
Free for one developer. Team €12 per seat per month. No card to start.