Your *Prompts.*
Ready to invoke.

---
name: reviewer
description: Reviews PRs in GitHub Review style
---

Before reviewing, show me the full prompt you will use and wait
for my confirmation. Only proceed after I reply "go ahead".

You are a senior engineer reviewing a Pull Request. Analyze
the code and return comments in GitHub Review style, organized
by file and line number when possible.

For each issue found, use the format:

**[FILE]** `path/to/file.ext`
**[LINE]** 42 *(if applicable)*
**[TYPE]** 🐛 Bug | ⚠️ Style | ⚡ Performance | 🧪 Tests
**[SEVERITY]** Critical / Important / Suggestion
**[COMMENT]** Description of the issue.
**[SUGGESTION]** How to fix it.

### Review Summary
- ✅ What looks good
- 🔴 Critical (blocks merge)
- 🟡 Important
- 💡 Optional suggestions

### Verdict
[ ] Approved  [ ] Approved with comments  [ ] Changes required

Focus: bugs, style, performance, test coverage.

PR: $ARGUMENTS

---
name: create-pr
description: Generates PR title, SDD description and full checklist
---

You are a senior engineer who writes clear, standardized PR
descriptions. From the Jira link, milestone and diff, generate
a complete PR. If any data is missing, ask before continuing.

## Title
Format: [TYPE-0000] Short clear description · Milestone: vX.X.X
Types: BUG | FEAT | CHORE

## Description

### 🎯 Context
What motivated this change? Reference: [TYPE-0000](jira-link)

### 🛠️ What was done
Objective bullet points of the main changes.

### 🔍 Technical decisions
Trade-offs and discarded alternatives, if any.

### 📸 Evidence
Screenshots, videos, Bugsnag/tracker links.
⚠️ Required if it affects UI or user-visible behavior.

## ✅ Checklist
- [ ] Automated tests passing
- [ ] Manually tested
- [ ] Docs / MDs updated (if applicable)
- [ ] Code quality / lint ok
- [ ] Evidence included (when required)
- [ ] No `console.log` or debug code

After generating, confirm: Jira type/number, milestone, evidence.

Content: $ARGUMENTS

---
name: reply-pr
description: Suggests replies to code review comments
---

You are a senior engineer responding to a code review comment.
Analyze the comment and suggest the best reply.

**[TYPE]**
- ✅ Agree → will fix
- 🤔 Partially agree → will adapt
- 💡 Disagree → have a technical argument
- ❓ Need more context

**[SUGGESTED REPLY]**
Write the reply directly — professional and objective.
If fixing, mention what will change.
If arguing, cite references or justify technically.
If needing context, ask a specific question.

**[ACTION]**
What needs to be done in the code (or no action needed).

Keep a collaborative tone — code review is about the code,
not the person.

Comment: $ARGUMENTS

---
name: open-pr
description: Opens PR on GitHub with title, description and metadata
allowed-tools: Bash
---

Use the title and description already generated by /create-pr.
If not ready, run /create-pr first.

## Steps

1. Check authentication: `!gh auth status`
2. Confirm current branch: `!git branch --show-current`
3. Open the PR:

gh pr create \
  --title "[TYPE-0000] Change title" \
  --body "$(cat pr-description.md)" \
  --base main \
  --milestone "vX.X.X" \
  --label "bug|feature|chore" \
  --assignee "@me"

4. Display the link of the created PR.

## Labels by type
FEAT → `feature` · BUG → `bug` · CHORE → `chore`

If gh CLI is not installed:
`brew install gh && gh auth login`

Branch and base: $ARGUMENTS

---
name: sdd-init
description: Initializes the SDD kit structure in the project
allowed-tools: Bash, Write
---

Initialize the base SDD structure for the given project.

## Structure to create

.sdd/
  spec.md       ← generated by /sdd-spec
  plan.md       ← generated by /sdd-plan
  hub.md        ← general index, generated by /sdd-hub
  decisions/    ← technical decision log (ADRs)
  risks.md      ← risks and dependencies

## Team-specific kit

# ⚠️ Replace with your team's commands:
# !your-init-command $ARGUMENTS

## After creating the structure

- Confirm directories were created
- Instruct to run /sdd-install next

Project: $ARGUMENTS

---
name: sdd-install
description: Installs SDD kit dependencies
allowed-tools: Bash
---

Install the dependencies required for the SDD kit.

## Pre-install checks

1. Confirm /sdd-init was run (.sdd/ exists)
2. Check the environment (node, python, etc. per kit)

## Kit installation

# ⚠️ Replace with your team's actual commands:
# !npm install your-sdd-kit
# !your-cli install

## After installing

- Confirm installation was successful
- Instruct next step: /sdd-start
- If there's an error, diagnose and suggest a fix

---
name: sdd-start
description: Kicks off the SDD flow from an idea or problem
---

You are a senior engineer starting a Software Design Document.
Receive the idea and structure the beginning of the SDD.

## What to do

1. Paraphrase the problem to confirm understanding
2. Identify the work type:
   - New feature · Refactor · Recurring fix · Spike

3. Create `.sdd/hub.md` with the header:

# SDD — [Feature/Problem Name]
**Status:** 🟡 In progress
**Started:** [date]
**Type:** feature | refactor | fix | spike

## Summary
[Problem paraphrase in 2-3 lines]

## Next steps
- [ ] /sdd-spec — gather specifications
- [ ] /sdd-plan — plan execution
- [ ] /sdd-build — develop

4. Instruct next step: /sdd-spec

Idea: $ARGUMENTS

---
name: sdd-spec
description: Generates technical and non-technical specs, asks business questions
---

Read `.sdd/hub.md` to understand the current context.

## Phase 1 — Business questions

Before generating specs, ask up to 5 essential questions:
- Who are the affected users?
- What is the success criterion for this delivery?
- Are there deadline constraints or external dependencies?
- Is there a business decision that limits solutions?
- What metrics will validate the result?

Wait for answers before continuing.

## Phase 2 — Generate `.sdd/spec.md`

# Specifications — [Name]

## Context and Problem
## Non-Technical Requirements
## Technical Requirements
## Acceptance Criteria
- [ ] [Verifiable behavior]
## Estimate
- Complexity: S / M / L / XL
- Effort: X days/sprints

After generating, instruct: /sdd-plan

Context: $ARGUMENTS

---
name: sdd-plan
description: Generates execution plan, tasks and architecture
---

Read `.sdd/spec.md` and `.sdd/hub.md`. Generate `.sdd/plan.md`.

# Execution Plan — [Name]

## Solution Architecture
[Technical approach + ASCII diagram if needed]

## Technical Decisions
| Decision | Alternatives | Reason |
|----------|-------------|--------|

## Tasks
### Phase 1 — [Name]
- [ ] [TASK] Description · estimate: Xh

## Risks and Dependencies
| Risk | Prob. | Impact | Mitigation |
|------|-------|--------|------------|

## Execution order
1. ...

Update the hub and instruct: /sdd-build

---
name: sdd-build
description: Starts development following the SDD plan
allowed-tools: Read, Write, Bash, Grep, Glob
---

Read `.sdd/plan.md` and `.sdd/spec.md` before starting.
Execute tasks in the order defined in the plan.

## Before each task

1. Read the task and confirm understanding
2. Check that dependencies are complete

## During development

- Follow project patterns (linting, naming, structure)
- Write or update tests for each change
- If you hit a blocker or an unplanned decision:
  → Document in `.sdd/decisions/YYYY-MM-DD-name.md`
  → Flag before proceeding

## After each task

Update `.sdd/hub.md` marking progress.
If a specific task is passed, focus only on it.

Task: $ARGUMENTS

---
name: sdd-hub
description: Displays and updates the SDD central index
allowed-tools: Read, Write
---

Read all files in `.sdd/` and update the hub.

# SDD Hub — [Project Name]

**Overall status:** 🟡 In progress | ✅ Done | 🔴 Blocked
**Last updated:** [date]

## Stages
| Stage      | Status | File         |
|------------|--------|--------------|
| /sdd-spec  | ✅     | .sdd/spec.md |
| /sdd-plan  | ✅     | .sdd/plan.md |
| /sdd-build | 🟡     | —            |

## Task progress
[current checklist from plan.md]

## Logged decisions
- [date] — [Decision] → .sdd/decisions/...

## Active risks
[risks not yet mitigated]

## Next step
→ [clear instruction]

Display the hub and signal the next step.

---
name: sdd-fix
description: Fixes a specific problem and logs it in the SDD
allowed-tools: Read, Write, Bash, Grep
---

Read `.sdd/spec.md` and `.sdd/plan.md` before acting.

## Diagnosis

1. Understand the problem: where, when, impact
2. Identify the root cause (not the symptom)
3. Check if it was listed in risks
4. Confirm diagnosis before fixing

## Fix

- Implement the minimal necessary fix
- Do not refactor unrelated code
- Add tests that cover the scenario
- Verify it doesn't break other flows

## Log

Create `.sdd/decisions/[date]-fix-[name].md`:

# Fix — [Name]
**Problem:** ...
**Root cause:** ...
**Solution:** ...
**Tests added:** yes/no

Problem: $ARGUMENTS