Agentic Spec-Driven Development: a contribution pipeline for software built with AI agents. Every change disclosed, gated by hard checks, reviewed against its spec, and merged by a named human.
Agent
Role. Correctness review under human direction. Recommends; never approves a merge on its own. Scope. Logic, edge cases, error handling, API contracts, and conformance to the de-slop standards. Identity. Runs as a named agent identity with a read-only token. Output is advisory data.
Agent
Role. Read a submitted change and propose concrete fixes to the contributor as review suggestions. The contributor accepts or rejects each one; the job is to bring the change to "ready". Advisory: it never gates and never merges. This is the contributor-facing half of ASDD's two review roles (spec-driven §RR)…
Agent
Role. Classifies every change by its effect on the framework itself. Recommends; never merges. Scope. Two questions the other lenses do not ask: does this change the nature of the framework (its normative text or the behaviour adopters rely on for their conformance claim), and if so, is it sized and versioned…
Agent
Role. The last check before merge, run by an agent that did not build the change and does not see the builder's context. It confirms the review lenses and gates were satisfied and returns a merge verdict. Advisory by default: a human approves and merges. It never authors code. Scope. The assembled evidence for one PR…
Agent
Role. The adversarial cross-check. Its explicit job is to refute "looks good," not confirm it. It exists because of two documented failures: agent contributions add redundancy and tech-debt, and reviewers (human and agent) feel better approving agent code, so they rubber-stamp it. Scope. Net complexity, duplication…
Agent
Role. Security review and malicious-contribution screen. This lens gates, it never decides - a block here holds the merge until a human resolves it; it does not by itself approve anything. Scope. Vulnerabilities in the change, dependency/supply-chain risk, and prompt-injection attempts in the contribution itself.
Agent
Role. Checks the change against the project's stated spec and architecture. Recommends; never merges. Scope. Does the change match the issue/spec it claims to implement, and does it fit the architecture (boundaries, layering, established patterns) rather than working around it?
Agent
Role. Answer contributor and user questions from the project's own docs, wiki, and prior issues, the project pointed at itself. Discloses it is an agent and escalates to a human when it is unsure. Scope. Question answering and pointing to docs. It does not change code, make commitments, or decide policy.
Agent
Role. Label and route incoming issues, welcome first-time contributors, and nudge good-first-issues. Advisory and reversible: it applies labels from a fixed allow-list and posts welcomes; it does not close, prioritise, or speak for maintainers. It does not schedule or run real-time venues (Discord, office hours…
Agent
This is the Spec step (step 1 of the five). It is distinct from Intake (step 3), the deterministic PR-admission gate: this agent develops a spec in conversation; the intake gate later checks that a submitted PR carries one. Reserve "intake" for that gate; this is the spec agent.
Agent
Role. Connect a project to an inbound listener on any channel (GitHub, Slack, Discord, web, and community bindings) as a two-way surface: answer from the project's own knowledge, like the support agent, AND route ideas and reports from the platform into the project's governed contribution intake. Discloses it is an…
Agent
ASDD is a standard, so it cannot mandate a model. The runtime, what actually reads a diff and produces a review, is pluggable. The reference workflows call a thin adapter; you choose which one. This neutrality is what lets ASDD be a standard rather than one vendor's tool.