StartCAUTION
The most comprehensive Claude Code guide: agentic workflows, hooks, skills, MCP servers, quizzes, and production-ready templates. 430K+ lines.
Overview
The most comprehensive Claude Code guide: agentic workflows, hooks, skills, MCP servers, quizzes, and production-ready templates. 430K+ lines.
d90170da4369OBSERVED · 2026-10-07What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: plan-pipeline-start
description: "5-phase planning: PRD analysis, design review, technical decisions, dynamic research team, metrics. Produces a complete implementation plan + ADRs before any code is written."
effort: high
disable-model-invocation: true
---
# /plan-pipeline:start: 5-phase planning
Analyze the request and produce a complete implementation plan through structured phases. No code is written. Every significant decision is recorded. Run `/clear` after this command before running `/plan-pipeline:validate`.
---
## Phase 1: PRD & design analysis
### Step 1.1: PRD analysis
*Skip if no PRD exists (refactor, infra change, bug fix).*
Read all PRD files and `docs/INFORMATION_ARCHITECTURE.md` if present. Scan the codebase to understand current implementation status.
Surface findings in 3 buckets:
**Missing requirements**: acceptance criteria that are absent or incomplete
**Ambiguous requirements**: items with multiple valid interpretations
**Compliance concerns**: security, data privacy, API contract implications
For each finding: present options with concrete pros/cons. Discuss with user. Record every decision in the plan file under a `## Decisions` section before moving on. Do not proceed past unresolved ambiguities.
### Step 1.2: Design analysis
*Skip if no UI changes are in scope.*
Read: `DESIGN_SYSTEM.md`, existing UX ADRs, CLAUDE.md UX rules.
Produce specs for:
- **Screen inventory**: new/modified screens, route placement, component reuse audit
- **State catalog**: empty, loading, populated, error, and partial states for every interactive element
- **Interaction specs**: user flows (happy path + alternates), focus/keyboard behavior
- **Animation specs**: map each interaction to existing keyframes or specify new ones, include `prefers-reduced-motion` fallbacks
- **Responsive behavior**: breakpoints, web/mobile divergence decisions
- **Accessibility**: WAI-ARIA pattern selection, live regions, error visibility
Create Design ADRs for significant UX decisions (choice of interaction pattern, new animation convention, platform divergence). Record minor layout choices directly in the plan file.
---
## Phase 2: Technical analysis
Spawn 1-2 Explore agents for targeted codebase research. Run them in the background via Task tool.
While agents run, check:
- Existing ADRs in `docs/adr/`: if 3+ ADRs confirm a decision → auto-resolve without asking
- PATTERNS.md: apply confirmed patterns directly
When agents return: present architecture decisions with 2-3 options each, concrete pros/cons, and a recommendation. Ask for user input on each unresolved decision.
For each significant decision:
1. Create `docs/adr/ADR-XXXX.md` using standard Nygard format (Context / Decision / Status / Consequences)
2. Update `docs/adr/PATTERNS.md` with the new observation
---
## Phase 3: Scope assessment
Apply trigger rules to determine which research agents are needed. Present the proposed team with justification for each inclusion.
**Research agent pool:**
| Agent | Trigger | Model |
|-------|---------|-------|
| `code-explorer` | Always | Sonnet |
| `arch-researcher` | Changes touch 2+ architectural layers | Sonnet |
| `database-analyst` | Any DB schema change | Sonnet |
| `security-analyst` | Auth, payments, PII, RBAC, rate limiting | Opus |
| `test-analyzer` | Non-trivial feature (not just a bug fix) | Sonnet |
| `cross-platform-specialist` | Web + mobile parity required | Sonnet |
| `native-app-specialist` | Tasks touch mobile/native UI package | Sonnet |
| `design-system-researcher` | UI changes in scope | Sonnet |
| `dependency-researcher` | New packages being added | Sonnet |
| `devops-specialist` | Docker, env vars, CI/CD changes | Sonnet |
| `integration-researcher` | New services, libraries, OTEL config | Opus |
| `planning-coordinator` | Always, when 2+ agents selected | Opus |
**Tier labels** (descriptive, not prescriptive):
- Tier 0 (0 agents): Solo (inline research, no spawning)
- Tier 1 (1-3 agents): Focused
- Tier 2 (4-6 agents): Standard
- Tier 3 (7-9 agents): Comprehensive
- Tier 4 (10+ agents): Full Spectrum
Tell the user: "I recommend a **[Tier N - Label]** team: [agent list with one-line justification each]. Want to add or remove any agents?"
Wait for approval before Phase 4.
---
## Phase 4: Research & plan creation
**Tier 0**: Conduct inline research. Write plan directly without spawning agents.
**Tier 1+**: Spawn approved agents in parallel using Task tool (run_in_background: true). For each agent, provide:
- Its specific research scope
- The relevant files/areas to investigate
- The questions it needs to answer
Monitor agents by reading their output files directly (TaskOutput was removed in v2.1.278; use `Read` on the output path reported by the agent instead). Report progress: "3/6 agents complete..."
When all agents return: if `planning-coordinator` was spawned, send it all agent reports and have it synthesize the final plan. Otherwise, synthesize directly.
**Plan file structure** (`docs/plans/plan-{name}.md`):
```markdown
# Plan: {feature-name}
Created: {date} | Branch: {branch-name} | Tier: {N}
## Summary
One paragraph: what this implements and why.
## Decisions
Decisions recorded during Phase 1 (PRD analysis).
## Architecture
ADRs created, patterns applied, architectural choices made.
## Tasks
Ordered task list with layers (1 = foundation, 2 = depends on 1, etc.)
### Layer 1
- [ ] Task A: description, files affected, acceptance criteria
- [ ] Task B: description, files affected, acceptance criteria
### Layer 2
- [ ] Task C (depends on A): description, files affected, acceptance criteria
## Test Plan
How each task will be verified. TDD tasks marked explicitly.
## Integration Verification
Smoke test commands to run post-execution (if backend/services in scope).
## Out of Scope
What this plan explicitly does not address.
```
Commit: plan file + ADR files + agent report manifests.
---
## Phase 5: Finalize metrics
Record timestampsTrust audit
CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | WARN |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (2)
whitepapers/recap-cards/en/_extensions
whitepapers/recap-cards/fr/_extensions
Gates applied: no_behavioural_pass.
d90170da4369full audit observations/trust-audit/skill/florianbruniaux__start.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-07 | d90170da4369 | CAUTION | B | 89 | first audit |
Questions
What does the Start skill do?
The most comprehensive Claude Code guide: agentic workflows, hooks, skills, MCP servers, quizzes, and production-ready templates. 430K+ lines.
Is Start safe to install?
With care. The audit graded it B (89/100) and found 2 things worth knowing before you trust this skill, listed below with the exact line each was found on.
What can Start access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
How current is this page?
The grade is for one exact copy of the source (d90170da4369), read on 2026-10-07. The repository is watched, and a new audit runs when it changes — this is the first audit.