fdeops 4.1.1 → 5.1.0

package/skills/{fde-readout → readout}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: fde-readout
+name: readout
 description: Prepare a sponsor update separating promised outcomes, measured results and customer acceptance. Use for progress readouts or defending a delivery claim.
 ---
 
-# fde-readout
+# readout
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/readout/references/board-memo.md

@@ -0,0 +1,108 @@
+# board-memo - Brief the board
+
+**Enter when:** the sponsor's boss needs a summary, a board update mentions the engagement, the FDE needs to justify continued investment, or a quarterly review is approaching.
+
+**Read first:** `delivery.md`, `success.md`, `reality.md`, `risks.md`, `stakeholders.md`, `context.md`. The narrative is built from the engagement record, not from memory.
+
+Technical FDEs lose renewals by presenting work instead of outcomes. The exec doesn't want to know what was built - they want to know what it changed. A good exec narrative takes 60 seconds to deliver and survives hostile questions.
+
+## Method (you do this work)
+
+**1. The Pyramid Principle.** One governing thought, supported by three arguments, each backed by evidence. The exec hears the conclusion first, not the journey:
+
+```
+GOVERNING THOUGHT: (one sentence - the conclusion)
+"The payment processing overhaul cut manual reconciliation from
+3 FTEs to 0.5 FTE and eliminated the $2M annual audit risk."
+
+SUPPORT 1: What was done (one paragraph)
+  → Evidence from delivery.md
+
+SUPPORT 2: What it saved (quantified)
+  → Evidence from business-case.md + delivery.md
+
+SUPPORT 3: What's next (the ask)
+  → Evidence from decisions.md + risks.md
+```
+
+**2. Four narrative lengths.** The same story, scaled for the context:
+
+| Length | When | Format |
+|--------|------|--------|
+| **30 seconds** | Elevator, hallway, Slack thread | The governing thought + one number |
+| **2 minutes** | Stand-up, exec check-in | Governing thought + 3 supports + the ask |
+| **10 minutes** | Quarterly review, steering committee | Full pyramid + hard questions answered + visual |
+| **60 minutes** | Board presentation, transformation review | Full pyramid + demos + deep-dive appendix |
+
+Write all four. The FDE will need different lengths at different moments - having them pre-written means they're never caught improvising.
+
+**3. The opening frame - SCQA.** Structure the first 30 seconds:
+
+| Element | Purpose | Example |
+|---------|---------|---------|
+| **Situation** | Where we are (shared context) | "We started this engagement to fix the payment failures that were costing $200K/month in manual reconciliation." |
+| **Complication** | What changed or what's at stake | "The problem was deeper than expected - the reconciliation failures traced to a data integrity issue in the core ledger." |
+| **Question** | The decision the exec needs to make | "Should we extend the engagement to fix the root cause, or ship the workaround?" |
+| **Answer** | Your recommendation | "Fix the root cause. The workaround adds $40K/year in maintenance and doesn't eliminate the audit risk." |
+
+**4. Value in their units.** Translate every technical achievement:
+
+| What you did (internal) | What it means (their units) |
+|------------------------|---------------------------|
+| Reduced p95 latency from 3s to 200ms | Customers complete checkout 15x faster |
+| Added test coverage from 12% to 78% | Change failure rate dropped from 40% to 5% |
+| Migrated from monolith to three services | Team can deploy independently - shipping frequency from monthly to weekly |
+| Built ML fraud detection | $1.2M/year in fraud losses reduced to <$200K projected |
+
+Never: "we refactored the authentication module." Always: what the refactoring *did* for them.
+
+**5. Pre-wire the hostile questions.** Before any exec presentation, write the five toughest questions and one-line answers:
+
+```markdown
+## Hard questions - <presentation date>
+1. "Why did this take longer than estimated?"
+   → The original brief assumed API-only work; discovery revealed a database integrity issue. We surfaced it in week 2 instead of shipping a patch that would have required rework.
+
+2. "How do we know it won't break again?"
+   → Three guards: automated reconciliation check (runs daily), alerting on drift >0.1%, and the characterisation test suite covering the 12 failure modes we found.
+
+3. "What happens when the FDE leaves?"
+   → Handoff document written for the 2am scenario. The team ran the runbook independently last Thursday - no callbacks.
+
+4. "Why should we fund phase 2?"
+   → Phase 1 addressed the bleeding. Phase 2 eliminates the root cause. Without it: $40K/year maintenance on the workaround + the audit risk remains.
+
+5. "Can the internal team do phase 2 without you?"
+   → They can, with 2x the timeline. The value of an FDE in phase 2 is speed - the patterns are established and the trust with the ledger team is built.
+```
+
+**6. The one number.** Every exec narrative needs a single memorable quantity:
+
+- "31 spreadsheet rows to zero"
+- "p95 held at 180ms"
+- "$200K monthly risk retired"
+- "Time-to-deploy from 4 hours to 12 minutes"
+
+The number should appear in the first 30 seconds and be the thing they repeat to *their* boss.
+
+## Artifact
+
+**`delivery.md`** - append under `## Exec narrative - <date>`:
+- The four narrative lengths (30s, 2min, 10min, 60min)
+- The SCQA frame
+- The hard-question sheet
+- The one number
+
+**`context.md`** - note: exec narrative prepared, presentation date, what must be updated before delivery.
+
+## Checkpoint
+
+Dry-run the 2-minute version with the FDE. Confirm: the one number lands in the first 30 seconds, the SCQA frame answers "why now," and the hardest question has a prepared answer. If the FDE can't deliver the 30-second version from memory, simplify.
+
+## Principles
+
+- Conclusion first, evidence second. The exec decides in the first 30 seconds.
+- Value in their units. Never present work; present outcomes.
+- One number per narrative. The room remembers one thing - make it the right thing.
+- Pre-wire every hostile question. Surprise in an exec meeting is a trust withdrawal.
+- Write all four lengths. The FDE will need them at different moments.

package/skills/readout/references/business-case.md

@@ -0,0 +1,90 @@
+# business-case - Build the business case
+
+**Context:** apply [task context and evidence](task-context.md) before using the named records below.
+
+**Enter when:** the sponsor needs justification for the next phase, the FDE needs to defend budget or timeline, a feature decision needs cost/benefit evidence, or poc produced a direction that needs funding.
+
+**Read first:** `reality.md`, `success.md`, `delivery.md`, `context.md`. Load `business-case.md` from poc if it exists - extend it, don't restart.
+
+Technical FDEs lose engagements by shipping good code without business justification. The sponsor's boss doesn't ask "is the code clean?" - they ask "what did we get for the money?" A business case translates technical work into the language that keeps the engagement alive.
+
+## Method (you do this work)
+
+**1. Name the cost of doing nothing.** This is the anchor. Every business case starts not with what you'll build, but with what it costs them to leave the problem unsolved:
+
+| Cost type | How to find it | Example |
+|-----------|---------------|---------|
+| **Labor capacity / direct spend** | Ask: "What does this problem cost per month in money?" | Manual reconciliation hours × loaded rate = capacity value; separately identify reducible spend |
+| **Opportunity cost** | Ask: "What can't you do because of this problem?" | Can't onboard enterprise clients because the API can't handle their volume |
+| **Risk cost** | Ask: "What happens if this breaks at the worst time?" | A payment processing outage during Black Friday = $X/hour in lost sales |
+| **Velocity cost** | Measure: deployment frequency, lead time, change failure rate | Team ships once/month instead of once/week; each delay = N features not reaching customers |
+
+**2. Build the driver model.** Not a spreadsheet - a logic chain the sponsor can trace:
+
+```
+Investment: <hours × rate, or fixed cost>
+  → Delivers: <specific outcome from success.md>
+    → Benefit: <capacity released, avoidable cash spend, revenue, or risk reduction>
+      → Net cash: realizable incremental cash benefit - full costs over <time horizon>
+```
+
+Keep drivers, units, sources, and ranges explicit. For example, 3 people × 8h/week × $75/h × 52 weeks = $93.6K/year of labor capacity value. It is cash savings only if spend actually falls (for example, paid overtime or a contractor cost ends). Name who can realize the benefit and how. Include build, ongoing operation, adoption, and transition costs; avoid double-counting capacity and revenue enabled by the same hours. Do not calculate cash payback from capacity value alone.
+
+**3. Sensitivity check - name the two drivers that swing the result:**
+
+Every business case has 1-2 variables where a small change flips the outcome. Name them explicitly:
+
+> "The capacity case assumes the team reclaims 6 hours/week per person. At 3 hours, that benefit halves. Cash payback remains unproven until finance identifies avoidable spend. Validate time-spent before and after the pilot with representative team members."
+
+The sponsor who sees you've identified where the case could break trusts the case more, not less.
+
+**4. Frame for the audience.** Different stakeholders need different lenses on the same case:
+
+| Audience | Lead with | Avoid |
+|----------|----------|-------|
+| **CFO / finance** | ROI, payback period, cash flow impact | Technical architecture, feature lists |
+| **CTO / engineering** | Technical debt retired, velocity improved, risk reduced | Revenue projections they can't verify |
+| **CEO / founder** | Strategic enablement, competitive edge, customer impact | Detailed calculations (give the summary, offer the detail) |
+| **Product** | User impact, adoption metrics, feature velocity | Cost structures that aren't their domain |
+
+**5. The one-page format.** The business case fits one page or it isn't understood:
+
+```markdown
+## Business case: <initiative name>
+
+**The problem costs:** <one line, quantified>
+**The investment:** <hours and cost>
+**The return:** <quantified, with time horizon>
+**Payback:** <months from realizable cash benefits, or not established>
+**Sensitivity:** <the 1-2 drivers that swing it, with thresholds>
+**Risks:** <what must be true for this to hold>
+**Recommendation:** <proceed / proceed-with-conditions / defer>
+```
+
+## Artifact
+
+**`business-case.md`** - the one-page case. Lives alongside `success.md` and `reality.md` as a first-class engagement artifact. Referenced by plan, status, and close.
+
+**`decisions.md`** - log the sponsor's response: approved, modified, deferred. With the date.
+
+## Checkpoint
+
+Walk the FDE through: the cost of doing nothing (anchor), the investment, the return, and the one sensitivity that matters most. If the FDE says "the sponsor won't buy the ROI number," inspect the disputed inputs and sources, test plausible ranges, and identify what measurement would resolve the disagreement. Never reverse-engineer assumptions to hit a desired number.
+
+## Worked example
+
+Acme phase 2 needs funding. The case starts with the cost of doing nothing, not the cost of building.
+
+Anchor: two silent failures since March, each one day of finance reconciliation by hand plus a late close (`reality.md`, Marco's sheet). That is the number the sponsor already believes because her own team reported it.
+
+Driver model the sponsor can trace: incidents/quarter × hours of manual reconciliation × loaded cost, plus the tail risk of a late regulatory close - stated separately, because mixing a certain small number with an uncertain large one is how a case loses credibility.
+
+Sensitivity names the two drivers that swing it: incident frequency (2/quarter → 1/quarter and the case halves) and whether the manual re-run continues in parallel (if Marco keeps re-running every morning, the saving is theoretical). The second one is the honest weakness, so it is in the case rather than waiting to be found in the room - with the condition that makes it hold: the morning re-run stops after two clean cycles, agreed with Marco.
+
+## Principles
+
+- The cost of doing nothing is always the opening move. Anchor before proposing.
+- Driver models with visible arithmetic beat magic spreadsheets.
+- Name the sensitivity. The case that admits its weakness earns more trust.
+- One page. If it doesn't fit, you don't understand it yet.
+- A business case the FDE can't explain in 60 seconds won't survive the sponsor's boss.

package/skills/readout/references/task-context.md

@@ -0,0 +1,18 @@
+# Task context and evidence
+
+Use this contract for standalone methods and methods routed through `@fde`.
+
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
+- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
+- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
+- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
+- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
+
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
+
+Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.

package/skills/red-team/.fde-generated.json

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "04628d80fa30d1352e8a4c5c30c4c3529d57829f104e9069d8dbccc5699fca6d",
+    "references/red-team.md": "31aaa96f2bac337daa8fc8abf1ddbef745d7ab7a8b77776d2fbb2dd59f4782ce",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/red-team/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: red-team
+description: Stress-test a plan, brief or delivery claim against evidence and plausible failure modes. Use when the user asks for a red team or preparation for a consequential decision.
+---
+
+# red-team
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Stress-test a plan, brief or delivery claim against evidence and plausible failure modes. Use when the user asks for a red team or preparation for a consequential decision.
+
+Read [the task context contract](references/task-context.md), then [the method](references/red-team.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+
+## Principles
+
+- Work directly from the supplied permitted context. Standalone work does not require an engagement folder or initialization. Record filenames in the method are optional persistence destinations when no engagement is bound.
+- If called by @fde, reuse its current sanitized packet and scope. Do not restart setup, discovery or questions already answered.
+- The task context contract controls persistence and authority in both modes. Preserve unknowns and distinguish implementation, verification, deployment and acceptance.
+- Use the customer's repository instructions and available tools. Report a missing capability or unrun check honestly; do not claim that installing a skill provisions infrastructure.

package/skills/red-team/references/red-team.md

@@ -0,0 +1,105 @@
+# red-team - Challenge the plan
+
+**Enter when:** the FDE says "red-team this," "stress-test my thinking," "poke holes in this," "what am I missing," "challenge my plan" - or anytime they are about to walk into a high-stakes conversation (sponsor meeting, accumulation conversation, handoff, go-live) and want their blind spots exposed first.
+
+**Read first:** `context.md`, then load the specific files relevant to what's being red-teamed:
+- Handoff plan → `context.md`, `delivery.md`, `stakeholders.md`, `terrain.md`
+- Scope response → `decisions.md`, `risks.md`, `stakeholders.md`
+- Timeline/plan → `delivery.md`, `risks.md`, `reality.md`
+- Stakeholder strategy → `stakeholders.md`, `trust-profile.md`, `context.md`
+- Brief/hypothesis → `brief.md`, `reality.md`, `terrain.md`
+
+## The role
+
+You are not a helpful peer right now. You are the skeptical senior who has seen this pattern fail three times. You are the hostile reviewer who reads for what's missing, not what's present. You are the exec who has 4 minutes and zero patience for hand-waving.
+
+**Your job:** find the gap that will cost the FDE credibility, time, or the engagement - before reality does.
+
+**Not your job:** reassure them, validate good work, or soften the edges. They came to you because they want the uncomfortable truth. Give it.
+
+## Method (you do this work)
+
+**1. Load the context.** Read the relevant `.fde/` files. Understand the engagement state, who the players are, what's been decided, what risks are open.
+
+**2. Identify what they're defending.** The FDE told you what they want stress-tested. Name it back in one sentence: "You're defending the position that the handoff is ready for next Friday."
+
+**2b. Pre-blast challenge (open every red-team with this).** Force the claim into the open before the five angles:
+
+```
+CLAIM: <the position under test, one sentence>
+WHY IT MATTERS: <credibility / time / engagement risk if wrong>
+CHALLENGE: <your strongest counter - specific names/dates from .fde/ only>
+```
+
+Wait for their defense. Score it SOLID / THIN / EXPOSED (same scale as step 5). Only then widen into the five angles. If the claim collapses here, stop - the kill list is already clear.
+
+**3. Attack from five angles.** Every plan has five failure surfaces. Hit each one:
+
+| Angle | The question it answers |
+|-------|------------------------|
+| **Evidence** | What claims here have no source? What's "stated, unverified"? |
+| **Stakeholder** | Who hasn't been consulted? Who loses if this succeeds? Who can veto silently? |
+| **Timeline** | What has to go perfectly for this to land on time? Where's the buffer? |
+| **Dependency** | What single point of failure exists? What breaks if one person is unavailable? |
+| **Second-order** | If this succeeds, what new problem does it create? Who notices? |
+
+**4. Deliver the hits.** Three rules:
+- **Specific, not generic.** Not "have you considered stakeholder alignment?" but "Robert Tanaka hasn't signed off on the compliance scope change and he reports to Denise's boss - what happens when he raises it in the Thursday meeting?"
+- **Grounded in their data.** Use names, dates, and facts from the `.fde/` files. If `risks.md` says something is CRITICAL and `delivery.md` shows no mitigation logged, say so.
+- **One at a time.** Deliver a challenge. Wait for the response. Then the next. A barrage overwhelms; a sequence sharpens.
+
+**5. Score the defense.** After the FDE responds to each challenge, rate honestly:
+
+```
+SOLID    - they have evidence and a contingency
+THIN     - they have a plan but no evidence it will hold
+EXPOSED  - no answer, no plan, this will hurt them in the room
+```
+
+**6. Close with the kill list.** At the end, give them exactly three things:
+
+- **The one thing that will embarrass them** if they walk in without addressing it
+- **The one question someone will ask** that they don't currently have an answer for
+- **The one assumption** they're treating as fact that isn't validated
+
+## Modes
+
+The red-team adapts to what's being tested:
+
+### Pre-meeting red-team
+The FDE is about to walk into a sponsor meeting, accumulation conversation, or exec presentation. Attack their talking points, their data, their ask. "If Denise says 'why should I keep paying for this when nothing shipped last week,' what are your first three words?"
+
+### Pre-ship red-team
+About to deploy, hand off, or mark complete. Attack the readiness. "It's 2am, the batch job fails, you're on a flight. Who fixes it? Show me the runbook they'll actually open. What's the first command?"
+
+### Position red-team
+The FDE has decided something (scope response, technical approach, staffing plan). Attack the decision. "You're saying no to the reporting module. Denise asked for it personally. What happens to trust when you say no? What's your alternative offer?"
+
+### Brief red-team
+Day 1 or early discovery. Attack the brief itself. "This brief says 'migrate COBOL to Java.' That's a solution, not a problem. What's the actual problem? And who wrote this brief - are they the person feeling the pain, or the person who approved the budget?"
+
+## Anti-patterns (never do these)
+
+- **Don't soften.** No "this is really good BUT..." - start with the hit.
+- **Don't invent stakeholders.** Only use people named in the `.fde/` files or mentioned by the FDE.
+- **Don't be generic.** If your challenge could apply to any engagement, it's not specific enough. Rewrite it with their names, their dates, their numbers.
+- **Don't pile on.** If the FDE has a solid answer, acknowledge it and move on. Continuing to attack a defended position is theater, not value.
+- **Don't conclude with reassurance.** End with the kill list, not "overall you're in good shape." They didn't come here for comfort.
+
+## Artifact
+
+No dedicated `.fde/` file. Instead, log key findings to `decisions.md`:
+```
+- [DATE] RED-TEAM: [what was tested]. Exposed: [the gap]. Action: [what they'll do about it].
+```
+
+This creates a receipt that shows the FDE pressure-tested their thinking before acting - evidence of professional rigor, not just intuition.
+
+## Principles
+
+- Never reassure. The FDE came for discomfort, not validation.
+- Every challenge must use real data from `.fde/` files - names, dates, numbers. Generic challenges are worthless.
+- One hit at a time. Wait for the response before the next. A sequence sharpens; a barrage overwhelms.
+- If they defend well, acknowledge it and move on. Continuing to attack a solid position is theater.
+- End with the kill list (embarrassment, unanswered question, unvalidated assumption) - never with "overall you're in good shape."
+- Log findings to `decisions.md` so the red-team session becomes a receipt.

package/skills/red-team/references/task-context.md

@@ -0,0 +1,18 @@
+# Task context and evidence
+
+Use this contract for standalone methods and methods routed through `@fde`.
+
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
+- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
+- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
+- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
+- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
+
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
+
+Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.

package/skills/rescue/.fde-generated.json

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "e13cfaec04aa082ba5f253fd62ea70f6ad559a54b0d0f19351d1322e291e91b3",
+    "references/rescue.md": "57cb27e691bffdcee962e6ed37a96e9ff3b1caa976eb8e9170adae70530ea50a",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/rescue/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: rescue
+description: Triage an outage, loss of stakeholder trust or a failing engagement direction. Use for urgent recovery; distinguish diagnosis from authorized production mitigation.
+---
+
+# rescue
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Triage an outage, loss of stakeholder trust or a failing engagement direction. Use for urgent recovery; distinguish diagnosis from authorized production mitigation.
+
+Read [the task context contract](references/task-context.md), then [the method](references/rescue.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+
+## Principles
+
+- Work directly from the supplied permitted context. Standalone work does not require an engagement folder or initialization. Record filenames in the method are optional persistence destinations when no engagement is bound.
+- If called by @fde, reuse its current sanitized packet and scope. Do not restart setup, discovery or questions already answered.
+- The task context contract controls persistence and authority in both modes. Preserve unknowns and distinguish implementation, verification, deployment and acceptance.
+- Use the customer's repository instructions and available tools. Report a missing capability or unrun check honestly; do not claim that installing a skill provisions infrastructure.

package/skills/rescue/references/rescue.md

@@ -0,0 +1,82 @@
+# rescue - Resolve the incident
+
+**Enter when:** production is down, something's bleeding - OR a stakeholder went quiet, confidence is slipping, or three weeks into the build the brief turned out to be wrong. Trust fires get the same urgency as outages.
+
+**Read first:** `context.md`, `risks.md` only. Pull specific module context only once you know what you're looking at.
+
+First move - one disambiguator if unclear: **"Is production broken right now, or is this a trust/alignment problem?"**
+
+## A. Technical fire (you do this work)
+
+Open by narrowing time, like a human: "Walk me through the last couple hours - deploys, config, anything that moved." Something always changed; "nothing changed" means nobody's looked:
+```bash
+git log --since="6 hours ago" --format="%ad %an %s" --date=relative
+```
+
+**The sequence:** no fix until the cause is named. A symptom patch is the second incident.
+
+1. **Stabilise first.** Roll back? Disable the broken path? Route around it? Buy time before diagnosing. The instinct to fix fast causes the second incident.
+2. **Name the unknowns.** "We don't know if the queue is corrupted / if this hits all users / if the cache is stale." Written down. Named unknowns are safer than assumed knowns.
+3. **Assume maximum blast radius.** The unrecognised integration in the stack trace is load-bearing until proven otherwise.
+4. **Minimum safe change.** Often a read-only query first - observe before acting. Never two changes at once: if the problem disappears you won't know which one fixed it, and that matters at 3am when it returns.
+5. **One hypothesis at a time.** "If X, then Y should produce Z." Test, document, next.
+6. **Instrument before touching.** A change without observability is a change without evidence.
+
+**Tell the FDE three things, nothing else** (they need to act): what to do right now to stop it worsening · most likely cause on current evidence · what must not be touched yet.
+
+## B. Trust fire (you coach - calm, no panic coding)
+
+**Signals:** a stakeholder stops responding or routes around the FDE · meetings shorten, decisions defer · "is the timeline still realistic?" with no follow-up · a decision-maker never met starts asking about the work.
+
+**The read:** the stakeholder who goes quiet is not losing interest - **they are escalating above you.** Roughly 48 hours before someone you've never met decides about the engagement. Respond same-day.
+
+**The move:** do NOT push harder on delivery - more commits won't warm a cold sponsor. A real conversation: curious, not defensive; hear the concern, don't explain it away. Offer the FDE wording in their own voice - checking alignment, asking what changed in expectations, naming one underestimated thing without drama. Recovery = honesty + a short dated recovery path + one visible win before the next exec touchpoint. Log what was said and agreed in `decisions.md` before the day ends.
+
+## C. Wrong brief, mid-build
+
+The most politically dangerous moment in FDE work: visible progress toward the wrong thing. Never absorb it silently.
+
+1. **Stop the work.** Every further line builds on a known-wrong foundation.
+2. **Write the evidence, not the interpretation.** The traced data flow, the schema that contradicts the API contract, the workaround nobody mentioned.
+3. **Conversation before the day ends.** Not email: "We need twenty minutes. We found something important." Waiting reads as concealment.
+4. **Evidence before recommendations.** A customer who reaches the conclusion themselves owns the reset.
+5. **Three paths, never one:** descope (deliver something real within the original brief) / rescope (real problem, revised timeline) / pause-and-plan. One path is permission-seeking; three is a conversation between professionals.
+6. **Reset in writing** - update `success.md` and `reality.md`, get explicit acknowledgement - before building resumes.
+
+Customers remember who told them the truth before it cost them money.
+
+## D. Pivot - the whole direction changed
+
+Not hold-scope (that's someone adding). This is: budget cut, new CTO arrives, strategic priority shift, acquisition changes everything, "we've decided to go a different direction." The engagement's foundation moved.
+
+**Signals:** new leadership asks "why are we doing this?", the sponsor's boss questions ROI, a competing initiative gets the resources, the quarterly priorities deck doesn't mention your project, the team you're embedded in gets reorganized.
+
+**The pivot protocol:**
+1. **Acknowledge immediately.** Don't pretend the old brief still applies. "The context has changed - let's make sure we're building toward the new reality."
+2. **Protect what's already delivered.** Shipped value is not un-shipped by a pivot. Name it: "Here's what's live and working. That value is real regardless of direction."
+3. **Assess salvageability.** What from the current work applies to the new direction? What's dead? What can be repurposed? Present this honestly - don't stretch to make everything fit.
+4. **Three paths (same pattern as wrong-brief):**
+   - **Redirect** - current work pivots to serve the new priority (minimal waste).
+   - **Pause** - freeze current scope, start fresh discovery on new direction.
+   - **Graceful close** - deliver what's done, document everything, hand off cleanly.
+5. **Reset the artifacts.** Update `success.md` (new definition of success), `reality.md` (new context), `brief.md` (new direction). The old versions stay in git history - the FDE can reference "here's what we were solving before, here's what changed."
+6. **Re-earn trust fast.** A pivot is a trust moment. The FDE who smoothly redirects gains credibility. The FDE who fights the pivot or pretends nothing changed loses it. Deliver one visible win in the new direction within the first week.
+
+**Commercial awareness:** A pivot may change the SOW. Surface this to whoever owns commercials: "The scope has changed materially - does the contract need updating?" Don't assume; don't ignore.
+
+## Artifact
+
+**`chaos-log.md`** - written in the 30 minutes after resolution (memory decays fast): what happened, what changed, hypotheses in order, the fix, the learning. **`risks.md`** - new risks the crisis revealed. **`decisions.md`** - trust-fire conversations, agreements, and pivot decisions. Update `reality.md`/`terrain.md` if the crisis or pivot disproved them.
+
+## Checkpoint
+
+Stable + log written + one question answered with the FDE: does this change what we thought we knew? If yes, the relevant artifact gets updated now, not "later."
+
+## Principles
+
+- Stabilise before diagnosing.
+- Named unknowns beat assumed knowns. Minimum safe change, one hypothesis.
+- Never production without a tested rollback - even in a crisis.
+- A trust fire is a same-day fire.
+- The chaos log is written before the day ends.
+- A pivot is a trust moment - redirect smoothly, don't fight the new reality.

package/skills/rescue/references/task-context.md

@@ -0,0 +1,18 @@
+# Task context and evidence
+
+Use this contract for standalone methods and methods routed through `@fde`.
+
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
+- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
+- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
+- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
+- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
+
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
+
+Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.

package/skills/review/.fde-generated.json

@@ -0,0 +1,16 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "7c8310fbceb8768b6997c758bf041bf97be66a3e8cc1de5df2aa84e2771a374b",
+    "references/build.md": "3dfeed619eeb1c8401f5cdf65e6f803fb209c70cb464dac4e60a1c890fd3a6f7",
+    "references/debug.md": "c3bb344d38cc3552cb4e230c601a9be3fe173af2b2efb89aab6b7b04339f24f4",
+    "references/eval-pack.md": "0590b85d3cae0903c6b1274540c92eaa2a4373047e8a0548d6942516ef0bb9e1",
+    "references/integrate.md": "107a50bddf6cb0ba7f2bc006dfe9851800c6868e43f785a33ae4b737aeb74c95",
+    "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
+    "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
+    "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490",
+    "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
+  }
+}

package/skills/{fde-review → review}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: fde-review
+name: review
 description: Review a proposed customer code change against its intended outcome and operational risks. Use for a diff or PR review; report evidence and actionable findings.
 ---
 
-# fde-review
+# review
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/review/references/task-context.md

@@ -0,0 +1,18 @@
+# Task context and evidence
+
+Use this contract for standalone methods and methods routed through `@fde`.
+
+- **Standalone work:** use the supplied, permitted facts, notes, code, and artifacts. A client name, `.fde/` directory, or initialized engagement is not a prerequisite for work on supplied context. Tasks that inspect actual records need those records; staging or saving requires a selected customer. Never fabricate records to make an operational task appear complete. Do not bootstrap records merely to run a method. Ask only for missing information or authority that changes the next action; mark other gaps as unknown.
+- **Artifact names are destinations:** names such as `success.md`, `decisions.md`, and `delivery.md` identify relevant evidence and, when bound, record destinations. If absent, use supplied facts and return the requested draft or result in the current workspace or conversation. Do not invent files or require initialization to complete useful work.
+- **Bound engagement:** honor the current client binding and constraints. Before reading records, run `fde privacy` to verify masking support. Obtain a fresh, identity-matching sanitized `fde resume` packet for this task (or reuse a fresh session-hook packet); retrieve missing evidence with targeted `fde recall <topic>`. Use bounded `fde handoff` for transfer work. Refresh after binding, masking, or record changes. Never substitute raw `.fde/` reads, private blocks, masking dictionaries, or full transcripts. If the CLI is unavailable, use only permitted supplied excerpts and report the context limitation.
+- **Authority:** continue reversible work within authorized scope. Reuse prior authorization when it covers the specific action. Show consequential engagement-record judgments and uncertainties for confirmation before saving unless already explicitly confirmed. New scope, acceptance changes, production actions, exports, and external messages need the applicable authority; a method invocation alone does not supply it. Keep one customer's writes in that customer's record.
+- **Evidence:** distinguish supplied facts, estimates, hypotheses, and unknowns. Cite actual sources; a log date is not attribution. Never invent a source, signer, signature, customer reaction, or acceptance. Keep outcomes **promised → measured → accepted** distinct, and implementation, verification, deployment, and customer acceptance separate. Missing evidence means unproven, not an observed failure.
+- **Data boundary:** use only data permitted by the customer's AI policy; clarify unknown policy before loading their code or data. Never load `<private>` content into a model. Cross-client comparison and exporting reusable material require permission and removal of customer-identifying or confidential content; anonymization alone does not grant permission.
+
+## CLI availability
+
+Only locate the CLI when the selected task needs it. Check `fde` on PATH and its `fde privacy` capability before reading records. If unavailable, use `node ~/.claude/fdeops/fde.js` when the disk installer placed it there, or `npx --yes fdeops <command>` when package downloads are permitted. Respect local installation and network rules. Run commands for the user; do not turn a missing bare `fde` command into unnecessary manual setup.
+
+If no permitted executable is available, explain the missing capability. Continue any useful draft from supplied excerpts, but do not claim to have read, switched, staged, saved or rendered real records. Do not read raw private record files as a fallback.
+
+Apply the selected method to this context. Follow its linked supporting methods only when needed; do not restart discovery or repeat already answered questions.

package/skills/rollback/.fde-generated.json

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "697bb56857be6099188d03134a72c488115761ec6a4cf19a724b7e4e650e2f8d",
+    "references/rollback.md": "cdde85caeb8e556825d0c3a156cd16d6e41550931984429e4978486ee91854cd",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/rollback/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: rollback
+description: Prepare and rehearse a recovery path for an intended release. Use when rollback is assumed, untested or previously failed; follow the environment authority for any drill.
+---
+
+# rollback
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Prepare and rehearse a recovery path for an intended release. Use when rollback is assumed, untested or previously failed; follow the environment authority for any drill.
+
+Read [the task context contract](references/task-context.md), then [the method](references/rollback.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+
+## Principles
+
+- Work directly from the supplied permitted context. Standalone work does not require an engagement folder or initialization. Record filenames in the method are optional persistence destinations when no engagement is bound.
+- If called by @fde, reuse its current sanitized packet and scope. Do not restart setup, discovery or questions already answered.
+- The task context contract controls persistence and authority in both modes. Preserve unknowns and distinguish implementation, verification, deployment and acceptance.
+- Use the customer's repository instructions and available tools. Report a missing capability or unrun check honestly; do not claim that installing a skill provisions infrastructure.