@slamb2k/mad-skills 2.0.43 → 2.0.44

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "mad-skills",
   "description": "AI-assisted planning, development and governance tools",
-  "version": "2.0.43",
+  "version": "2.0.44",
   "author": {
     "name": "slamb2k",
     "url": "https://github.com/slamb2k"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@slamb2k/mad-skills",
-  "version": "2.0.43",
+  "version": "2.0.44",
   "description": "Claude Code skills collection — full lifecycle development tools",
   "type": "module",
   "repository": {

package/skills/build/SKILL.md

@@ -107,7 +107,17 @@ For each row, in order:
    manually scanning CLAUDE.md and specs/ directory.
 3. Detect project type using `references/project-detection.md` to populate
    **PROJECT_CONFIG** (language, test_runner, test_setup)
-3. Check for outstanding items from previous work:
+4. **Create task list** — ALWAYS create tasks upfront for all stages using
+   `TaskCreate`. This provides visible progress tracking throughout the build:
+   - Task: "Stage 1: Explore codebase"
+   - Task: "Stage 2: Clarifying questions" (if not `--skip-questions`)
+   - Task: "Stage 3: Architecture design"
+   - Task: "Stage 4: Implementation"
+   - Task: "Stage 5: Code review" (if not `--skip-review`)
+   - Task: "Stage 7: Verify"
+   - Task: "Stage 9: Ship" (if not `--no-ship`)
+   Mark each task `in_progress` when starting and `completed` when done.
+5. Check for outstanding items from previous work:
    - Query persistent tasks via `TaskList` for incomplete items
    - Search CLAUDE.md for a "Known Issues" or "Open Questions" section
    - Search memory (if available) for recent unresolved items
@@ -226,10 +236,13 @@ If rejected, incorporate feedback and re-run.
 
 ## Stage 4: Implementation
 
-If `--parallel-impl` and ARCH_REPORT has independent `parallel_groups`,
-launch **multiple general-purpose subagents in parallel**.
+If ARCH_REPORT identifies independent `parallel_groups`, launch **multiple
+general-purpose subagents in parallel** — one per group. Do NOT wait for
+`--parallel-impl` flag; parallel execution is the **default** when the
+architecture supports it. The flag is retained only as an explicit override.
 
-Otherwise launch **one general-purpose subagent**:
+If the architecture has no independent groups, launch **one general-purpose
+subagent**:
 
 ```
 Task(

package/skills/manifest.json

@@ -1,5 +1,5 @@
 {
-  "generated": "2026-03-24T08:38:36.091Z",
+  "generated": "2026-03-24T15:07:20.484Z",
   "count": 10,
   "skills": [
     {
@@ -16,7 +16,7 @@
       "name": "build",
       "directory": "build",
       "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.",
-      "lines": 438,
+      "lines": 451,
       "hasScripts": false,
       "hasReferences": true,
       "hasAssets": false,
@@ -86,7 +86,7 @@
       "name": "speccy",
       "directory": "speccy",
       "description": "Deep-dive interview skill for creating comprehensive specifications. Reviews existing code and docs, then interviews the user through multiple rounds of targeted questions covering technical implementation, UI/UX, concerns, and tradeoffs. Produces a structured spec in specs/. Use when starting a new feature, system, or major change that needs a spec.",
-      "lines": 260,
+      "lines": 249,
       "hasScripts": false,
       "hasReferences": true,
       "hasAssets": false,

package/skills/speccy/SKILL.md

@@ -232,28 +232,17 @@ After the spec is created, report to the user:
 └─────────────────────────────────────────────────
 ```
 
-Then **immediately** ask the user via AskUserQuestion:
+Then display the build command:
 
-   Question: "Spec written to {spec file path}. Ready to build?"
-   Options:
-   - "Build now (Recommended)" — invoke `/build` immediately
-   - "Review first" — stop here so the user can review the spec before building
-   - "Done" — stop here, no build
-
-If the user selects **"Build now"**:
-1. Invoke `/build {spec file path}` directly:
-   ```
-   Skill(skill: "build", args: "{spec file path}")
-   ```
-   `/build` reads the spec file via Plan Resolution and executes the full
-   pipeline. **Do not** attempt to implement the spec yourself — always
-   delegate to `/build`.
-
-If the user selects **"Review first"** or **"Done"**, stop and display:
 ```
-⚡ To build later, run: /build {spec file path}
+⚡ To implement, run: /build {spec file path}
 ```
 
-**IMPORTANT:** After generating the spec, do NOT enter plan mode, do NOT
-start implementing directly, and do NOT offer to execute the plan yourself.
-The only path to implementation is through `/build`.
+The spec file persists on disk, so the user can `/clear` the conversation
+to free context before running `/build`. This is the recommended flow for
+large specs — clearing context gives `/build` maximum working room.
+
+**IMPORTANT:** After generating the spec, STOP. Do NOT enter plan mode,
+do NOT start implementing directly, do NOT invoke `/build` yourself, and
+do NOT offer to execute the plan. The spec file is the handoff artifact —
+the user controls when and how to invoke `/build`.