How a Product Person Ships Real Products

---
description: Review code, add comments, write tests, and run quality checks
allowed-tools: Read, Write, Bash(npm test:*), Bash(npm run lint:*), Bash(npm run format:*), Bash(git:*)
argument-hint: [file-or-directory]
---

Review and test: $ARGUMENTS

## Rules:
- **NO regressions** - run `npm test` after EVERY file change
- **NO logic changes** - only add comments, never modify functional code
- If tests fail after a change -> revert immediately with `git checkout -- `

## Process:

1. **Baseline**: Run `npm test` first. If failing, STOP.

2. **Review code** for bugs, security issues, and missing error handling

3. **Add comments**:
   - Explain WHY, not what
   - Document edge cases and assumptions
   - Reference related code/docs

4. **Write tests** for new functionality (target 80% coverage)

5. **Run quality checks**:
   npm run lint && npm run format && npm test
   Revert any change that breaks tests.

6. **Update** `/tests/README.md` with new test files or testing instructions

7. **Report**: Show test results, linting summary, and files changed

---
name: ask-questions-if-underspecified
description: Clarify requirements before implementing.
---

# Ask Questions If Underspecified

## Goal

Ask the minimum set of clarifying questions needed to avoid wrong work; do not start implementing until the must-have questions are answered (or the user explicitly approves proceeding with stated assumptions).

## Workflow

### 1) Decide whether the request is underspecified

Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear:
- Define the objective (what should change vs stay the same)
- Define "done" (acceptance criteria, examples, edge cases)
- Define scope (which files/components/users are in/out)
- Define constraints (compatibility, performance, style, deps, time)
- Identify environment (language/runtime versions, OS, build/test runner)
- Clarify safety/reversibility (data migration, rollout/rollback, risk)

If multiple plausible interpretations exist, assume it is underspecified.

### 2) Ask must-have questions first (keep it small)

Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work.

Make questions easy to answer:
- Optimize for scannability (short, numbered questions; avoid paragraphs)
- Offer multiple-choice options when possible
- Suggest reasonable defaults when appropriate (mark them clearly as the default/recommended choice)
- Include a fast-path response (e.g., reply `defaults` to accept all recommended/default choices)
- Include a low-friction "not sure" option when helpful
- Separate "Need to know" from "Nice to know" if that reduces friction

### 3) Pause before acting

Until must-have answers arrive:
- Do not run commands, edit files, or produce a detailed plan that depends on unknowns
- Do perform a clearly labeled, low-risk discovery step only if it does not commit you to a direction

### 4) Confirm interpretation, then proceed

Once you have answers, restate the requirements in 1-3 sentences, then start work.

---
description: Compact context with explicit preservation rules
---

Perform a smart compaction:

## MUST PRESERVE (never summarize away):
1. Current task/goal
2. All file paths mentioned in last 10 messages
3. Any explicit decisions or constraints I stated
4. Error messages and their solutions
5. The current plan/checklist if one exists

## CAN SUMMARIZE:
1. Exploration that led to dead ends
2. Verbose output from commands (keep just the conclusion)
3. File contents that haven't been modified
4. General discussion that led to decisions (keep just decisions)

## FORMAT:
After compaction, start your next message with:

📦 Context compacted. Preserved:
- [key item 1]
- [key item 2]
- [current goal]

Now perform /compact with these rules in mind.