返回资讯中心
外部精选
软件工程
#开发者实时流

Show HN: Specification First Agentic Development Plugin and Prove

Implemented agent smith since start 2026 with over 1000 specifications which lead to about 500k lines of code. The procedure with that spec-first works well. How do you do it?

Hacker News 最新hleichsenring2026/10/27 · 今天19 分钟阅读

以下正文同步自 Hacker News 最新,版权归原站所有,已转换为易读排版。

This is how Agent Smith is built every day, across more than a thousand specs.

A fresh reviewer checks the spec against the code before the build. A gate runs your checks before the commit.

One branch and worktree per spec. Ids come from the clock, so two agents never take the same one.

A reviewed spec has already answered the open questions, so the agent builds to its done criteria instead of coming back to ask.

One spec, one branch, one commit. A pull request carries one spec or a whole series, and every change has the same shape.

State lives in context.yaml. Restart the machine or the agent and the work picks up where it stopped.

Each choice is logged with what it beat and why, so the reasoning stays next to the code.

Cut a bigger change into a series of specs. /spec-first:deliver-series reviews all of them, builds the groups that share no file at the same time, verifies the merged tree and opens one pull request.

3 worktrees building in parallel · every spec commit through the gate

An example run of /spec-first:deliver-series. Specs that share no file are built at the same time; specs that depend on each other share a group.

Four skills take a piece of work through its own branch and worktree. Each one leaves a file behind for the next step and for whoever reads the history later.

Goal, steps, facts with file and line, what done means. No code yet.

Every citation resolved, then a reviewer who never saw the chat attacks it.

Contracts, code, wiring, tests, following the project's own rules.

One commit through the gate, pushed, pull request opened.

Every spec, from planned to done, with its facts and done criteria.

What each spec chose, what it chose over, and why.

What you told the agent once, so you don't say it twice.

/spec-first:bootstrap-project writes the contexts once from your code: stack, rules and the checks a commit must pass. After that, each spec adds one line of state.

A REFUSE costs you one spec. Without the review, the same mistake would have cost you the branch.

Ticket providers so pipelines can pull work from GitHub and Jira.

Adapter over repository: read-mostly data, no unit of work needed.

Step jira needs a second auth mode the config can't hold yet. AppConfig.cs:15 Move it to its own spec.

Paging is missing: GitHub returns 30 issues per page. GitHubClient.cs:88 Add a done criterion.

A script opens each file and line the spec cites. A claim nobody checked in the code has to be listed as an assumption.

A new agent with no conversation history reads the code as it is, not as the spec says it is.

BUILD, BUILD WITH CUTS or REFUSE, and every finding names a file and a line.

Nobody has to write documentation afterwards. While it builds, the agent logs each choice that wasn't obvious: what it chose, what it chose over, and why. One file per spec, next to the code.

spec: 2026-10-27-8a3f decisions:

  • category: TradeOff chose: "Raw HttpClient for the GitHub API" over: "Octokit" reason: "Three megabytes of dependencies for four calls."
  • category: Architecture chose: "One ITicketProvider per tracker" over: "A generic REST mapper" reason: "Each tracker pages and authenticates differently; the mapper would leak it."

No wiki to keep alive

cat decisions/*.yaml is the project's reasoning, spec by spec, in the same history as the code it explains.

How the operator wants things done, a constraint outside the repo, a pointer elsewhere. One fact per file, one line in an index.

Restart the machine, restart the agent, open context.yaml. It knows what is done, what is active and what comes next.

The plugin's commit gate runs every verify stage your contexts declare when a commit names its spec. All green, it commits. The first red stage blocks it, and its output goes back to the agent.

git commit -m "feat: ticket providers (2026-10-27-8a3f)"

The id in parentheses triggers it. -F <file>, -C and --amend --no-edit are gated too.

the first red stage stops it, and its output goes back to the agent

A spec commit with no line in the ledger never met the gate. A project with its own gate says gate: project, and the plugin steps aside.

The open source agentic software factory: a ticket goes in, a verified pull request comes out. Agent Smith is entirely built with this method, and the method grew out of building it. Everything in the plugin ran there first.

In Claude Code the plugin does the bookkeeping and runs the gate. Other agents follow the same files through AGENTS.md, and a git hook runs the same gate.

Then run /spec-first:bootstrap-project. It reads your code and writes the contexts and rules from what it finds.

Paste this into Codex, Cursor, Copilot or any agent that can read and write your repository.

Set up specification-first agentic development in this repository, following the templates at https://github.com/holgerleichsenring/specification-first-agentic-development/tree/main/templates

  1. Create .{project}/contexts/default/context.yaml and coding-principles.md. Fill them from the code as it is: stack, architecture, limits, conventions, and the commands that build and test it as verify: stages. Invent nothing.
  2. Create .{project}/specs/planned, active and done, .{project}/decisions/ and .{project}/memory/MEMORY.md.
  3. Write AGENTS.md from templates/prompt.md, with .{project}/ filled in.
  4. Add "gate: git" at the top level of that context.yaml.

Copy prompt

AGENTS.md carries the method

Codex, Cursor and Copilot read AGENTS.md when a session starts. It holds the read order and the workflow, and every step says how to do it by hand, the review brief for a fresh session included.

Clone the spec-first repository once, then run python3 <clone>/hooks/install-git-hook.py in each clone of your project. The commit-msg hook runs your verify: stages on every commit that names a spec, from any agent or the terminal. git commit --no-verify skips it. The evidence check is skills/review-spec/scripts/check-evidence.py in the same clone and needs PyYAML.

Specification-driven agentic development, in short answers.

A way of working with AI coding agents in which every change starts as a written spec in your repository. A fresh reviewer checks the spec against your code before anything is built, the agent builds it on its own branch and worktree, and the commit lands only when your checks pass.

The spec drives the work from start to finish. It names the goal, the facts it rests on with file and line, the steps and the done criteria, and the agent builds to exactly that. Spec-first agentic development is specification-driven agentic development in which the spec is reviewed against the code before the first line is written.

No. The Claude Code plugin runs the steps as commands. Codex, Cursor, Copilot or a terminal follow the same files through AGENTS.md, and a git commit-msg hook runs the same commit gate in every clone where it is installed.

You still describe the feature in your own words and talk it through. After that, the agent works from a reviewed spec instead of from the last prompt, logs each decision with its reason, and a commit lands only when your build and tests pass.

A one-sentence goal, the facts it rests on with file and line, the steps, what an upgrade costs an operator, and the done criteria. The decisions made while building go into a separate YAML file next to it.

Nothing. The method, the templates and the Claude Code plugin are MIT licensed.

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →