@slamb2k/mad-skills 2.0.42 → 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.42",
+  "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.42",
+  "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(
@@ -399,6 +412,33 @@ Invoke the `/ship` skill:
 
 If any stage failed, report the failure point and what was accomplished.
 
+### Pipeline Summary
+
+When `/build` was invoked as part of a chained pipeline (e.g., from `/speccy`),
+emit a concise **Pipeline Summary** after the Final Report. This gives an
+at-a-glance view of the entire end-to-end process:
+
+```
+┌─ Pipeline Summary ─────────────────────────────
+│
+│  {icon} Spec       {spec file or "inline plan"}
+│  {icon} Explore    {files identified count}
+│  {icon} Questions  {answered or "skipped"}
+│  {icon} Architect  {approach one-liner}
+│  {icon} Implement  {files changed summary}
+│  {icon} Review     {findings summary}
+│  {icon} Verify     {test result}
+│  {icon} Ship       {PR link} → {merge commit}
+│
+└─────────────────────────────────────────────────
+```
+
+Use ✅ for completed stages, ⏭️ for skipped, ❌ for failed.
+
+**Always emit this summary** — even when `/build` was invoked directly (not
+from `/speccy`). It serves as a compact status line for any multi-stage build,
+regardless of how it was triggered.
+
 ---
 
 ## Rollback

package/skills/manifest.json

@@ -1,5 +1,5 @@
 {
-  "generated": "2026-03-24T07:52:19.071Z",
+  "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": 411,
+      "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": 272,
+      "lines": 249,
       "hasScripts": false,
       "hasReferences": true,
       "hasAssets": false,

package/skills/speccy/SKILL.md

@@ -232,40 +232,17 @@ After the spec is created, report to the user:
 └─────────────────────────────────────────────────
 ```
 
-Then **immediately** ask the user via AskUserQuestion:
-
-   Question: "Spec written to {spec file path}. Ready to build?"
-   Options:
-   - "Clear context & build (Recommended)" — clear the conversation first, then run `/build`
-   - "Build now" — invoke `/build` immediately in the current context
-   - "Review first" — stop here so the user can review the spec before building
-   - "Done" — stop here, no build
-
-If the user selects **"Clear context & build"**:
-1. Run `/clear` to clear the conversation context
-2. Then invoke `/build {spec file path}`:
-   ```
-   Skill(skill: "build", args: "{spec file path}")
-   ```
-   `/build` reads the spec file via Plan Resolution and executes the full
-   pipeline with maximum context window available.
+Then display the build command:
 
-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. The current conversation context is preserved.
-
-In both cases, **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`.