fdeops 5.0.0 → 5.1.0

package/skills/runbook/references/encode-pattern.md

@@ -0,0 +1,96 @@
+# encode-pattern - Encode the pattern
+
+**Context:** apply [task context and evidence](task-context.md) before using the named records below.
+
+**Enter when:** the engagement is closing and reusable patterns exist, a technique worked well and will apply to future clients, the FDE notices themselves doing the same thing on a second engagement, or close identified a pattern worth preserving.
+
+**Read first:** `decisions.md`, `reality.md`, `delivery.md`, `retrospectives/`, `context.md`. Patterns live in what was *done*, not what was planned.
+
+The difference between a 5-year FDE and a 15-year FDE is not talent - it's encoded patterns. The 15-year FDE walks into a new engagement and recognises the situation in minutes because they've seen it before, named it, and know the move. Pattern extraction turns experience into reusable intelligence.
+
+## Method (you do this work)
+
+**1. Identify the pattern candidates.** Scan the engagement for things that:
+
+| Signal | Example |
+|--------|---------|
+| Worked well and would work again in a similar situation | The "show the workaround first" approach to earning ops team trust |
+| Failed and the failure mode is predictable | The "refactor before understanding" mistake on legacy codebases |
+| Was discovered late and should have been discovered early | The hidden cron job that broke the migration - always ask about cron jobs |
+| Required a workaround that others would face too | The compliance dance for getting AI tools approved in regulated environments |
+| Involved a political dynamic that repeats | The passed-over internal team dynamic - present in every engagement with external FDEs |
+
+**2. Write the pattern in a transferable format.** Each pattern must be usable by a future FDE who has never heard of this engagement:
+
+```markdown
+## Pattern: <name>
+
+### Situation
+<When does this pattern apply? What does the FDE see/hear that triggers recognition?>
+
+### The move
+<What to do, specifically. Not advice - steps.>
+
+### Why it works
+<The mechanism - why this approach succeeds where the obvious approach fails.>
+
+### Watch out for
+<The failure mode or edge case that makes the pattern not apply.>
+
+### Evidence
+<Permitted source, what happened, measured result, and limits. Keep identifying evidence in its original customer record.>
+```
+
+**3. The pattern quality test.** Before encoding:
+
+| Test | Pass | Fail |
+|------|------|------|
+| **Transferable?** | Another FDE could apply this without context from this engagement | Only makes sense if you know the specific client |
+| **Specific enough?** | Contains concrete steps, not just principles | "Build trust" / "Communicate well" - too vague to act on |
+| **Repeatable?** | Applies to a class of situations, not just this one | Only worked because of a unique circumstance |
+| **Falsifiable?** | You can tell when the pattern is working or not | No way to measure whether applying it helped |
+| **Monday bag?** | You would refuse the next similar embed without this in your bag - a named move plus an artifact you can drop on day one (pipe questions, CAB dance, eval golden shape, floor-drill script) | "We learned to communicate." Patterns that only live in this client's `.fde/` do not compound |
+
+**4. Classify by stage.** Patterns sort into the same stages as the skills:
+
+| Stage | Pattern type | Example |
+|--------|-------------|---------|
+| **Land** | Political / relational | "The passed-over team warm-up protocol" |
+| **Discover** | Investigative / analytical | "The cron-job discovery checklist for legacy systems" |
+| **Plan** | Structural / strategic | "The three-option presentation for nervous sponsors" |
+| **Ship** | Technical / safety | "The Strangler Fig on financial transaction code" |
+| **Outcome** | Operational / process | "The regulated-environment change-approval timeline buffer" |
+| **Close** | Knowledge / handoff | "The 2am document format that actually gets used" |
+
+**5. Version and evolve.** Patterns are living documents:
+
+- First use: **v0.1** - hypothesis based on one engagement
+- Later uses: record context, observed results, failures, and refinements. Repetition supplies evidence; it does not automatically validate the pattern. Promote a version when a substantive revision warrants it, not at a fixed use count.
+- After modification: increment minor version with what changed and why
+- After contradiction: note the counter-example, adjust the "watch out for" section
+
+**6. Cross-engagement pattern mining.** Only when explicitly authorized for the named engagements and permitted by each customer's data policy. Keep records separate; use sanitized CLI packets or targeted recall in each authorized context, never raw file comparisons. Otherwise extract a candidate from the current permitted context only.
+
+- Compare permitted problem summaries - do the same problems recur?
+- Compare permitted decision summaries - are the same decisions being made?
+- Compare permitted lessons - are the same lessons being learned twice?
+
+A pattern learned twice is a process failure. Encoding it prevents the third time.
+
+## Artifact
+
+**`patterns.md`** - candidates and evidence for this engagement, indexed by stage and situation trigger. A shared library is a separate, authorized export: remove names, identifiers, distinctive operational details, secrets, and confidential code or data. Keep source receipts in the original record and export only permitted generalizations.
+
+**`retrospectives/YYYY-MM-DD-<engagement>.md`** - reference to which patterns were extracted from this engagement.
+
+## Checkpoint
+
+Present the extracted patterns to the FDE: "From this engagement, I've identified N patterns worth encoding. The highest-value one is <name> because <it will apply to future engagements in these situations>." Confirm the pattern is accurate - the FDE's field judgment outranks the analysis.
+
+## Principles
+
+- If you did it twice, encode it. The same lesson learned three times is a failure.
+- Patterns are steps, not principles. "Build trust" isn't a pattern; "fix a small visible bug on day one" is.
+- Every pattern needs a situation trigger - the FDE must recognise when it applies.
+- Version substantive changes. State the evidence and limits; repeated use is not automatic confirmation.
+- The pattern library is the FDE's compound interest. It's what separates 5 years of experience from 1 year repeated 5 times.

package/skills/runbook/references/runbook.md

@@ -0,0 +1,73 @@
+# runbook - Write an operating guide
+
+**Enter when:** the team needs instructions to operate, diagnose or recover a system, or an engineer is preparing to transfer responsibility.
+
+Apply [task context](task-context.md). Use supplied operational facts, relevant code and verified procedures. For a bound engagement, retrieve relevant sanitized delivery, dependency and ownership evidence; do not load the full customer record or raw private material.
+
+## Match the request
+
+- **Draft a guide:** write what is known, mark unverified procedures and missing evidence, and return the requested document. No customer record, live access, drill or closure ceremony is required.
+- **Verify an operating guide:** agree the permitted environment and checks, exercise relevant procedures, and record what happened. Do not run a destructive or production drill from a documentation request alone.
+- **Complete a handoff:** use [handoff](close.md) for the wider ownership and acceptance decision. A written guide is one part of that decision, not proof of readiness.
+
+## Build the guide from evidence
+
+Identify the system, the intended reader and the decisions that reader can make. Follow the actual operating path and include only relevant sections:
+
+```markdown
+# Operating guide - <system>
+Status: Draft / Verified for <environment and scope>
+Evidence: <code, observed run, operator statement or existing document>
+Operating owner: <confirmed role/person and source, or proposed/unconfirmed>
+
+## Normal operation
+What should happen, how often, and how to check it.
+
+## Known failure modes
+Symptom: <what the operator sees>
+Evidence: <what establishes this behavior>
+Cause: <verified cause or explicit unknown>
+Action: <supported steps, constraints and stop conditions>
+Validation: <tested environment/date/result, or unverified>
+Escalation: <confirmed role/channel, or missing>
+
+## Deploy and recover
+Procedure: <verified commands or a source link; do not invent commands>
+Permissions and prerequisites: <required access and safety conditions>
+Check: <expected observable result>
+Recovery: <tested procedure or the missing recovery evidence>
+
+## Monitor and escalate
+Signal: <existing alert or check>
+Meaning: <known interpretation>
+Response: <authorized action and when to escalate>
+
+## Open readiness gaps
+Missing evidence, owner to confirm, and proposed next check.
+```
+
+Do not pad the document with an arbitrary number of failures, contacts or commands. A stated retry problem without a known cause should remain an investigation item, not become a fabricated repair procedure. A suggested owner is not an accepted operating responsibility.
+
+For AI components, include relevant model and configuration versions, evaluation checks, failure limits and the supported way to pause actions. Do not assume retraining or autonomous operation is required.
+
+## Verify when requested
+
+Select checks based on the system's actual consequences. For example, the receiving operator may demonstrate normal operation, diagnose a known failure, or recover a failed release in a permitted test environment.
+
+Record each critical capability separately as verified, failed or untested, with evidence. A successful walkthrough cannot compensate for an untested recovery path. Avoid an averaged confidence score that hides a critical gap.
+
+If a procedure fails, correct the guide or system within scope and repeat the affected check. If verification is unavailable, deliver the draft with its limits and propose the next check; do not claim the handoff complete or indefinitely extend the engagement yourself.
+
+## Deliver and retain ownership boundaries
+
+Return the guide, its verification status and any remaining operating decisions. Save it to the requested location. In a bound engagement, propose updates to `handoff.md` and relevant current-state records under their confirmation rules.
+
+Access changes, exports of customer records, sponsor messages and closure decisions require their own authorization. A request for a runbook does not authorize these actions. Transfer only the material the recipient is entitled to receive.
+
+## Principles
+
+- Write for the person handling the actual failure.
+- Supported procedures beat plausible commands.
+- Draft, tested procedure and accepted ownership remain distinct.
+- Verify critical capabilities individually.
+- Keep private relationship notes and credentials out of an operating guide.

package/skills/runbook/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/scope/.fde-generated.json

@@ -4,6 +4,6 @@
   "files": {
     "SKILL.md": "13640b029f34068b08f2b0532ad7d2bae2d1063eeff17ec85a840bfbf832311e",
     "references/hold-scope.md": "42b3823f6b49b87b432f81208b0a61115f22340f6a922a4e858012e908c6643d",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
   }
 }

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

@@ -2,11 +2,17 @@
 
 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. 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.
+- **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/score-use-cases/.fde-generated.json

@@ -0,0 +1,10 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "d201fe1d784eea04ce25bde63fb3e6beb129ac4924b8f654b7c4fd5b3022f2d1",
+    "references/business-case.md": "32e000e8351cd59f9eaad8be40babb276df69948ea4f81e01a4672e47f48cb25",
+    "references/score-use-cases.md": "bb304cf2de26a2df0b9f2a299e3a6b2760ebce15b8b523d9cb4a584cc26038f8",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/score-use-cases/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: score-use-cases
+description: Compare competing customer use cases by value, feasibility and evidence. Use when several problems compete for delivery capacity.
+---
+
+# score-use-cases
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Compare competing customer use cases by value, feasibility and evidence. Use when several problems compete for delivery capacity.
+
+Read [the task context contract](references/task-context.md), then [the method](references/score-use-cases.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/score-use-cases/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/score-use-cases/references/score-use-cases.md

@@ -0,0 +1,70 @@
+# score-use-cases - Score use cases
+
+**Enter when:** multiple potential use cases compete for attention, the customer says "we want to do everything," a transformation engagement needs a starting point, or the FDE needs to recommend which problem to solve first.
+
+**Read first:** `reality.md`, `brief.md`, `terrain.md`, `context.md`. If `business-case.md` or `prototype-log.md` exist from poc, load those - they carry forward.
+
+The most dangerous moment in a multi-use-case engagement is when the technically interesting problem wins over the high-value problem. Scoring replaces opinion with arithmetic. The arithmetic is wrong - all models are - but it's *visibly* wrong, which means it can be debated and corrected. Opinion can't.
+
+## Method (you do this work)
+
+**1. List every candidate.** From the brief, from discovery conversations, from the FDE's own observations. Include the ones the customer hasn't said aloud but the codebase implies - a high-churn module with no tests is a candidate even if nobody named it.
+
+**2. Score on five dimensions.** Each 1-5, with the scoring rubric below. If discover already ranked candidates with (Value × Data readiness) / Complexity, reuse that order; this table extends the conversation. Do not invent dimension scores from a thin brief - write `unknown` and ask.
+
+| Dimension | 1 | 3 | 5 |
+|-----------|---|---|---|
+| **Business value** | Nice-to-have improvement | Noticeable cost or revenue impact | Existential - they lose customers or face regulatory action without it |
+| **Urgency** | Someday; no deadline | Needed this quarter; mild pressure | Burning now; every week costs real money or trust |
+| **Feasibility** | Requires new infrastructure, skills, or major refactoring | Moderate effort with known patterns | Can be built on existing systems with existing team |
+| **Data readiness** | Data doesn't exist or is deeply unclean | Data exists but needs work; volume uncertain | Available, clean, sufficient volume today |
+| **Stakeholder alignment** | No sponsor; political resistance | One sponsor but competing priorities | Active sponsor with budget and decision authority |
+
+**3. Calculate the score.**
+
+```
+Score = (Business value × Urgency × Stakeholder alignment) / (6 - Feasibility) × Data readiness
+```
+
+Why this formula:
+- **Multiplied numerator** - all three must be present. A high-value problem with no urgency or no sponsor scores low because it won't ship.
+- **Feasibility inverted** - harder problems get a higher denominator, pulling the score down. A feasibility of 5 (easy) gives denominator 1; feasibility of 1 (hard) gives denominator 5.
+- **Data readiness as multiplier** - for data-dependent use cases (ML, analytics). For pure engineering work, set to 3 (neutral) unless data quality is genuinely a factor.
+
+**4. Rank and present.** Sort by score. Present the top 3 to the FDE and the sponsor:
+
+```markdown
+| Rank | Use case | Value | Urgency | Feasibility | Data | Alignment | Score | Recommend |
+|------|----------|-------|---------|-------------|------|-----------|-------|-----------|
+| 1 | Fix payment reconciliation | 5 | 5 | 4 | 3 | 5 | 187.5 | Start here |
+| 2 | Dashboard redesign | 3 | 2 | 5 | 3 | 3 | 54.0 | Quick win if capacity |
+| 3 | ML fraud detection | 5 | 3 | 2 | 2 | 4 | 30.0 | Phase 2 after data prep |
+```
+
+**5. Defend the recommendation, not the model.** The model is a reasoning tool, not a decision. When presenting:
+
+- "The scoring puts payment reconciliation first because it's the only use case where all three conditions hold: the sponsor is active, the problem is burning, and we can build it on the existing system."
+- Never: "The model says X." Models don't decide; people decide with evidence.
+
+**6. Handle the CEO's pet project.** Sometimes the highest-scoring use case isn't the one the most powerful stakeholder wants. That's information, not a problem:
+
+- Present the scores honestly - the stakeholder sees you're being rigorous, not political.
+- If they override: log it in `decisions.md` as a deliberate choice, note the trade-off, and build what they chose. The FDE who was honest about the trade-off is protected when the override creates problems.
+
+## Artifact
+
+**`reality.md`** - the scored use-case table with the recommendation. This is the evidence the sponsor references when justifying the prioritisation upward.
+
+**`decisions.md`** - if the scored recommendation was overridden: what was chosen, by whom, the trade-off accepted.
+
+## Checkpoint
+
+Walk the FDE through the top 3 scores and the recommendation. One question: "Does the sponsor have a strong preference that overrides the scoring?" If yes, log it. If no, proceed with the highest score to poc or plan.
+
+## Principles
+
+- Score replaces opinion. Visible arithmetic beats invisible judgment.
+- All three conditions (value, urgency, alignment) must hold - or the use case won't ship.
+- The technically interesting problem that scores low gets deferred, not pursued.
+- Present the model; let the human decide. If overridden, log the trade-off.
+- A use case with no active sponsor is a research project, not an engagement deliverable.

package/skills/score-use-cases/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/ship/.fde-generated.json

@@ -10,7 +10,7 @@
     "references/qa.md": "d8f58e6d36436469a58aeb1107037f3e27fa81ff5b82d0e4df3c23eeadaf683c",
     "references/review.md": "63a007f78288089cc84cccc72647e8ce6721b7efa0f4f8d6774c0f0af594749d",
     "references/ship.md": "8cdcb2d4d6eb57e0adf3f1996bc02ae66920852ca304d2afd778fa483b7e969a",
-    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490",
     "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
   }
 }

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

@@ -2,11 +2,17 @@
 
 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. 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.
+- **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/switch-clients/.fde-generated.json

@@ -0,0 +1,9 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "f675a420f65b1542a66e713bb15f83c06310c0a8f4fa6d4a4d1b15672dea51c3",
+    "references/switch-clients.md": "4e8cb763db871b38fece3adaf9d1ac3b995c21dd1d0e463903eaa3854332c389",
+    "references/task-context.md": "73eea2d7f164fac3226599e5be26ae4e79dcf69e0d24428dd12d623861410490"
+  }
+}

package/skills/switch-clients/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: switch-clients
+description: Switch between existing customer engagements and triage competing needs. Use when context switching causes confusion; requires engagement records and preserves one client per write.
+---
+
+# switch-clients
+
+<!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
+
+## Purpose
+
+Switch between existing customer engagements and triage competing needs. Use when context switching causes confusion; requires engagement records and preserves one client per write.
+
+Read [the task context contract](references/task-context.md), then [the method](references/switch-clients.md). Load further references only when the task needs them. Everything linked is included in this skill; no other skill pack is required.
+
+## Principles
+
+- This task operates on existing engagement records. Use the local CLI and permitted sanitized packets; do not invent a portfolio or initialize records merely to complete the task. Report missing records or access as a limitation.
+- 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/switch-clients/references/switch-clients.md

@@ -0,0 +1,114 @@
+# switch-clients - Switch engagements
+
+**Enter when:** the FDE is running 2+ engagements simultaneously, context-switching is causing mistakes or delays, a new customer is being onboarded while existing engagements are active, or the FDE says "I'm losing track."
+
+**Read first:** Run `fde status --all` for the portfolio view. Then per engagement: `context.md` only - load deeper files only for the engagement being worked on.
+
+The solo FDE running three customers simultaneously is the norm, not the exception. Without a system, the third customer gets the scraps of attention left after the other two have their crises. Multi-customer ops is the discipline of giving each customer the experience of being your only customer.
+
+## Method (you do this work)
+
+**1. The hard boundary: one `.fde/` per customer, always.**
+
+```
+~/fde-engagements/
+  garvey-payments/.fde/    ← Garvey's engagement memory
+  kesterman-freight/.fde/  ← Kesterman's engagement memory
+  rennick-health/.fde/     ← Rennick's engagement memory
+```
+
+**Never:**
+- Merge two customers' data into one folder
+- Reference one customer's code/data in another's context
+- Load two customers' `.fde/` folders in the same session
+- Copy patterns between customers without stripping identifying information
+
+Cross-contamination is the fastest way to lose two engagements at once.
+
+**2. The daily triage.** Every morning, before opening any editor:
+
+```markdown
+## Daily triage - <date>
+
+| Customer | Trust signal | Top risk | Today's action | Time budget |
+|----------|-------------|----------|---------------|-------------|
+| Garvey | green | Canary blocked on their security ticket | Chase ticket, prep ship checklist | 4h |
+| Kesterman | AMBER | Sponsor went quiet Tue | Proactive conversation TODAY | 2h |
+| Rennick | green | None active | Build slice 3, push PR | 2h |
+
+Priority order: Kesterman (amber trust), Garvey (deadline), Rennick (steady)
+```
+
+**3. The triage rules.** In order of priority:
+
+| Priority | Rule | Why |
+|----------|------|-----|
+| **1** | Trust fires first | A green-trust engagement with a deadline can wait 4 hours. An amber-trust engagement cannot wait 4 hours - it's 48 hours from red. |
+| **2** | Deadlines second | Real deadlines (customer-facing, regulatory, contractual) outrank planned milestones. |
+| **3** | Highest-value delivery third | The engagement where today's work produces the most visible outcome. |
+| **4** | Steady-state last | Engagements on track with no urgent needs get allocated remaining time. |
+
+**4. Context-switch protocol.** When moving between customers:
+
+```
+BEFORE LEAVING CUSTOMER A:
+  1. Write 3 lines to context.md: where we are, what changed, next step
+  2. Commit or stash any work in progress
+  3. Close all customer A files and browser tabs
+
+BEFORE STARTING CUSTOMER B:
+  1. Run: fde resume (loads Customer B's engagement)
+  2. Read context.md - where did we leave off?
+  3. Confirm: what's the one thing to accomplish in this block?
+  4. Set a time boundary (e.g., "2 hours on Kesterman, then back to Garvey")
+```
+
+The 3-line context update is the bridge. Without it, the next session starts with "what was I doing?" - that's 20 minutes of re-discovery each time.
+
+**5. The communication cadence.** Each customer gets a rhythm:
+
+| Engagement intensity | Status cadence | Touchpoint type |
+|---------------------|---------------|-----------------|
+| Active build (daily work) | Weekly written + ad-hoc Slack | Status update + visible progress |
+| Light touch (2-3 days/week) | Weekly written | Status update + next week's plan |
+| Monitoring only | Bi-weekly written | Health check + any emerging risks |
+
+**The golden rule: no customer should have to chase you for an update.** Proactive status updates are cheaper than reactive ones - and they protect trust across all engagements.
+
+**6. Capacity management.** The honest conversation with yourself:
+
+| Situation | Action |
+|-----------|--------|
+| All engagements are steady | Allocate by value; reserve 20% for unplanned |
+| One engagement is on fire | Other engagements get a proactive heads-up: "Focus is on X this week; here's what's planned for you next week" |
+| Two engagements are on fire | Triage - one gets full attention, one gets stabilised, tell the sponsor of the stabilised one what's happening |
+| Three+ are on fire simultaneously | Escalate to your manager/team. Solo capacity is exceeded - communicate before quality drops |
+
+**7. The cross-contamination checklist.** Before every customer interaction:
+
+- [ ] Am I in the right `.fde/` folder?
+- [ ] Am I referencing the right customer's context?
+- [ ] Is the status update addressed to the right person?
+- [ ] Does my current context contain any data from another customer?
+- [ ] Are my browser tabs / code editors pointed at the right customer?
+
+One wrong customer name in a status update damages both relationships.
+
+## Artifact
+
+**`context.md`** (per customer) - the 3-line bridge updated at every context switch. The most-written file in multi-customer ops.
+
+**`fieldbook.html`** - regenerated by `fde dashboard --all` (deterministic, zero tokens) for the portfolio. Bare `fde dashboard` refreshes the bound `fieldbook-current.html`.
+
+## Checkpoint
+
+The daily triage is the checkpoint. One line per customer: signal, priority, today's action. If any customer hasn't been touched in 3+ business days: flag it - silence is noticed.
+
+## Principles
+
+- One `.fde/` per customer. Never merge. Never cross-reference.
+- Trust fires outrank deadlines. A deadline can be renegotiated; trust can't.
+- Write the 3-line context bridge at every switch. 20 seconds saves 20 minutes.
+- No customer should have to chase for an update.
+- Two fires simultaneously is a triage decision. Three is an escalation.
+- The wrong customer name in a status update is a two-customer trust fire.