kushi-agents 3.4.1

package/plugin/skills/consolidate-evidence/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: "consolidate-evidence"
+version: "2.0.0"
+description: "Merge per-contributor evidence (snapshot + stream) into Evidence/_Consolidated/ for a window. Provenance tags on every merged claim. Used by refresh-project and bootstrap-project when multiple contributors exist."
+---
+
+# Skill: consolidate-evidence
+
+Run this when multiple contributors have evidence and the user wants a single merged view per source per week. Triggers from `refresh-project` automatically when `Evidence/contributors.yml` lists >1 alias with recent evidence; or directly via `@Kushi consolidate <X> last 7 days`.
+
+## Inputs
+
+- `<project>` — project to consolidate.
+- `<window>` — date range to consolidate (default last 7 days).
+
+## Steps
+
+### Step 1 — Identify contributors with evidence in the window
+
+Read `Evidence/contributors.yml`. For each alias, check if `Evidence/<alias>/*/stream/<weeks-in-window>.md` exists.
+
+### Step 2 — For each (week × source) in the window
+
+Read all per-contributor stream files for that (week, source). Merge into:
+`Evidence/_Consolidated/<source>/<YYYY-MM-DD>_consolidated.md`
+
+Merge rules:
+- Group by event ID where possible (message ID, transcript timestamp). Same event from multiple contributors → single entry, list contributors who saw it.
+- Different events → preserve all, sorted chronologically.
+- Every claim carries a provenance tag: `[via: <alias>]` immediately after the citation.
+- If two contributors disagree on the content of the same event (e.g. different paraphrases) → include both, flag with `⚠️ Disagreement` and add a Q-row to `09_open-questions.md`.
+
+### Step 3 — Snapshot consolidation
+
+Snapshots are mostly per-source-of-truth (one canonical entity), so consolidation is rarely needed. EXCEPT for:
+- `Evidence/<alias>/teams/snapshot/chat-roster.md` — different contributors may see different chats. Union the rosters into `_Consolidated/teams/chat-roster.md` with `[via: <alias>]` per chat.
+- `Evidence/<alias>/sharepoint/snapshot/files/*.md` — different contributors may have access to different SP sites. Union, deduped by file path.
+
+### Step 4 — Update run-log
+
+Append a `consolidation_runs:` entry: `{ window, contributors, files_written }`.
+
+## Triggers
+
+- "consolidate `<X>` last `<N>` days"
+- "merge contributors for `<X>` week of `<date>`"
+- (auto) called by refresh-project when contributors.yml lists >1 alias

package/plugin/skills/fde-intake/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: "fde-intake"
+version: "1.0.0"
+description: "Author or update the FDE Intake document — the first artifact in any FDE engagement. Reads project Evidence + the FDE reference pack (intake-questions + report-doctrine + core-fde-reference) and produces a single strategic brief that answers the 6 canonical FDE Intake questions. Read-only against the project; never refreshes sources; never sends outbound."
+---
+
+# Skill: fde-intake
+
+Author (first time) or update (subsequent runs) the FDE Intake document for an FDE engagement. The intake is the **first artifact** in the engagement's `Reports/` folder and is consumed by FDE Triage to decide which team is best suited and whether the engagement is billable or non-billable.
+
+## Hard rules
+
+- **Read-only.** No `pull-*`, no Graph writes, no WorkIQ calls. Source pulls are a separate user-initiated step.
+- **Cite everything.** Every claim carries an inline `[source: <alias>/<source>/<file> · YYYY-MM-DD]` (per project Evidence) or `[source: reference-packs/fde/<file>.md · <layer>]` (per the FDE reference pack). Untraceable assertions are defects.
+- **No outbound.** Never send mail, Teams DM, RSVP comment, CRM/ADO note. If recommended next steps include reaching out, park them in the intake document only.
+- **Apply the FDE report doctrine.** Source resolution gate, recency precedence, CRM-field-vs-confirmed-fact, validation warnings protocol — all per `reference-packs/fde/report-doctrine.md`.
+- **Privacy posture.** The intake is an internal MS artifact. Do not include attendee emails — display names only.
+
+## Inputs
+
+- `<project>` — fuzzy-matched project name (same resolution algorithm as `ask-project`).
+
+## Steps
+
+### Step 1 — Resolve project root
+
+Same algorithm as `ask-project` Step 1. Echo the resolved root path before drafting.
+
+### Step 2 — Load the FDE reference pack
+
+Build the pack's virtual filesystem with the **3-layer override order** (highest wins):
+
+1. **Project override** — `<engagement-root>/<project>/.kushi-reference/fde/` (if present)
+2. **User override** — `~/.copilot/kushi-reference/fde/` (if present)
+3. **Packaged default** — relative to this skill's install location:
+   - vscode target: `<workspace>/.kushi/reference-packs/fde/`
+   - clawpilot target: `~/.copilot/m-skills/kushi/reference-packs/fde/`
+
+Required reads:
+
+- `README.md` — pack overview + file ownership.
+- `report-doctrine.md` — the 9 rules. Apply them throughout.
+- `intake-questions.md` — the 6 canonical questions, role rules, validation summary shape.
+- `core-fde-reference.md` — operating model, anti-patterns, fitness checklist, stage gates, CRM status meanings, risk categories.
+
+Cite reference-pack quotes as `[source: reference-packs/fde/<file>.md · <layer>]` where `<layer>` is `packaged` / `user-override` / `project-override`.
+
+### Step 3 — Source Resolution Gate (Rule 1)
+
+Per `report-doctrine.md § Rule 1`, attempt every applicable Evidence retrieval path and record per-source coverage. Append the result to the intake document's footer under `## Source Coverage` with one of: `retrieved` / `attempted-empty` / `attempted-failed` / `not-applicable` / `not-attempted`. An intake missing this section is a defect.
+
+For each contributor in `Evidence/contributors.yml`, attempt:
+
+1. `Evidence/<alias>/crm/snapshot/<record>.md` — for MSX Opportunity ID, MACC, ECIF, ownership.
+2. `Evidence/_Consolidated/<latest-week>.md` — for the freshest cross-source picture.
+3. `Evidence/<alias>/meetings/stream/<latest-week>.md` + earlier weeks — for customer-confirmed outcomes.
+4. `Evidence/<alias>/teams/stream/<latest-week>.md` — for asynchronous decisions.
+5. `Evidence/<alias>/sharepoint/snapshot/files/*.md` — for proposals, SOWs, decks, business cases.
+6. `Evidence/<alias>/onenote/snapshot/pages/*.md` — for durable architecture and plans.
+7. `Evidence/<alias>/email/stream/<latest-week>.md` — for sponsor / ATU correspondence.
+
+### Step 4 — Detect existing intake
+
+If `<engagement-root>/<project>/Reports/00-FDE-Intake-<project>.md` already exists:
+
+- Load it.
+- Treat user-authored prose as **canonical** unless Evidence contradicts. Preserve verbiage when re-rendering.
+- Diff each section against newest Evidence. Update changed answers; mark superseded items per Rule 2.
+- Append a `## Revision log` entry at the bottom (date + author = current alias + summary of changes).
+
+If absent → first-time author.
+
+### Step 5 — Apply intake-questions doctrine
+
+Per `intake-questions.md`, the intake answers **6 canonical questions** plus role / commercial / outcome / risk sections. Use the template `templates/fde/intake.md` as the structural skeleton. Fill every placeholder, including required validation warnings where Evidence is silent.
+
+Sections (required, in order):
+
+1. Document header (Customer + Engagement title + MSX Opportunity).
+2. **Question 1** — Who is the customer, and what business problem are they trying to solve?
+3. **Question 2** — What is being asked of FDE specifically?
+4. **Question 3** — Why is FDE the right offer (vs partner / standard MS product / advisory)?
+5. **Question 4** — When does this need to land, and is the timeline realistic?
+6. **Question 5** — How will success be measured (customer's own ROI)?
+7. **Question 6** — Who catches the outcome after FDE leaves?
+8. Microsoft stakeholder roster.
+9. Customer stakeholder roster.
+10. Commercial summary (MACC / ECIF / funding model / legal posture).
+11. Outcome hypothesis + KPIs (with baseline + target).
+12. Top risks (using the 8 reference-pack risk categories).
+13. Anti-patterns triggered (from `core-fde-reference.md`).
+14. Validation warnings summary.
+15. Source coverage.
+
+### Step 6 — Apply doctrine rules
+
+Walk every Rule from `report-doctrine.md`. For each one that fires, embed an inline `> ⚠️ VALIDATION WARNING — Rule X.Y: <description>` blockquote in the relevant section AND mirror it in the document's `## Validation warnings` summary section.
+
+Common triggers for intake:
+
+- **Rule 3.x** — CRM lists MSX Opportunity in `Draft`; surface qualifier "CRM field value — not yet customer-confirmed".
+- **Rule 4.1** — ATU rep or Industry team not yet engaged.
+- **Rule 4.2** — Funding model / MACC absent.
+- **Rule 4.3** — Outcome KPIs missing baseline or target.
+- **Rule 5.1** — Stage claim in CRM not yet supported by Evidence.
+- **Rule 6.1** — CWAA / EMA / contracting absent.
+
+### Step 7 — Freshness gate (Rule 7)
+
+If the freshest Evidence is older than `chat.freshness_warn_days` (default 14), embed at the top of the intake:
+
+> ℹ️ Freshest evidence is N days old (as of YYYY-MM-DD). Consider `@Kushi refresh <project>` before relying on this intake for high-stakes decisions.
+
+Do NOT auto-refresh.
+
+### Step 8 — Save
+
+Write to `<engagement-root>/<project>/Reports/00-FDE-Intake-<project>.md`. Create the `Reports/` folder if absent. The intake does **not** use the date-prefixed naming convention used by `fde-report` shapes — it lives in-place and is updated.
+
+Append a row to `Evidence/run-log.yml` under `fde_reports:` documenting the run (key: `intake`, value: `{ written: <date>, source_coverage: <summary>, warnings_open: <count> }`).
+
+### Step 9 — Run summary
+
+Display:
+
+- Resolved project root + freshness banner if applicable.
+- Whether this was first-time author OR update (and what changed if update).
+- Validation warnings count by rule.
+- Open Questions opened by this run.
+- Pointer to file path + suggestion: *"You can ask `@Kushi fde-triage <project>` to produce the full triage bundle, or `@Kushi fde-report <project> stage-readiness` for an advance-the-stage check."*
+
+## See also
+
+- `plugin/reference-packs/fde/intake-questions.md` — the 6 questions + role rules
+- `plugin/reference-packs/fde/report-doctrine.md` — the 9 rules every FDE report must obey
+- `plugin/reference-packs/fde/core-fde-reference.md` — operating model, fitness checklist, stage gates
+- `plugin/templates/fde/intake.md` — template skeleton
+- `plugin/skills/fde-report/SKILL.md` — sibling skill for stage-readiness / weekly / etc.
+- `plugin/skills/fde-triage/SKILL.md` — produces the full 7-file triage bundle
+
+## Triggers
+
+- "fde intake for `<project>`"
+- "kushi fde-intake `<project>`"
+- "draft the fde intake for `<project>`"
+- "update the intake for `<project>`"
+- "@Kushi fde-intake `<project>`"

package/plugin/skills/fde-report/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: "fde-report"
+version: "1.0.0"
+description: "Generate FDE-shaped engagement reports in one of five shapes (weekly / short / long / fitness / stage-readiness), grounded in the project's Evidence/ folder AND the FDE reference pack (operating model, doctrine, intake questions, anti-patterns, fitness criteria, stage gates, CRM status meanings, risk categories). Read-only; no source pulls; no outbound."
+---
+
+# Skill: fde-report
+
+Generates FDE (Forward Deployed Engineering) reports for an engagement. Five report shapes share one skill — invocation differs by trailing `<shape>` argument. The skill reads Evidence/ directly and **never** depends on State/ — it works on `standard` profile (no State/ rollup) and `full` profile equally.
+
+## Report shapes
+
+The user picks one of five (default: `weekly`):
+
+| Shape | Audience | Tone | Length | Verb |
+|---|---|---|---|---|
+| `weekly` | Internal MS leads (TPM / EM / Recon / Studio) | Direct, action-oriented | 1–2 pages | `@Kushi fde-report <project>` |
+| `short` | Customer sponsor + business owner | Outcome-oriented, sanitized | 1 page | `@Kushi fde-report <project> short` |
+| `long` | Incoming FDE crew during transition | Comprehensive context dump | 3–5 pages | `@Kushi fde-report <project> long` |
+| `fitness` | FDE leadership / triage | 10-row FDE fitness scorecard + verdict | 1 page | `@Kushi fde-report <project> fitness` |
+| `stage-readiness` | FDE leadership / triage | Stage-gate diff (advance the stage?) | 1 page | `@Kushi fde-report <project> stage-readiness` |
+
+Invocation:
+
+```text
+@Kushi fde-report <project>                       → weekly (default)
+@Kushi fde-report <project> weekly
+@Kushi fde-report <project> short
+@Kushi fde-report <project> long
+@Kushi fde-report <project> fitness
+@Kushi fde-report <project> stage-readiness
+```
+
+> Note on `fitness` vs the triage bundle: `fde-report <project> fitness` produces the same content as bundle file 01 of `fde-triage`. Use it standalone when you want only the fitness scorecard.
+>
+> Note on `stage-readiness` vs mobilization readiness: `stage-readiness` answers "should we advance to the next FDE stage?" (per stage exit criteria from `core-fde-reference.md`). The triage bundle's file 04 (`readiness-checklist.md`) answers a different question — "if we got approval today, could the crew actually start?". Different audiences, different artifacts; run both for a stage gate.
+
+## Hard rules
+
+- **Read-only.** No `pull-*`, no Graph writes, no WorkIQ calls. Source pulls are a separate user-initiated step.
+- **Cite everything.** Per `report-doctrine.md § Rule 8`. Reference-pack assertions cite `[source: reference-packs/fde/<file>.md · <layer>]`.
+- **No outbound.** Never send mail, Teams DM, RSVP comment, CRM/ADO note.
+- **Apply the FDE report doctrine.** All 9 rules from `reference-packs/fde/report-doctrine.md`.
+- **Privacy posture.** `short` is **external-facing** — apply Rule 9 (suppress MACC/ECIF, MS staffing, FDE-internal stage terms, CRM IDs, attendee emails). All other shapes are **internal** — show everything.
+- **Reads Evidence/ directly.** Does not require State/. On `full` profile, State/ is consulted for convenience but Evidence/ remains source of truth.
+- **Stage claims must be grounded.** Per Rule 5. If CRM says Stage 4 but Evidence supports Stage 3 → embed `Rule 5.1` warning AND list mismatch in Open Questions.
+
+## Inputs
+
+- `<project>` — fuzzy-matched project name (same resolution algorithm as `ask-project`).
+- `<shape>` — `weekly` (default) | `short` | `long` | `fitness` | `stage-readiness`.
+
+## Steps
+
+### Step 1 — Resolve project root
+
+Same algorithm as `ask-project` Step 1. Echo the resolved root path before generating the report.
+
+### Step 2 — Load the FDE reference pack
+
+Build the pack's virtual filesystem with the **3-layer override order** (project → user → packaged). Required reads:
+
+- `README.md` — pack overview + file ownership.
+- `report-doctrine.md` — the 9 rules. Apply throughout.
+- `core-fde-reference.md` — operating model, fitness checklist (10 rows), stage gates + exit criteria, anti-patterns, CRM status meanings, risk categories (8).
+- `intake-questions.md` — only if the shape narrates intake answers.
+
+If two files in the SAME layer disagree on a concept, surface the conflict in the report's `## Open Questions` — do not silently average.
+
+### Step 3 — Source Resolution Gate (Rule 1)
+
+Attempt every applicable Evidence retrieval path per `report-doctrine.md § Rule 1`. Record per-source coverage in the report's `## Source Coverage` footer.
+
+Cheapest → richest, stop when sufficient for the chosen shape:
+
+1. (If full profile + State/ exists) `State/00_overview.md` → `09_open-questions.md`.
+2. `Evidence/_Consolidated/<latest-week>.md` — if it exists.
+3. `Evidence/<alias>/crm/snapshot/<record>.md` — for CRM stage/status, MACC, ECIF, ownership.
+4. `Evidence/<alias>/ado/snapshot/items/` — for engagement record + work items.
+5. `Evidence/<alias>/meetings/stream/<latest-week>.md` — for customer-confirmed decisions.
+6. `Evidence/<alias>/teams/stream/<latest-week>.md` — for asynchronous decisions / asks.
+7. `Evidence/<alias>/onenote/snapshot/pages/*.md` — for durable artifacts (architecture, plans).
+8. `Evidence/<alias>/sharepoint/snapshot/files/*.md` — for proposals, SOWs, business cases.
+9. `Evidence/<alias>/email/stream/<latest-week>.md` — for sponsor / ATU correspondence.
+
+For **CRM status**, prefer the CRM snapshot file. If CRM disagrees with the freshest customer-facing source → Rule 2 (recency precedence) + Rule 3 warnings.
+
+### Step 4 — Apply the reference pack to Evidence
+
+For each section of the chosen shape, ground Evidence-derived facts against the reference-pack doctrine:
+
+- **Stage assessment** — read CRM `Status` from snapshot, look up the row in `core-fde-reference.md § CRM Triage Plan Status Meanings`, report the stage with that exact interpretation.
+- **What's pending to advance** — pull the corresponding "Minimum Checklist" + "Exit Criteria" from `core-fde-reference.md § FDE Intake Stages, Gates, and Checklists` and diff against Evidence.
+- **FDE fit** — walk the 10-row "FDE Fitness Checklist"; mark each row `Good Signal` / `Risk Signal` / `Unknown` based on Evidence. Unknowns → Open Questions.
+- **Risks** — bucket project-specific risks into the 8 reference-pack categories.
+
+### Step 5 — Apply doctrine rules
+
+Walk every Rule from `report-doctrine.md`. Embed inline `> ⚠️ VALIDATION WARNING — Rule X.Y: <description>` blockquotes wherever Evidence is silent or contradicts. Summarize all warnings in the report's `## Validation warnings` section.
+
+### Step 6 — Freshness gate (Rule 7)
+
+Read `Evidence/run-log.yml`. If any source material to this report is older than `chat.freshness_warn_days` (default 14), warn the user inline at the top of the report and offer `@Kushi refresh <project>`. Do NOT auto-refresh.
+
+### Step 7 — Render
+
+Render the chosen shape using the matching template from `plugin/templates/fde/`:
+
+| Shape | Template |
+|---|---|
+| `weekly` | `report-weekly.md` |
+| `short` | `report-short.md` |
+| `long` | `report-long.md` |
+| `fitness` | `report-fitness.md` |
+| `stage-readiness` | `report-stage-readiness.md` |
+
+Fill every `{{placeholder}}` from the template using Evidence + reference-pack content. Required sections (every shape):
+
+- Header (project + shape + generated-at + freshness banner if applicable).
+- Body sections per template.
+- `## Validation warnings` — all warnings raised by this report.
+- `## Source Coverage` — per-source retrieval result.
+
+### Step 8 — Save
+
+Save to `<engagement-root>/<project>/Reports/fde-<shape>-<YYYY-MM-DD>.md`. Create the `Reports/` folder if absent. Append a row to `Evidence/run-log.yml` under `fde_reports:` documenting the run (key: `<shape>-<YYYY-MM-DD>`, value: `{ written: <date>, source_coverage: <summary>, warnings_open: <count> }`).
+
+> On `standard` profile (no State/), this is the only opinionated output. On `full` profile, State/ provides additional grounding but the file path is identical.
+
+### Step 9 — Run summary
+
+Display:
+
+- Resolved project root + freshness banner if applicable.
+- Shape produced + output path.
+- Validation warnings count by rule.
+- Pointer: *"Try `@Kushi fde-triage <project>` for the full 7-file bundle, or `@Kushi fde-intake <project>` for the first-artifact intake document."*
+
+## See also
+
+- `plugin/reference-packs/fde/README.md` — what the FDE pack covers and how it's organized
+- `plugin/reference-packs/fde/report-doctrine.md` — the 9 rules every FDE report must obey
+- `plugin/reference-packs/fde/core-fde-reference.md` — operating model + fitness checklist + stage gates
+- `plugin/templates/fde/report-*.md` — shape templates
+- `plugin/skills/fde-intake/SKILL.md` — first-artifact intake document (precursor)
+- `plugin/skills/fde-triage/SKILL.md` — full 7-file triage bundle
+- `plugin/skills/ask-project/SKILL.md` — uses the same reference pack for FDE-shaped Q&A
+- `plugin/instructions/answer-from-evidence.instructions.md` — citation discipline
+
+## Triggers
+
+- "fde report for `<project>`"
+- "kushi fde-report `<project>` `<shape>`"
+- "weekly fde report for `<project>`"
+- "customer-facing fde report for `<project>`" → `short` shape
+- "handoff fde report for `<project>`" → `long` shape
+- "fde fitness for `<project>`"
+- "stage readiness for `<project>`"
+- "@Kushi fde-report `<project>` [`<shape>`]"

package/plugin/skills/fde-triage/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: "fde-triage"
+version: "1.0.0"
+description: "Produce the full FDE Triage bundle — 7 companion files at <project>/Reports/triage/<YYYY-MM-DD>/ covering analysis, fitness, risk, 6Q framing, mobilization readiness, executive readout, global reuse, and a central validation warnings tracker. Grounded in project Evidence + the FDE reference pack. Read-only; no outbound."
+---
+
+# Skill: fde-triage
+
+Produce the full **FDE Triage bundle** for an FDE engagement — a 7-file companion set generated as a single dated folder. The bundle is the standard handoff package between FDE Intake (authoring) and FDE leadership triage (decisioning).
+
+## Hard rules
+
+- **Read-only.** No `pull-*`, no Graph writes, no WorkIQ calls. Source pulls are a separate user-initiated step.
+- **Cite everything.** Per `report-doctrine.md § Rule 8`. Reference-pack assertions cite `[source: reference-packs/fde/<file>.md · <layer>]`.
+- **No outbound.** Never send mail, Teams DM, CRM note, ADO comment.
+- **Apply the FDE report doctrine.** All 9 rules from `reference-packs/fde/report-doctrine.md`. Validation warnings inline + mirrored in file 07.
+- **Privacy posture.** Triage bundle is **internal**. Do not suppress MS staffing, MACC, ECIF — leadership audience needs these. Do still avoid attendee emails (display names only).
+- **No silent regenerate.** If the user has hand-edited file 07 to mark warnings `resolved` / `not-applicable`, preserve those statuses on re-run (merge by Rule + description).
+
+## Inputs
+
+- `<project>` — fuzzy-matched project name (same resolution algorithm as `ask-project`).
+
+## Steps
+
+### Step 1 — Resolve project root
+
+Same algorithm as `ask-project` Step 1. Echo the resolved root path.
+
+### Step 2 — Load the FDE reference pack
+
+Build the pack's virtual filesystem with the **3-layer override order** (project → user → packaged). Required reads:
+
+- `README.md` — pack overview.
+- `report-doctrine.md` — the 9 rules.
+- `core-fde-reference.md` — fitness checklist (10 rows), stage gates, anti-patterns, CRM status meanings, risk categories (8).
+- `intake-questions.md` — only if file 00 references the 6Q framing.
+
+### Step 3 — Source Resolution Gate (Rule 1)
+
+Same as `fde-intake` Step 3. Record per-source coverage per file (every bundle file has its own `## Source Coverage` section).
+
+### Step 4 — Detect existing bundle
+
+Look for any existing folder under `<engagement-root>/<project>/Reports/triage/`:
+
+- If today's folder (`<YYYY-MM-DD>/`) exists → overwrite files 00–06 in place, MERGE file 07 (preserve open / resolved / NA statuses, refresh descriptions).
+- If a prior date exists → create a new dated folder, but read the most-recent prior file 07 to preserve user-set NA justifications for stable warnings.
+- If no prior bundle → first-time author.
+
+### Step 5 — Render the 7 bundle files
+
+Render in this order. Each file uses the matching template from `plugin/templates/fde/`:
+
+| # | File | Template | Purpose |
+|---|---|---|---|
+| 00 | `00-fde-analysis.md` | `triage-00-fde-analysis.md` | Concise FDE-oriented project analysis — bundle entry point |
+| 01 | `01-fde-fitness.md` | `report-fitness.md` (reused) | 10-row FDE fitness scorecard + overall fit verdict |
+| 02 | `02-risk-analysis.md` | `triage-02-risk-analysis.md` | Risk view bucketed into 8 FDE risk categories |
+| 03 | `03-6Q.md` | `triage-03-6Q.md` | 6-question engagement framing brief |
+| 04 | `04-readiness-checklist.md` | `triage-04-readiness-checklist.md` | Mobilization readiness — distinct from stage readiness |
+| 05 | `05-executive-consolidated-report.md` | `triage-05-executive-consolidated.md` | Leadership-friendly combined readout |
+| 06 | `06-global-opportunity-and-reuse.md` | `triage-06-global-opportunity.md` | Repeatability + reuse + commercialization lens |
+| 07 | `07-validation-warnings-checklist.md` | `triage-07-validation-warnings.md` | Central tracker of all warnings (open / resolved / NA) |
+
+**File 01 reuses the `report-fitness.md` template** verbatim (no separate `triage-01-` template) — it is the same content the standalone `fde-report <project> fitness` shape produces.
+
+**Mobilization readiness (file 04) is distinct from the `stage-readiness` report shape**:
+
+- File 04 — "If we got approval today, could the crew actually start?" (8 Hard items + 8 Soft items).
+- `fde-report <project> stage-readiness` — "Should we advance to the next FDE stage?" (per stage exit criteria from `core-fde-reference.md`).
+
+Run them both for a stage gate.
+
+### Step 6 — Apply doctrine rules
+
+Walk every Rule from `report-doctrine.md` for every bundle file. Embed inline `> ⚠️ VALIDATION WARNING — Rule X.Y` blockquotes wherever Evidence is silent or contradicts. **Mirror every warning into file 07** with status `open` (or preserve prior `resolved` / `not-applicable` on re-run).
+
+### Step 7 — Freshness gate (Rule 7)
+
+If the freshest Evidence is older than `chat.freshness_warn_days` (default 14), embed at the top of file 05 (executive readout) and file 00 (analysis entry point):
+
+> ℹ️ Freshest evidence is N days old (as of YYYY-MM-DD). Consider `@Kushi refresh <project>` before relying on this bundle for triage decisions.
+
+Do NOT auto-refresh.
+
+### Step 8 — Save
+
+Write all 7 files to `<engagement-root>/<project>/Reports/triage/<YYYY-MM-DD>/`. Create the folder if absent. Append a row to `Evidence/run-log.yml` under `fde_reports:` documenting the run (key: `triage-<YYYY-MM-DD>`, value: `{ written: <date>, files: 7, warnings_open: <count>, warnings_resolved_preserved: <count> }`).
+
+### Step 9 — Run summary
+
+Display:
+
+- Resolved project root + freshness banner if applicable.
+- Bundle folder path + file count.
+- Validation warnings count by rule + by status (open / resolved / NA).
+- Pointer: *"Next steps: review file 05 (executive readout). To advance the stage, run `@Kushi fde-report <project> stage-readiness`."*
+
+## See also
+
+- `plugin/reference-packs/fde/report-doctrine.md` — the 9 rules
+- `plugin/reference-packs/fde/core-fde-reference.md` — fitness checklist, stage gates, risk categories
+- `plugin/templates/fde/triage-*.md` — bundle templates
+- `plugin/skills/fde-intake/SKILL.md` — produces the precursor intake document
+- `plugin/skills/fde-report/SKILL.md` — sibling skill for non-bundle report shapes
+
+## Triggers
+
+- "fde triage for `<project>`"
+- "kushi fde-triage `<project>`"
+- "triage bundle for `<project>`"
+- "do the full fde triage for `<project>`"
+- "@Kushi fde-triage `<project>`"