Fusion Issue Authoring

# Author Bug Issue

## When to use

Use this agent mode when the request is about broken behavior, regressions, crashes, or unexpected results.

## When not to use

Do not use this agent mode for feature requests, user stories, or generic enablement tasks.

## Required inputs

- Bug context (observed behavior, expected behavior, impact)
- Reproduction information (if available)
- Environment context

## Instructions

1. Confirm routed type is `Bug`.
2. Draft locally in `.tmp/BUG-<context>.md`.
3. Structure draft with:
   - Description
   - Steps to reproduce
   - Expected behavior
   - Actual behavior
   - Environment
   - Impact
4. Validate the draft has enough reproduction detail for triage.
5. Return the draft summary for orchestrator review/publish flow.

Template fallback:
- `assets/issue-templates/bug.md`

## Expected output

- Draft file path in `.tmp/`
- Proposed title/body summary
- Bug-specific triage notes (repro clarity + impact)

## Safety & constraints

Do not perform mutation directly; mutation stays in the orchestrator flow (`SKILL.md`).


# Devil's Advocate

## When to use

Always-on quality collaborator for issue authoring. Plays the opposing side to strengthen the plan — pointing out weak scope, missing criteria, and dependency gaps so they get resolved before drafting.

**Moderate mode (default):** Active during normal authoring. Raises the 2–3 most important concerns as inline observations after classification. Does not interrupt flow or force a separate interview.

**Interrogator mode (on request or significant gaps):** Full structured interview when the user says "grill me", "stress-test this", "poke holes", or equivalent; or when scope/criteria gaps are significant after classification; or when invoked from `fusion-issue-task-planning` and two or more architecture-ambiguity signals are present (see Task-planning context below). Walks the decision tree for the classified issue type until critical unknowns are resolved.

## When not to use

- The issue intent is already clear with well-defined scope, criteria, and dependencies
- Post-draft content review (that stays in the review gate of `SKILL.md`)
- The user has explicitly said they don't want pushback on this iteration

## Required inputs

- Issue context: what the user wants to create or update
- Issue type (Bug, Feature, User Story, Task) — already classified by orchestrator
- Any partial draft or prior conversation context

## Instructions

### Moderate mode

Weave into the authoring flow without a separate interview:

1. Read the user's request, any partial draft, and relevant repository context.
2. Identify the top 2–3 concerns for the classified issue type:
   - **Bug**: reproduction gaps, unclear severity, missing environment detail
   - **Feature**: vague scope boundaries, untestable success criteria, hidden dependencies
   - **User Story**: unclear role, incomplete scenarios, non-testable acceptance criteria
   - **Task**: missing decomposition, circular blockers, no validation approach; in a task-planning context also probe for premature decomposition (splitting implementation before design is settled), implicit cross-task contracts (backend/frontend API shape not yet agreed), and tasks that look actionable but hide unresolved architecture assumptions
3. Resolve what you can from the codebase silently.
4. Surface remaining concerns as brief, actionable observations — each with your recommended resolution.
5. Let the user accept, adjust, or dismiss. Hand off to the type-specific agent.

### Interrogator mode

Structured interview for thorough plan stress-testing:

#### Step 1: Triage what matters

1. Read the user's request, any partial draft, and relevant repository context.
2. Identify unresolved decision branches for the classified issue type.
3. Discard questions answerable from the codebase or prior conversation.
4. Rank remaining questions by dependency: scope-defining questions before detail questions.

#### Task-planning context (User