@jakkrichm/create-nexus-devflow 2.15.1 → 2.15.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jakkrichm/create-nexus-devflow",
-  "version": "2.15.1",
+  "version": "2.15.2",
   "description": "Installer and workflow manager for Nexus-DevFlow agentic workflow layer.",
   "license": "MIT",
   "author": "Jakkrich",

package/template/.agents/skills/audit/SKILL.md

@@ -67,6 +67,8 @@ Optional lens:
   unbounded-work risks
 - `tests`: missing coverage for important logic, weak assertions, skipped or
   focused tests, poor isolation, brittle mocks, and likely flakiness
+- `scrutiny`: outsider end-to-end review questioning intent, checking simpler
+  alternatives, tracing real call paths beyond diffs, and verifying edge-case claims
 
 `full` is always the full-project scope, not a lens. `/audit full` therefore runs
 all lenses across the full project. When only a lens is supplied, select scope
@@ -277,6 +279,11 @@ expectations. Apply only the selected lens or lenses:
   state, time or order dependence, skipped or focused tests, placeholder tests,
   swallowed failures, and missing browser or integration evidence where behavior
   crosses a real boundary. Never invent a coverage percentage.
+- **Scrutiny (Outsider Stance & Intent Challenge):**
+  - *Question Intent & Simpler Alternatives*: State what the change actually attempts in one sentence. Ask: is there a simpler, smaller, or more elegant way to achieve the same goal (reusing existing code, config vs code, solving at a different layer)?
+  - *Full Call-Path Tracing*: Follow the call graph through real code paths (entry point → call sites → branches taken → state mutated → exit/side effect), including unchanged code on either side of the diff where bugs hide.
+  - *Verify Claims & Edge Cases*: Does the traced path actually produce the claimed behavior? What inputs/states would break it (concurrency, retries, null/unicode/huge payloads, ordering)? What does it silently change?
+  - *No Rubber-Stamping*: "LGTM" is prohibited. State what was traced, what was verified, and what evidence supports the verdict.
 
 Do not nitpick harmless style differences unless they signal drift from the local
 patterns. Prefer a short list of real findings over a broad list of guesses.

package/template/.agents/skills/audit/reference/independent-review.md

@@ -55,7 +55,9 @@ execution` so both execution fields remain absent.
 ## Handoff
 
 Review the active spec and the complete `<base>..<target>` delta in a fresh
-session or isolated subagent without the builder conversation. Run all Audit lenses from scratch.
+session or isolated subagent without the builder conversation. Apply the Outsider
+Scrutiny stance: trace full call paths beyond the diff, challenge whether a simpler
+alternative exists, and run all Audit lenses from scratch.
 Run Check when required above. Do not edit product code, accept findings, or
 reuse the existing findings as the review scope.
 ```

package/template/.agents/skills/complete/SKILL.md

@@ -108,7 +108,7 @@ Check whether the spec is a feature, fix, or rollback. A fix is marked
 and records the exact target feature, archive, commit, and parent.
 
 - **Feature** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/features/{xxx-slug}.md`, check it off in `devflow/build-plan.md` (and its parent item once all sub-items are checked), recompute the overview fingerprint using `/overview`'s checkbox-normalized hash contract and update `devflow:source-hash` in `devflow/context/project-overview.md`, and record an entry into `devflow/history/HISTORY.md`.
-- **Fix** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/fixes/{xxx-slug}.md`, and record an entry into `devflow/history/HISTORY.md`.
+- **Fix** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/fixes/{xxx-slug}.md` preserving canonical post-mortem blocks (Summary, Symptom, Root Cause mechanism, Why it produced symptom, Fix, How found, Why slipped through, Validation, Action items), and record an entry into `devflow/history/HISTORY.md`.
 - **Rollback** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/rollbacks/YYYY-MM-DD-{xxx-slug}.md`, preserving the original completed feature archive. Uncheck the target item in `devflow/build-plan.md` and record in `devflow/history/HISTORY.md`.
 
 **Archive resolved findings & review receipts.**
@@ -162,4 +162,11 @@ Present the user with two clear delivery options:
 ## Step 4 - Finish & Try Path
 
 Point the user at `/feature`, `/fix`, or `/rollback` for the next task.
-Finish with a concise **How to try it** note for the completed work.
+Finish with a concise **How to try it** note for the completed work.
+
+### 📢 Leadership & Stakeholder Summary (Channel-Ready)
+
+Optionally output a concise, leadership-flavored digest (ready for Slack, JIRA comment, or standup):
+- **Translate**: Reframe engineering mechanism into customer/business impact in 1-2 plain sentences.
+- **Keep**: Product/feature names, PR number, JIRA ticket keys, and owner.
+- **Strip**: Function names, file paths, struct fields, and internal code minutiae.

package/template/.agents/skills/debug/SKILL.md

@@ -133,6 +133,28 @@ Give a structured, concise debug report:
 
 ---
 
+### Phase 7: Post-Mortem & Fix Handoff (Canonical Engineering Record)
+
+Once a fix is identified and validated (or when prompted: "write the post-mortem", "document this fix", "RCA"), draft the canonical engineering record for other engineers:
+
+- **Prerequisites (Refuse to draft without all 4)**:
+  1. Reliable repro exists (from Phase 1 & 2).
+  2. Root cause mechanism is confirmed (from Phase 5).
+  3. Fix is identified (commit / PR / branch).
+  4. Fix is validated (original red loop is now green).
+- **Canonical Structure**:
+  1. *Summary*: One paragraph: what broke, what fixed it, JIRA/PR keys, owner.
+  2. *Symptom*: Actual observed error, test failure, or log lines with concrete identifiers.
+  3. *Root cause*: Actual bug mechanism with code identifiers (functions, files, fields, conditions).
+  4. *Why it produced the symptom*: Cause-and-effect chain linking mechanism to symptom.
+  5. *Fix*: What changed and why this addresses the cause rather than masking the symptom.
+  6. *How it was found*: Repro path, rejected hypotheses, decisive experiment.
+  7. *Why it slipped through*: CI gap, latent code, workload gap, or review miss (blameless).
+  8. *Validation*: Concrete proof (tests passing, benchmark delta, workload completion).
+  9. *Action items*: Concrete follow-ups with owners and ticket keys.
+
+---
+
 ## Rules
 
 - **Diagnose, do not repair**: Never edit production source, package lockfiles, or DevFlow state inside `/debug`.

package/template/.agents/skills/status/SKILL.md

@@ -87,6 +87,15 @@ A short, scannable summary, not a wall of text. Aim for something like:
 
     Next action: run /implement 061 for Task 2.
 
+### 👔 Leadership / Executive Summary Mode (`/status --exec`)
+
+When requested via `/status --exec`, `/status leadership`, or when writing an update for engineering leadership (VPs, Directors, PMs, release managers):
+- **Tone**: Keep product names, JIRA keys, PR numbers, and business impact. Strip function names, file paths, struct fields, and internal code minutiae.
+- **Channel Shapes**:
+  - *Slack*: 1 bolded TL;DR line + 2-3 short bullets (impact, owner + PR link, next step) under 80 words.
+  - *Async Standup*: 1-2 lines: `<state> <thing> (JIRA/PR). <owner>. <next>.`
+  - *Written Status*: Status (bolded TL;DR) -> Customer Impact -> Progress/Next steps -> Owner.
+
 End with a single suggested next action, chosen in this order:
 
 - The project configuration is invalid -> `/doctor`.

package/template/.claude/skills/audit/SKILL.md

@@ -67,6 +67,8 @@ Optional lens:
   unbounded-work risks
 - `tests`: missing coverage for important logic, weak assertions, skipped or
   focused tests, poor isolation, brittle mocks, and likely flakiness
+- `scrutiny`: outsider end-to-end review questioning intent, checking simpler
+  alternatives, tracing real call paths beyond diffs, and verifying edge-case claims
 
 `full` is always the full-project scope, not a lens. `/audit full` therefore runs
 all lenses across the full project. When only a lens is supplied, select scope
@@ -277,6 +279,11 @@ expectations. Apply only the selected lens or lenses:
   state, time or order dependence, skipped or focused tests, placeholder tests,
   swallowed failures, and missing browser or integration evidence where behavior
   crosses a real boundary. Never invent a coverage percentage.
+- **Scrutiny (Outsider Stance & Intent Challenge):**
+  - *Question Intent & Simpler Alternatives*: State what the change actually attempts in one sentence. Ask: is there a simpler, smaller, or more elegant way to achieve the same goal (reusing existing code, config vs code, solving at a different layer)?
+  - *Full Call-Path Tracing*: Follow the call graph through real code paths (entry point → call sites → branches taken → state mutated → exit/side effect), including unchanged code on either side of the diff where bugs hide.
+  - *Verify Claims & Edge Cases*: Does the traced path actually produce the claimed behavior? What inputs/states would break it (concurrency, retries, null/unicode/huge payloads, ordering)? What does it silently change?
+  - *No Rubber-Stamping*: "LGTM" is prohibited. State what was traced, what was verified, and what evidence supports the verdict.
 
 Do not nitpick harmless style differences unless they signal drift from the local
 patterns. Prefer a short list of real findings over a broad list of guesses.

package/template/.claude/skills/audit/reference/independent-review.md

@@ -55,7 +55,9 @@ execution` so both execution fields remain absent.
 ## Handoff
 
 Review the active spec and the complete `<base>..<target>` delta in a fresh
-session or isolated subagent without the builder conversation. Run all Audit lenses from scratch.
+session or isolated subagent without the builder conversation. Apply the Outsider
+Scrutiny stance: trace full call paths beyond the diff, challenge whether a simpler
+alternative exists, and run all Audit lenses from scratch.
 Run Check when required above. Do not edit product code, accept findings, or
 reuse the existing findings as the review scope.
 ```

package/template/.claude/skills/complete/SKILL.md

@@ -108,7 +108,7 @@ Check whether the spec is a feature, fix, or rollback. A fix is marked
 and records the exact target feature, archive, commit, and parent.
 
 - **Feature** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/features/{xxx-slug}.md`, check it off in `devflow/build-plan.md` (and its parent item once all sub-items are checked), recompute the overview fingerprint using `/overview`'s checkbox-normalized hash contract and update `devflow:source-hash` in `devflow/context/project-overview.md`, and record an entry into `devflow/history/HISTORY.md`.
-- **Fix** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/fixes/{xxx-slug}.md`, and record an entry into `devflow/history/HISTORY.md`.
+- **Fix** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/fixes/{xxx-slug}.md` preserving canonical post-mortem blocks (Summary, Symptom, Root Cause mechanism, Why it produced symptom, Fix, How found, Why slipped through, Validation, Action items), and record an entry into `devflow/history/HISTORY.md`.
 - **Rollback** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/rollbacks/YYYY-MM-DD-{xxx-slug}.md`, preserving the original completed feature archive. Uncheck the target item in `devflow/build-plan.md` and record in `devflow/history/HISTORY.md`.
 
 **Archive resolved findings & review receipts.**
@@ -162,4 +162,11 @@ Present the user with two clear delivery options:
 ## Step 4 - Finish & Try Path
 
 Point the user at `/feature`, `/fix`, or `/rollback` for the next task.
-Finish with a concise **How to try it** note for the completed work.
+Finish with a concise **How to try it** note for the completed work.
+
+### 📢 Leadership & Stakeholder Summary (Channel-Ready)
+
+Optionally output a concise, leadership-flavored digest (ready for Slack, JIRA comment, or standup):
+- **Translate**: Reframe engineering mechanism into customer/business impact in 1-2 plain sentences.
+- **Keep**: Product/feature names, PR number, JIRA ticket keys, and owner.
+- **Strip**: Function names, file paths, struct fields, and internal code minutiae.

package/template/.claude/skills/debug/SKILL.md

@@ -133,6 +133,28 @@ Give a structured, concise debug report:
 
 ---
 
+### Phase 7: Post-Mortem & Fix Handoff (Canonical Engineering Record)
+
+Once a fix is identified and validated (or when prompted: "write the post-mortem", "document this fix", "RCA"), draft the canonical engineering record for other engineers:
+
+- **Prerequisites (Refuse to draft without all 4)**:
+  1. Reliable repro exists (from Phase 1 & 2).
+  2. Root cause mechanism is confirmed (from Phase 5).
+  3. Fix is identified (commit / PR / branch).
+  4. Fix is validated (original red loop is now green).
+- **Canonical Structure**:
+  1. *Summary*: One paragraph: what broke, what fixed it, JIRA/PR keys, owner.
+  2. *Symptom*: Actual observed error, test failure, or log lines with concrete identifiers.
+  3. *Root cause*: Actual bug mechanism with code identifiers (functions, files, fields, conditions).
+  4. *Why it produced the symptom*: Cause-and-effect chain linking mechanism to symptom.
+  5. *Fix*: What changed and why this addresses the cause rather than masking the symptom.
+  6. *How it was found*: Repro path, rejected hypotheses, decisive experiment.
+  7. *Why it slipped through*: CI gap, latent code, workload gap, or review miss (blameless).
+  8. *Validation*: Concrete proof (tests passing, benchmark delta, workload completion).
+  9. *Action items*: Concrete follow-ups with owners and ticket keys.
+
+---
+
 ## Rules
 
 - **Diagnose, do not repair**: Never edit production source, package lockfiles, or DevFlow state inside `/debug`.

package/template/.claude/skills/status/SKILL.md

@@ -87,6 +87,15 @@ A short, scannable summary, not a wall of text. Aim for something like:
 
     Next action: run /implement 061 for Task 2.
 
+### 👔 Leadership / Executive Summary Mode (`/status --exec`)
+
+When requested via `/status --exec`, `/status leadership`, or when writing an update for engineering leadership (VPs, Directors, PMs, release managers):
+- **Tone**: Keep product names, JIRA keys, PR numbers, and business impact. Strip function names, file paths, struct fields, and internal code minutiae.
+- **Channel Shapes**:
+  - *Slack*: 1 bolded TL;DR line + 2-3 short bullets (impact, owner + PR link, next step) under 80 words.
+  - *Async Standup*: 1-2 lines: `<state> <thing> (JIRA/PR). <owner>. <next>.`
+  - *Written Status*: Status (bolded TL;DR) -> Customer Impact -> Progress/Next steps -> Owner.
+
 End with a single suggested next action, chosen in this order:
 
 - The project configuration is invalid -> `/doctor`.

package/template/devflow/build-plan.md

@@ -243,3 +243,12 @@
   - *Dependencies*: None
   - *Scope*: ตัดโฟลเดอร์ vendor `devflow/.vendor/matt-pocock/`, ลบ skill wrapper ของ `matt-pocock` และ `debug-mantra`, รวมสาระสำคัญของ mantra 4 ข้อเข้าสู่ `/debug` (ทั้ง `.agents` และ `.claude`), ลบโฟลเดอร์ตกค้าง `.scratch/` และ `docs/agents/`, อัปเดต `AGENTS.md` และเอกสารเพื่อรองรับการนำเข้า external spec และ tickets จาก `devflow/context/{slug}/issues/` หรือ `tickets/` ได้ทันที
 
+---
+
+## 🧹 Phase 32: Consolidate 9arm Skills into DevFlow Core & Purge Extension
+
+- [x] **32. Consolidate 9arm Skills into DevFlow Core & Purge Extension (`DISC-20260908-001`, `082-consolidate-9arm-skills-and-purge`)** `[Size: S]`
+  - *Dependencies*: None
+  - *Scope*: รวมสาระสำคัญของ `scrutinize` (Outsider Stance, Call-path tracing, Challenge intent) เข้าสู่ `/audit`, ผสาน `post-mortem` เข้าสู่ `/debug` (Phase 4 Handoff) และ `/complete` (Fix Archive Template), เพิ่ม Executive / Stakeholder Summary ใน `/status` และ `/complete`, ลบโฟลเดอร์ extension `post-mortem`, `scrutinize`, `management-talk` ทั้งใน `.agents/` และ `.claude/`, ลบ entries 9arm-skills ออกจาก `.nexus/nexus-devflow.json`, อัปเดตเอกสารและยืนยัน static contracts ผ่าน 100%
+
+

package/template/devflow/history/fixes/README.md

@@ -1,5 +1,21 @@
-# Completed Fixes Archive
+# Completed Fixes Archive (Canonical Post-Mortem Records)
 
 Finished bug fixes, hotfixes, regressions, security patches, and performance optimizations are archived here as `{xxx-slug}.md`.
 
 Together they form the project's permanent bug resolution history, recording root causes, TDD test decisions, and empirical proof.
+
+---
+
+## 🏛️ The 8 Canonical Post-Mortem Blocks
+
+Each completed fix in this directory preserves the following canonical engineering record:
+
+1. **Summary**: One paragraph describing what broke in user/workload terms, what fixed it, JIRA/PR identifiers, and owner.
+2. **Symptom**: Observed test failure, error message, stack trace, or log line with concrete identifiers.
+3. **Root Cause**: The actual bug mechanism with code identifiers (functions, file paths, struct fields, branch conditions).
+4. **Why it Produced the Symptom**: The cause-and-effect chain connecting the root cause to the observed symptom.
+5. **Fix**: What changed and why it addresses the root cause rather than papering over the symptom.
+6. **How it Was Found**: Debugging path, minimal repro command, hypotheses tested and rejected, and the decisive experiment.
+7. **Why it Slipped Through**: The real gap (CI gap, latent code path, workload gap, incomplete prior fix, review miss).
+8. **Validation**: Concrete proof that the fix works (failing test now green, benchmark, customer repro passes).
+9. **Action Items**: Concrete follow-ups (regression test at seam, class-of-bug audit, CI matrix entry) with owners and tickets.