VeryGoodOpenSource/vgv-wingspan

# Brainstorm a feature or improvement

Clarify **WHAT** to build before diving into **HOW** to build it. Explore user intent, approaches, and design decisions through collaborative dialogue.

## Feature description

<feature description>$ARGUMENTS</feature description>

**If the feature description above is empty, ask the user**: "What feature would you like to brainstorm? Describe the idea, problem or feature you are thinking about."

DO NOT proceed until you have a description from the user.

## Execution flow

# Execute an implementation plan

Take a plan from `docs/plan/` and turn it into shipped code: implement features, write tests, and validate quality.

## Build Progress

Copy this checklist and track your progress:

```markdown
Build Progress:
- [ ] Phase 0: Load plan and confirm scope (or resume a phased build)
- [ ] Phase 1: Read context for the current implementation phase
- [ ] Phase 2: Loop implementation phases (implement → validate → commit or hand off → checkpoint → clear)
- [ ] Phase 3: Run review agents (5 in parallel), consolidate into one report

# Create a new project

Route project creation to the right companion plugin. Wingspan does not scaffold projects itself — it discovers companion plugins from recommendation files and delegates to the matching plugin's create skill.

## Project description

<description>$ARGUMENTS</description>

**If the description above is empty:**

1. First, scan recommendation files (Step 1 below) to discover available project types.
2. Then use **AskUserQuestion tool**:
   - **Question:** "What kind of project would you like to create?"
   - **Options:** Build the option list from the discovered companion plugins' descriptions, plus "Other" as the last option.

# Create a pull request

Stage uncommitted changes, commit them, push the branch, and open a pull request on the project's Git hosting platform.

## Steps checklist

- [ ] Step 0: Parse arguments
- [ ] Step 1: Validate (skip if `SKIP_CHECKS`)
- [ ] Step 2: Assess git state and determine base branch
- [ ] Step 3: Stage and commit
- [ ] Step 4: Push
- [ ] Step 5: Run CI checks (skip if `SKIP_CHECKS`)
- [ ] Step 6: Open PR

# Post-incident debrief

Produce a structured, blameless debrief document after an incident, failed release, or significant bug. Capture what happened, why, and what to change — while the context is still fresh.

**Use this when** a production incident, failed release, flaky deploy, or significant bug warrants more than just a fix — when the team needs to understand *why* it happened and prevent recurrence.

## Incident Context

<incident_context>$ARGUMENTS</incident_context>

**If the incident context above is empty, ask the user**: "What incident would you like to debrief? Describe what happened, link to relevant PRs/commits, or paste error logs."

DO NOT proceed until you have a description from the user.

# Elements of Style

Apply these principles to produce clear, vigorous prose.

## Core Principles

**Omit needless words.** Every word must earn its place. Cut filler phrases:

| Cut | Keep |
|-----|------|
| the question as to whether | whether |
| owing to the fact that | since |
| the fact that he failed | his failure |
| he is a man who | he |

# Hotfix — emergency fix workflow

Apply a minimal, targeted fix fast. No brainstorm document, no plan document — but tests and review are still non-negotiable.

## Bug Description

<bug_description>$ARGUMENTS</bug_description>

**If the bug description above is empty, ask the user**: "What's the bug? Paste a description, issue link, or error message."

DO NOT proceed until you have a bug description.

## Phase 0 — Triage

# Create a new implementation plan (or bug fix)

Transform feature descriptions, bug reports, or improvement ideas into well-structured markdown files that follow VGV conventions and best practices. This command provides flexible detail levels to match your needs.

## Feature Description

<feature_description>$ARGUMENTS</feature_description>

### 0. Idea Refinement

Check for brainstorm output first — before asking the user anything.

```bash
ls docs/brainstorm/

# Plan technical review

Review a plan that was not created by `/plan`. `/plan` runs this same review inline during
creation, so use this skill for externally-authored plans — hand-written, from another tool,
or from a teammate.

**Plan file:** `$ARGUMENTS` (if empty, ask the user for the plan path or pick the most recent file under `docs/plan/`).

## Review

Follow the [plan review procedure](references/plan-review.md) with `<PLAN_PATH>` set to the
plan file. It runs the simplicity, VGV, and scope-splitting agents in parallel, applies their
findings to the plan inline, and resolves any scope-splitting recommendation.

# Rebase onto base branch

Rebase the current feature branch onto the latest base branch to keep it up-to-date and prevent merge conflicts from accumulating.

## Step 1: Validate preconditions

Run these checks in order. If any fail, inform the user and stop.

### Detect current branch and base branch

```bash
git rev-parse --abbrev-ref HEAD
```

# Refine Approach

Improve brainstorm and/or planning documents through structured review.

## Step 1. Get the document that needs review

**Document path:** `$ARGUMENTS`

**If `$ARGUMENTS` is non-empty**, treat it as the document path and proceed to `Step 2. Assess`.

**If `$ARGUMENTS` is empty**, ask the user which document to review. Check `docs/brainstorm/` and `docs/plan/` for recent documents to suggest.

## Step 2. Assess

# Review code on demand

Run quality review agents. Review manually written code, assess existing codebases, or
check a branch before merging. Output is **one consolidated report** with stable,
numbered findings the user can act on by id.

## Review Scope

<review_scope>$ARGUMENTS</review_scope>

## Step 1 — Detect Scope

Parse the review scope above for optional file paths or directories.