@reddb-io/red-skills-dev 2.75.2

package/skills/engineering/code-review/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: code-review
+description: Two-axis code review of the diff between HEAD and a fixed point — Standards (does the code follow this repo's documented coding standards and the Fowler smell baseline?) and Spec (does it implement what the issue/Spec asked for?). Runs both reviews as parallel sub-agents. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
+---
+
+# Code Review
+
+Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
+
+- **Standards** — does the code conform to this repo's documented coding standards, and does it avoid the universal Fowler smell baseline?
+- **Spec** — does the code faithfully implement the originating issue / Spec / spec?
+
+Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
+
+The issue tracker should have been provided to you — run `/red-setup` if `.red/agents/issue-tracker.md` is missing.
+
+<what-to-do>
+
+## Process
+
+### 1. Pin the fixed point
+
+Whatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. Don't be opinionated; pass it through. If they didn't specify one, ask: "Review against what — a branch, a commit, or `main`?" Don't proceed until you have it.
+
+Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
+
+### 2. Identify the spec source
+
+Look for the originating spec, in this order:
+
+1. Issue references in the commit messages (`#123`, `Closes #45`, etc.) — fetch via `gh issue view` per `.red/agents/issue-tracker.md`.
+2. A path the user passed as an argument.
+3. A Spec/spec file under `docs/` or `specs/` matching the branch name or feature.
+4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
+
+### 3. Identify the standards sources
+
+Anything in the repo that documents how code should be written. Common locations:
+
+- `CLAUDE.md`, `AGENTS.md`
+- `CONTRIBUTING.md`
+- `.red/CONTEXT.md`, `.red/CONTEXT-MAP.md`, per-context `.red/CONTEXT.md` files
+- `.red/adr/` (architectural decisions are standards)
+- `.editorconfig`, `eslint.config.*`, `biome.json`, `prettier.config.*`, `tsconfig.json` (machine-enforced standards — note them but don't re-check what tooling already checks)
+- Any `STYLE.md`, `STANDARDS.md`, `STYLEGUIDE.md`, or similar at the repo root or under `docs/`
+
+Collect the list of files. The **Standards** sub-agent will read them and also apply the always-on Fowler smell baseline (see `<supporting-info>`).
+
+### 4. Spawn both sub-agents in parallel
+
+Send a single message with two `Agent` tool calls. Use the `general-purpose` subagent for both.
+
+**Standards sub-agent prompt** — include:
+
+- The full diff command and commit list.
+- The list of standards-source files you found in step 3.
+- The twelve-smell Fowler baseline table from `<supporting-info>`, pasted in verbatim so the sub-agent has the list without reading this skill's file.
+- The brief: "Read the standards docs. Then read the diff. Report — per file/hunk where relevant — every place the diff violates a documented standard. Cite the standard (file + the rule). Distinguish hard violations from judgement calls. Skip anything tooling enforces. Also apply the always-on Fowler smell baseline table above, even when no standards doc exists. For each smell found, name it and suggest a one-line fix. Repo standards override the baseline. Under 400 words total."
+
+**Spec sub-agent prompt** — include:
+
+- The diff command and commit list.
+- The path or fetched contents of the spec.
+- The brief: "Read the spec. Then read the diff. Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
+
+If the spec is missing, skip the Spec sub-agent and note this in the final report.
+
+### 5. Aggregate
+
+Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings — the two axes are deliberately separate so the user can see them independently.
+
+End with a one-line summary: total findings per axis, and the worst single issue (if any) flagged.
+
+</what-to-do>
+
+<supporting-info>
+
+## Why two axes
+
+A change can pass one axis and fail the other:
+
+- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**
+- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**
+
+Reporting them separately stops one axis from masking the other.
+
+## Fowler smell baseline
+
+These twelve smells apply universally to every review, even when the repo has no written standards. Repo-specific standards override or extend them.
+
+| Smell | One-line fix |
+|---|---|
+| **Mysterious Name** | Rename to describe exactly what it does |
+| **Duplicated Code** | Extract the shared logic once |
+| **Feature Envy** | Move the method closer to the data it uses |
+| **Data Clumps** | Bundle the recurring group into an object |
+| **Primitive Obsession** | Replace bare strings/numbers with typed objects |
+| **Repeated Switches** | Replace with polymorphism or a dispatch table |
+| **Shotgun Surgery** | Consolidate the scattered change points into one place |
+| **Divergent Change** | Split the class by its distinct responsibilities |
+| **Speculative Generality** | Delete the unused abstraction |
+| **Message Chains** | Introduce a method that hides the chain |
+| **Middle Man** | Remove the delegator and call the real object directly |
+| **Refused Bequest** | Push down the unused inheritance to the subclass that needs it |
+
+</supporting-info>

package/skills/engineering/context/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: context
+description: Build and refresh the project context stack before non-trivial work — domain glossary, ADRs, LLM Wiki, Memory graph, graph-aware zoom-out, and self-improvement signals. Use when the user asks to "get context", "manage context", onboard to a repo, prepare a large change, or improve agent memory/self-improvement loops.
+---
+
+# context
+
+**Ground the session before non-trivial work — read committed docs, recall memory, zoom out, then drill in.**
+
+<what-to-do>
+
+## Context stack loop
+
+Run these phases in order. Skip a phase only when its prerequisite is absent and the fallback says to skip.
+
+### 1. Orient from committed project context
+
+Read these first, if present:
+
+1. `CLAUDE.md` or `AGENTS.md` — agent rules and registered skills.
+2. `.red/CONTEXT.md` — canonical domain glossary.
+3. `.red/adr/` — architectural decisions, newest relevant ADRs first.
+4. `.red/CONTEXT-MAP.md` — monorepo context routing, if present.
+
+Do not ask the user to repeat information that is already present in those files. If the glossary is missing a term you must use in the answer or plan, add or propose the term through the owning workflow (`/start` for domain/ADR updates) instead of inventing private vocabulary in chat.
+
+### 2. Recall prior memory before re-deriving
+
+If memory is configured here (a `plugins.memory` block in `.red/config.yaml`, or the legacy `.red/memory/config.json`), run a targeted recall before deep investigation:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" recall "<topic terms>"
+```
+
+Use the configured Memory mode automatically. In graph mode, recall is neighborhood-expanded and supersede-aware; in markdown-only mode, it searches notes. Treat hits as historical claims: cite them internally, then verify against the current worktree before relying on them.
+
+Fallback: if Memory is absent, unbuilt, uninitialized, markdown-only when graph is needed, or failing, continue with ordinary repo reads. Memory is an optimization, not a hard dependency of `dev`.
+
+### 3. Refresh structural graph only when explicitly useful
+
+Use graph indexing for large or unfamiliar codebases, impact analysis, onboarding, or repeated work across sessions:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" ingest . --root .
+```
+
+Only run this when Memory is initialized in graph mode. Do not run it from read-only skills such as `/zoom-out`; for those, recommend the command instead. Re-run after large refactors or before a long `/afk` wave if the graph is stale.
+
+### 4. Zoom out before drilling in
+
+Use `/zoom-out` semantics for map-first understanding:
+
+- Start with modules/layers and ownership boundaries.
+- Then explain relationships, critical paths, risks/gaps, and optional impact.
+- Use Memory graph neighbors/paths only as evidence to interpret, never as raw dumps.
+- Verify graph evidence against files before making claims.
+
+For a concrete bug or feature, produce a short orientation map before reading leaf files. This mirrors the Understand-Anything / graphify lesson: the graph is valuable when it teaches how pieces fit together, not when it merely shows complexity.
+
+### 5. Use the LLM Wiki for durable project knowledge
+
+If `.red/agents/wiki.md` and `.red/wiki/` exist, use `/wiki query <question>` for compiled knowledge and `/wiki ingest <source>` for durable external or internal sources.
+
+Rules:
+
+- Read `.red/agents/wiki.md` before any wiki operation.
+- Keep `.red/wiki/` gitignored; do not commit raw/private wiki state.
+- File back only durable syntheses that would be painful to re-derive.
+- Keep source pages, concept/entity pages, contradictions, and index/log current.
+
+Fallback: if the wiki is not initialized and the project would benefit from compounding research/docs memory, recommend `/wiki-init` with the target domain.
+
+### 6. Capture only durable learning
+
+After a non-trivial investigation, store one fact per durable lesson:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" store "<decision, gotcha, or why-note>"
+```
+
+Store durable operational decisions, root causes, and gotchas. Do not store secrets, Personal facts, biographical details, durable human preferences, transient progress, issue numbers, PR numbers, commit SHAs, or "task done" logs that will be stale in a week. Route human-facing context to Brain with `brain capture`. If the learning is procedural and reusable, update or create a skill instead of storing it as memory.
+
+### 7. Check self-improvement signals
+
+When Skill telemetry is enabled, inspect it before curating:
+
+```bash
+node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" status skills --root .
+node "${CLAUDE_PLUGIN_ROOT}/../memory/scripts/bootstrap.mjs" curate skills --root .
+```
+
+`memory curate skills` is report-only. Mutating workflow stays in `/curate`, which archives only Curatable skills after explicit approval and can restore them. Never auto-delete skills.
+
+### 8. Report the context posture
+
+Before moving into implementation, summarize:
+
+- Committed context read: files/ADRs consulted.
+- Memory posture: absent / markdown-only / graph ready / graph stale / recall hits used.
+- Wiki posture: absent / queried / updated.
+- Codebase map: key modules and edges relevant to the task.
+- Self-improvement posture: no action / store facts / update skill / run curator.
+
+Keep this summary concise. The goal is to prove the agent is grounded, not to dump every artifact.
+
+### 9. End-of-session doc-landing finalizer
+
+When the context session ends, run the shared end-of-session doc-landing finalizer in [`/start`'s DOC-LANDING-FINALIZER.md](../start/DOC-LANDING-FINALIZER.md) before exiting.
+
+## Hard rules
+
+- Do not let graph or memory output outrank the current worktree.
+- Do not dump raw nodes, edges, recall hits, or path listings as the final answer; interpret them into project terms.
+- Do not write Memory/Wiki/Skill state from a read-only analysis unless the user asked for that side effect.
+- Do not commit `.red/wiki/`, `.red/memory/graph.rdb*`, generated graph exports, or private memory notes unless the project explicitly made them committable.
+- Prefer one focused context refresh over repeated broad searches.
+
+</what-to-do>
+
+<supporting-info>
+
+## Choosing the right surface
+
+| Need | Surface |
+|------|---------|
+| Current repo rules and vocabulary | `CLAUDE.md` / `AGENTS.md`, `.red/CONTEXT.md`, `.red/adr/` |
+| Prior decisions/gotchas | `/memory:recall` |
+| Code structure and impact | `/memory:ingest`, graph reads, `/zoom-out` |
+| External docs/research/source synthesis | `/wiki ingest`, `/wiki query` |
+| Durable operational work fact | `/memory:store` |
+| Personal fact or human-facing context | `brain capture` / `/brain:capture` |
+| Reusable procedure | update/create a `SKILL.md` |
+| Skill lifecycle maintenance | `memory status skills`, `memory curate skills`, `/curate` |
+
+## Common outcomes
+
+- **Cold repo:** run `/red-setup`, then `/wiki-init` only if the repo needs a private knowledge base, then `memory init --mode graph` when persistent graph recall is worth the local RedDB store.
+- **Large code change:** recall prior decisions, ingest if graph is stale, zoom out around the target, then drill down.
+- **Repeated agent failures:** recall prior attempts/root causes, inspect Skill telemetry, update the failing skill or file a human-ready curator issue.
+- **Research-heavy project:** ingest sources into the wiki, create synthesis pages, store only stable operational decisions/gotchas in Memory, and capture Personal facts or human-facing context in Brain.
+
+</supporting-info>

package/skills/engineering/curate/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: curate
+description: Interactive Skill curator. Reads `memory curate skills --json`, groups Curatable-skill candidates by category (`stale`, `abandoned`, `frequently-failing`, `archive`), asks for explicit approval, archives the approved set recoverably with the approving category recorded in the manifest, and reverses any archive with `/curate --restore <name>`. With `--background`, files a single `ready-for-human` Issue listing candidates and never mutates a Skill file.
+argument-hint: "[--restore <skill-name>] [--background] (no arg = interactive curation flow)"
+disable-model-invocation: true
+---
+
+**Archive Curatable skills recoverably — the engine uses `rename` only; never call `rm`, `unlink`, or `git rm`, because every archive reverses with `--restore <name>`.**
+
+<what-to-do>
+
+This skill **mutates skills on disk**. Run the loop below verbatim. Every mutation goes through `memory curate`, the workflow engine embedded in the Memory CLI — never invent shell commands that delete, overwrite, or rename skill files directly.
+
+### Boot precondition (always, before anything else)
+
+Run `memory curate check`. If it exits non-zero, print its stderr verbatim and **stop**. The error already names the exact `memory init --mode graph --skill-telemetry` command the user needs.
+
+### Background mode — `--background`
+
+If the argument is `--background`:
+
+1. Run `memory curate background`. The engine runs the same boot precondition (graph mode + Skill telemetry); if the precondition fails it prints the **same prerequisite message** the interactive path uses and exits non-zero. Print its stderr verbatim and stop.
+2. The engine reads `memory curate skills --json`, applies the same Curatable / pinned / category filtering as the interactive view, and:
+   - if the candidate list is **empty**, exits with no side effect (no issue is filed, no comment, no noise);
+   - otherwise files **exactly one** Issue on the project's Issue tracker labelled `ready-for-human` whose body lists candidates grouped by category (`stale` → `abandoned` → `frequently-failing` → `archive`) with the same glossary vocabulary and evidence the interactive view shows.
+3. Print the engine's one-line receipt verbatim. Stop.
+
+`--background` performs **zero filesystem mutations of any Skill file** under any input — it never invokes `archive` or `restore`. The loop closes when a human (or `/afk` against the filed issue) runs interactive `/curate` and names the skills to archive; that path keeps the tracer-slice atomic-rename + hash-manifest guarantees.
+
+### Restore mode — `--restore <name>`
+
+If the argument starts with `--restore`:
+
+1. Extract `<name>` (everything after `--restore`).
+2. Run `memory curate restore <name>`.
+3. The engine reads the archive manifest, moves the skill back to its **original** path, and verifies every restored file's SHA-256 against the manifest.
+4. Print the engine's receipt verbatim. Stop.
+
+If the user passes `--restore` with no name, ask for one and re-issue.
+
+### Curation mode — default (interactive)
+
+1. **List candidates.** Run `memory curate list`. It emits JSON of the form:
+   ```json
+   {
+     "candidates": [...],
+     "byCategory": { "stale": [...], "abandoned": [...], "frequently-failing": [...], "archive": [...] },
+     "filtered": [...],
+     "totals": {...}
+   }
+   ```
+   `candidates[]` is the flat list across every in-scope category; each entry carries `category` and the curator's `reason` for that category. `byCategory` is the same data indexed by category — **categories with zero candidates are absent**, never present as empty arrays. `filtered[]` records anything the engine defensively dropped (bundled `plugin`/`hub` source kinds, pinned skills, non-curatable items).
+
+2. **Empty case.** If `candidates` is `[]` (equivalently, `byCategory` is `{}`), print `no curate candidates — nothing to curate` and **stop**. Do not invoke `archive`. Do not write any file.
+
+3. **Show the user, grouped by category.** For each category present in `byCategory`, in the order `stale`, `abandoned`, `frequently-failing`, `archive`, print a header naming the category and one block per candidate beneath it. Each block must show:
+   - the skill `name`,
+   - `source_kind`,
+   - the original `path`,
+   - the category-specific evidence carried in `reason` (e.g. "no skill activity for 90d (threshold 60d)" for `stale`, "loaded 5× but never invoked" for `abandoned`, "3/6 results failed (50%)" for `frequently-failing`, the archive signal text for `archive`).
+
+   **Do not** render a header for a category that is not present in `byCategory`. Use the canonical glossary terms — "Curatable skill", "Skill telemetry", and the four category names — verbatim.
+
+4. **Ask for explicit approval.** Prompt: `Archive which skills? Reply with comma-separated names, "all", or "none".` Approval is by skill name; if the same skill appears in more than one category, ask the user which category to record before archiving and archive once. Treat anything that isn't a known candidate name (or `all`) as `none`. **No approval = no mutation.** This is the load-bearing safety surface; do not infer consent from silence, conversation history, or default.
+
+5. **Archive each approved Curatable skill.** For every approved name, invoke `memory curate archive --candidate <json>` where `<json>` is the matching candidate object from step 1 (including its `category`) emitted via single-quoted JSON. The engine:
+   - Re-validates `source_kind` and `pinned` (refuses bundled / pinned inputs with a structured rejection — no I/O).
+   - Computes SHA-256 + byte length for every file under the skill's directory.
+   - Moves the skill into `.red/memory/skill-archive/<name>/payload/` via atomic `rename` (no `unlink`/`rm`).
+   - Writes a manifest at `.red/memory/skill-archive/<name>/manifest.json` recording the original root, archive timestamp, **the approving category**, the evidence reason, and per-file hashes.
+
+6. **Print the receipt.** For each archived skill, echo the engine's one-line output. Then print: `Restore any of them with /curate --restore <name>.`
+
+### Invariants you must not violate
+
+- ✅ Empty / declined approval → zero filesystem mutations.
+- ✅ Bundled (`source_kind` `plugin` / `hub`) and pinned skills are filtered defensively in every category and never archived, even if a future Memory build leaks one into the report.
+- ✅ Categories with zero candidates are omitted from the listing — never shown as empty headers.
+- ✅ Every archive is recoverable through `/curate --restore <name>` — the engine refuses to clobber an existing archive directory and refuses to overwrite a live skill on restore.
+- ❌ Never call `rm`, `unlink`, `git rm`, or any shell that deletes files in this flow. The engine uses `rename` only; you must follow the same discipline.
+
+</what-to-do>
+
+<supporting-info>
+
+### Invocation cheat sheet
+
+```
+# Boot check (always first)
+memory curate check
+
+# List candidates grouped by category as JSON
+memory curate list
+
+# Non-interactive: file a single ready-for-human Issue (never mutates a Skill file)
+memory curate background
+
+# Archive one approved candidate (category flows into the manifest)
+memory curate archive --candidate '{"name":"foo","source_kind":"project","path":"/abs/.../SKILL.md","reason":"no skill activity for 90d (threshold 60d)","category":"stale"}'
+
+# Restore one archived skill
+memory curate restore foo
+```
+
+The workflow ships inside the `memory` CLI. `memory curate skills` remains report-only; `memory curate check|list|background|archive|restore` are the `/curate` workflow commands.
+
+### Archive layout
+
+```
+.red/memory/skill-archive/
+└── <skill-name>/
+    ├── manifest.json   # {name, originalRoot, archivedAt, category, reason, files:[{relativePath, sha256, byteLength}]}
+    └── payload/        # the renamed-in original skill directory
+        ├── SKILL.md
+        └── ...
+```
+
+After a restore, the `payload/` directory is renamed back to its original path and the `manifest.json` is intentionally left behind as a record (the engine never calls a destructive op).
+
+### Glossary anchors
+
+- **Curatable skill** — a Skill whose files may be modified, consolidated, or archived because it is user-owned or agent-created. Bundled `plugin` / `hub` skills are not Curatable.
+- **Skill telemetry** — lifecycle and interaction events for a Skill, available only in **Graph mode** with the `--skill-telemetry` opt-in.
+- **stale** — a Skill that has had no activity for at least the configured stale threshold (default 60 days).
+- **abandoned** — a Skill that has been viewed (loaded) but never used, or whose `abandoned` outcomes outweigh `succeeded` ones.
+- **frequently-failing** — a Skill whose share of `failed` result outcomes is at or above the failure-ratio threshold over a minimum number of result events.
+- **archive** — the recoverable move of an approved Curatable skill into `.red/memory/skill-archive/`, reversible via `/curate --restore`.
+
+### Scope (this slice)
+
+This slice extends the tracer's archive-only flow to the four in-scope curator categories: `stale`, `abandoned`, `frequently-failing`, and `archive`. The remaining curator categories (`consolidation`, `restore`) surface in the Memory report but are **not** acted on by this version of `/curate`; their mutating workflows are later slices.
+
+</supporting-info>

package/skills/engineering/daily-review/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: daily-review
+description: Generates a RedSkills operational review for a requested period. Default period is yesterday midnight to now (one day); pass `--period week` for a six-day window. Covers delivered work, local AFK workers, cycle times, and HITL/blocker challenges. Use when the user invokes `/daily-review`, `/weekly-review`, asks for daily or weekly delivery numbers, issues/PRs/commits/diffstat, worker attempts, token spend, or why tasks needed HITL.
+argument-hint: "[--period day|week] [--json] [--human]"
+disable-model-invocation: true
+---
+
+# /daily-review
+
+<what-to-do>
+
+**Wrapper over the dev runtime — see [`_report-runtime/WRAPPER.md`](./../_report-runtime/WRAPPER.md) for the Run shim and output-format rules.**
+
+Run the subcommand that matches the requested period:
+
+| Period flag | Subcommand |
+| --- | --- |
+| `--period day` (default) | `red-skills-dev daily-review [--json]` |
+| `--period week` | `red-skills-dev weekly-review [--json]` |
+
+Dev-checkout equivalent:
+
+| Period flag | Command |
+| --- | --- |
+| `--period day` (default) | `node plugins/dev/skills/engineering/afk/bin/afk.mjs daily-review [--json]` |
+| `--period week` | `node plugins/dev/skills/engineering/afk/bin/afk.mjs weekly-review [--json]` |
+
+</what-to-do>
+
+<supporting-info>
+
+## Intervals
+
+**day (default):** local midnight at the start of yesterday through the exact
+generation time. Example: if now is `2026-06-06 14:25`, the interval is
+`2026-06-05 00:00` through `2026-06-06 14:25`.
+
+**week:** local midnight six calendar days before today through the exact
+generation time. Example: if now is `2026-06-06 14:25`, the interval is
+`2026-05-31 00:00` through `2026-06-06 14:25`.
+
+## Output format detail
+
+The TOON wire format renders the `workers`, `challenges`, and cycle-time tables
+as one column header plus bare CSV rows; big-number aggregates are pre-computed;
+empty tables use the definitive `key[0]:` empty state.
+
+## Report Sections
+
+- Big numbers: issues created/closed, PRs created/closed/merged, commits, lines
+  added/removed, local workers, local attempts, local worker time, token spend
+  when retained runner logs expose usage fields.
+- Local workers: worker id, attempts, issues, runner, duration, and terminal
+  events from the `.red/state/castle/history.toonl` TOONL lane plus live local
+  worker state. `tq` is pinned by `/red-setup` and is the only documented
+  reader for RedSkills-owned TOONL lanes; there is no jq fallback.
+- Challenges: HITL/blocker/no-sentinel/merge-conflict evidence from issue
+  labels, issue bodies/comments, and local AFK history reasons.
+- Issue and PR cycle times: closed-in-interval rows include items opened before
+  the interval, so old work closed in the review window remains visible.
+
+## Notes
+
+Token spend is best-effort. Current AFK artifacts do not guarantee usage fields;
+the report says `n/a` and emits a warning when no retained local log has token
+data.
+
+</supporting-info>

package/skills/engineering/dashboard/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: dashboard
+description: Shows a RedSkills operational dashboard with issue, Spec, AFK worker, flow, and DORA-proxy metrics from GitHub plus local AFK state. Use when the user invokes `/dashboard`, asks for RedSkills process metrics, workers running, open Specs/issues, cycle time, or DORA metrics.
+argument-hint: "[--period N|Nd] [--json] [--human]"
+disable-model-invocation: true
+---
+
+# /dashboard
+
+<what-to-do>
+
+**Wrapper over the dev runtime — see [`_report-runtime/WRAPPER.md`](./../_report-runtime/WRAPPER.md) for the Run shim and output-format rules.**
+
+Run: `red-skills-dev dashboard [--period 30d] [--json]`
+
+Dev-checkout equivalent: `node plugins/dev/skills/engineering/afk/bin/afk.mjs dashboard [--period 30d] [--json]`
+
+</what-to-do>
+
+<supporting-info>
+
+## Output format detail
+
+The TOON wire format uses pre-computed aggregate groups, minimal schemas, and a
+definitive `warnings[0]:` empty state.
+
+## Metrics
+
+- Open Specs.
+- Open non-Spec issues.
+- Global running workers: open issues labelled `running`.
+- Local workers on this machine: live/stale/total AFK worker state files.
+- Issues created, closed today, and closed in the selected period.
+- Due metrics from `due: YYYY-MM-DD`, `due_date: YYYY-MM-DD`, `deadline: YYYY-MM-DD`, `target date: YYYY-MM-DD`, or label `due:YYYY-MM-DD`.
+- PR flow: open PRs, merged PRs, average issue cycle time, average PR lead time.
+- DORA proxies: release frequency, lead time for changes, change-failure-rate proxy, failure-like issues closed, MTTR proxy.
+
+## Notes
+
+The DORA values are explicit proxies, not compliance claims. Change failure and
+MTTR depend on issue labels such as `type:bug`, `bug`, `regression`, `incident`,
+`type:incident`, or `blocked:validation`.
+
+</supporting-info>

package/skills/engineering/diagnose/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: diagnose
+description: Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
+---
+
+# Diagnose
+
+**Build the feedback loop first — without one, every subsequent phase is mechanical guesswork.**
+
+<what-to-do>
+
+When exploring the codebase, use the project's domain glossary to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
+
+### Phase 1 — Build a feedback loop
+
+**This is the skill.** Do not move on without one. A fast, deterministic, agent-runnable pass/fail signal makes every later phase mechanical. Without one, no amount of staring at code will save you.
+
+**Be aggressive. Be creative. Refuse to give up.** Spend disproportionate effort here.
+
+Try the 10 construction strategies in `<supporting-info>` in roughly that order. Once you have a loop, **iterate on it as a product**:
+
+- Make it faster (cache setup, narrow scope)
+- Make the signal sharper (assert on the specific symptom, not "didn't crash")
+- Make it deterministic (pin time, seed RNG, isolate filesystem, freeze network)
+
+For **non-deterministic** bugs the goal is a **higher reproduction rate**, not a clean repro. Loop the trigger 100×, parallelise, add stress, narrow timing windows. 50% flake is debuggable; 1% is not.
+
+**Do not proceed to Phase 2 until you have a loop you believe in.** If you genuinely cannot build one, stop and tell the user what you tried; ask for environment access, a captured artifact, or permission to add temporary production instrumentation.
+
+### Phase 2 — Reproduce
+
+Run the loop. Watch the bug appear. Confirm all three:
+
+- [ ] The loop produces the failure mode the **user** described — not a different failure that happens to be nearby
+- [ ] The failure is reproducible across multiple runs (or, for non-deterministic bugs, at a high enough rate to debug against)
+- [ ] You captured the exact symptom (error message, wrong output, slow timing) so later phases can verify the fix addresses it
+
+**Do not proceed until you reproduce the bug.**
+
+### Phase 3 — Hypothesise
+
+**First, recall past root causes** (optional — only if the `memory` plugin is installed; see *Memory recall* in `<supporting-info>`). A symptom you're seeing now may have a documented root cause from a previous diagnosis — recalling it pre-seeds the hypothesis list with battle-tested candidates instead of starting cold. Best-effort: if `memory` is absent, skip silently and hypothesise as usual.
+
+Generate **3–5 ranked hypotheses** before testing any of them. Single-hypothesis generation anchors on the first plausible idea. Fold any recalled root cause in as a candidate — but still verify it against *this* repro; a past cause is a lead, not a verdict.
+
+Each hypothesis **must be falsifiable**:
+
+> Format: *"If &lt;X&gt; is the cause, then &lt;changing Y&gt; will make the bug disappear / &lt;changing Z&gt; will make it worse."*
+
+If you can't state the prediction, the hypothesis is a vibe — discard or sharpen it.
+
+**Show the ranked list to the user before testing.** They often have domain knowledge that re-ranks instantly ("we just deployed a change to #3") or know hypotheses they've already ruled out. Cheap checkpoint, big time saver. Don't block on it if the user is AFK — proceed with your ranking.
+
+### Phase 4 — Instrument
+
+Each probe maps to a specific prediction from Phase 3. **Change one variable at a time.**
+
+Tool preference, in order:
+
+1. Debugger / REPL inspection if the env supports it — one breakpoint beats ten logs
+2. Targeted logs at the boundaries that distinguish hypotheses
+3. Never "log everything and grep"
+
+**Tag every debug log** with a unique prefix, e.g. `[DEBUG-a4f2]`. Cleanup becomes a single grep. Untagged logs survive; tagged logs die.
+
+**Perf branch.** For performance regressions, logs are usually wrong. Establish a baseline measurement (timing harness, `performance.now()`, profiler, query plan), then bisect. Measure first, fix second.
+
+### Phase 5 — Fix + regression test
+
+Write the regression test **before the fix** — but only if a **correct seam** exists. A correct seam exercises the **real bug pattern** as it occurs at the call site. A too-shallow seam (single-caller unit test when the bug needs the multi-caller chain) gives false confidence.
+
+**If no correct seam exists, that itself is the finding.** Note it explicitly. The codebase architecture is preventing the bug from being locked down — flag for Phase 6.
+
+If a correct seam exists:
+
+1. Turn the minimised repro into a failing test at that seam
+2. Watch it fail
+3. Apply the fix
+4. Watch it pass
+5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario
+
+### Phase 6 — Cleanup + post-mortem
+
+Required before declaring done — every box:
+
+- [ ] Original repro no longer reproduces (re-run the Phase 1 loop)
+- [ ] Regression test passes (or absence of seam is documented)
+- [ ] All `[DEBUG-...]` instrumentation removed (`grep` the prefix)
+- [ ] Throwaway prototypes deleted (or moved to a clearly-marked debug location)
+- [ ] The hypothesis that turned out correct is stated in the commit / PR message — so the next debugger learns
+- [ ] **If `memory` is installed**, store the root cause + fix so the *next* diagnosis recalls it in Phase 3: `/memory:store <symptom → root cause → fix>` (optional — skip silently if the plugin is absent)
+
+**Then ask: what would have prevented this bug?** If the answer involves architectural change (no good test seam, tangled callers, hidden coupling), hand off to `/improve-codebase-architecture` with the specifics. Make the recommendation **after** the fix is in, not before — you have more information now than when you started.
+
+### Hard rules — apply across phases
+
+- ❌ Do **not** start hypothesising without a feedback loop (Phase 1 must close first)
+- ❌ Do **not** apply a fix before reproducing the bug
+- ❌ Do **not** change more than one variable per probe in Phase 4
+- ❌ Do **not** leave `[DEBUG-...]` instrumentation in the final diff
+- ❌ Do **not** declare done without re-running the Phase 1 loop against the original scenario
+- ✅ **Do** state explicitly when you're skipping a phase and why
+
+</what-to-do>
+
+<supporting-info>
+
+## Ten ways to construct a feedback loop (Phase 1)
+
+Try in roughly this order. Stop at the first one that gives you a fast, deterministic pass/fail signal.
+
+1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e
+2. **Curl / HTTP script** against a running dev server
+3. **CLI invocation** with a fixture input, diffing stdout against a known-good snapshot
+4. **Headless browser script** (Playwright / Puppeteer) — drives the UI, asserts on DOM/console/network
+5. **Replay a captured trace.** Save a real network request / payload / event log to disk; replay through the code path in isolation
+6. **Throwaway harness.** Spin up a minimal subset of the system (one service, mocked deps) that exercises the bug with a single function call
+7. **Property / fuzz loop.** If "sometimes wrong output", run 1000 random inputs and look for the failure mode
+8. **Bisection harness.** If the bug appeared between two known states (commit, dataset, version), automate `boot at state X, check, repeat` so you can `git bisect run` it
+9. **Differential loop.** Run the same input through old-version vs new-version (or two configs) and diff outputs
+10. **HITL bash script.** Last resort. If a human must click, drive *them* with `scripts/hitl-loop.template.sh` so the loop is still structured. Captured output feeds back to you
+
+Build the right feedback loop and the bug is 90% fixed.
+
+## Loop quality reminder
+
+A 30-second flaky loop is barely better than no loop. A 2-second deterministic loop is a debugging superpower.
+
+## When you genuinely cannot build a loop
+
+Stop and say so explicitly. List what you tried. Ask the user for one of:
+
+- (a) Access to whatever environment reproduces it
+- (b) A captured artifact (HAR file, log dump, core dump, screen recording with timestamps)
+- (c) Permission to add temporary production instrumentation
+
+Do **not** proceed to hypothesise without a loop.
+
+## Memory recall (optional — only if the `memory` plugin is installed)
+
+`memory` is a sibling plugin that, when present, holds root causes from past diagnoses. Recalling at the top of Phase 3 means a recurring or related bug arrives with its previously-found cause already on the table — the single biggest accelerator for "we've seen this before". **Best-effort, never a gate**: if `memory` is not installed, skip it and diagnose exactly as today.
+
+```bash
+if { [ -f .red/config.yaml ] && grep -qE '^[[:space:]]+memory:' .red/config.yaml; } || [ -f .red/memory/config.json ]; then
+  _bridge="${CLAUDE_PLUGIN_ROOT:-}/scripts/memory-bridge.sh"
+  [ -f "$_bridge" ] || _bridge="$(git rev-parse --show-toplevel 2>/dev/null)/plugins/dev/scripts/memory-bridge.sh"
+  [ -f "$_bridge" ] && source "$_bridge" \
+    && MEMORY_REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null)" \
+       memory_recall . "<2–6 keywords from the symptom / error / module>"
+fi
+```
+
+`memory_recall` prints a ranked block or nothing and **always exits 0** — a missing or erroring memory never derails the diagnosis. Each hit is a claim made at store time: verify it against the current repro before promoting it up your hypothesis ranking. An empty result means "nothing stored", not "novel bug". Close the loop in Phase 6 by storing this diagnosis's root cause so the next one recalls it.
+
+</supporting-info>