@minhduydev/mdpi 0.4.0 → 0.5.0

package/dist/template/.pi/workflows/frontend-feature-workflow.md

@@ -0,0 +1,343 @@
+---
+description: Full frontend feature workflow — design analysis → deslop → architecture → craft polish → parallel implementation → hardening → quality audit (7 phases)
+---
+
+# frontend-feature-workflow
+
+Multi-agent workflow for building production-quality frontend features. Chains 7 phases: design analysis, baseline cleanup, component architecture, craft polish, parallel implementation, hardening, and quality audit.
+
+## Args
+
+- `feature` (required) — The frontend feature or component to build
+- `mockup` (optional) — URL or path to Figma mockup, screenshot, or design reference
+
+## Phases
+
+### Phase 1: Design Analysis
+
+- **Agent:** vision
+- **Concurrency:** 1
+- **Depends on:** —
+- **Tool:** `subagent` (single mode)
+- **Skill:** `figma` (if mockup provided), `mockup-to-code` (if screenshot provided)
+
+**Pre-Flight: Load DESIGN.md + aesthetic skills.** Before analyzing any mockup or design file: (1) read `.pi/DESIGN.md` (fallback: `.pi/templates/DESIGN.md`) to load project mood, color palette, typography scale, and design constraints; (2) load `frontend-design` and `design-taste-frontend` skills via `/skill:frontend-design` and `/skill:design-taste-frontend`. Use DESIGN.md prose as the aesthetic anchor — the Overview section's specific reference sets the tone for all subsequent design decisions.
+
+Also load `design-taste-frontend` and `frontend-design` skills — they enforce the aesthetic rules that translate DESIGN.md's prose into concrete component styling decisions.
+
+**Prompt:**
+
+```
+Analyze the design for: {feature}. 
+
+If a mockup is provided ({mockup}):
+- Extract layout structure (grid, sections, spacing patterns)
+- Identify all visual components (buttons, cards, inputs, navigation)
+- Extract color palette (primary, accent, neutrals, semantic tokens)
+- Identify typography (font families, sizes, weights, hierarchy)
+- Note responsive breakpoint behavior
+- Identify animation/motion patterns
+- Flag any accessibility concerns in the design
+
+If no mockup is provided:
+- Based on the feature description, recommend a layout structure
+- Suggest component decomposition
+- Propose a color palette (OKLCH tokens preferred)
+- Recommend typography pairings
+
+Return findings in this format:
+
+## Layout Structure
+- [Grid/stack/split-screen description]
+
+## Components Identified
+| Component | Type | States | Priority |
+|-----------|------|--------|----------|
+| [name] | [button/card/form/...] | [default, hover, active, disabled, loading, error] | [P0/P1/P2] |
+
+## Design Tokens
+- Colors: [primitive + semantic tokens]
+- Typography: [font stack, scale, weights]
+- Spacing: [scale reference]
+- Motion: [animation patterns]
+
+## Accessibility Notes
+- [Potential issues or considerations]
+```
+
+### Phase 2: Baseline Cleanup
+
+- **Agent:** general
+- **Concurrency:** 1
+- **Depends on:** Phase 1
+- **Tool:** `subagent` (single mode)
+- **Skill:** `baseline-ui`
+
+**Prompt:**
+
+```
+Apply the baseline-ui deslop pass to the feature: {feature}.
+
+Using the design analysis from Phase 1 ({phase_1_output}):
+
+1. Scan existing code (if any) or scaffold for:
+   - MUST violations: purple gradients, banned fonts (Inter/Roboto/Arial), emojis, h-screen, div onClick
+   - SHOULD violations: inconsistent spacing, raw color values, missing semantic tokens
+   - NEVER violations: pure black (#000), centered hero with high variance, 3-column identical cards
+
+2. Apply fixes for each violation found. Use the before/after patterns from baseline-ui.
+
+3. Verify all MUST rules pass after fixes.
+
+Return the list of fixes applied and verification results.
+```
+
+### Phase 3: Component Architecture
+
+- **Agent:** plan
+- **Concurrency:** 1
+- **Depends on:** Phase 2
+- **Tool:** `subagent` (single mode)
+- **Skill:** `frontend-design`
+
+**Prompt:**
+
+```
+Plan the component architecture for: {feature}.
+
+Based on the design analysis ({phase_1_output}) and baseline cleanup ({phase_2_output}):
+
+1. Decompose the feature into components:
+   - Page-level components (layout containers)
+   - Section components (feature areas)
+   - Shared/primitive components (reusable across sections)
+   - Leaf components (specific interactive elements)
+
+2. For each component, specify:
+   - Props interface (TypeScript)
+   - State requirements (local, lifted, context, server)
+   - Loading/empty/error state design
+   - Accessibility requirements (ARIA roles, keyboard handling)
+   - Data dependencies
+
+3. Define the component tree with parent-child relationships.
+
+4. Identify which components can be built in parallel (no shared state, no parent-child dependency).
+
+Return the architecture plan in this format:
+
+## Component Tree
+```
+PageLayout
+├── Header
+│   ├── Navigation
+│   └── UserMenu
+├── MainContent
+│   ├── SectionA
+│   │   ├── ComponentA1
+│   │   └── ComponentA2
+│   └── SectionB
+│       └── ComponentB1
+└── Footer
+```
+
+## Component Specs
+### [ComponentName]
+- **Type:** [page/section/shared/leaf]
+- **Props:** [TypeScript interface]
+- **State:** [local/lifted/context/server]
+- **States:** [loading, empty, error, default]
+- **Accessibility:** [ARIA, keyboard, focus]
+- **Data:** [dependencies]
+
+## Parallel Build Groups
+- Group 1: [components that can be built simultaneously]
+- Group 2: [components that can be built simultaneously]
+```
+
+### Phase 4: Craft Polish
+
+- **Agent:** general
+- **Concurrency:** 1
+- **Depends on:** Phase 3
+- **Tool:** `subagent` (single mode)
+- **Skill:** `ui-craft-principles`, `oklch-color-workflow`
+
+**Prompt:**
+
+```
+Apply craft polish to the component architecture for: {feature}.
+
+Using the architecture plan ({phase_3_output}) and design tokens ({phase_1_output}):
+
+1. Verify and enhance color tokens using OKLCH:
+   - Convert any HEX/RGB tokens to OKLCH
+   - Check gamut for all colors
+   - Generate 50-950 scale for primary and accent
+   - Define semantic tokens from primitives
+   - Verify contrast ratios (4.5:1 min for text)
+
+2. Apply craft principles to each component:
+   - Concentric border-radius (outer = inner + padding)
+   - Optical text alignment (-0.05em margin for visual centering)
+   - Multi-shadow layering (not single box-shadow)
+   - Interruptible animations (spring-based, not duration-based)
+   - Tabular numbers for data displays
+   - Hit areas ≥ 44px for interactive elements
+   - Focus ring offset (outline-offset: 2px)
+
+3. Define motion specs:
+   - Animation duration hierarchy (100ms/200ms/300ms/500ms)
+   - Easing: exponential only (cubic-bezier(0.16, 1, 0.3, 1))
+   - prefers-reduced-motion handling
+
+Return the enhanced design specs with before/after for each craft improvement.
+```
+
+### Phase 5: Parallel Implementation
+
+- **Agent:** general
+- **Concurrency:** Dynamic: 1..5
+- **Notes:** One subagent per build group from Phase 3.
+- **Depends on:** Phase 4
+- **Tool:** `subagent` (parallel mode)
+- **Skill:** `frontend-ui-engineering`, `react-best-practices`
+
+**Prompt:**
+
+```
+Implement the components for build group: [assigned group] in feature: {feature}.
+
+Using the architecture plan ({phase_3_output}) and craft polish specs ({phase_4_output}):
+
+1. For each component in your assigned group:
+   - Implement the component with full TypeScript types
+   - Handle all states: loading, empty, error, default, active, disabled
+   - Apply all craft principles from the polish phase
+   - Use semantic HTML and ARIA attributes
+   - Add keyboard navigation support
+   - Use the exact design tokens (colors, spacing, typography)
+
+2. Follow frontend-ui-engineering patterns:
+   - Composition over configuration
+   - Colocate component files (component + test + types)
+   - Separate data fetching from presentation
+   - Components < 200 lines; split if larger
+
+3. Apply react-best-practices:
+   - Server Components by default, Client Components only for interactivity
+   - Memoize expensive computations
+   - Optimize re-renders
+
+Return each component implementation with its test file.
+```
+
+### Phase 6: Hardening
+
+- **Agent:** general
+- **Concurrency:** 1
+- **Depends on:** Phase 5
+- **Tool:** `subagent` (single mode)
+- **Skill:** `production-hardening`, `fixing-accessibility`
+
+**Prompt:**
+
+```
+Apply production hardening to the implemented feature: {feature}.
+
+Using the implemented components ({phase_5_output}):
+
+1. Production hardening checklist:
+   - Text overflow: add truncation, word-break for long content
+   - i18n readiness: 30% text expansion allowance, RTL support
+   - Error states: what happened + why + how to fix
+   - Empty states: don't show blank screens, provide guidance
+   - Loading states: skeleton loaders matching exact layout
+   - Input validation: HTML5 + JS, sanitization, max lengths
+   - Edge cases: 0 items, 1 item, many items, very long names, missing images
+   - Cross-browser: -webkit-appearance, scrollbar styling, safe area insets
+
+2. Accessibility fixes (WCAG 2.1 AA):
+   - Keyboard navigation: all interactive elements reachable via Tab
+   - Focus management: visible focus indicators, trap in modals
+   - ARIA labels: all icon buttons, form inputs labeled
+   - Color contrast: verify 4.5:1 for text, 3:1 for UI elements
+   - Heading hierarchy: logical H1-H6, no skipped levels
+   - Touch targets: minimum 44x44px
+   - Screen reader: meaningful content and structure
+
+Return hardening report with each issue found and fix applied.
+```
+
+### Phase 7: Quality Audit
+
+- **Agent:** review
+- **Concurrency:** 1
+- **Depends on:** Phase 6
+- **Tool:** `subagent` (single mode)
+- **Skill:** `ui-quality-audit`
+
+**Prompt:**
+
+```
+Run a 5-dimension quality audit on the completed feature: {feature}.
+
+Using all previous phase outputs:
+
+Score each dimension 0-4:
+
+1. **Accessibility** (0-4): keyboard, ARIA, contrast, focus, semantic HTML
+2. **Performance** (0-4): bundle size, render performance, animation perf, image optimization
+3. **Theming** (0-4): token consistency, dark mode, color contrast, typography scale
+4. **Responsive** (0-4): breakpoints, touch targets, content reflow, viewport meta
+5. **Anti-patterns** (0-4): AI fingerprints, dead code, over-engineering, inconsistent patterns
+
+For each finding, tag severity:
+- **P0**: Ship blocker — must fix before release
+- **P1**: Must fix this release
+- **P2**: Should fix
+- **P3**: Nice to have
+
+Return the complete audit report with total score /20 and per-dimension breakdown.
+
+## Overall Score: X/20
+
+## Dimension Breakdown
+| Dimension | Score | P0 | P1 | P2 | P3 |
+|-----------|-------|----|----|----|-----|
+| Accessibility | X/4 | N | N | N | N |
+| Performance | X/4 | N | N | N | N |
+| Theming | X/4 | N | N | N | N |
+| Responsive | X/4 | N | N | N | N |
+| Anti-patterns | X/4 | N | N | N | N |
+
+## Findings
+### [P0/P1/P2/P3] [Title]
+- **Dimension:** [name]
+- **Location:** [file:line]
+- **Issue:** [description]
+- **Fix:** [recommendation]
+```
+
+---
+
+## Final Synthesis (Main Agent)
+
+After all 7 phases complete, the main agent:
+
+1. **Aggregates** the quality audit ({phase_7_output}) and all phase outputs
+2. **Verifies** P0 issues are resolved (re-run Phase 7 if needed)
+3. **Compiles** the final summary:
+   - Feature delivered vs spec
+   - Quality score /20
+   - Open issues (P1-P3)
+   - Files created/modified
+4. **Reports** to the user with the complete results
+
+## Notes
+
+- **Empty mockup guard:** If no mockup provided, Phase 1 focuses on recommendation rather than extraction
+- **Skip guard:** If Phase 2 finds no violations, report clean and proceed to Phase 3
+- **Parallel safety:** Phase 5 groups must have no shared files; if conflicts detected, fall back to sequential
+- **Score gate:** Quality score < 12/20 triggers re-hardening (Phase 6) before final synthesis
+- All phases use project's design tokens and conventions as established in Phase 1

package/dist/template/.pi/workflows/quality-loop.md

@@ -69,7 +69,7 @@ Score-gated, review-driven feedback loop for high-risk features. Runs iterative
     "findings": [
       { "severity": "critical", "file": "src/auth.ts:42", "finding": "...", "suggestion": "..." }
     ],
-    "suggested_action": "fix" | "ask_user" | "proceed"
+    "suggested_action": "fix" | "ask_user_question" | "proceed"
   }
   ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@minhduydev/mdpi",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "CLI to scaffold and manage a Pi coding-agent kit (.pi/) in any repo",
   "keywords": [
     "pi",

package/dist/template/.pi/prompts/loop-check.md

@@ -1,87 +0,0 @@
----
-description: NO-GO qualification gate — decide whether a task is safe to run as an unattended loop
-argument-hint: "<task description> [--help]"
----
-
-# Loop-Check: $ARGUMENTS
-
-Qualify a task before it is ever scheduled as an unattended loop. Emit a single GO/NO-GO verdict with the cited condition that produced it. This prompt is the gate *before* the gate — it refuses work a loop cannot honestly judge.
-
-> Refuse first, test second, checklist last. Never let "looks automatable" override the refuse-list.
-
-## Parse Arguments
-
-| Argument       | Default  | Description                                      |
-| ------------- | -------- | ------------------------------------------------ |
-| `<task>`      | required | The task proposed for unattended looping          |
-| `--help`      | false    | Show this usage                                   |
-
-## Step 1 — Refuse-List (Immediate NO-GO)
-
-If the task touches any of these, **stop here** and emit NO-GO. Do not proceed to the 2-condition test.
-
-- **auth** — login, sessions, tokens, permissions, auth flows, auth module rewrites
-- **payments** — billing, checkout, refunds, subscriptions, payment provider integration
-- **architecture** — framework/library switches, schema migrations, new DB tables, new services, breaking API changes
-
-> Rationale: these need human judgement a loop cannot provide. The refuse-list is the honest ceiling, not a configurable preference.
-
-If a refuse-list category is hit → `CONDITION: <refused category> refused` (e.g. `CONDITION: architecture refused`).
-
-## Step 2 — The 2-Condition Test
-
-Both conditions must hold. If either fails, emit NO-GO citing the failed condition.
-
-1. **Verification is automated.** There exists an objective command whose **exit code** decides pass/fail — `npm test`, `tsc --noEmit`, `eslint`, a custom gate script. The stop condition is computational (exit code), never an LLM's opinion. If the only "check" is "the agent says it looks good" → FAIL.
-2. **The token budget absorbs the waste.** The cost of one wasted run (gate fails, no-op, early-exit) is small enough that running on the scheduled cadence does not blow the budget. If a single failed run is expensive (large model, long context, many turns) and there is no per-run cap → FAIL.
-
-If condition 1 fails → `CONDITION: verification not automated (no exit-code gate)`.
-If condition 2 fails → `CONDITION: budget does not absorb waste (uncapped/expensive failed run)`.
-
-## Step 3 — 30-Second Checklist
-
-Confirm every item. Any miss → NO-GO citing the missing item.
-
-- [ ] **Objective gate exists** — a named command with a pass = exit 0 contract (write it down; "tests" without a command is not a gate).
-- [ ] **Hard stop exists** — a non-negotiable exit condition: repeated gate failure, budget cap hit, or forbidden path touched. The loop exits; it does not improvise.
-- [ ] **Human approves merge/deploy/dependency changes** — the loop may open PRs and stage work; a human merges, deploys, and changes deps. No auto-merge.
-
-Missing gate → `CONDITION: no objective gate`.
-Missing hard stop → `CONDITION: no hard stop`.
-No human-approval boundary → `CONDITION: no human-approval boundary on merge/deploy/deps`.
-
-## Step 4 — Emit Verdict
-
-Output **exactly** these two lines and nothing else as the decision:
-
-```
-VERDICT: GO
-CONDITION: verification automated + budget absorbs waste
-```
-
-or
-
-```
-VERDICT: NO-GO
-CONDITION: <cited condition from Step 1, 2, or 3>
-```
-
-- `VERDICT` is `GO` or `NO-GO` — no other values.
-- `CONDITION` cites the specific condition that produced the verdict. For GO, cite both passing conditions. For NO-GO, cite the first failing condition (Step 1 overrides Step 2 overrides Step 3).
-- Do not add rationale, recommendations, or next steps after the verdict lines. The verdict is the contract.
-
-## Worked Examples
-
-- **"triage failing CI nightly"** with `npm test` gate, no-op early-exit <5k tokens → `VERDICT: GO` / `CONDITION: verification automated + budget absorbs waste`
-- **"rewrite auth module"** → `VERDICT: NO-GO` / `CONDITION: auth refused`
-- **"migrate from REST to GraphQL"** → `VERDICT: NO-GO` / `CONDITION: architecture refused`
-- **"keep docs in sync with code weekly"** with no gate command → `VERDICT: NO-GO` / `CONDITION: verification not automated (no exit-code gate)`
-
-## Related
-
-| Companion | Role |
-|---|---|
-| `loop-engineering` skill | The 2-condition test, refuse-list, and 5 building blocks this gate codifies |
-| `/loop-init` | Scaffold `.pi/loops/<name>/` once a task is GO |
-| `/loop-review` | Maker/checker verification — the gate *during* a run |
-| `loop-audit` | Readiness scoring (L0-L3) for an already-GO loop |

package/dist/template/.pi/prompts/loop-init.md

@@ -1,157 +0,0 @@
----
-description: Scaffold a new unattended loop at .pi/loops/<name>/ with VISION, STATE, and a per-loop SKILL stub
-argument-hint: "<name> [--help]"
----
-
-# Loop Init: $ARGUMENTS
-
-Scaffold a new loop-engineering harness at `.pi/loops/<name>/` from the templates shipped in `.pi/templates/`. Run once per loop. The scaffold is the contract + ledger + procedure the orchestrator (T9/T10) drives unattended.
-
-> **Prerequisite:** `/loop-check <task>` returned GO. If not, refuse and tell the user to qualify the task first.
-
-## Parse Arguments
-
-| Argument | Default   | Description                                  |
-| -------- | --------- | -------------------------------------------- |
-| `<name>` | required  | Loop slug; used as directory name `loop/<name>/<ts>` branch prefix |
-| `--help` | false     | Show this usage                              |
-
-**Validation:** `<name>` must be a filesystem-safe slug (`^[a-z0-9][a-z0-9-]*$`, lowercase). Reject names containing `/`, spaces, or upper-case. Trim surrounding whitespace before use.
-
-## When to Use
-
-- You want to start a new unattended loop (nightly CI triage, dependency bumps, doc sync, PR babysitting).
-- `/loop-check <task>` already returned GO (verification automated + token budget absorbs waste + human approves merge/deploy/deps).
-- You need the contract (VISION.md), dedup ledger (STATE.json + STATE.md), and per-loop procedure (SKILL.md) that the orchestrator will drive.
-
-Do NOT use for:
-- One-off tasks (use `/create` or `/fix`).
-- Tasks `/loop-check` refused (auth, payments, architecture) — refuse here too.
-
-## The Scaffold Steps
-
-### 1. Create the loop directory
-
-Create `.pi/loops/<name>/` (parent `.pi/loops/` may not exist yet — create it).
-
-### 2. Copy the four artifacts
-
-Copy map (exact source → destination):
-
-| Source (template)                         | Destination                          | Purpose                                   |
-| ----------------------------------------- | ------------------------------------ | ----------------------------------------- |
-| `.pi/templates/loop-vision.md`            | `.pi/loops/<name>/VISION.md`         | Anti goal-drift contract (FR2)            |
-| `.pi/templates/loop-state.md`             | `.pi/loops/<name>/STATE.md`           | Human-readable state mirror (FR3)        |
-| `.pi/templates/loop-state.json`           | `.pi/loops/<name>/STATE.json`         | Machine dedup ledger (FR3, authoritative) |
-| (new stub)                                | `.pi/loops/<name>/SKILL.md`           | Per-loop procedure (classification + fix patterns) |
-
-Copy the three templates byte-for-byte first (placeholders intact), then fill placeholders in the copied files. The `SKILL.md` stub is not a template — write a minimal seed:
-
-```markdown
----
-name: <name>
-description: Per-loop procedure for <name> — classify, fix, escalate
----
-
-# Loop Procedure: <name>
-
-Reread `VISION.md` at the start of every run. Do not act outside it.
-
-## Procedure
-
-1. Reread `VISION.md` (boundaries authoritative).
-2. Read `STATE.json` — build the dedup set from `processed[]`.
-3. Fetch candidate items (per the loop's source: CI runs, PRs, packages, commits).
-4. For each item: skip if in `processed[]`; else classify → fix / escalate / reject.
-5. Run the Gate command (the ```bash block directly under `## Gate` in VISION.md); ship only on exit 0.
-6. Append to `STATE.json.processed[]`, `completed[]`, `escalated[]`, or `failures[]`.
-7. Enforce hard stops (see VISION.md "Hard stops").
-
-## Classification rubric
-
-<!-- Fill by hand after supervising the first manual runs. -->
-
-## Fix patterns
-
-<!-- Fill by hand as repeatable fixes are discovered. -->
-```
-
-### 3. Fill `<name>` placeholders
-
-In the copied `VISION.md`, `STATE.md`, and `STATE.json`, replace every placeholder occurrence with the actual loop name:
-
-- `<loop-name>` → `<name>`
-- Leave human-fill placeholders (`[Owner]`, `[Date]`, `[cron expression or "manual"]`, `[Allowed action 1]`, `<GATE_COMMAND>`, etc.) as bracketed prompts for the user to edit by hand — do NOT invent values.
-
-Tell the user explicitly which placeholders still need their input.
-
-### 4. Print the rollout order
-
-After scaffolding, print this rollout order so the user knows the path from scaffold to unattended run:
-
-```
-Rollout order:
-  1. check      — /loop-check <task> (already GO; re-run if scope changes)
-  2. init       — /loop-init <name>   (this step — scaffold created)
-  3. supervise  — run the loop's SKILL.md manually in a session; refine classification/fix patterns
-  4. wire       — copy loop-orchestrator.ts/.sh + loop-github-action.yml; set cadence + gate + scope
-  5. run        — schedule cron/launchd (local) or GitHub Actions `on: schedule` (CI); loop runs unattended
-  6. review     — /loop-review <name> for interactive maker/checker verify
-  7. audit/cost — loop-audit scores readiness (L0-L3); track cost-per-accepted-change; kill if acceptance < 50%
-```
-
-## Idempotency Guard
-
-Before writing anything:
-
-1. Check whether `.pi/loops/<name>/` already exists.
-2. **If it exists:** STOP. Do not overwrite. Ask the user:
-   > `.pi/loops/<name>/` already exists. Overwrite all files (VISION.md, STATE.md, STATE.json, SKILL.md)? This destroys any hand-edited contract/state. (y/N)
-3. **Refuse overwrite without explicit confirmation.** On `N` or no answer, abort and report the existing tree without modifying it.
-4. **If it does not exist:** proceed with the scaffold.
-
-This guard protects hand-edited VISION.md contracts and STATE.json dedup ledgers from being clobbered by a re-run.
-
-## Output
-
-Print:
-
-1. **Created tree** (e.g.):
-   ```
-   .pi/loops/<name>/
-   ├── VISION.md   (contract — fill [Owner], [Date], cadence, Scope, Gate)
-   ├── STATE.md    (human-readable state mirror)
-   ├── STATE.json  (machine dedup ledger — authoritative)
-   └── SKILL.md    (per-loop procedure — fill classification + fix patterns by hand)
-   ```
-2. **Rollout order** (the 7-step block above).
-3. **Placeholders still needing input** (list each `[...]` / `<GATE_COMMAND>` the user must fill by hand, with file:line where useful).
-4. **Next step:** `supervise` — run the loop's `SKILL.md` manually in a session and refine classification/fix patterns before wiring the orchestrator.
-
-## Failure Handling
-
-| Scenario                              | Action                                                        |
-| ------------------------------------- | ------------------------------------------------------------ |
-| `<name>` missing or invalid slug      | Abort with the validation regex and an example               |
-| `.pi/loops/<name>/` exists, no confirm| Abort, print existing tree, do not modify                     |
-| Template missing from `.pi/templates/`| Abort, list which template is missing (T2 must be shipped first) |
-| `<name>` would collide with a reserved path | Abort, suggest an alternate slug                        |
-
-## Stop Conditions
-
-- `<name>` invalid → stop, report the regex.
-- Directory exists and user declines overwrite → stop, report existing tree.
-- Any of the three templates missing → stop, report (T2 prerequisite unmet).
-
-## Related Commands
-
-| Need                     | Command           |
-| ------------------------ | ----------------- |
-| Qualify a task first     | `/loop-check`     |
-| Review a running loop    | `/loop-review`    |
-| Audit loop readiness     | `loop-audit`      |
-
-## Related Skills
-
-- `loop-engineering` — 2-condition test, 5 building blocks, VISION/state contract, failure modes
-- `planning-and-task-breakdown` — decompose the loop's procedure into verifiable steps