fdeops 4.1.0 → 5.0.0

package/bin/install.js

@@ -10,6 +10,8 @@ const HOOKS_SRC = path.join(__dirname, '..', 'hooks')
 const CLAUDE_MD_SRC = path.join(__dirname, '..', 'CLAUDE.md.template')
 const FDE_TEMPLATES_SRC = path.join(__dirname, '..', 'templates', '.fde')
 const ADAPTERS_SRC = path.join(__dirname, '..', 'adapters')
+const TASK_NAMES = new Set(require('./skill-catalog').map(item => item.name))
+const RENAMED_SKILLS = new Set([...TASK_NAMES].map(name => `fde-${name}`))
 const LIB_SRC = path.join(__dirname, 'lib')
 
 const GLOBAL_SKILLS_DIR = path.join(os.homedir(), '.claude', 'skills')
@@ -115,7 +117,7 @@ function removeLegacySkills(opts = {}) {
   const skipped = []
   const links = []
   for (const dir of LEGACY_SKILL_DIRS) {
-    if (fs.existsSync(path.join(SKILLS_SRC, dir, 'SKILL.md'))) continue
+    if (RENAMED_SKILLS.has(dir) || fs.existsSync(path.join(SKILLS_SRC, dir, 'SKILL.md'))) continue
     const p = path.join(GLOBAL_SKILLS_DIR, dir)
     if (isLink(p)) { links.push(dir); continue }
     if (!fs.existsSync(path.join(p, 'SKILL.md'))) continue
@@ -129,6 +131,29 @@ function removeLegacySkills(opts = {}) {
   return { removed, skipped, links }
 }
 
+// Archive the complete previous package only after its replacement is installed.
+// Keep edits and additions outside the discovery directory, without guessing which
+// individual files are personal. Unmarked third-party installs require manual cleanup.
+function archiveRenamedSkill(name) {
+  if (!TASK_NAMES.has(name)) return
+  const oldName = `fde-${name}`
+  const old = path.join(GLOBAL_SKILLS_DIR, oldName)
+  checkPath(old)
+  if (!fs.existsSync(old)) return
+  if (!isManaged(old)) {
+    installIncomplete = true
+    console.log(`  keep   ~/.claude/skills/${oldName} (ownership unknown; move it outside skills manually after reviewing ${name})`)
+    return
+  }
+  checkTree(old, old)
+  const archiveRoot = path.join(os.homedir(), '.claude', 'fdeops', 'skill-backups')
+  mkdir(archiveRoot)
+  const archive = fs.mkdtempSync(path.join(archiveRoot, `${oldName}-`))
+  try { fs.renameSync(old, path.join(archive, oldName)) }
+  catch (error) { fs.rmdirSync(archive); throw error }
+  console.log(`  archive ~/.claude/skills/${oldName} → ${path.join(archive, oldName)} (all previous content preserved)`)
+}
+
 // Copy each skill in, but never over a directory fdeops did not create.
 function installSkillDirs(opts = {}) {
   const skipped = []
@@ -146,8 +171,10 @@ function installSkillDirs(opts = {}) {
       if (fs.existsSync(dest) && !isManaged(dest) && !opts.force) {
         // Installs predating the marker are still ours: adopt a same-named dir
         // whose SKILL.md is recognizably fdeops', so upgrades keep working.
-        if (!wasInstalledByUs(dest)) {
+        // Newly generic task names require an explicit marker, never a fingerprint.
+        if (TASK_NAMES.has(entry.name) || !wasInstalledByUs(dest)) {
           skipped.push(entry.name)
+          if (TASK_NAMES.has(entry.name)) installIncomplete = true
           continue
         }
         console.log(`  adopt  ~/.claude/skills/${entry.name} (earlier fdeops install)`)
@@ -156,6 +183,7 @@ function installSkillDirs(opts = {}) {
       // say it in human terms, place the rest, and exit non-zero at the end.
       copyDir(src, dest)
       markManaged(dest)
+      archiveRenamedSkill(entry.name)
     } catch (e) {
       failed.push({ name: entry.name, code: e.code || 'error', path: destPathFor(e.path, src, dest) })
     }

package/bin/skill-catalog.js

@@ -1,17 +1,17 @@
 // Public entry points. Methods remain authored once in skills/fde/references/.
 module.exports = [
-  ['fde-discover', 'discover', 'Trace a customer workflow and identify the problem, baseline and evidence gaps. Use for discovery or an unclear customer brief, before choosing a solution.'],
-  ['fde-scope', 'hold-scope', 'Assess a new customer request against agreed scope, trade-offs and ownership. Use when an engagement expands or a custom feature needs a commitment decision.'],
-  ['fde-options', 'three-options', 'Compare feasible approaches to a customer problem and recommend a path with costs, constraints and evidence. Use for an architecture or delivery decision, not implementation.'],
-  ['fde-poc', 'poc', 'Run a bounded customer proof of concept to test a consequential uncertainty. Use for a spike or pilot with a question and decision deadline, not a full rollout.'],
-  ['fde-build', 'build', 'Implement a scoped customer-facing software change in the existing repository and verify its behavior. Use for delivery work with an understood outcome, not incident response.'],
-  ['fde-integrate', 'integrate', 'Build or change a customer-system integration with explicit data mapping, permissions, retries and reconciliation. Use for connectors, imports, write-back and upstream APIs.'],
-  ['fde-debug', 'debug', 'Investigate and repair a reproducible failure in a customer integration or application. Use for diagnosis and regression prevention; follow incident authority for live mitigation.'],
-  ['fde-review', 'review', '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-evaluate', 'eval-pack', 'Evaluate an AI workflow against representative cases and its permitted actions. Use for model, retrieval or agent evaluation; tests do not grant release authority.'],
-  ['fde-qa', 'qa', 'Exercise the delivered customer journey using real runtime or browser evidence. Use for functional acceptance testing after implementation, including failure paths.'],
-  ['fde-ship', 'ship', 'Prepare or execute an authorized controlled release with verified checks, recovery and an operating owner. Use when a customer increment is ready for deployment.'],
-  ['fde-readout', 'readout', 'Prepare a sponsor update separating promised outcomes, measured results and customer acceptance. Use for progress readouts or defending a delivery claim.'],
-  ['fde-handoff', 'close', 'Transfer operation of a customer deployment with ownership, evidence and a tested support path. Use for handoff or an engineer rotation, not merely code delivery.'],
-  ['fde-feedback', 'encode-pattern', 'Assess a field lesson for reuse or product feedback without exposing customer context. Use for recurring deployment lessons; distinguish a hypothesis from a validated pattern.'],
+  ['discover', 'discover', 'Trace a customer workflow and identify the problem, baseline and evidence gaps. Use for discovery or an unclear customer brief, before choosing a solution.'],
+  ['scope', 'hold-scope', 'Assess a new customer request against agreed scope, trade-offs and ownership. Use when an engagement expands or a custom feature needs a commitment decision.'],
+  ['options', 'three-options', 'Compare feasible approaches to a customer problem and recommend a path with costs, constraints and evidence. Use for an architecture or delivery decision, not implementation.'],
+  ['poc', 'poc', 'Run a bounded customer proof of concept to test a consequential uncertainty. Use for a spike or pilot with a question and decision deadline, not a full rollout.'],
+  ['build', 'build', 'Implement a scoped customer-facing software change in the existing repository and verify its behavior. Use for delivery work with an understood outcome, not incident response.'],
+  ['integrate', 'integrate', 'Build or change a customer-system integration with explicit data mapping, permissions, retries and reconciliation. Use for connectors, imports, write-back and upstream APIs.'],
+  ['debug', 'debug', 'Investigate and repair a reproducible failure in a customer integration or application. Use for diagnosis and regression prevention; follow incident authority for live mitigation.'],
+  ['review', 'review', '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.'],
+  ['evaluate', 'eval-pack', 'Evaluate an AI workflow against representative cases and its permitted actions. Use for model, retrieval or agent evaluation; tests do not grant release authority.'],
+  ['qa', 'qa', 'Exercise the delivered customer journey using real runtime or browser evidence. Use for functional acceptance testing after implementation, including failure paths.'],
+  ['ship', 'ship', 'Prepare or execute an authorized controlled release with verified checks, recovery and an operating owner. Use when a customer increment is ready for deployment.'],
+  ['readout', 'readout', 'Prepare a sponsor update separating promised outcomes, measured results and customer acceptance. Use for progress readouts or defending a delivery claim.'],
+  ['handoff', 'close', 'Transfer operation of a customer deployment with ownership, evidence and a tested support path. Use for handoff or an engineer rotation, not merely code delivery.'],
+  ['feedback', 'encode-pattern', 'Assess a field lesson for reuse or product feedback without exposing customer context. Use for recurring deployment lessons; distinguish a hypothesis from a validated pattern.'],
 ].map(([name, method, description]) => ({ name, method, description }))

package/mcp/fdeops-ingest/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops-ingest-mcp",
-  "version": "4.1.0",
+  "version": "5.0.0",
   "private": true,
   "description": "Thin stdio MCP sink for FDEOps ingest (stage \u2192 propose \u2192 apply). Zero runtime dependencies.",
   "bin": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fdeops",
-  "version": "4.1.0",
+  "version": "5.0.0",
   "description": "Forward deployed engineering skills for AI coding agents. Use focused task skills or @fde for discovery, implementation, verification and handoff, with local engagement records.",
   "bin": {
     "fdeops": "bin/install.js",

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "fdeops",
-  "version": "4.1.0",
+  "version": "5.0.0",
   "description": "Forward deployed engineering skills for AI coding agents. Use focused task skills or @fde for discovery, implementation, verification and handoff, with local engagement records.",
   "author": {
     "name": "Subash Natarajan",

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

@@ -0,0 +1,16 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "19f32ecae72b96ee19cb87658ddd998cce96ec2e3960255d13fcc2906c6d0b6b",
+    "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": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
+  }
+}

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

@@ -1,9 +1,9 @@
 ---
-name: fde-build
+name: build
 description: Implement a scoped customer-facing software change in the existing repository and verify its behavior. Use for delivery work with an understood outcome, not incident response.
 ---
 
-# fde-build
+# build
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

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

@@ -0,0 +1,16 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "7862670d5c023f0195e0b3fa8b52a3b33796813e53aaad083ae82a9a469e0faa",
+    "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": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
+  }
+}

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

@@ -1,9 +1,9 @@
 ---
-name: fde-debug
+name: debug
 description: Investigate and repair a reproducible failure in a customer integration or application. Use for diagnosis and regression prevention; follow incident authority for live mitigation.
 ---
 
-# fde-debug
+# debug
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

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

@@ -0,0 +1,10 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "d97d4192064ae4236e03579a65ec7207445624aee8ad41e412fc3dbaaf465ddc",
+    "references/audit.md": "ed32ea78cbccb100742dd838e8cf4cd4b6f33ad44b3de7424fc624670d571dbc",
+    "references/discover.md": "f65aa11a539b4dbbed70cfaa94ec2a35595aa9a2d0282790510b933ac9c721ce",
+    "references/task-context.md": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780"
+  }
+}

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

@@ -1,9 +1,9 @@
 ---
-name: fde-discover
+name: discover
 description: Trace a customer workflow and identify the problem, baseline and evidence gaps. Use for discovery or an unclear customer brief, before choosing a solution.
 ---
 
-# fde-discover
+# discover
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/discover/references/discover.md

@@ -0,0 +1,112 @@
+# discover - Find the problem behind the request
+
+**Enter when:** the customer brief is unclear, the proposed solution may miss the real problem, or a change has exposed an unmapped part of the work.
+
+Apply [task context and evidence](task-context.md) first. Supplied notes are enough to begin. In an existing engagement, use permitted summaries of `context.md`, `brief.md`, `reality.md` and relevant `terrain.md` sections; extend existing findings instead of restarting.
+
+## Choose the depth the task needs
+
+- **Notes or meeting preparation:** return the current steps, observations, hypotheses and a few questions that would change the next decision. No repository scan, workshop or customer-record setup is required.
+- **A specific delivery problem:** follow the affected people, systems and data far enough to explain the break and identify what evidence is missing.
+- **A wider engagement:** map dependencies and decision owners across the involved teams. Examine each candidate problem before choosing where to invest; do not make a full enterprise inventory a prerequisite for one useful finding.
+
+State what you are investigating and which decision it informs. Reuse the user's stated goal. Ask only when a missing answer changes the next action; otherwise proceed with a clearly labelled provisional interpretation.
+
+## Frame the decision
+
+Write a short frame from the evidence available:
+
+| Part | What to establish |
+|---|---|
+| Situation | How people complete this task today |
+| Complication | The observed delay, failure, cost or constraint |
+| Question | The decision that further evidence should help someone make |
+| Possible outcomes | Confirm the brief, change its scope, investigate further or pause |
+
+Keep the question specific and neutral. “What causes requests to wait before assignment?” leaves room for different explanations. “How should we automate assignment?” assumes the solution before establishing the cause.
+
+Name the decision owner when known. An unknown owner or unmeasured baseline is a finding, not a reason to keep questioning indefinitely. Return a provisional frame and identify who or what could verify it. Do not present a new interpretation as agreed scope.
+
+## Trace the work
+
+Follow an ordinary case from arrival to completion, then relevant exceptions. Use the customer's terms for the request, system and people involved.
+
+For each step, establish:
+
+- Who performs it and where the input comes from.
+- What they do, check or decide, and which system they update.
+- Time spent working versus time spent waiting.
+- What happens when information is missing or the normal path fails.
+- Who notices the failure, how they recover, and which record they trust.
+
+Distinguish measured timings from estimates. A team lead's recollection is useful evidence about their experience; it is not a measured baseline. Do not infer that the slowest visible step causes the whole delay without following its dependencies.
+
+Use concrete questions when the supplied material leaves a gap: “Show me the last request that waited a day. What had to happen before someone could take it?” Ask about spreadsheets, manual transfers or other workarounds when there is evidence of them, without assuming they exist.
+
+When a workaround looks surprising, use the targeted history check in [audit](audit.md#before-changing-an-unfamiliar-workaround). History supplies clues, not proof that an old requirement still applies.
+
+## Inspect systems when relevant and permitted
+
+If the question depends on application behavior and code access is authorized, use `fde scan` and targeted file reads. If the CLI is unavailable, use the repository's existing search, Git and test tools. Do not load the whole repository or unrelated customer data.
+
+Follow the actual path: entry point → validation → processing → storage or downstream action. Inspect the code, configuration and tests that can explain the observed discrepancy.
+
+Check existing capability before proposing new work. A disabled feature, frequent edits or a missing nearby test is a lead to investigate, not proof of a root cause. Record the evidence behind any technical risk. When there is no repository access, state that implementation behavior remains unchecked and finish the work possible from the notes.
+
+## Check the data and dependencies the proposed work needs
+
+For each relevant source, establish where it lives, how fresh it is, who controls access, which fields the task needs, and what happens when it is unavailable. Inspect a permitted sample appropriate to the question; report its size and limitations rather than treating a small sample as representative by default.
+
+| Source or connection | Needed for | Freshness and quality evidence | Access owner | Failure or constraint | Next check |
+|---|---|---|---|---|---|
+| Fill only relevant sources | | | Unknown if unconfirmed | | |
+
+Check mappings between systems, supported APIs, permissions and retry behavior where they affect feasibility. A promised export or integration is not yet an available dependency. Record its responsible owner, verification date and required evidence when known; propose missing commitments for confirmation.
+
+For AI work, identify which steps can use deterministic logic, which need model judgment, and which require a human decision. Keep that allocation provisional until the affected owners agree. Establish who would operate the resulting change and what access or training they would need.
+
+## Use a workshop only when it resolves a real disagreement
+
+A short meeting with the relevant decision makers may help when teams describe different problems or constraints. Bring the observed cases and the decision to be made. Ask participants to state their constraints before discussing options.
+
+Summarize areas of agreement and disagreement. A vote or an absence of objections does not establish authority or acceptance. Ask the responsible owner to confirm the decision and record any unresolved objection, next action and date. Draft the summary promptly, then follow the record-confirmation rules before saving it.
+
+## Return a useful discovery result
+
+Use the smallest output that answers the user's request:
+
+1. The current task and the decision under investigation.
+2. What the evidence establishes, with its source.
+3. The working explanation and plausible alternatives.
+4. Relevant exceptions, dependencies or technical risks actually observed.
+5. Missing evidence and the next check that would change the decision.
+
+Do not fill a quota of risks, exceptions or questions. If no system was inspected, do not invent code findings. If several interpretations have failed, reassess the evidence and investigation method rather than blaming the person who wrote the brief.
+
+For a bound engagement, propose updates to the existing records after the discovery result is reviewed:
+
+- `reality.md`: preserve `Working theory`, `Evidence` and `Differs from brief how`; add the decision frame and validation status.
+- `terrain.md`: relevant steps, system behavior, data dependencies and unknowns. Preserve the `## Operating map (exception-led)` section and its columns when recording observed breaks.
+- `assumptions.md`: new or changed assumptions, verification owners and checkpoints.
+
+An operating-map row uses: `Exception / break | Who notices first | What they do today | System of record then | Blast | Evidence`. Preserve the existing schema. If no break has been observed, report that gap; do not fabricate a row to satisfy a readiness check.
+
+For standalone work, return the same findings in the conversation or requested document. No `.fde/` write or initialization is needed.
+
+## Worked example
+
+This example is fictional and uses only supplied meeting notes.
+
+The brief asks for an assistant to draft responses. The supplied notes say drafting takes about four minutes, while requests sometimes wait a day for assignment. The timings come from a team lead; no measured baseline is available.
+
+**Working theory:** assignment delay may matter more than drafting time. **Evidence:** the lead's estimates in the supplied notes, still unverified. **Differs from brief how:** the requested assistant addresses drafting, while the reported delay concerns assignment. **Question:** what causes the assignment delay, and which change would reduce it? **Next check:** trace a sample of recent requests using arrival and assignment timestamps, then ask the people handling delayed cases what prevented assignment.
+
+The discovery result does not reject the assistant or declare an ownership problem solved. It gives the FDE a focused way to find out what to build, change or investigate next. Return this as a short draft for notes-only work; in a bound engagement, propose it for `reality.md` with validation still pending.
+
+## Principles
+
+- Investigate the work before choosing a solution.
+- Keep observations, estimates and hypotheses distinct.
+- Match discovery effort to the decision at hand.
+- Unknown ownership and missing evidence remain explicit.
+- Confirmation comes from the responsible person, never from silence.

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

@@ -0,0 +1,16 @@
+{
+  "generator": "bin/generate-skills.js",
+  "version": 1,
+  "files": {
+    "SKILL.md": "6a8f9490294e1a055c25984955d011db23ebb1eb2fb4f8634584d1455331425e",
+    "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": "8ec90708522e512a50a57ab2a377a7472e93bae169c6f075a93fa603ce2ad780",
+    "references/verification.md": "d453c075b849437375338fd23782ca7fe6d427b05137a2b10fc2f724aaf7f8a9"
+  }
+}

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

@@ -1,9 +1,9 @@
 ---
-name: fde-evaluate
+name: evaluate
 description: Evaluate an AI workflow against representative cases and its permitted actions. Use for model, retrieval or agent evaluation; tests do not grant release authority.
 ---
 
-# fde-evaluate
+# evaluate
 
 <!-- Generated by bin/generate-skills.js; edit the canonical references and catalog. -->
 

package/skills/fde/SKILL.md

@@ -11,7 +11,7 @@ The **engagement record** for one client, from first meeting to signed outcome.
 
 ## Task entry
 
-Read `references/task-context.md` first. An explicitly selected `fde-*` task runs directly; do not wrap it in another coordinator or repeat entry. For a one-off task with supplied context, use the relevant method without initializing `.fde/`. For ongoing client work use the bounded entry and memory contract below. Missing record files alone are not a reason to restart discovery.
+Read `references/task-context.md` first. An explicitly selected task skill (such as `discover` or `build`) runs directly; do not wrap it in another coordinator or repeat entry. For a one-off task with supplied context, use the relevant method without initializing `.fde/`. For ongoing client work use the bounded entry and memory contract below. Missing record files alone are not a reason to restart discovery.
 
 ## When to use
 
@@ -54,7 +54,7 @@ Use `references/build.md` for implementation, `references/integrate.md` for cust
 
 ## Human surface vs agent plumbing
 
-**FDE (human):** `@fde` + English, or `/brief` `/discover` `/plan` `/ship` `/outcome` `/close` `/debrief` `/prep` `/trust` `/receipts` `/readout`. They may also invoke an individual `fde-*` skill directly.
+**FDE (human):** `@fde` + English, or `/brief` `/discover` `/plan` `/ship` `/outcome` `/close` `/debrief` `/prep` `/trust` `/receipts` `/readout`. They may also invoke an individual task skill directly.
 
 **You (agent):** run the CLI. **Never tell the FDE to type** `fde …`. If unbound, you run `fde resume --init` after one question. Never ask them to run the CLI.
 

package/skills/fde/references/close.md

@@ -4,7 +4,7 @@
 
 **Enter when:** the engagement is ending - the customer team must run this without the FDE.
 
-**Read first:** bounded `fde handoff` or `fde resume`, then targeted `fde recall` for missing evidence. Build the full picture through relevant excerpts, not a full-directory load. Consult `terrain.md` only for the code paths needed by the successor.
+**Read first:** for standalone work, use the supplied permitted operating notes, evidence and ownership; no engagement binding or CLI command is required. For a bound engagement, use bounded `fde handoff` or `fde resume`, then targeted `fde recall` for missing evidence. Never initialize records merely to draft a handoff. Build the picture through relevant excerpts, not a full-directory load. Consult `terrain.md` only for code paths needed by the successor.
 
 The engagement doesn't end at ship. It ends when the customer can maintain what was built without calling.