Autonomous Requirements: unclear ticket → spec auto

Autonomous Requirements is the capability of AI agents to receive a vague or underspecified ticket - "add dark mode to the settings page" or "fix the slowness in the search endpoint" - and produce a structured specification before any implementation begins. The agent queries available context sources: the existing codebase structure, similar past tickets, relevant ADRs, the design system, performance benchmarks. It identifies ambiguities, lists the assumptions it would need to make, and produces a draft spec that a human can review, approve, and hand back to an implementation agent.

The problem this solves is the requirements gap that creates the most expensive rework in software development. Vague tickets get implemented according to the implementing engineer's interpretation. If that interpretation differs from the requester's intent, the work is wrong at the end, not the beginning. In human-only development, this gap is closed through conversations, clarifying questions, and incremental feedback. In agent-assisted development at scale, where dozens of agents may be working concurrently, manual clarification conversations become a bottleneck. Autonomous Requirements closes the gap automatically.

The quality of the generated spec depends directly on the quality of the Context Fabric available to the requirements agent. An agent with access to the codebase knowledge graph, the ADR repository, similar historical tickets, the design system documentation, and the current performance baseline can generate a specific, accurate spec. An agent with access only to the ticket description and the code it can read directly will generate a spec that misses critical constraints and context. Autonomous Requirements is the highest-leverage application of a mature Context Fabric.

At L4, the requirements generation process is established and trusted for well-scoped ticket types. Engineers have learned which kinds of tickets the agent specs well and which require more human involvement. The process is not yet fully autonomous - a human reviews and approves every generated spec before implementation begins - but the time from ticket creation to approved spec has dropped from days to hours, and the ambiguity rate in specs that enter implementation has fallen significantly.

By mid-2026, two trends made this capability more practical and more demanding at the same time. First, "skills" became the unit of reuse for agent behavior, and they are now shipped as official, versioned, governed packs - Apple (Xcode 27), NVIDIA (BioNeMo plus NVIDIA-Verified), Cloudflare, and Alpaca (June 17) all released them. A requirements agent built on maintained skill-packs produces more consistent specs, but those packs are assets that decay without maintenance, so the spec-generation discipline now includes versioning and ownership of the skills the agent relies on. Second, AI moved further up the lifecycle: a June 24 report on AI moving from code review to PRD governance describes Uber, DoorDash, and Cloudflare using AI to evaluate PRDs and specs before implementation begins. Autonomous Requirements sits exactly at this layer - the same context infrastructure that drafts a spec is increasingly used to govern whether the spec is good enough to build.

In August 2026 the packaging question got a vendor-neutral answer. Agent Plugins 1.0 was published on August 6 and announced in clients on August 12: an open standard that bundles agent skills and MCP servers into one installable plugin, governed independently of any single vendor, with AWS, Anysphere, Microsoft, OpenAI, Vercel and Google as core participants. For a requirements agent this collapses a real maintenance problem. The skills that teach it what a good spec looks like and the MCP servers that give it the codebase, the ADRs and the ticket history stop being two separately-versioned things configured per client, and become one artifact you write once and install in VS Code, Copilot CLI and other compatible clients. Packaging is not the hard part of this practice, but it is the part that decides whether the capability survives a tooling change.

What packaging does not solve is decay, and the corrective belongs in the same breath. Addy Osmani's audit of agent files (August 27) describes the accretion pattern exactly: teams add a rule or a skill every time an agent errs and never remove one. Across a hundred repositories he found lint leakage in 62%, context bloat in 42% and skill leakage in 35%, and his two most useful datapoints argue that the pruning is cheaper than it feels - Anthropic removed more than 80% of Claude Code's system prompt for Claude 5 with no measurable quality loss, and across 288 test runs context files changed efficiency rather than correctness. Personalised skills performed similarly to generic community ones. The practice that follows is a review cadence with an eviction rule attached: audit every few weeks, review memory separately from skills, and test whether performance actually declines after removal rather than assuming it will. Installing a useful skill and keeping it forever are separate decisions.

The eviction rule has a security half. The OWASP Agentic Skills Top 10 v1.0 landed on August 17 as the first framework covering the skill layer itself - SKILL.md, frontmatter, bundled scripts, the registry, inherited permissions - as AST01 through AST10, mapped to AISVS, NIST AI RMF and ISO 42001. It is grounded in a USENIX Security 2026 study of 98,380 marketplace skills that confirmed 157 malicious ones carrying 632 vulnerabilities, with 73.2% using shadow features absent from their documentation. Scanning will not save you here: on July 30 a single malicious skill passed all eight open-source skill scanners tested, including Cisco skill-scanner, NVIDIA SkillSpector, skillcheck, skillcop and claude-skill-antivirus, using base64 and gzip wrappers, Cyrillic homoglyphs, paraphrasing and runtime command reassembly, while on 4,000 benign skills six of those scanners flagged between 8.6% and 62.4%. Allowlist and pin the skills your requirements agent depends on; treat a scanner result as one weak signal rather than a gate.

• Vague tickets are the most expensive upstream defect - a requirement that is wrong or ambiguous when implementation begins will be wrong when implementation ends; catching and resolving ambiguity before coding starts is 10-100x cheaper than rework after coding ends
• Spec generation at scale is impossible manually - when dozens of agents are working concurrently, manually writing specs for each ticket is a bottleneck; autonomous requirements generation parallelizes spec creation with the same throughput as implementation
• Requirements agents surface constraints that humans miss - an agent querying the knowledge graph and ADR repository will identify architectural constraints, existing similar patterns, and performance requirements that a human ticket author did not think to include
• The generated spec is documentation - an auto-generated spec that is reviewed and approved by a human becomes the canonical record of what was intended, why it was designed as it was, and what alternatives were rejected; this is ADR-quality documentation produced as a side effect of the development process
• Spec quality measures knowledge infrastructure maturity - the quality of auto-generated specs is a direct proxy for the quality of the Context Fabric; poor specs indicate gaps in context coverage that affect all agent work, not just requirements generation

1. Define what a good spec looks like for your team - before automating spec generation, agree on what a complete spec contains: functional requirements, non-functional requirements (performance, security, accessibility), affected components, assumptions made explicit, alternatives considered and rejected, acceptance criteria. This template is the target for the requirements agent.

2. Select a pilot ticket type - choose a specific, recurring ticket category where ambiguity is the most common cause of rework: UI changes, API endpoint additions, database schema changes. Narrow scope improves the quality of the requirements agent's output and makes evaluation tractable.

3. Connect the requirements agent to all relevant context sources - the requirements agent should have access to the knowledge graph, ADR repository, design system, similar closed tickets, and performance benchmarks. The more context it has, the more specific and accurate its specs will be. This is the primary investment that enables Autonomous Requirements.

4. Evaluate generated specs against manual specs - for the first 20 tickets in the pilot, have a human write the spec first, then run the requirements agent, then compare. Identify the systematic gaps in the agent's specs. These gaps are context sources that need to be added to the Fabric or prompt improvements that make the agent more effective.

5. Establish a spec approval workflow - created a lightweight approval process: the requirements agent generates the spec, a product owner or senior engineer reviews it within one business day, ambiguities are resolved via comments, and the approved spec is attached to the ticket before implementation begins. Keep the approval step fast - the goal is hours, not days.

6. Track spec ambiguity rate as a quality metric - measure the percentage of implementation PRs that require changes because the spec was wrong or incomplete. This is your primary quality metric for the requirements process. It should decrease as the requirements agent improves and the Context Fabric matures.

7. Package the agent's skills and MCP servers as one installable unit - the requirements agent is a bundle: the skills that define what a good spec looks like, plus the MCP servers that supply codebase, ADR and ticket context. Ship them together as a single vendor-neutral plugin rather than as per-client configuration, so that the capability moves with the team when the tooling changes rather than being rebuilt each time.

8. Give the bundle a review cadence and an eviction rule - put a recurring audit of the installed skills and servers on the calendar, review agent memory separately from skills, and default to removing anything you cannot demonstrate is still earning its place. The test is empirical, not rhetorical: remove it and see whether spec quality actually declines. Pin the versions you depend on and keep the set allowlisted, because pre-install scanning is not currently a control you can rely on.

Skipping the human review step. Autonomous requirements generation is a speed tool, not an authority transfer. The agent generates a first draft quickly; the human ensures it is correct before work begins. Removing the human review step to maximize throughput will produce implementations that are fast and wrong. The review step must be fast - minutes to an hour - but it must exist.

Using Autonomous Requirements on tickets that require human negotiation. Some tickets are vague because the requirements are genuinely contested or unclear - not because the information exists and wasn't included. A vague ticket for a feature where product, design, and engineering have not aligned will produce a spec that is internally consistent but wrong about what is actually wanted. Autonomous Requirements works best for tickets where the intent is clear but the specification is underspecified, not for tickets where the intent is itself unclear.

Not feeding back spec quality into Context Fabric improvement. Every systematic gap in generated specs is a signal about missing context. If the requirements agent consistently misses accessibility requirements, it probably lacks access to the accessibility guidelines. If it consistently misses performance constraints, it probably lacks access to performance benchmarks. Track spec gaps, trace them to missing context sources, and add those sources to the Fabric.

Measuring speed instead of quality. It is easy to measure that specs are generated faster with automation. It is harder but more important to measure whether the implemented features are correct. Track the delta between automated specs and human-written specs in terms of rework rate, not generation time. Speed is the benefit; correctness is the requirement.

Mistaking vendor enthusiasm for practitioner consensus. There is a great deal of published material presenting spec-driven development as the settled way to work with agents. The practitioner record does not support that reading: across the August 2026 window, "spec-driven development" drew roughly 25 mentions in the main practitioner forum and "agent fleet" seven, which is close to nothing against the volume of vendor content on both. Treat autonomous requirements as what it demonstrably is - a high-value technique for a bounded set of ticket types where intent is clear and specification is thin - rather than as a methodology to roll out organization-wide. Rolling out a practice the people doing the work have not adopted produces process compliance and no quality change.

Letting the skill and plugin set accrete. The bundle behind a requirements agent grows every time someone adds a rule to fix a bad spec, and nobody ever proposes a removal. The result is a slower, more expensive agent whose behaviour nobody can account for, and a larger dependency surface than anyone intended. Audit on a cadence, prune by default, and prove the loss before keeping something.

Applying the same requirements agent to vastly different ticket types. A requirements agent tuned for API endpoint specs will perform poorly on infrastructure change tickets. Avoid the temptation to use a single generic requirements agent for all ticket types. Better to have two or three well-tuned agents for specific ticket categories than one general agent that does all of them poorly.