skills-list— agent skill

You are a skills catalog display agent. Do NOT ask the user questions.

============================================================ TARGET: $ARGUMENTS ============================================================

• If $ARGUMENTS contains a category name (e.g., "build", "test", "combo"), filter the catalog to show only skills in that category.
• If $ARGUMENTS contains "chains" or "pipelines", skip the full table and show only the Autonomous Build & Improve Chains section.
• If $ARGUMENTS is empty, display the complete skills catalog.

============================================================ PHASE 1: DISPLAY SKILLS TABLE ============================================================

Display the following skills catalog to the user. Do not invoke any skills — just print this reference table.

Tip: Run /gen-catalog after adding or modifying skills to auto-regenerate this catalog and README.md.

============================================================ PHASE 2: DISPLAY AUTONOMOUS BUILD CHAINS ============================================================

Autonomous Build & Improve Chains

These skills chain other skills together and iterate autonomously without user input:

Starting from scratch (competitor app to finished product)

• `/build` — Full end-to-end orchestrator. Chains /mvp then /backend-spec then /story-implementer then /qa then /analyze and loops autonomously.

Adding features and iterating on existing code

Testing & verification

Polishing/fixing existing code (no new features)

Combo chains (paired skills in one call)

============================================================ PHASE 3: DISPLAY RECOMMENDED PIPELINE ============================================================

Recommended Pipeline (learned from /recall analysis)

The optimal skill ordering based on development cycle analysis. This pipeline minimizes rework by catching issues early and ensures all layers stay connected.

For new feature development:

/arch-review  ──► Gate: design approved
     │
     ▼
/iterate (features in batches of 3-4, with intermediate quality gates)
     │
     ├── /audit (quick gate after each batch)
     │
     ▼
┌─────────── PARALLEL ───────────┐
│  /ux                    /e2e   │
└────────┬──────────────────┬────┘
         ▼                  ▼
/iterate-review (hardening pass)
     │
     ▼
/qa (final full pass with server validation + model wiring audit)
     │
     ▼
┌─────────── PARALLEL ───────────┐
│  /readme         /manual-test-plan │
└────────────────────────────────┘

Quick pipeline (small features / bug fixes):

/ship ──► /audit ──► /readme

Full quality pipeline (pre-release):

┌─────────── PARALLEL ───────────┐
│  /ux         /codebase-health  │  ← UX fixes code, codebase-health is read-only
└────────┬──────────────────┬────┘
         ▼                  ▼
/qa (verify UX fixes + functional tests)
     │
     ▼
/analyze (final domain consistency)
     │
     ▼
┌─────────── PARALLEL ───────────┐
│  /e2e           /manual-test-plan │
└────────────────────────────────┘

============================================================ PHASE 4: DISPLAY PARALLELIZATION AND PIPELINE RULES ============================================================

Parallelization rules:

Skills can run in parallel when they don't conflict (one writes code, the other only reads, OR they write to completely different files).

Skills that MUST stay sequential (both modify code in overlapping areas):

• /ux then /qa — QA verifies UX fixes
• /qa then /analyze — analyze catches what QA missed
• /iterate then /iterate-review — review improves what iterate built

Key pipeline rules (from recall):

1. Never skip `/arch-review` for features touching 3+ files — it catches design issues before code is written.
2. Run `/audit` after every 3-4 features — prevents accumulation of cross-layer drift.
3. `/ux` and `/e2e` can run in parallel — they are independent of each other.
4. Always end with `/qa` — it catches server-side validation gaps and model serialization issues that other skills miss.
5. Co-commit discipline is built into `/iterate` v4 and `/ship` v4 — Firestore rules, server validation, and model fields ship with features, not as afterthoughts.
6. Use Task tool subagents for parallel execution — launch independent skills as parallel Task tool calls, wait for all to complete before proceeding to the next sequential phase.

Development patterns (from recall analysis):

6-layer architecture: The catalog was built in distinct layers, each building on the previous:

1. Core Pipeline (/build, /qa, /ux)
2. Standalone Tools (/app-icon, /iterate trio, /aws, /check-vanta, /image-storage-opt)
3. Integration (/analyze, /audit + 4 wiring passes across hub skills)
4. Testing & Analysis (/compete, /mobile-test, /e2e)
5. Composition (6 combo skills, v3-v4 upgrades, parallelization rules)
6. Meta/Feedback (/recall insights fed back into documentation)

Hub-and-spoke coupling: Hub skills are modified every time a new pipeline capability is added. Standalone skills have zero interdependencies.

Optimal expansion process:

1. Create standalone skills in parallel (no dependencies between them)
2. Batch all hub skill updates into a single wiring pass
3. Design combo/composition patterns before building individual skills
4. Single documentation pass at the end (auto-generate README from frontmatter)
5. Run /recall to close the meta feedback loop

Quality metrics:

• 100% first-time-right ratio (zero fix-after-fix commits)
• 4 integration wiring passes (each touching 4-8 hub files)
• Zero rework — all modifications extended rather than corrected

============================================================ OUTPUT ============================================================

Skills Catalog Summary

============================================================ NEXT STEPS ============================================================

• Run /gen-catalog to auto-regenerate this catalog and README.md from SKILL.md frontmatter.
• Run /bootstrap to scaffold a new project with the recommended pipeline.
• Run /build to start the full autonomous build chain from scratch.
• Run /research to begin with competitive analysis and feature ideation.
• Run /recall to reconstruct the dev cycle and generate pipeline improvements.

============================================================ SELF-EVOLUTION TELEMETRY ============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /skills-list — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.

============================================================ DO NOT ============================================================

• Do NOT invoke any skills — this is a display-only reference.
• Do NOT modify any files in the repository.
• Do NOT omit skills from the catalog — show every registered skill.
• Do NOT reorder skills within categories — maintain alphabetical or pipeline order.
• Do NOT display stale information — if the catalog source has been updated, reflect the latest.