@slamb2k/mad-skills 2.0.14 → 2.0.16

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "mad-skills",
3
3
  "description": "AI-assisted planning, development and governance tools",
4
- "version": "2.0.14",
4
+ "version": "2.0.16",
5
5
  "author": {
6
6
  "name": "slamb2k",
7
7
  "url": "https://github.com/slamb2k"
package/README.md CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  ![Mad Skills](assets/mad-skills.png)
4
4
 
5
- A skill framework for Claude Code. Ships 8 skills covering the full development lifecycle — from project initialization to shipping PRs.
5
+ A skill framework for Claude Code. Ships 10 skills covering the full development lifecycle — from project initialization to shipping PRs.
6
6
 
7
7
  ## Skills
8
8
 
@@ -11,19 +11,399 @@ A skill framework for Claude Code. Ships 8 skills covering the full development
11
11
  | **build** | `/build` | Context-isolated feature development pipeline. Takes a design/plan and executes explore, question, architect, implement, review, ship inside subagents. |
12
12
  | **brace** | `/brace` | Initialize projects with the GOTCHA/BRACE framework. Creates 6-layer structure, BRACE build methodology, and project CLAUDE.md. |
13
13
  | **distil** | `/distil` | Generate multiple unique web design variations. Creates a Vite + React + TypeScript + Tailwind project with N designs at /1, /2, /3. |
14
+ | **dock** | `/dock` | Generate container release pipelines. Builds once, promotes immutable images through dev → staging → prod. Supports Azure Container Apps, AWS Fargate, Cloud Run, Kubernetes, Dokku, Coolify, CapRover. |
15
+ | **keel** | `/keel` | Generate IaC pipelines (Terraform, Bicep, Pulumi, CDK) to provision cloud infrastructure. Plans on PR, applies on merge. Provisions what /dock deploys to. |
14
16
  | **prime** | `/prime` | Load project context before feature work. Supports domain-specific context (security, routing, dashboard, etc.). |
15
17
  | **rig** | `/rig` | Bootstrap repos with lefthook hooks, commit templates, PR templates, and GitHub Actions workflows. Idempotent. |
16
18
  | **ship** | `/ship` | Full PR lifecycle — sync with main, create branch, commit, push, create PR, wait for CI, fix issues, squash merge, cleanup. |
17
19
  | **speccy** | `/speccy` | Interview-driven specification builder. Reviews code/docs, interviews through targeted questions, produces structured specs. |
18
20
  | **sync** | `/sync` | Sync local repo with origin/main. Stashes changes, pulls, restores stash, cleans up stale branches. |
19
21
 
22
+ ## Lifecycle Overview
23
+
24
+ The 10 skills form a complete development-to-deployment pipeline. Each skill produces artifacts that downstream skills consume.
25
+
26
+ ```mermaid
27
+ graph LR
28
+ A["/brace<br/>Project Init"] --> B["/rig<br/>Dev Tooling"]
29
+ B --> C["/speccy<br/>Spec Builder"]
30
+ C --> D["/build<br/>Features"]
31
+ D --> E["/ship<br/>Merge PRs"]
32
+ E --> F["/keel<br/>Infra (IaC)"]
33
+ F --> G["/dock<br/>Deploy"]
34
+
35
+ style A fill:#4a9eff,color:#fff
36
+ style B fill:#4a9eff,color:#fff
37
+ style C fill:#9b59b6,color:#fff
38
+ style D fill:#2ecc71,color:#fff
39
+ style E fill:#2ecc71,color:#fff
40
+ style F fill:#e67e22,color:#fff
41
+ style G fill:#e67e22,color:#fff
42
+ ```
43
+
44
+ | Phase | Skills | What happens |
45
+ |-------|--------|--------------|
46
+ | **Setup** | `/brace` → `/rig` | Initialize project structure, install hooks, templates, CI workflows |
47
+ | **Develop** | `/speccy` → `/build` → `/ship` | Spec features, implement in isolated subagents, merge via PR lifecycle |
48
+ | **Deploy** | `/keel` → `/dock` | Provision cloud infrastructure, then deploy containers to it |
49
+
50
+ Supporting skills (`/sync`, `/prime`, `/distil`) are used as needed throughout:
51
+ - `/sync` — Pull latest changes before starting work
52
+ - `/prime` — Load domain context before complex features
53
+ - `/distil` — Generate multiple web design variations
54
+
55
+ ---
56
+
57
+ ## End-to-End Walkthrough
58
+
59
+ This walkthrough follows a Node.js app from an empty folder to a deployed container running on cloud infrastructure.
60
+
61
+ ### Step 0: Session Guard
62
+
63
+ When you open Claude Code in any project with the mad-skills plugin installed, the **session guard** runs automatically. It validates your development environment before you write a single line of code.
64
+
65
+ ```
66
+ ┌─────────────────────────────────────────────────────┐
67
+ │ Session Guard — automatic on every session start │
68
+ │ │
69
+ │ ✅ CLAUDE.md found │
70
+ │ ✅ Git repository initialized │
71
+ │ ✅ On branch: main │
72
+ │ ⚠️ CLAUDE.md last modified 5 days ago │
73
+ │ ℹ️ Task list configured: my-project │
74
+ └─────────────────────────────────────────────────────┘
75
+ ```
76
+
77
+ The session guard checks: git status, CLAUDE.md presence and freshness, task list configuration, and branch state. If issues are found, they're surfaced before your first prompt.
78
+
79
+ ---
80
+
81
+ ### Step 1: `/brace` — Initialize the Project
82
+
83
+ Start in an empty folder. `/brace` creates the project skeleton using the GOTCHA/BRACE framework.
84
+
85
+ ```
86
+ > /brace my-webapp
87
+ ```
88
+
89
+ **What it generates:**
90
+
91
+ ```
92
+ my-webapp/
93
+ ├── CLAUDE.md # AI-readable project instructions
94
+ ├── goals/ # Project goals and success criteria
95
+ ├── orchestration/ # Workflow definitions
96
+ ├── tools/ # Tool configurations
97
+ ├── context/ # Domain knowledge
98
+ ├── hard_prompts/ # Reusable prompt templates
99
+ └── args/ # Runtime parameters
100
+ ```
101
+
102
+ The CLAUDE.md it creates becomes the foundation — every subsequent skill reads it for project context.
103
+
104
+ ---
105
+
106
+ ### Step 2: `/rig` — Set Up Dev Tooling
107
+
108
+ With the skeleton in place, `/rig` bootstraps the development infrastructure.
109
+
110
+ ```
111
+ > /rig
112
+ ```
113
+
114
+ **What it generates:**
115
+
116
+ ```
117
+ my-webapp/
118
+ ├── .github/
119
+ │ ├── workflows/ci.yml # PR validation pipeline
120
+ │ └── pull_request_template.md
121
+ ├── .lefthook.yml # Git hooks (lint, test on commit)
122
+ ├── .commitlintrc.yml # Conventional commit enforcement
123
+ └── .editorconfig # Consistent formatting
124
+ ```
125
+
126
+ `/rig` is idempotent — run it again later and it updates without overwriting your customizations.
127
+
128
+ ---
129
+
130
+ ### Step 3: `/speccy` — Specify What to Build
131
+
132
+ Before writing code, `/speccy` interviews you to create a detailed specification.
133
+
134
+ ```
135
+ > /speccy a user authentication system with OAuth2
136
+ ```
137
+
138
+ It asks targeted questions about requirements, edge cases, security concerns, and technical constraints, then produces a structured spec document that `/build` can consume.
139
+
140
+ ---
141
+
142
+ ### Step 4: `/build` — Implement Features
143
+
144
+ Feed the spec (or any design) to `/build`. It runs the entire development lifecycle inside isolated subagents so your main conversation stays clean.
145
+
146
+ ```
147
+ > /build implement the auth system from specs/auth-spec.md
148
+ ```
149
+
150
+ ```mermaid
151
+ graph TD
152
+ A["Stage 1: Explore<br/>Understand codebase"] --> B["Stage 2: Question<br/>Clarify ambiguities"]
153
+ B --> C["Stage 3: Architect<br/>Design solution"]
154
+ C --> D["Stage 4: Implement<br/>Write code"]
155
+ D --> E["Stage 5: Review<br/>Check quality"]
156
+ E --> F["Stage 6: Ship<br/>Invoke /ship"]
157
+
158
+ style A fill:#3498db,color:#fff
159
+ style B fill:#3498db,color:#fff
160
+ style C fill:#9b59b6,color:#fff
161
+ style D fill:#2ecc71,color:#fff
162
+ style E fill:#e74c3c,color:#fff
163
+ style F fill:#f39c12,color:#fff
164
+ ```
165
+
166
+ Each stage runs in a subagent with its own context. The primary conversation only receives structured reports.
167
+
168
+ ---
169
+
170
+ ### Step 5: `/ship` — Merge via PR
171
+
172
+ When features are ready, `/ship` handles the entire PR lifecycle.
173
+
174
+ ```
175
+ > /ship
176
+ ```
177
+
178
+ ```mermaid
179
+ sequenceDiagram
180
+ participant Dev as Developer
181
+ participant Ship as /ship
182
+ participant GH as GitHub
183
+ participant CI as CI Pipeline
184
+
185
+ Dev->>Ship: /ship
186
+ Ship->>Ship: Stage 1: Sync with main
187
+ Ship->>Ship: Stage 2: Analyze, commit, push
188
+ Ship->>GH: Create PR
189
+ Ship->>CI: Stage 3: Monitor checks
190
+ CI-->>Ship: All checks passed ✅
191
+ Ship->>GH: Stage 5: Squash merge
192
+ Ship->>Ship: Sync local main, cleanup branches
193
+ Ship-->>Dev: Ship complete ✅
194
+ ```
195
+
196
+ If CI fails, `/ship` automatically reads the failure logs, fixes the code, pushes a fix commit, and re-monitors — up to 2 attempts before asking for help.
197
+
198
+ ---
199
+
200
+ ### Step 6: `/keel` — Provision Infrastructure
201
+
202
+ Before deploying, you need infrastructure. `/keel` interviews you about your cloud setup and generates IaC files.
203
+
204
+ ```
205
+ > /keel
206
+ ```
207
+
208
+ The interview covers: cloud provider, IaC tool, components needed, environments, state management, naming conventions, and resource sizing.
209
+
210
+ **Example output for Azure + Terraform:**
211
+
212
+ ```
213
+ my-webapp/
214
+ ├── infra/
215
+ │ ├── main.tf # Provider, backend, module calls
216
+ │ ├── variables.tf # Input variables
217
+ │ ├── outputs.tf # Registry URL, endpoints, connection strings
218
+ │ ├── versions.tf # Required providers
219
+ │ ├── bootstrap.sh # One-time state backend setup
220
+ │ ├── sync-outputs.sh # Sync TF outputs → CI/CD variables
221
+ │ ├── environments/
222
+ │ │ ├── dev.tfvars
223
+ │ │ ├── staging.tfvars
224
+ │ │ └── prod.tfvars
225
+ │ └── modules/
226
+ │ ├── registry/ # Azure Container Registry
227
+ │ ├── compute/ # Azure Container Apps
228
+ │ ├── database/ # PostgreSQL Flexible Server
229
+ │ ├── networking/ # VNet, subnets
230
+ │ └── monitoring/ # Log Analytics, App Insights
231
+ └── .github/workflows/
232
+ └── infra.yml # Plan on PR, apply on merge
233
+ ```
234
+
235
+ **Infrastructure pipeline flow:**
236
+
237
+ ```mermaid
238
+ graph LR
239
+ subgraph "PR Phase"
240
+ A["Push infra/ changes"] --> B["terraform plan"]
241
+ B --> C["Post plan as<br/>PR comment"]
242
+ end
243
+
244
+ subgraph "Merge Phase"
245
+ D["Merge to main"] --> E["terraform apply<br/>(dev)"]
246
+ E --> F["Sync outputs to<br/>CI/CD variables"]
247
+ end
248
+
249
+ subgraph "Promotion Phase"
250
+ G["Manual dispatch"] --> H["terraform apply<br/>(staging)"]
251
+ H --> I["terraform apply<br/>(prod)"]
252
+ end
253
+
254
+ C --> D
255
+ F --> G
256
+
257
+ style B fill:#3498db,color:#fff
258
+ style E fill:#2ecc71,color:#fff
259
+ style H fill:#e67e22,color:#fff
260
+ style I fill:#e74c3c,color:#fff
261
+ ```
262
+
263
+ After `/keel` applies, the infrastructure outputs (registry URL, compute endpoints, database connection strings) are synced as CI/CD variables for `/dock` to consume.
264
+
265
+ ---
266
+
267
+ ### Step 7: `/dock` — Deploy Containers
268
+
269
+ With infrastructure provisioned, `/dock` creates the release pipeline that builds and deploys your app.
270
+
271
+ ```
272
+ > /dock
273
+ ```
274
+
275
+ The interview covers: container registry, environments, deployment targets per environment, testing gates, secrets, and rollback strategy.
276
+
277
+ **Example output:**
278
+
279
+ ```
280
+ my-webapp/
281
+ ├── Dockerfile # Multi-stage: deps → build → test → production
282
+ ├── .dockerignore
283
+ ├── docker-compose.yml # Local dev parity
284
+ ├── deploy/
285
+ │ └── environments.yml # Per-environment config matrix
286
+ └── .github/workflows/
287
+ └── deploy.yml # Build, push, deploy pipeline
288
+ ```
289
+
290
+ **The build-once-promote-everywhere pipeline:**
291
+
292
+ ```mermaid
293
+ graph TD
294
+ subgraph "Build Phase (on merge to main)"
295
+ A["Checkout code"] --> B["Build image<br/>target: test"]
296
+ B --> C["Run tests<br/>inside container"]
297
+ C --> D["Build image<br/>target: production"]
298
+ D --> E["Push to registry<br/>tag: abc1234 + latest"]
299
+ end
300
+
301
+ subgraph "Deploy Dev"
302
+ E --> F["Deploy abc1234<br/>to dev"]
303
+ F --> G["Smoke tests ✅"]
304
+ end
305
+
306
+ subgraph "Promote to Staging (on release tag v1.2.3)"
307
+ G -.-> H["Retag abc1234<br/>as v1.2.3"]
308
+ H --> I["Deploy v1.2.3<br/>to staging"]
309
+ I --> J["Integration +<br/>e2e tests ✅"]
310
+ end
311
+
312
+ subgraph "Promote to Production"
313
+ J --> K["Deploy v1.2.3<br/>to production"]
314
+ K --> L["Post-deploy<br/>smoke test ✅"]
315
+ end
316
+
317
+ style B fill:#3498db,color:#fff
318
+ style D fill:#3498db,color:#fff
319
+ style E fill:#2ecc71,color:#fff
320
+ style H fill:#e67e22,color:#fff
321
+ style I fill:#e67e22,color:#fff
322
+ style K fill:#e74c3c,color:#fff
323
+
324
+ linkStyle 6 stroke:#999,stroke-dasharray:5
325
+ ```
326
+
327
+ The critical principle: the release tag step **retags** the existing tested image — it never rebuilds. The exact same bytes that passed tests on `main` are what runs in production.
328
+
329
+ ---
330
+
331
+ ### Full Architecture
332
+
333
+ Here's how all the pipelines connect in the final system:
334
+
335
+ ```mermaid
336
+ graph TB
337
+ subgraph "Developer Workflow"
338
+ DEV["Developer"] -->|"/build"| CODE["Code Changes"]
339
+ CODE -->|"/ship"| PR["Pull Request"]
340
+ end
341
+
342
+ subgraph "CI Pipeline (/rig)"
343
+ PR --> LINT["Lint + Validate"]
344
+ LINT --> TEST["Unit Tests"]
345
+ TEST --> PASS{"Checks<br/>pass?"}
346
+ PASS -->|Yes| MERGE["Merge to main"]
347
+ PASS -->|No| FIX["/ship auto-fix"]
348
+ FIX --> LINT
349
+ end
350
+
351
+ subgraph "Infrastructure Pipeline (/keel)"
352
+ INFRA_PR["Infra PR"] --> PLAN["terraform plan"]
353
+ PLAN --> INFRA_MERGE["Merge"]
354
+ INFRA_MERGE --> APPLY_DEV["Apply to dev"]
355
+ APPLY_DEV --> SYNC["Sync outputs →<br/>CI/CD vars"]
356
+ end
357
+
358
+ subgraph "Deployment Pipeline (/dock)"
359
+ MERGE --> BUILD["Build container<br/>image"]
360
+ BUILD --> PUSH["Push to registry<br/>:sha + :latest"]
361
+ PUSH --> DEPLOY_DEV["Deploy to dev"]
362
+ DEPLOY_DEV --> SMOKE["Smoke tests"]
363
+
364
+ TAG["Release tag<br/>v1.2.3"] --> RETAG["Retag image<br/>(no rebuild)"]
365
+ RETAG --> DEPLOY_STG["Deploy staging"]
366
+ DEPLOY_STG --> E2E["e2e tests"]
367
+ E2E --> DEPLOY_PROD["Deploy production"]
368
+ DEPLOY_PROD --> FINAL["Post-deploy smoke"]
369
+ end
370
+
371
+ SYNC -.->|"Registry URL<br/>Endpoints"| BUILD
372
+
373
+ style DEV fill:#4a9eff,color:#fff
374
+ style MERGE fill:#2ecc71,color:#fff
375
+ style BUILD fill:#3498db,color:#fff
376
+ style PUSH fill:#3498db,color:#fff
377
+ style RETAG fill:#e67e22,color:#fff
378
+ style DEPLOY_PROD fill:#e74c3c,color:#fff
379
+ ```
380
+
381
+ ---
382
+
383
+ ### Quick Reference: What Each Skill Generates
384
+
385
+ | Skill | Key artifacts | Consumed by |
386
+ |-------|--------------|-------------|
387
+ | `/brace` | `CLAUDE.md`, project skeleton | All other skills |
388
+ | `/rig` | `.github/workflows/ci.yml`, hooks, templates | `/ship` (CI checks) |
389
+ | `/speccy` | Specification document | `/build` (implementation guide) |
390
+ | `/build` | Feature code, tests | `/ship` (files to commit) |
391
+ | `/ship` | Commits, PRs, merged code | CI pipeline, `/dock` triggers |
392
+ | `/keel` | `infra/` (Terraform/Bicep), `infra.yml` workflow | `/dock` (infrastructure outputs) |
393
+ | `/dock` | `Dockerfile`, `deploy.yml`, `deploy/` config | CI/CD system (runtime) |
394
+ | `/sync` | Clean working tree | Any skill (pre-work) |
395
+ | `/prime` | Domain context in memory | `/build` (informed decisions) |
396
+ | `/distil` | Multiple web design variations | `/build` (chosen design) |
397
+
398
+ ---
399
+
20
400
  ## Installation
21
401
 
22
402
  Three methods are available. The table below shows what each delivers:
23
403
 
24
404
  | | Plugin | npx skills | npm package |
25
405
  |---|---|---|---|
26
- | Skills (slash commands) | ✅ all 8 | ✅ all 8 | — |
406
+ | Skills (slash commands) | ✅ all 10 | ✅ all 10 | — |
27
407
  | Agents (e.g. ship-analyzer) | ✅ | ❌ | — |
28
408
  | Session hooks (session-guard) | ✅ | ❌ | — |
29
409
  | Cross-agent (Cursor, Cline, etc.) | ❌ Claude Code only | ✅ | — |
@@ -111,10 +491,12 @@ ln -sfn "$DOTFILES_DIR/skills/my-skill" "$HOME/.claude/skills/my-skill"
111
491
 
112
492
  ```
113
493
  mad-skills/
114
- ├── skills/ # Skill definitions (8 skills)
494
+ ├── skills/ # Skill definitions (10 skills)
115
495
  │ ├── build/
116
496
  │ ├── brace/
117
497
  │ ├── distil/
498
+ │ ├── dock/
499
+ │ ├── keel/
118
500
  │ ├── prime/
119
501
  │ ├── rig/
120
502
  │ ├── ship/
@@ -134,8 +516,7 @@ mad-skills/
134
516
  │ ├── marketplace.json
135
517
  │ └── plugin.json
136
518
  └── .github/workflows/
137
- ├── ci.yml # PR validation + evals
138
- └── release.yml # Tagged release → npm + GitHub
519
+ └── ci.yml # Unified CI, evals, and release
139
520
  ```
140
521
 
141
522
  ### Skill Structure
@@ -176,16 +557,10 @@ npm test # validate + lint + eval
176
557
 
177
558
  ## CI/CD
178
559
 
179
- **PR pipeline** (`.github/workflows/ci.yml`):
180
- - Triggers on all pull requests (required status check)
181
- - Runs validate and lint
182
- - Runs evals when API key is available (skipped for external PRs)
183
- - Detects which skills changed and posts eval results as PR comments
184
-
185
- **Release pipeline** (`.github/workflows/release.yml`):
186
- - Phase 1: Triggers on push to main, validates, bumps patch version, creates auto-merge PR
187
- - Phase 2: When version bump merges, creates tag, publishes to npm with provenance
188
- - Builds `.skill` packages and creates a GitHub Release
560
+ **Unified pipeline** (`.github/workflows/ci.yml`):
561
+ - **On pull requests:** validate + lint, evals (when API key available), posts eval results as PR comments
562
+ - **On push to main (non-release):** validates, bumps patch version, creates auto-merge PR
563
+ - **On push to main (release):** creates version tag, publishes to npm with provenance, builds `.skill` packages, creates GitHub Release
189
564
 
190
565
  ## Archive
191
566
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@slamb2k/mad-skills",
3
- "version": "2.0.14",
3
+ "version": "2.0.16",
4
4
  "description": "Claude Code skills collection — planning, development and governance tools",
5
5
  "type": "module",
6
6
  "repository": {
@@ -2,7 +2,7 @@
2
2
  name: brace
3
3
  description: 'Initialize any project directory with the GOTCHA/BRACE framework for agentic AI systems. Creates the 6-layer structure (Goals, Orchestration, Tools, Context, Hard prompts, Args), BRACE build methodology, and a project CLAUDE.md. Recommends claude-mem for persistent memory. Idempotent — safe to run on existing projects. Triggers: "init gotcha", "setup brace", "brace", "initialize framework", "bootstrap gotcha".'
4
4
  argument-hint: "[--no-brace] [--force]"
5
- allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion
5
+ allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, AskUserQuestion
6
6
  ---
7
7
 
8
8
  # Brace - GOTCHA/BRACE Framework Bootstrap
@@ -2,7 +2,7 @@
2
2
  name: build
3
3
  description: Context-isolated feature development pipeline. Takes a detailed design/plan as argument and executes the full feature-dev lifecycle (explore, question, architect, implement, review, ship) inside subagents so the primary conversation stays compact. Use when you have a well-defined plan and want autonomous execution with minimal context window consumption.
4
4
  argument-hint: <detailed design/plan to implement> [--skip-questions] [--skip-review] [--no-ship] [--parallel-impl]
5
- allowed-tools: Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion
5
+ allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, AskUserQuestion
6
6
  ---
7
7
 
8
8
  # Build - Context-Isolated Feature Development
@@ -60,6 +60,7 @@ Before starting, check all dependencies in this table:
60
60
  | Dependency | Type | Check | Required | Resolution | Detail |
61
61
  |-----------|------|-------|----------|------------|--------|
62
62
  | ship | skill | `.claude/skills/ship/SKILL.md` | yes | stop | Install with: npx skills add slamb2k/mad-skills --skill ship |
63
+ | prime | skill | `.claude/skills/prime/SKILL.md` | no | fallback | Context loading; falls back to manual CLAUDE.md/goals scan |
63
64
  | feature-dev:code-explorer | agent | — | no | fallback | Uses general-purpose agent |
64
65
  | feature-dev:code-architect | agent | — | no | fallback | Uses general-purpose agent |
65
66
  | feature-dev:code-reviewer | agent | — | no | fallback | Uses general-purpose agent |
@@ -76,7 +77,10 @@ For each row, in order:
76
77
  4. After all checks: summarize what's available and what's degraded
77
78
 
78
79
  1. Capture **PLAN** (the user's argument) and **FLAGS**
79
- 2. Detect project type using `references/project-detection.md` to populate
80
+ 2. **Load project context** invoke `/prime` to load domain-specific context
81
+ (CLAUDE.md, goals, specs, memory). If /prime is unavailable, fall back to
82
+ manually scanning CLAUDE.md and goals/ directory.
83
+ 3. Detect project type using `references/project-detection.md` to populate
80
84
  **PROJECT_CONFIG** (language, test_runner, test_setup)
81
85
  3. Check for outstanding questions from previous work:
82
86
  - Search CLAUDE.md for a "Known Issues" or "Open Questions" section
@@ -2,7 +2,7 @@
2
2
  name: distil
3
3
  description: Generate multiple unique web design variations for any website or web application. Accepts site specifications from a file (--spec path) or pasted text block. Creates a Vite + React + TypeScript + Tailwind project with Bun and produces N different creative designs accessible at /1, /2, /3, etc. Use when prototyping or exploring design directions for any web interface.
4
4
  argument-hint: <count> --port <port> [--spec <path>] [--favorites <1,2,3>]
5
- allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion
5
+ allowed-tools: Bash, Read, Write, Edit, Glob, Grep, Agent, WebFetch, AskUserQuestion
6
6
  ---
7
7
 
8
8
  # Distil - Design Variation Generator