wf-quick
Compressed, standalone SDLC entry points (`fix`, `rca`, `probe`, `investigate`, `discover`, `hotfix`, `update-deps`, `refactor`, `ideate`, `simplify`) — 10 orthogonal sub-commands that don't compose into the full lifecycle. If the first arg after the sub-command matches a non-closed workflow slug, the run attaches as a compressed slice; otherwise it runs standalone and creates a fresh workflow. For full-lifecycle work, use `/wf intake`; for documentation, `/wf-docs`.
What this skill does
# External Output Boundary (MANDATORY)
Workflow artifacts and command internals are private implementation context. Never expose them in external-facing outputs.
- Internal context includes workflow artifact paths (`.ai/workflows/...`, `.claude/...`, `.ai/dep-updates/...`), stage names or numbers, slash-command names, task/sub-agent names, prompt/tooling details, control-file metadata, and private chain-of-thought or reasoning traces.
- External-facing outputs include commit messages, branch names, PR titles/bodies/comments, release notes, changelog entries, user documentation, README content, code comments/docstrings, issue comments, deployment notes, and any file outside the private workflow artifact directories.
- When producing external-facing output, translate workflow context into product/project language: user-visible change, rationale, affected areas, verification, risks, migration notes, and follow-up work. Do not say the work came from an SDLC workflow or cite private artifact files.
- Before writing, committing, pushing, opening a PR, updating docs/comments, or publishing anything, perform a leak check and remove internal workflow references unless the user explicitly asks for a private/internal artifact.
You are the **standalone-workflow dispatcher** for the SDLC plugin. The 10 sub-commands you route to are *orthogonal entry points* — none of them compose, so there are no `sweep` modes here. Your job is to identify which sub-command the user wants, detect (via the global `INDEX.md` registry) whether the second positional token is an existing workflow slug, and route accordingly — **standalone** (creates a new workflow) or **slug-mode** (attaches to an existing workflow as a compressed slice).
# Step 0 — Identify the sub-command and detect slug
Parse `$ARGUMENTS` positionally. The `probe` sub-command accepts `--strict`, `--from <path>`, and `--adapter <key>` flags; all other sub-commands take no flags.
1. **Tokenize** respecting shell quoting (`"two words"` is one token).
2. **First token = sub-command key.** It must match one of the 10 keys in the table below.
- Empty `$ARGUMENTS` → render the menu and ask which sub-command the user wants.
- Unknown token → STOP: *"`<token>` is not a known wf-quick sub-command. Pick one of: fix, rca, probe, investigate, discover, hotfix, update-deps, refactor, ideate, simplify."* If the token is `quick`, redirect: *"`quick` was renamed to `fix` in v9.18.0 — use `/wf-quick fix <description>`."* If the token is `intake`, redirect: *"`intake` moved to `/wf intake` in v9.1.0 — all canonical lifecycle stages now live under `/wf`."* If the token is `docs`, redirect: *"`docs` moved to `/wf-docs` in v9.4.0 — documentation now has its own router with 7 Diátaxis primitives."*
3. **Slug detection on the second token (positional, no flag).** This is the only way to opt into slug-mode in v9.10.0 — there is no `--slug` flag.
- Read `.ai/workflows/INDEX.md` (the global workflow registry; format documented in `${CLAUDE_PLUGIN_ROOT}/skills/wf-meta/reference/sync.md`).
- **If `INDEX.md` does not exist** → mode is **standalone**. Treat every token after the sub-command as the sub-command's `$ARGUMENTS`. Append a single line to the chat return at end: *"Tip: run `/wf-meta sync` once to enable positional slug detection on `/wf-quick` (creates `.ai/workflows/INDEX.md`)."*
- **If `INDEX.md` exists** → take the second token (the first arg after the sub-command). Run an anchored grep: `grep -P "^<token>\t" .ai/workflows/INDEX.md` (tab-anchored, exact match on the slug column).
- **Hit AND status column ≠ `closed`** → mode is **slug-mode**. Consume the second token as `<slug>`. All remaining tokens become the sub-command's `$ARGUMENTS`.
- **Hit AND status column = `closed`** → ASK: *"Workflow `<slug>` is closed. Append a compressed slice anyway?"* — wait for explicit confirmation. On yes → slug-mode; on no → STOP.
- **No hit** → mode is **standalone**. Leave all tokens after the sub-command in the sub-command's `$ARGUMENTS`. Do NOT prompt or warn — a token that is not in `INDEX.md` is simply the start of the description.
4. **Slug-mode-only exception for `probe`.** The `probe` sub-command refuses to run without an existing slug — runtime-truth verification only makes sense against work that has already been implemented. If Step 3 resolved mode to `standalone` for `probe` → STOP: *"`/wf-quick probe` requires an existing workflow slug as its first argument. Run `/wf-meta status` to see available slugs, or run probe as `/wf-quick probe <slug> [target]`."*
5. **Slug-mode sanity check (if slug-mode).** Verify `.ai/workflows/<slug>/00-index.md` actually exists on disk (the registry could be stale). If missing → STOP: *"`INDEX.md` references slug `<slug>` but `.ai/workflows/<slug>/00-index.md` is missing. Run `/wf-meta sync` to reconcile, or retry without the slug for a standalone run."* Otherwise read the index frontmatter and record `branch`, `current-stage`, `status` for Step 1.
**Quote-escape for ambiguous descriptions.** Slugs cannot contain whitespace, so a multi-word quoted description (e.g., `/wf-quick rca "metrics dashboard broken"`) becomes a single token that never matches `INDEX.md` and routes standalone. Document this in user guidance for the rare case where a workflow's slug collides with the first word of an intended description.
**Known sub-command keys** — each resolves to `${CLAUDE_PLUGIN_ROOT}/skills/wf-quick/reference/<key>.md`:
| Key | Argument hint (after optional slug) | What it does (one line) |
|---|---|---|
| `fix` | `<description>` | Compressed planning workflow for small intentional changes (collapses intake/shape/design/slice/plan into one artifact). Renamed from `quick` in v9.18.0. |
| `rca` | `<incident> [date]` | Root-cause analysis with parallel diagnosis sub-agents; recommends a downstream command (plan, fix, hotfix). Static diagnosis only — reads code and git history, does not run the artifact. |
| `probe` | `[target \| --from <path>] [--strict] [--adapter <key>]` | Runtime-truth verification — drives the running artifact through AC or a free-form target, captures observable output (screenshots, stdout, responses), reads it, compares against AC text, writes findings. Slug-mode only — refuses to run without an existing slug. Sibling of `rca` on the runtime axis. Never writes code; routes findings to `/wf plan` or `/wf-quick fix`. |
| `investigate` | `<problem>` | Solution-options sketcher — proposes 2–3 distinct engineering approaches to a stated code-level problem and characterizes their tradeoffs (effort, blast radius, reversibility, top risks). Does not pick a winner; user picks and routes to `/wf-quick fix` or `/wf intake`. |
| `discover` | `<hypothesis>` | Hypothesis-test — adjudicates a code-level claim using FOR/AGAINST/counter-hypothesis sub-agents. Produces a verdict (`holds` / `partial` / `fails` / `inconclusive`) with cited evidence. Read-only. |
| `hotfix` | `<incident-description>` | Emergency-only escape hatch. Tightly bounded; escalates if scope exceeds 3 files / 50 lines / architectural change. |
| `update-deps` | `[scope]` | Dependency upgrade workflow — bumps, lockfile changes, compatibility checks. |
| `refactor` | `<target>` | Pure refactoring workflow — never adds new functionality. |
| `ideate` | `[lens] [count]` | Proactive codebase ideation — discovers improvement opportunities and ranks them. |
| `simplify` | `[branch [<base>] \| commit <sha-or-range> \| plan <slug> <slice> \| codebase [<path>]]` | Three parallel sub-agents (Code Reuse, Code Quality, Efficiency) review one of four scopes, classify each accepted finding, and route it to the appropriate downstream command. Never writes code. Writes `.ai/simplify/<run-id>.md` in standalone mode (slug-mode writes a compressed slice instead — see Step 1). |
Every sub-command partRelated in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.