Adopt Existing Issues

If your repo predates the Iron Tree Protocol and already has open issues, you can standardize them without rewriting history.

Usage

/task adopt issue-12

This produces the same brief, events, and label set as a native /mino-task PRD.md flow.

Adoption Rules

Condition	Result
Issue is OPEN	Proceed
Issue is CLOSED	Refused with error message
Issue has ≥ 3 open checkboxes	Composite — refused with iron-tree:needs-breakdown label

Label Set

Label	Meaning
iron-tree:adopted	Under Iron Tree workflow (permanent)
iron-tree:needs-breakdown	Composite — split before adopting
stage:task	Awaiting approval
stage:run	Approved, ready or executing run
stage:verify	Run committed, awaiting verify
stage:done	Verify passed

Pull Requests are not adopted; they continue to merge against issues as usual.

Re-Adoption

If an adopted issue's title or body is edited on GitHub, re-adoption archives the previous chain:

• .mino/archive/issue-{N}-rev-{OLD}/brief.md — original brief
• .mino/archive/issue-{N}-rev-{OLD}/events/ — original events
• New brief with a different Spec Revision
• task_re_adopted event with previous_revision and archive_path

Brief Quality (v1.11+)

The brief generated by adopt is structured, not a verbatim dump. The agent extracts:

• Testable acceptance criteria
• Derived verification steps
• Inferred target files

This matches the field-filling pattern of briefs produced by /mino-task PRD.md. Issue bodies on GitHub are never modified; standardization lives in .mino/briefs/issue-{N}.md only.

High-Quality Adoption

For bug issues with reproduction steps and stack traces, the agent:

• Sets type: bug
• Generates ≥ 3 testable checklist items
• Lists target files from stack traces (excluding JDK internals)
• Incorporates maintainer comments that refine scope
• Ignores unendorsed noise comments

For vague feature requests, the agent halts and lists specific gaps in Open Questions / Warnings, requiring human resolution before proceeding.