manage-issues

name	manage-issues
description	Create, triage, update, and close GitHub issues for iroh-http with duplicate checks, evidence-backed classification, durable agent briefs, safe public comments, and merge-aware closure. Use when reporting a bug or enhancement, organizing issue state, preparing work for an agent or human, or closing resolved issues.

Manage iroh-http issues

Infer the repository from the current Git remote. Use an available GitHub integration or gh; do not require a particular agent host.

Public-output safety

Start every AI-authored issue or triage comment with:

> *This was generated by AI during triage.*

Publish only repository-relevant evidence. Never expose local-only skill names, ignored files, unrelated working-tree contents, usernames, home directories, credentials, device identifiers, or absolute filesystem paths. Describe local evidence generically when it matters, for example "an untracked review report" or "a machine-specific path".

Labels

Query the repository's current labels before changing them. Do not silently invent a taxonomy.

• Apply exactly one category: bug or enhancement.
• Apply one priority (P1 through P4) when severity is established.
• Apply relevant topic labels such as api, protocol, connectivity, observability, dx, documentation, testing, or architecture.
• Apply a workflow-state label only when that state exists in the repository.
• Use ready-for-agent only after posting a complete agent brief.
• Remove conflicting category or workflow-state labels when transitioning.

Create an issue

1. Search open and closed issues using distinctive domain terms.
2. Read likely matches before deciding whether the report is new.
3. Inspect the relevant code, specification, tests, and recent history.
4. For a bug, reproduce it when safe and practical. Record observed behavior, not assumptions.
5. Create one durable issue or a small set of independently verifiable vertical slices. Do not split work merely by implementation layer.

Use this structure when applicable:

## Summary

What is wrong or needed, in user-visible or contract terms.

## Evidence

Reproduction, logs, test output, API mismatch, or repository evidence.

## Impact

Who is affected, severity, and available workarounds.

## Acceptance criteria

- [ ] Observable condition that proves completion

## Out of scope

- Adjacent behavior deliberately excluded

Keep titles imperative and specific. Prefer behavioral contracts over proposed file edits. Paths are acceptable as present-tense evidence, but acceptance criteria must remain useful after files move.

Triage an existing issue

1. Read the full issue, every comment, its labels, linked changes, and prior triage notes.
2. Search for duplicates or work that already resolved the report.
3. Inspect the implementation and tests. Attempt bug reproduction before proposing a fix when practical.
4. Recommend a category, priority, topics, and next state with evidence.
5. Ask for maintainer judgment only when the remaining choice materially changes behavior or scope.
6. Apply the agreed transition and leave a concise durable comment.

If an issue is ready for autonomous implementation, read references/agent-brief.md and post the completed brief before applying ready-for-agent.

If more reporter information is required, preserve established facts and ask specific answerable questions. Do not restart triage when the reporter replies.

Close an issue

Close an issue only when the resolving change is on the repository's default branch or the issue is intentionally rejected or duplicated.

For completed work:

1. Verify the merged commit and acceptance criteria.
2. Post a full commit or pull-request link plus a one-sentence outcome.
3. Close with reason completed if an automatic closing keyword did not.

For duplicates, link the canonical issue before closing. For rejected work, record the durable reason rather than a temporary scheduling constraint.

Rules

• Never create a duplicate without explicitly linking the prior issue.
• Never claim reproduction, test success, merge, or release without evidence.
• Never close implementation work merely because a branch or pull request exists.
• Never broaden an issue silently; record newly discovered behavior separately when it can be implemented and verified independently.