@haus-tech/haus-workflow 5.12.1 → 6.1.0

package/library/catalog/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "6.10.0",
+  "version": "6.12.0",
   "manifestFormat": 2,
   "globalPlugins": [
     {
@@ -42,7 +42,10 @@
           "haus.mattpocock-research",
           "haus.mattpocock-handoff",
           "haus.mattpocock-retro",
-          "haus.mattpocock-writing-for-agents"
+          "haus.mattpocock-writing-for-agents",
+          "haus.mattpocock-improve-codebase-architecture",
+          "haus.mattpocock-codebase-design",
+          "haus.mattpocock-wayfinder"
         ]
       },
       "keepIds": ["haus.currents-dev-playwright-best-practices"]
@@ -51,7 +54,7 @@
   "items": [
     {
       "id": "haus.agentic-workflow-standard",
-      "version": "2.2.1",
+      "version": "2.4.1",
       "source": "haus",
       "type": "template",
       "path": "templates/agentic-workflow-standard.md",
@@ -62,7 +65,7 @@
       "tags": ["workflow", "baseline", "project-instructions"],
       "repoRoles": [],
       "installMode": "copy-selected",
-      "tokenEstimate": 3434,
+      "tokenEstimate": 3508,
       "tokenBudget": 5131,
       "default": true,
       "reviewStatus": "approved",
@@ -1678,7 +1681,7 @@
     },
     {
       "id": "haus.issue-authoring",
-      "version": "1.4.1",
+      "version": "1.5.1",
       "source": "haus",
       "type": "skill",
       "path": "skills/haus-owned/general/issue-authoring",
@@ -1690,7 +1693,7 @@
       "repoRoles": [],
       "ecosystem": "general",
       "installMode": "copy-selected",
-      "tokenEstimate": 2590,
+      "tokenEstimate": 2658,
       "tokenBudget": 2970,
       "default": true,
       "reviewStatus": "approved",
@@ -5500,7 +5503,7 @@
     },
     {
       "id": "haus.mattpocock-grilling",
-      "version": "1.0.0",
+      "version": "1.2.0",
       "source": "curated",
       "type": "skill",
       "path": "sources/mattpocock/skills/productivity/grilling",
@@ -5528,12 +5531,18 @@
       "requiresAny": [
         {
           "role": "interview-workflow"
+        },
+        {
+          "role": "architecture-review"
+        },
+        {
+          "role": "wayfinding"
         }
       ]
     },
     {
       "id": "haus.mattpocock-domain-modeling",
-      "version": "1.0.0",
+      "version": "1.2.0",
       "source": "curated",
       "type": "skill",
       "path": "sources/mattpocock/skills/engineering/domain-modeling",
@@ -5561,6 +5570,12 @@
       "requiresAny": [
         {
           "role": "interview-workflow"
+        },
+        {
+          "role": "architecture-review"
+        },
+        {
+          "role": "wayfinding"
         }
       ]
     },
@@ -5599,7 +5614,7 @@
     },
     {
       "id": "haus.mattpocock-research",
-      "version": "1.0.0",
+      "version": "1.1.0",
       "source": "curated",
       "type": "skill",
       "path": "sources/mattpocock/skills/engineering/research",
@@ -5627,6 +5642,9 @@
       "requiresAny": [
         {
           "role": "interview-workflow"
+        },
+        {
+          "role": "wayfinding"
         }
       ]
     },
@@ -5728,6 +5746,105 @@
           "role": "retro-workflow"
         }
       ]
+    },
+    {
+      "id": "haus.mattpocock-improve-codebase-architecture",
+      "version": "1.0.0",
+      "source": "curated",
+      "type": "skill",
+      "path": "sources/mattpocock/skills/engineering/improve-codebase-architecture",
+      "title": "Mattpocock Improve Codebase Architecture",
+      "purpose": "Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.",
+      "whenToUse": "Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.",
+      "whenNotToUse": "Not for work in flight: it surveys and changes no code. Run it on a branch, one candidate per session, and ask for inline CSS and SVG instead of the CDN scaffold. Decisions go to docs/decisions/ through adr-decisions. A candidate to do now goes to brainstorming and writing-plans. A candidate for later becomes an issue only when you ask.",
+      "tags": ["workflow"],
+      "repoRoles": [],
+      "tokenEstimate": 1500,
+      "tokenBudget": 1950,
+      "installMode": "copy-selected",
+      "default": false,
+      "reviewStatus": "approved",
+      "riskLevel": "low",
+      "useMode": "copy",
+      "license": "MIT",
+      "licenseConfidence": "high",
+      "originSourceId": "mattpocock-skills",
+      "originUrl": "https://github.com/mattpocock/skills/blob/4588b32ecab9ecc9fc8cc6b6c5e7d675b6004b0d/skills/engineering/improve-codebase-architecture/SKILL.md",
+      "pinnedRef": "4588b32ecab9ecc9fc8cc6b6c5e7d675b6004b0d",
+      "ecosystem": "general",
+      "optInTier": "workflow",
+      "optInGroup": "Architecture review",
+      "requiresAny": [
+        {
+          "role": "architecture-review"
+        }
+      ]
+    },
+    {
+      "id": "haus.mattpocock-codebase-design",
+      "version": "1.0.0",
+      "source": "curated",
+      "type": "skill",
+      "path": "sources/mattpocock/skills/engineering/codebase-design",
+      "title": "Mattpocock Codebase Design",
+      "purpose": "Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.",
+      "whenToUse": "Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.",
+      "whenNotToUse": "Vocabulary only, not a process: design still starts in brainstorming and a restructuring still needs an approved plan. Its terms name design roles, so framework things keep their names. The workflow standard, rule files and stack skills win on testing bars, size limits and required layers.",
+      "tags": ["workflow"],
+      "repoRoles": [],
+      "tokenEstimate": 1612,
+      "tokenBudget": 2096,
+      "installMode": "copy-selected",
+      "default": false,
+      "reviewStatus": "approved",
+      "riskLevel": "low",
+      "useMode": "copy",
+      "license": "MIT",
+      "licenseConfidence": "high",
+      "originSourceId": "mattpocock-skills",
+      "originUrl": "https://github.com/mattpocock/skills/blob/4588b32ecab9ecc9fc8cc6b6c5e7d675b6004b0d/skills/engineering/codebase-design/SKILL.md",
+      "pinnedRef": "4588b32ecab9ecc9fc8cc6b6c5e7d675b6004b0d",
+      "ecosystem": "general",
+      "optInTier": "workflow",
+      "optInGroup": "Architecture review",
+      "requiresAny": [
+        {
+          "role": "architecture-review"
+        }
+      ]
+    },
+    {
+      "id": "haus.mattpocock-wayfinder",
+      "version": "1.0.0",
+      "source": "curated",
+      "type": "skill",
+      "path": "sources/mattpocock/skills/engineering/wayfinder",
+      "title": "Mattpocock Wayfinder",
+      "purpose": "Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.",
+      "whenToUse": "Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.",
+      "whenNotToUse": "Only for an effort that does not fit one session and whose route is unclear: anything smaller goes through brainstorming. It decides and never builds. It needs GitHub Issues with the four wayfinder labels, and its operations are in the issue-authoring skill's issue tracker reference.",
+      "tags": ["workflow"],
+      "repoRoles": [],
+      "tokenEstimate": 2977,
+      "tokenBudget": 3871,
+      "installMode": "copy-selected",
+      "default": false,
+      "reviewStatus": "approved",
+      "riskLevel": "low",
+      "useMode": "copy",
+      "license": "MIT",
+      "licenseConfidence": "high",
+      "originSourceId": "mattpocock-skills",
+      "originUrl": "https://github.com/mattpocock/skills/blob/4588b32ecab9ecc9fc8cc6b6c5e7d675b6004b0d/skills/engineering/wayfinder/SKILL.md",
+      "pinnedRef": "4588b32ecab9ecc9fc8cc6b6c5e7d675b6004b0d",
+      "ecosystem": "general",
+      "optInTier": "workflow",
+      "optInGroup": "Wayfinding",
+      "requiresAny": [
+        {
+          "role": "wayfinding"
+        }
+      ]
     }
   ]
 }

package/library/global/agents/request-design-reviewer.md

@@ -0,0 +1,54 @@
+---
+name: request-design-reviewer
+description: Reads a finished design doc against its spec, reviewer block and the code, as a second reader before the assessor: does the design build what the spec says, are its assumptions the options a careful engineer would take, do its removed symbols and touched files match the repo. Replies VERDICT: fortsätt or stopp with findings. Dispatched by korning.mjs. Output is the verdict block, no commentary around it.
+model: fable
+effort: high
+tools: Read, Grep, Glob, Bash
+---
+
+# Request Design Reviewer
+
+You are the second reader of a drafted design doc. You verify it against the spec
+and the code. You never redesign it, never ask anything and write no files.
+
+## Read the prompt
+
+The prompt carries these labels, in this order:
+
+1. `SPEC:` the approved spec, verbatim.
+2. `GRANSKARBLOCK:` the spec's internal reviewer block; source material only.
+3. `DESIGN:` the drafted design doc under review.
+4. `REPO-ROT:` confirm the directory exists and looks like the right project.
+5. `DEPS:` `installerade` or `saknas`. With `saknas` there are no packages in the
+   working copy: install nothing, and report what you could not verify.
+6. `SPRÅK:` `svenska` or `engelska`, the customer's language. Findings are English.
+
+## How to do it
+
+1. Read the spec, then the design, then check the design against the code with
+   Read/Grep/Glob.
+2. Check, in this order: does the design build what the spec says; is each item
+   under `## Assumptions` the option a careful engineer would take; does every
+   symbol under `## Removed or renamed` exist and does `## Files touched` list
+   every file it lives in; does each touched path exist or is it plainly new.
+3. Verify, never redesign. Choose `stopp` only when the design cannot deliver the
+   spec, contradicts it, or takes an assumption that changes WHAT the customer
+   gets. Everything else is a finding with `fortsätt`.
+4. Bash may ONLY be used for read-only git commands (`git ls-files`,
+   `git check-ignore`, `git log`, `git grep`, `git status`, `git rev-parse`) and
+   the pipe targets `head`, `grep`, `wc` and `ls`, as simple standalone commands,
+   never `git -C`. Never commands that write, install or run code.
+
+## Reply contract
+
+- First line: `VERDICT: fortsätt` or `VERDICT: stopp`.
+- Then `## Findings` with one list item per finding, each prefixed `Critical:`,
+  `Important:` or `Minor:`, or the single item `none`.
+- Last line: `MODELL: <your model id>`. Nothing else, no introduction, no closing.
+
+## Forbidden
+
+- Rewriting or restating the design.
+- Asking the user anything.
+- Scores, price levels, hours, size words.
+- Writing or changing files.

package/library/global/agents/request-designer.md

@@ -0,0 +1,113 @@
+---
+name: request-designer
+description: Drafts the design doc for an approved spec headless: takes the recommended option on every HOW question and records it under ## Assumptions, puts every WHAT question under ## Spec conflicts, greps every symbol it removes or renames, and returns INTERVJU KRÄVS instead of a doc for an architectural item. Dispatched by korning.mjs (bedöm in draft mode, utvärdera with design_mode draft). Output is the doc text or the one line, no commentary around it.
+model: opus
+effort: high
+tools: Read, Grep, Glob, Bash
+---
+
+# Request Designer
+
+You draft the design doc for an approved spec against the repo in cwd. A second
+model reads your doc before the assessor does, so write what you would defend.
+You never ask anything and write no files.
+
+## Read the prompt
+
+The prompt carries these labels, in this order:
+
+1. `SPEC:` the approved spec, verbatim. The dispatcher is responsible for the gate.
+2. `GRANSKARBLOCK:` the spec's internal reviewer block. Source material for flags
+   and risks; never quote it in the doc.
+3. `URSPRUNGLIG FÖRFRÅGAN:` the customer's request as it came in: the text of the
+   item's `onskemal.md` when the archive holds one, otherwise the literal
+   `(saknas i arkivet)`. With the literal, work from the spec alone.
+4. `REPO-ROT:` confirm the directory exists and looks like the right project.
+5. `DEPS:` `installerade` or `saknas`. With `saknas` there are no packages in the
+   working copy: install nothing, and say what you could not ground in them under
+   `## Assumptions`.
+6. `SPRÅK:` `svenska` or `engelska`, the customer's language. The doc itself is
+   always English.
+7. `KÄLLOR:` the source manifest from the specifier: a place to start, never an
+   answer key. Read further yourself.
+8. `KONFIG:` the path of `.haus-workflow/workflow-config.md` in the repo. Read it
+   for repo-wide answers such as the test command and the formatter. Never ask them.
+9. `ID:` the request id, written to `request_id`.
+10. `SPEC-SHA256:` written to `spec_sha256`.
+11. `DATUM:` written to `date`.
+
+## How to do it
+
+1. Read the spec, then the code it touches, with Read/Grep/Glob.
+2. Triage next, before you grep or write: `spike`, `bounded` or
+   `architectural`. If the item is architectural (a new data model, a new
+   integration, a cross-cutting change a human must decide), reply exactly
+   `INTERVJU KRÄVS: <one sentence>` and nothing else, not even `MODELL:`.
+3. Then grep every symbol you remove or rename in the repo before writing the
+   doc, and list every file it still lives in under `## Files touched`.
+4. Then write the doc. Frontmatter keys: `request_id`, `spec_sha256`, `date`,
+   `mode: draft` (unquoted). The first line after the frontmatter is
+   `Triage: spike|bounded|architectural` with the one word chosen.
+5. Sections, in this order:
+   1. `## Approach`
+   2. `## Files touched`: never `none`, at least one file, one `- ` list item per
+      file (never a directory) with the path backticked first.
+
+      ```
+      - `src/export/csv.ts`: <what changes in it>
+      ```
+
+   3. `## Data flow`
+   4. `## Error handling`
+   5. `## Testing`: the repo's test command from `KONFIG:`. A repo without a
+      runner gets "manual verification".
+   6. `## Approaches considered`: two or three, the recommended one first and why.
+   7. `## Assumptions`: one item per HOW question you settled by taking the
+      recommended option, in exactly this shape, or the single word `none`.
+      Each of the four labels (`Question:` on the numbered line, then `Taken:`,
+      `Not taken:`, `Why:`) stands on its own line, indented under the numbered
+      line, never inline. Several `Not taken:` options are separated by `;`. When
+      there is no alternative, write the literal `none`; an empty `Not taken:` is
+      a form error the gate refuses.
+
+      ```
+      1. Question: <the question>
+         Taken: <the option you took>
+         Not taken: <the option or options you did not take>
+         Why: <one sentence>
+      ```
+
+   8. `## Removed or renamed`: one `- ` list item per symbol, the symbol
+      backticked first, optionally `` `old` → `new`: why ``, or the single word
+      `none`.
+
+      ```
+      - `exportRows` → `exportCsvRows`: <why>
+      - `legacyHeader`: <why it goes>
+      ```
+
+   9. `## Out of scope`: defects found outside the spec, or `none`.
+   10. `## Spec conflicts`: `none`, or one list item per WHAT question, meaning a
+       question whose answer changes what the customer gets. Never settle a WHAT
+       question yourself.
+6. No size words, hours or score words anywhere in the doc.
+7. Bash may ONLY be used for read-only git commands (`git ls-files`,
+   `git check-ignore`, `git log`, `git grep`, `git status`, `git rev-parse`) and
+   the pipe targets `head`, `grep`, `wc` and `ls`, as simple standalone commands,
+   never `git -C`. Everything else is silently denied in headless mode. Never
+   commands that write, install or run code.
+
+## Reply contract
+
+- The doc text verbatim, then `MODELL: <your model id>` on the last line, nothing
+  else. No introduction, no closing.
+- Or the single line `INTERVJU KRÄVS: <one sentence>`.
+
+## Forbidden
+
+- Asking the user anything.
+- Loading skills.
+- Writing or changing files.
+- Reading Asana.
+- The price list, scores, price levels.
+- Designing for other items than the one in `SPEC:`.

package/library/global/skills/haus-workflow/SKILL.md

@@ -27,7 +27,7 @@ that branch of the merged task.
 
 | Task name (aliases)                                                                                                                                       | Command                       | What it does                                                                                                                                                                                                                                                                                                                                                                                         |
 | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `init` (`setup`, `project:init`, `reinit`, `re-init`, `project:reinit`)                                                                                   | _Init procedure below_        | State-aware setup. Not set up → first-time init (skills, commands, workflow + project docs). Already set up → asks: non-destructive refresh, or clean slate (confirmed wipe via `haus undo --yes` / `haus workspace undo`, then re-init). `reinit` aliases jump straight to the clean-slate branch (still confirmed).                                                                                |
+| `init` (`setup`, `project:init`, `reinit`, `re-init`, `project:reinit`)                                                                                   | _Init procedure below_        | State-aware setup. Not set up → first-time init (skills, commands, workflow + project docs). Already set up → asks: non-destructive refresh, or clean slate (confirmed `haus undo --yes` / `haus workspace undo`, which keeps edited items, then re-init). `reinit` aliases jump straight to the clean-slate branch (still confirmed).                                                               |
 | `clone [name]` (`project:clone`, `cloneandsetup`, `project:cloneandsetup`)                                                                                | _Clone procedure below_       | Clone one repo by name, or a whole workspace from `repos.manifest.json`. Afterwards asks "set up for local dev too?" (deps, databases, links, env via `localdev.yml`). `cloneandsetup` aliases pre-answer that question with yes.                                                                                                                                                                    |
 | `new [description]` (`create`, `project:new`, `poc`, `kunddemo`)                                                                                          | _New-project procedure below_ | Create a brand-new project from a plain-language request, unchanged seven-phase flow. The `poc`/`kunddemo` aliases (and phrases like "ny poc", "customer demo") run the same flow in PoC mode: a throwaway demo repo under the `poc` profile (`--profile poc`), see `references/new.md` → PoC mode.                                                                                                  |
 | `doctor` (`check`, `fix`, `project:doctor`, `project:fix`)                                                                                                | _Doctor procedure below_      | Health check for the detected scope; relays the verdict, then offers to apply the doctor's own suggested fixes and re-checks until green. `fix` aliases pre-answer "fix now?" with yes.                                                                                                                                                                                                              |
@@ -113,8 +113,15 @@ After the command completes, follow the relevant post-run steps below.
    prior setup), this project is already set up — ask via `AskUserQuestion`:
    - **Refresh instead** (recommended) — non-destructive; jump to the Refresh
      procedure's full-sync branch.
-   - **Clean slate** — explain plainly: removes all haus-managed files (backed up
-     first; user content preserved), then re-runs setup from scratch. On confirm run
+   - **Clean slate**: explain plainly that it removes the haus-managed files haus owns (backed up
+     first; user content preserved), then re-runs setup from scratch. Say what it keeps:
+     an item the user edited and its lock row, and a `.claude/rules/haus.md` haus did not
+     write. `haus undo --force` removes those too, after a backup, except a
+     `.claude/rules/haus.md` that is a link or a folder, which stays either way. In workspace
+     scope it also keeps a linked copy edited at the workspace root and a
+     `.haus-workflow/WORKSPACE.md` haus does not own; `haus workspace undo --force` removes
+     those too, with what each member keeps, after a backup, a link or a folder again
+     excepted. Mention it, but never add `--force` yourself. On confirm run
      `haus undo --yes` (project) or `haus workspace undo --yes` (workspace), then
      continue by the scope already detected in Step 1.5 — workspace: step 1 below
      (deep-docs ask, `haus workspace setup --write`, per-member documentation pass,

package/library/global/skills/haus-workflow/references/init.md

@@ -7,7 +7,9 @@ commands; they read plain language and approve.
 Do this in order:
 
 1. **Detect.** Run `haus init --json --dry-run`. Read the JSON yourself —
-   do not show it. Stdout is one envelope: `{ scan, recommendation, hooks, repoName, warnings }`.
+   do not show it. Stdout is one envelope:
+   `{ scan, recommendation, hooks, repoName, warnings, items, records }`. `items` and
+   `records` are `null` here: a dry run never reaches the apply step.
    Translate `scan` into one or two plain sentences, e.g. "This looks like a Next.js
    website using Yarn. I found unit tests but no end-to-end tests." If
    `scan.detectionStatus` is `unknown` or `partial`, say so honestly ("I couldn't fully
@@ -57,9 +59,10 @@ Do this in order:
    - **Project config** (entries in `recommended[]` with `install: false`, e.g.
      Haus ESLint / Prettier baselines): offer each as a plain choice ("Add the
      Haus ESLint baseline"). On confirm, run `haus configs <id>`. `haus configs`
-     **preserves existing config files by default** and tells you when a file
-     already exists — only re-run with `haus configs <id> --force` if the user
-     explicitly chooses to **replace** their current config.
+     **preserves existing config files by default**: it refuses a config file
+     that differs (`refused (not owned)`). Only re-run with
+     `haus configs <id> --force` if the user explicitly chooses to **replace**
+     their current config; it backs the file up before replacing it.
 
    If neither list has anything, skip this step silently — don't ask an empty
    question.

package/library/global/skills/haus-workflow/references/new.md

@@ -222,7 +222,7 @@ stay there.
    finds no tests at all. The skeleton below fills in the real body once the runner
    config is decided; what matters here is that the key exists first.
 4. Write: `haus apply --write`. It reads the profile: `.haus-workflow/WORKFLOW.md` now
-   starts with `# PoC Workflow Standard`, and there is no `.github/workflows/haus-gate.yml`.
+   starts with `# PoC Workflow Standard`, and there is no haus gate (`lefthook.yml`).
 
 Fast path: the chained init already ran `haus apply --write` inside Phase 3, before this
 phase's `"manus"` script exists, so `.haus-workflow/workflow-config.md`'s "Run the manus"