Implementation Plan: Retire Auto-Generated Requirements (#4477) - #4661
Merged
Conversation
prepare-issue Step 7a no longer traces backward from the goal to enumerate
REQ-{GRP}-NNN requirements on every recipe:implementation issue. It now applies
a three-part bar (absolute, broad, unarguable) whose default outcome is zero
requirements, capped at three plain sentences with no REQ- identifiers or groups.
Drops the issue-comment path, which violated AGENTS.md 3.4.
triage-issues --enrich and Step 3c are removed entirely: batch generation is the
same behavior at the worst scale, and a flag that survived the new bar would
produce nothing on nearly every issue.
Deletes the tests that guarded the removed behavior.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
make-req is kept — it is user-invoked, writes to a local file rather than an
issue body, and make-groups traceability depends on its REQ-{GRP}-NNN IDs. It
gets the same bar the pipeline generators are being retired for: absolute,
broad, unarguable, default none. Applied to both the bundled copy and the
project-local .claude/ override.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
enrich-issues existed only to backfill REQ-{GRP}-NNN requirements onto the
backlog. Under the new requirement bar there is nothing to backfill, and a
dispatcher for a deleted skill is dead code.
Removes the skill directory, the enrich_issues tool with its private helpers
(_build_enrich_skill_command, _parse_enrich_result, _extract_partial_enrich_data,
_ENRICHED_ISSUE_RE, _ENRICH_RESULT_*), and every registry entry: _MUTATION_TOOLS,
_TOOL_DEFS, GATED_TOOLS, TOOL_SUBSET_TAGS, _DISPLAY_CATEGORIES, _UNFORMATTED_TOOLS,
defaults.yaml tier2, and skill_contracts.yaml.
Registers enrich-issues in RETIRED_SKILL_NAMES in the same commit, per
AGENTS.md 3.1. Corrects the tracked doc totals this changes: MCP tools 75 to 74,
kitchen-tagged 52 to 51, bundled skills 142 to 141, tier2 106 to 105.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ntracts triage-issues no longer generates requirements, so it no longer carries a ## Requirements section or REQ- identifiers. Its only surviving 'requirements' mentions are the semantic_requirements frontmatter key and a make-groups cross-reference, which trip the loose substring gate in the header-consistency test. Removed it from that list; the test still guards prepare-issue and pipeline-summary. Deleted test_req_id_format_consistent_across_skills outright. Neither of its subjects generates REQ- IDs now, and for prepare-issue it would pass only because the rewritten Step 7a prohibits the format by name — the same inverted assertion that retired test_prepare_issue_uses_req_id_format. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Per review-pr finding: deleting test_prepare_issue_uses_req_id_format left the new NEVER- clause forbidding REQ- identifiers, requirement groups, and the at-most-three constraint cap with zero coverage. Add a positive assertion on the prohibition text in the Critical Constraints block — asserting on the literal 'REQ-' would fail because the NEVER bullet itself contains the token.
Per review-pr finding: enrich-issues retirement left the parametrization collapsed to a single skill (review-pr), silently dropping coverage of the single delegated-worker + sonnet child_model_policy shape. Add apply-review-dimensions which carries exactly that semantic frontmatter shape (count: 1, delegated-worker, sonnet).
Per review-pr finding: rename 'Hard Constraints (rare)' → 'Hard Requirements (rare)' and align the NEVER- clause 'constraint sentences' → 'requirement sentences'. The 'requirements_generated'/'requirements_appended' field names and '## Requirements' section header are the public API consumed by the pipeline; choosing 'requirement' as the unifying term avoids breaking the public contract while resolving the four-way vocabulary drift in a single step. This also subsumes the I7 (rename REQUIREMENTS_FILE) and I8 (add retention comment for ## Requirements) info findings — both become moot once vocabulary aligns on 'requirement'.
Per review-pr info finding: enrich_issues retirement left _HEADLESS_FAILURE_SCENARIOS
parametrizing a single tool name and tool_fn = {'prepare_issue': prepare_issue}[tool_name]
as a vestigial one-entry dispatch dict. Drop the tool_name parameter and inline
prepare_issue so the test reads as what it is.
…_report_bug.py
Per review-pr info finding: enrich_issues retirement removed the _parse_enrich_result
tests, exposing that _parse_prepare_result unit tests were duplicated across
test_tools_report_bug.py and test_tools_issue_lifecycle.py with identical
assertions ('no result block found' / 'result block contained invalid JSON').
Keep the prepare-result parse tests in test_tools_issue_lifecycle.py (next to the
other tools_issue_headless helper tests) and remove the duplicate from
test_tools_report_bug.py, plus its now-unused _PREPARE_RESULT_START/END constants.
Adversarial validation caught two leftover 'constraint' references inside Step 7a: - L371 'If one or more constraints pass' → 'requirements' - L388 bash comment 'constraint sentences' → 'requirement sentences' The step now consistently uses 'requirement' everywhere (heading L350, body L371, NEVER clause L466, bash comment L388, field names, section header). Public API (requirements_generated/appended, ## Requirements) remains untouched per the original unification rationale.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three surfaces auto-generate
REQ-{GRP}-NNNrequirement lists onto GitHub issue bodies:prepare-issueStep 7a (everyrecipe:implementationissue at creation),triage-issuesStep 3c (batch, behind
--enrich), and the wholeenrich-issuesskill +enrich_issuesMCP tool (backlog backfill). Downstream sessions treat each generated line as absolute, so
this quietly multiplies constraints nobody chose.
This plan replaces auto-generation with a single, short requirement bar and makes the
default outcome no requirements at all:
prepare-issueStep 7a becomes "Hard Constraints (rare)": default zero; append a## Requirementssection only for constraints that are absolute, broad, and unarguable,written as at most three plain sentences with no
REQ-identifiers and no groups.triage-issues--enrichand Step 3c are removed entirely. Batch generation is thesame behavior at the worst scale, and a flag that survives the new bar would produce
nothing on nearly every issue.
enrich-issuesis retired — skill,enrich_issuesMCP tool, registry entries, docs,and tests. Its only purpose is backfilling
REQ-{GRP}-NNNonto the backlog; under the newbar there is nothing to backfill, and a dispatcher for a deleted skill is dead code.
make-reqis kept and given the same bar in its Core Principles. It is user-invoked,writes to a local file (never to an issue), and
make-groupstraceability depends on itsREQ-{GRP}-NNNIDs. It is a deliberate act on a supplied document, not pipeline debt.The
## Requirementsheading itself is preserved as the contract point.prepare-pr,pipeline-summary,compose-pr,merge-pr,analyze-prs, anddry-walkthroughStep 4.6all extract that heading from an issue or PR body, and all already degrade when it is absent:
the first five set
requirements_section = ""and omit the section, anddry-walkthroughStep 4.6 records "coverage check not applicable" rather than failing. Nothing starves.
make-planandaudit-implbuild their own requirement inventories from plan text, not fromthe issue's
## Requirementssection —make-plandoes read the whole issue body viafetch_github_issueas unstructured context, so a rare hard constraint still reaches it.Closes #4477
Implementation Plan
Plan file:
.autoskillit/temp/make-plan/retire_auto_requirements_plan_2026-08-16_225423.md🤖 Generated with Claude Code via AutoSkillit