@relipa/ai-flow-kit 0.1.0-beta.0 → 0.1.1-beta.0

package/custom/skills/read-study-requirement/SKILL.md

@@ -1,334 +1,334 @@
----
-name: read-study-requirement
-description: Gate 1 — AI reads ticket from Backlog/Jira + reads source code, then uses collaborative Q&A and solution proposal. Adds impact analysis and effort estimate. Outputs requirement.md for DEV to approve.
-keywords: ticket, requirement, study, read, context, backlog, jira, analyze, understand, solution, estimate
----
-
-# Analyze Requirement — Gate 1
-
-> **GATE 1: Must run before any other gate. Auto-starts when ticket context exists.**
->
-> Principle: AI actively participates in understanding requirements — reading ticket + source code, clarifying via collaborative dialogue, proposing solutions, analyzing impact, and estimating effort.
-
----
-
-## Mode Selection
-
-Check `mode` in `.aiflow/context/current.json` before starting:
-
-| Mode | Trigger | Behaviour |
-|------|---------|-----------|
-| `fast` | `aiflow use TICKET --fast` | Jump to **[Fast Track](#fast-track-mode-fast)** below |
-| `full` | `aiflow use TICKET --full` | Use standard steps — full Q&A + all 6 sections |
-| `auto` (default) | `aiflow use TICKET` | Standard steps |
-
----
-
-## Fast Track (mode: fast)
-
-> Target: Gate 1 complete in **< 5 minutes**, minimum token usage.
-
-## Fast Mode Output Rules (CRITICAL)
-
-When creating `plan/[ticket-id]/summary.md` during Gate 1:
-- You must create the `summary.md` file after Gate 1 is APPROVED, to track session progress.
-- Keep `summary.md` concise. Only include short bullet points tracking Gates.
-- Do not write verbose implementation details in `summary.md` at Gate 1.
-
-0. **Pre-flight — Sync with remote** (before reading any source file):
-   - Run `git status --porcelain` to check for uncommitted changes.
-   - Working tree clean → run `git pull --ff-only` to fetch the latest code.
-   - Uncommitted changes detected → SKIP pull and notify DEV: `⚠️ Uncommitted changes detected — skipping git pull. Analysing local state.`
-   - `git pull --ff-only` fails (branch diverged from remote) → notify DEV: `⚠️ Local branch diverged from remote — skipping pull. Resolve manually before next ticket.` Then continue with local state.
-1. Read `.aiflow/context/current.json` — ticket title, description, acceptance criteria
-2. Identify **directly affected files** from ticket text and file names only.
-   DO NOT trace data flow or read unrelated source files.
-3. Q&A: Ask at most **ONE** question if there is a blocking ambiguity.
-   If the ticket + source file names make intent clear → skip Q&A entirely.
-   Wait for answer before writing the requirement doc.
-4. Output `plan/[ticket-id]/requirement.md` with **3 sections only**:
-
-```markdown
-# Requirement: [Ticket ID] — [Title]
-
-**Date:** [YYYY-MM-DD]  **Mode:** fast  **Status:** ⏸️ Waiting for DEV Approval
-
-## 1. Requirements Summary
-[2–4 sentence restatement of what needs to change and why]
-
-**Acceptance Criteria:**
-- [ ] [each AC from ticket]
-
-## 3. Files to Create / Modify
-| Action | File | Change |
-|--------|------|--------|
-| Modify | [path] | [what changes] |
-
-## 5. Effort Estimate
-| Task | Size |
-|------|------|
-| Tests | S/M/L |
-| Implementation | S/M/L |
-| **Total** | **S/M/L** |
-```
-
-5. Display Gate 1 prompt and wait for `APPROVED`.
-
-> After APPROVED, proceed to Gate 2. The lean doc is intentional — Gate 2 plan will fill in the details.
-
----
-
-## Steps
-
-### Step 1: Load Ticket & Read Source Code
-
-0. **Pre-flight — Sync with remote** (run BEFORE reading any source file):
-   - Run `git status --porcelain` first. Empty output = clean working tree.
-   - Clean working tree → run `git pull --ff-only` to pull the latest code from remote. This guarantees the analysis is based on current source, not stale local state.
-   - Uncommitted changes → SKIP pull and notify DEV: `⚠️ Uncommitted changes detected — skipping git pull. Analysing local state.`
-   - `git pull --ff-only` fails because the branch has diverged → notify DEV: `⚠️ Local branch diverged from remote — skipping pull. Resolve manually before next ticket.` Continue with local state.
-   - Repo has no remote tracking branch (detached HEAD or local-only branch) → skip silently and proceed.
-1. Read `.aiflow/context/current.json` — ticket info from Backlog/Jira
-2. **Supplementary Context:** If `current.json` has a `supplementaryContext[]` array, read each item and integrate it as supporting context for your analysis. Items may be:
-   - `[ticket]` — linked tickets (related features, dependencies, parent tickets)
-   - `[comment]` — specific comments from PM/QA/stakeholders
-   - `[file]` — architecture docs, business logic specs, API references
-   - `[text]` — any other supplementary information
-
-   If you encounter a backlog/jira URL in the ticket description that is **not** already in `supplementaryContext[]`, run `ak fetch-links <url>` and use the JSON output in your analysis without saving.
-3. Read `CLAUDE.md` — understand project architecture, tech stack, conventions
-4. Read related source files — trace data flow, identify patterns, dependencies
-   - **If GitNexus MCP is available** (`.mcp.json` has `gitnexus` entry): invoke GitNexus MCP tools instead of reading files directly — one call returns full context without multi-file exploration:
-     - `gitnexus: context("ClassName")` → 360° view of a symbol (dependencies, callers, methods)
-     - `gitnexus: query("keyword or description")` → hybrid search across codebase
-     - Saves ~50% of token cost at this step vs reading files manually
-   - **If task is a Bug Fix:** Invoke `superpowers:systematic-debugging` to trace root cause before proposing fixes.
-5. Read ticket comments — additional context from PM/team
-
-Do this investigation **before** asking any questions. Come prepared.
-
----
-
-### Step 2: Clarify Requirements via Q&A
-
-Ask clarifying questions directly — **one question at a time**, wait for the developer's response before asking the next.
-
-**When to ask:**
-- Business requirements are vague or ambiguous
-- Acceptance criteria are not measurable
-- Edge cases discovered in source code need input
-- Multiple approaches exist and the developer's preference matters
-
-**When NOT to ask:**
-- The ticket and source code together make the intent clear → proceed directly
-
-Once you have sufficient clarity, propose **2–3 solution approaches** with trade-offs and a recommendation:
-- Present options conversationally, lead with your recommendation
-- Get developer confirmation on the chosen approach
-
-**Do NOT proceed to Step 3 until the developer has confirmed the design direction.**
-
-> ⚠️ **DO NOT invoke `superpowers:brainstorming`** — brainstorming's terminal state invokes
-> `writing-plans` (Gate 2), which would bypass Gate 1's approval gate. All Q&A happens here.
-
----
-
-### Step 3: Extend with Impact Analysis & Effort Estimate
-
-After the developer confirms the design direction (Step 2), extend with:
-
-**Impact Analysis:**
-- Which services, modules, and jobs are affected?
-- Any breaking changes to APIs, DB schema, or shared components?
-- Risk level: 🟢 Low / 🟡 Medium / 🔴 High
-- Mitigation for each risk
-
-**Effort Estimate:**
-- Break down into tasks: tests, implementation, migration
-- Size each task: S (< 1h) / M (1–4h) / L (4–8h) / XL (8h+, consider splitting)
-- If XL → suggest sub-task breakdown
-
----
-
-### Step 4: Write Requirement Document
-
-Save to `plan/[ticket-id]/requirement.md`:
-
-```markdown
-# Requirement: [Ticket ID] — [Title]
-
-**Date:** [YYYY-MM-DD]
-**Type:** [feature | bug-fix | refactor | investigation]
-**Status:** ⏸️ Waiting for DEV Approval
-
----
-
-## 1. Requirements Summary
-
-### Description
-[Clear technical restatement of the requirement, incorporating all clarifications from Q&A]
-
-### Current Behavior / Business Goal
-[What exists now vs what is needed]
-
-### Acceptance Criteria
-- [ ] [Criteria 1 — specific, measurable]
-- [ ] [Criteria 2]
-
-### Context & Constraints
-[Environment, business rules, dependencies, deadlines]
-
----
-
-## 2. Source Code Analysis
-
-### Related Files
-| File | Role | Current State |
-|------|------|---------------|
-| [path] | [Controller/Service/...] | [what it does now] |
-
-### Data Flow
-```
-[Entry point] → [Service] → [Repository] → [DB/External]
-```
-
-### Existing Patterns to Follow
-[Patterns in the codebase this change must follow]
-
-### Current Test Coverage
-| Area | Test File | Status |
-|------|-----------|--------|
-| [area] | [file] | [exists / missing] |
-
----
-
-## 3. Proposed Solution
-
-### Chosen Approach: [Name]
-[From brainstorming session — the approach the developer confirmed]
-
-### Alternatives Considered
-| Option | Pros | Cons | Why Not Chosen |
-|--------|------|------|----------------|
-| [Option B] | ... | ... | ... |
-
-### Files to Create / Modify
-| Action | File | Change |
-|--------|------|--------|
-| Create | [path] | [purpose] |
-| Modify | [path] | [what changes] |
-
-### Database Changes
-| Table | Change | Details |
-|-------|--------|---------|
-| [table] | [migration type] | [description] |
-
----
-
-## 4. Impact Analysis
-
-**Impact Level:** 🟢 Low / 🟡 Medium / 🔴 High
-
-| Area | Impact | Reason |
-|------|--------|--------|
-| [Module] | 🟢 None / 🟡 Minor / 🔴 Major | [why] |
-
-**Breaking Changes:**
-- [ ] None expected
-- [ ] [Breaking change if any]
-
-**Risks:**
-| Risk | Severity | Mitigation |
-|------|----------|------------|
-| [description] | Low / Medium / High | [mitigation] |
-
----
-
-## 5. Effort Estimate
-
-| Task | Size | Notes |
-|------|------|-------|
-| Tests (TDD) | S/M/L | [N scenarios] |
-| Implementation | S/M/L | [complexity] |
-| Migration / Integration | S/M/L | [if applicable] |
-| **Total** | **S/M/L/XL** | |
-
-> S = <1h · M = 1–4h · L = 4–8h · XL = 8h+ (split recommended)
-
-**Sub-tasks (if XL):**
-- [ ] [Sub-task 1]
-- [ ] [Sub-task 2]
-
----
-
-## 6. Testing Plan
-
-### Unit Tests
-- [ ] [Scenario to test]
-
-### Integration Tests
-- [ ] [API/service flow to test]
-
-### Manual Test Cases
-- [ ] [Step-by-step]
-```
-
----
-
-### Step 5: Present to Developer
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⏸️  GATE 1: REQUIREMENT DOCUMENT READY
-
-Ticket: [ticket-id] — [title]
-File:   plan/[ticket-id]/requirement.md
-
-Summary:
-  Type:     [feature / bug-fix / refactor]
-  Impact:   [Low / Medium / High]
-  Estimate: [S / M / L / XL]
-  Approach: [one-line description]
-
-Please review the requirement document.
-  → Type APPROVED to proceed to implementation plan
-  → Or provide feedback to update the document
-
-⚠️  I will NOT generate code until I receive "APPROVED".
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
----
-
-### Step 6: Handle Feedback
-
-- DEV provides feedback → update `requirement.md` → re-show Gate 1 prompt
-- DEV types `APPROVED` → proceed to Gate 2 (Implementation Plan)
-
----
-
-## What This Skill Delegates vs Owns
-
-| Concern | Handled by |
-|---------|-----------|
-| Q&A loop (one question at a time) | This skill (inline) |
-| Propose 2–3 solution approaches | This skill (inline) |
-| Root cause tracing (bug tasks) | `superpowers:systematic-debugging` |
-| Impact analysis | This skill |
-| Effort estimate | This skill |
-| requirement.md template & output | This skill |
-| Gate 1 APPROVED gate | This skill |
-
----
-
-## Mandatory Rules
-
-- ❌ **DO NOT** invoke `superpowers:brainstorming` — its terminal state calls `writing-plans` and bypasses Gate 1 approval
-- ❌ **DO NOT** invoke `superpowers:writing-plans` — that belongs to Gate 2 (`generate-spec` skill)
-- ❌ **DO NOT** proceed past Step 2 if design is not confirmed by developer
-- ❌ **DO NOT** write code at any point in this skill
-- ❌ **DO NOT** skip impact analysis and effort estimate
-- ✅ **MUST** run `git status` + `git pull --ff-only` (Pre-flight) before reading source code, when working tree is clean
-- ✅ **MUST** read source code before Q&A begins
-- ✅ **MUST** save `plan/[ticket-id]/requirement.md`
-- ✅ **MUST** display Gate 1 prompt and wait for `APPROVED`
+---
+name: read-study-requirement
+description: Gate 1 — AI reads ticket from Backlog/Jira + reads source code, then uses collaborative Q&A and solution proposal. Adds impact analysis and effort estimate. Outputs requirement.md for DEV to approve.
+keywords: ticket, requirement, study, read, context, backlog, jira, analyze, understand, solution, estimate
+---
+
+# Analyze Requirement — Gate 1
+
+> **GATE 1: Must run before any other gate. Auto-starts when ticket context exists.**
+>
+> Principle: AI actively participates in understanding requirements — reading ticket + source code, clarifying via collaborative dialogue, proposing solutions, analyzing impact, and estimating effort.
+
+---
+
+## Mode Selection
+
+Check `mode` in `.aiflow/context/current.json` before starting:
+
+| Mode | Trigger | Behaviour |
+|------|---------|-----------|
+| `fast` | `aiflow use TICKET --fast` | Jump to **[Fast Track](#fast-track-mode-fast)** below |
+| `full` | `aiflow use TICKET --full` | Use standard steps — full Q&A + all 6 sections |
+| `auto` (default) | `aiflow use TICKET` | Standard steps |
+
+---
+
+## Fast Track (mode: fast)
+
+> Target: Gate 1 complete in **< 5 minutes**, minimum token usage.
+
+## Fast Mode Output Rules (CRITICAL)
+
+When creating `plan/[ticket-id]/summary.md` during Gate 1:
+- You must create the `summary.md` file after Gate 1 is APPROVED, to track session progress.
+- Keep `summary.md` concise. Only include short bullet points tracking Gates.
+- Do not write verbose implementation details in `summary.md` at Gate 1.
+
+0. **Pre-flight — Sync with remote** (before reading any source file):
+   - Run `git status --porcelain` to check for uncommitted changes.
+   - Working tree clean → run `git pull --ff-only` to fetch the latest code.
+   - Uncommitted changes detected → SKIP pull and notify DEV: `⚠️ Uncommitted changes detected — skipping git pull. Analysing local state.`
+   - `git pull --ff-only` fails (branch diverged from remote) → notify DEV: `⚠️ Local branch diverged from remote — skipping pull. Resolve manually before next ticket.` Then continue with local state.
+1. Read `.aiflow/context/current.json` — ticket title, description, acceptance criteria
+2. Identify **directly affected files** from ticket text and file names only.
+   DO NOT trace data flow or read unrelated source files.
+3. Q&A: Ask at most **ONE** question if there is a blocking ambiguity.
+   If the ticket + source file names make intent clear → skip Q&A entirely.
+   Wait for answer before writing the requirement doc.
+4. Output `plan/[ticket-id]/requirement.md` with **3 sections only**:
+
+```markdown
+# Requirement: [Ticket ID] — [Title]
+
+**Date:** [YYYY-MM-DD]  **Mode:** fast  **Status:** ⏸️ Waiting for DEV Approval
+
+## 1. Requirements Summary
+[2–4 sentence restatement of what needs to change and why]
+
+**Acceptance Criteria:**
+- [ ] [each AC from ticket]
+
+## 3. Files to Create / Modify
+| Action | File | Change |
+|--------|------|--------|
+| Modify | [path] | [what changes] |
+
+## 5. Effort Estimate
+| Task | Size |
+|------|------|
+| Tests | S/M/L |
+| Implementation | S/M/L |
+| **Total** | **S/M/L** |
+```
+
+5. Display Gate 1 prompt and wait for `APPROVED`.
+
+> After APPROVED, proceed to Gate 2. The lean doc is intentional — Gate 2 plan will fill in the details.
+
+---
+
+## Steps
+
+### Step 1: Load Ticket & Read Source Code
+
+0. **Pre-flight — Sync with remote** (run BEFORE reading any source file):
+   - Run `git status --porcelain` first. Empty output = clean working tree.
+   - Clean working tree → run `git pull --ff-only` to pull the latest code from remote. This guarantees the analysis is based on current source, not stale local state.
+   - Uncommitted changes → SKIP pull and notify DEV: `⚠️ Uncommitted changes detected — skipping git pull. Analysing local state.`
+   - `git pull --ff-only` fails because the branch has diverged → notify DEV: `⚠️ Local branch diverged from remote — skipping pull. Resolve manually before next ticket.` Continue with local state.
+   - Repo has no remote tracking branch (detached HEAD or local-only branch) → skip silently and proceed.
+1. Read `.aiflow/context/current.json` — ticket info from Backlog/Jira
+2. **Supplementary Context:** If `current.json` has a `supplementaryContext[]` array, read each item and integrate it as supporting context for your analysis. Items may be:
+   - `[ticket]` — linked tickets (related features, dependencies, parent tickets)
+   - `[comment]` — specific comments from PM/QA/stakeholders
+   - `[file]` — architecture docs, business logic specs, API references
+   - `[text]` — any other supplementary information
+
+   If you encounter a backlog/jira URL in the ticket description that is **not** already in `supplementaryContext[]`, run `ak fetch-links <url>` and use the JSON output in your analysis without saving.
+3. Read `CLAUDE.md` — understand project architecture, tech stack, conventions
+4. Read related source files — trace data flow, identify patterns, dependencies
+   - **If GitNexus MCP is available** (`.mcp.json` has `gitnexus` entry): invoke GitNexus MCP tools instead of reading files directly — one call returns full context without multi-file exploration:
+     - `gitnexus: context("ClassName")` → 360° view of a symbol (dependencies, callers, methods)
+     - `gitnexus: query("keyword or description")` → hybrid search across codebase
+     - Saves ~50% of token cost at this step vs reading files manually
+   - **If task is a Bug Fix:** Invoke `superpowers:systematic-debugging` to trace root cause before proposing fixes.
+5. Read ticket comments — additional context from PM/team
+
+Do this investigation **before** asking any questions. Come prepared.
+
+---
+
+### Step 2: Clarify Requirements via Q&A
+
+Ask clarifying questions directly — **one question at a time**, wait for the developer's response before asking the next.
+
+**When to ask:**
+- Business requirements are vague or ambiguous
+- Acceptance criteria are not measurable
+- Edge cases discovered in source code need input
+- Multiple approaches exist and the developer's preference matters
+
+**When NOT to ask:**
+- The ticket and source code together make the intent clear → proceed directly
+
+Once you have sufficient clarity, propose **2–3 solution approaches** with trade-offs and a recommendation:
+- Present options conversationally, lead with your recommendation
+- Get developer confirmation on the chosen approach
+
+**Do NOT proceed to Step 3 until the developer has confirmed the design direction.**
+
+> ⚠️ **DO NOT invoke `superpowers:brainstorming`** — brainstorming's terminal state invokes
+> `writing-plans` (Gate 2), which would bypass Gate 1's approval gate. All Q&A happens here.
+
+---
+
+### Step 3: Extend with Impact Analysis & Effort Estimate
+
+After the developer confirms the design direction (Step 2), extend with:
+
+**Impact Analysis:**
+- Which services, modules, and jobs are affected?
+- Any breaking changes to APIs, DB schema, or shared components?
+- Risk level: 🟢 Low / 🟡 Medium / 🔴 High
+- Mitigation for each risk
+
+**Effort Estimate:**
+- Break down into tasks: tests, implementation, migration
+- Size each task: S (< 1h) / M (1–4h) / L (4–8h) / XL (8h+, consider splitting)
+- If XL → suggest sub-task breakdown
+
+---
+
+### Step 4: Write Requirement Document
+
+Save to `plan/[ticket-id]/requirement.md`:
+
+```markdown
+# Requirement: [Ticket ID] — [Title]
+
+**Date:** [YYYY-MM-DD]
+**Type:** [feature | bug-fix | refactor | investigation]
+**Status:** ⏸️ Waiting for DEV Approval
+
+---
+
+## 1. Requirements Summary
+
+### Description
+[Clear technical restatement of the requirement, incorporating all clarifications from Q&A]
+
+### Current Behavior / Business Goal
+[What exists now vs what is needed]
+
+### Acceptance Criteria
+- [ ] [Criteria 1 — specific, measurable]
+- [ ] [Criteria 2]
+
+### Context & Constraints
+[Environment, business rules, dependencies, deadlines]
+
+---
+
+## 2. Source Code Analysis
+
+### Related Files
+| File | Role | Current State |
+|------|------|---------------|
+| [path] | [Controller/Service/...] | [what it does now] |
+
+### Data Flow
+```
+[Entry point] → [Service] → [Repository] → [DB/External]
+```
+
+### Existing Patterns to Follow
+[Patterns in the codebase this change must follow]
+
+### Current Test Coverage
+| Area | Test File | Status |
+|------|-----------|--------|
+| [area] | [file] | [exists / missing] |
+
+---
+
+## 3. Proposed Solution
+
+### Chosen Approach: [Name]
+[From brainstorming session — the approach the developer confirmed]
+
+### Alternatives Considered
+| Option | Pros | Cons | Why Not Chosen |
+|--------|------|------|----------------|
+| [Option B] | ... | ... | ... |
+
+### Files to Create / Modify
+| Action | File | Change |
+|--------|------|--------|
+| Create | [path] | [purpose] |
+| Modify | [path] | [what changes] |
+
+### Database Changes
+| Table | Change | Details |
+|-------|--------|---------|
+| [table] | [migration type] | [description] |
+
+---
+
+## 4. Impact Analysis
+
+**Impact Level:** 🟢 Low / 🟡 Medium / 🔴 High
+
+| Area | Impact | Reason |
+|------|--------|--------|
+| [Module] | 🟢 None / 🟡 Minor / 🔴 Major | [why] |
+
+**Breaking Changes:**
+- [ ] None expected
+- [ ] [Breaking change if any]
+
+**Risks:**
+| Risk | Severity | Mitigation |
+|------|----------|------------|
+| [description] | Low / Medium / High | [mitigation] |
+
+---
+
+## 5. Effort Estimate
+
+| Task | Size | Notes |
+|------|------|-------|
+| Tests (TDD) | S/M/L | [N scenarios] |
+| Implementation | S/M/L | [complexity] |
+| Migration / Integration | S/M/L | [if applicable] |
+| **Total** | **S/M/L/XL** | |
+
+> S = <1h · M = 1–4h · L = 4–8h · XL = 8h+ (split recommended)
+
+**Sub-tasks (if XL):**
+- [ ] [Sub-task 1]
+- [ ] [Sub-task 2]
+
+---
+
+## 6. Testing Plan
+
+### Unit Tests
+- [ ] [Scenario to test]
+
+### Integration Tests
+- [ ] [API/service flow to test]
+
+### Manual Test Cases
+- [ ] [Step-by-step]
+```
+
+---
+
+### Step 5: Present to Developer
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+⏸️  GATE 1: REQUIREMENT DOCUMENT READY
+
+Ticket: [ticket-id] — [title]
+File:   plan/[ticket-id]/requirement.md
+
+Summary:
+  Type:     [feature / bug-fix / refactor]
+  Impact:   [Low / Medium / High]
+  Estimate: [S / M / L / XL]
+  Approach: [one-line description]
+
+Please review the requirement document.
+  → Type APPROVED to proceed to implementation plan
+  → Or provide feedback to update the document
+
+⚠️  I will NOT generate code until I receive "APPROVED".
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+---
+
+### Step 6: Handle Feedback
+
+- DEV provides feedback → update `requirement.md` → re-show Gate 1 prompt
+- DEV types `APPROVED` → proceed to Gate 2 (Implementation Plan)
+
+---
+
+## What This Skill Delegates vs Owns
+
+| Concern | Handled by |
+|---------|-----------|
+| Q&A loop (one question at a time) | This skill (inline) |
+| Propose 2–3 solution approaches | This skill (inline) |
+| Root cause tracing (bug tasks) | `superpowers:systematic-debugging` |
+| Impact analysis | This skill |
+| Effort estimate | This skill |
+| requirement.md template & output | This skill |
+| Gate 1 APPROVED gate | This skill |
+
+---
+
+## Mandatory Rules
+
+- ❌ **DO NOT** invoke `superpowers:brainstorming` — its terminal state calls `writing-plans` and bypasses Gate 1 approval
+- ❌ **DO NOT** invoke `superpowers:writing-plans` — that belongs to Gate 2 (`generate-spec` skill)
+- ❌ **DO NOT** proceed past Step 2 if design is not confirmed by developer
+- ❌ **DO NOT** write code at any point in this skill
+- ❌ **DO NOT** skip impact analysis and effort estimate
+- ✅ **MUST** run `git status` + `git pull --ff-only` (Pre-flight) before reading source code, when working tree is clean
+- ✅ **MUST** read source code before Q&A begins
+- ✅ **MUST** save `plan/[ticket-id]/requirement.md`
+- ✅ **MUST** display Gate 1 prompt and wait for `APPROVED`