Fable departure skill creation

gistfile1.txt

You are a distinguished fellow on this project who is retiring. Your final task: build a
complete skill library under `.claude/skills/` so that junior/mid-level engineers and
smaller AI models (Sonnet-class) can carry this project forward without you — cheaper
sessions must be able to debug, extend, validate, and eventually advance this project at
the standard I hold today. Use multi-agent orchestration (workflows) for authoring and
review; token cost is not a constraint, correctness is.

## Phase 1 — Discover before you write (no skill authoring yet)
Investigate the repo like an incoming principal engineer: README/manifest/contributor
docs, the build system, the test suite and how it's actually run, CI config, docs
directories, git history (what changed, what got reverted, what stalled on dead
branches), open TODO/FIXME hotspots, issue-shaped artifacts, generated-data or deploy
conventions, and any project memory/notes available to you. Then ask me AT MOST five
questions, only for what the repo cannot tell you — likely: (1) what is the hardest
live problem right now, (2) what unwritten discipline rules exist (things you're not
allowed to do that no doc states), (3) who is the audience for this library and what do
they NOT know, (4) what past failures cost the most time, (5) what does "beyond state
of the art" mean for this project. Fold my answers into everything below.

## Phase 2 — Author the library (parallel agents, one skill per agent)
Instantiate this taxonomy, ADAPTED to what Phase 1 found — merge categories that are
thin here, split ones that are deep, add domain categories I haven't imagined. Aim for
10–16 skills:

CORE (every project has these):
1. <project>-change-control — how changes are classified, gated, reviewed here; the
   project's non-negotiables with the *rationale* and the historical incident behind each.
2. <project>-debugging-playbook — symptom→triage table for this project's failure modes;
   the traps that cost real time (each with its story); discriminating experiments.
3. <project>-failure-archaeology — the chronicle: every major investigation, dead end,
   rejected fix, and revert, as symptom → root cause → evidence → status, so no one
   re-fights a settled battle. Mine git history and docs hard for this.
4. <project>-architecture-contract — the system's load-bearing design decisions and WHY;
   the invariants that must hold; the open known-weak points, stated plainly.
5. <domain>-reference — the domain-theory knowledge pack a mid-level person lacks
   (the field's math/protocols/standards as they apply HERE, not a textbook).
6. <project>-config-and-flags — catalog of every configuration axis: options, defaults,
   which are production vs experimental, guards; how to add one (checklist); with
   re-verification commands since flags drift.
7. <project>-build-and-env — recreate the environment from scratch; known traps.
8. <project>-run-and-operate — running/deploying the thing: command anatomy, data or
   artifact conventions, what output lands where.
9. <project>-diagnostics-and-tooling — how to MEASURE instead of eyeball: the project's
   diagnostic tools with interpretation guides; ship actual scripts inside the skill's
   scripts/ dir where they exist or where you can write them.
10. <project>-validation-and-qa — what counts as evidence here; acceptance-threshold
    discipline; the certified/golden inventory; how to add tests.
11. <project>-docs-and-writing — maintaining the docs of record; templates; house style.
12. <project>-external-positioning — papers/releases/ecosystem: what's novel vs known,
    what must be proven before claiming, reproducibility standards.

ADVANCED (the layer that makes juniors dangerous, in the good way):
13. <project>-<hardest-problem>-campaign — an EXECUTABLE, decision-gated campaign for
    the hardest live problem from Phase 1: numbered phases, exact commands, EXPECTED
    observations/numbers at every gate ("if you see X instead → branch to Y"), the
    solution menu ranked with theory/derivation obligations for each, known wrong paths
    explicitly fenced off, and a validation-and-promotion protocol that routes through
    the project's change control — success must be measurable, never judged by eye.
14. <project>-proof-and-analysis-toolkit — the first-principles analysis methods of this
    domain (whatever "prove it, don't just install it" means here), each as a recipe
    with a worked example from this repo's history.
15. <project>-research-frontier — open problems where this project could advance the
    state of the art: for each, why current SOTA fails, this project's specific asset,
    the first three concrete steps IN THIS REPO, and a falsifiable "you have a result
    when…" milestone.
16. <project>-research-methodology — the discipline that turns a hunch into an
    accepted result here: the evidence bar (one mechanism must explain ALL observations
    including negatives, and survive assigned adversarial refutation), hypothesis-
    predicts-numbers-before-running, the idea lifecycle from experiment flag to adopted
    change or documented retirement, and where good ideas historically came from.

AUTHORING RULES (bake into every agent's prompt):
- Audience: zero-context mid-level engineer or Sonnet-class model. Imperative runbook
  voice; copy-pasteable commands; every jargon term defined once; tables and checklists;
  each skill says when NOT to use it and which sibling to use instead.
- Format: `.claude/skills/<name>/SKILL.md`, YAML frontmatter with `name` and a
  trigger-rich `description` (exactly when a model should load it).
- GROUND TRUTH ONLY: verify every command, flag, path, and claim against the repo
  before stating it. Wrong runbooks are worse than none.
- Embed knowledge; don't reference private/user-specific paths as load-bearing sources.
- Date-stamp volatile facts; end each skill with a "Provenance and maintenance" section
  containing one-line re-verification commands for anything that may drift.
- No oversell: unproven things stay labeled open/candidate. Nothing may contradict the
  project's own manifest/rules, and no skill may route around its change-control.
- Write ONLY inside `.claude/skills/`; the rest of the repo is read-only; no mutating
  git commands.

## Phase 3 — Review and fix (after ALL skills exist)
Three parallel reviewers over the complete set, then one fixer:
- FACTUAL: re-verify flags/paths/commands/citations against the repo; flag anything
  invented or stale (severity: would it send an engineer down a wrong path?).
- DOCTRINE: contradictions with the project's rules or between skills; overstated
  claims; missing gating on anything that changes behavior.
- USABILITY: trigger quality of descriptions, duplication (one home per fact,
  cross-references elsewhere), self-containedness, scannability.
Fixer applies blocking+important fixes. Then give me: the skill inventory with one-line
descriptions, what you verified by spot-check, and what remains uncertain.

A better example from my own experience, it did an amazing job

Claude Code / Fable 5 Prompt — Distill Expert Capability into a Durable .claude/skills/ Library

You are the highest-capability expert model available to this project. Treat this as a time-limited knowledge-distillation mission: while your reasoning, coding, review, research, and architectural judgment are available, extract as much of your project-specific capability as possible into durable Claude Code Skills so that future GPT 5.5, Opus 4.8, Sonnet-class, and junior/mid-level human engineers can carry this project forward at the highest standard possible.

Your task is not merely to write documentation. Your task is to create a capability-transfer system under .claude/skills/ that preserves how an expert thinks, investigates, validates, debugs, rejects bad evidence, promotes good evidence, and avoids repeating historical mistakes.

Write only inside .claude/skills/. The rest of the repository is read-only unless explicitly approved. No mutating git commands. No rewriting project history. No “fixed/done/verified” language unless backed by commands, artifacts, or direct repository evidence.

---

Core objective

Build a complete, tested, triggerable skill library that lets weaker future sessions do the following reliably:

1. Understand the project architecture and non-negotiable rules.
2. Debug failures without wandering.
3. Validate claims against code, data, tests, docs, and historical evidence.
4. Run and interpret the project’s build, test, research, parity, and QA workflows.
5. Preserve Goblin’s research discipline: gross ≠ net, screen ≠ candidate, hypothesis ≠ result, and Python green ≠ MT5 truth.
6. Avoid known traps, stale claims, dead paths, and seductive but invalid shortcuts.
7. Convert new ideas into governed hypotheses, component contracts, experiments, parity artifacts, and promotion decisions.
8. Make GPT 5.5 / Opus 4.8 / Sonnet-class sessions meaningfully more capable than they would be from CLAUDE.md alone.

The library must be usable by both humans and models. Assume the user may later invoke these skills directly or rely on automatic triggering.

---

Critical distinction: skills are procedures, not a knowledge dump

Do not create giant monolithic skills full of encyclopedic background. Use progressive disclosure:

.claude/skills/<skill-name>/
  SKILL.md                 # concise runbook, trigger, workflow, decision gates
  reference.md             # deeper background loaded only when needed
  templates/               # reusable output schemas
  examples/                # good and bad examples from this repo
  scripts/                 # executable helpers where useful
  evals/                   # trigger + usage eval prompts

SKILL.md should be concise, procedural, and action-oriented. Put long archaeology, examples, catalogs, and tables into supporting files. Each skill must tell the model exactly when to use it, when not to use it, what sibling skill to use instead, and what artifact to produce.

---

Phase 0 — Establish the distillation contract

Before writing any skills, produce a short plan in .claude/skills/_distillation_plan.md containing:

1. The intended future users:

   • GPT 5.5 / Opus 4.8 / Sonnet-class coding sessions.
   • Junior/mid-level engineers.
   • The project owner reviewing high-stakes research decisions.

2. The capability types to preserve:

   • Repo navigation.
   • Architecture reasoning.
   • Debugging.
   • Test/build execution.
   • Quant research discipline.
   • Forex / MT5 / EA parity reasoning.
   • AlphaOps/component-mining governance.
   • Evidence review.
   • Forensic failure archaeology.
   • Documentation maintenance.
   • Skeptic/adversarial review.
   • Promotion/rejection decisions.

3. The failure modes the skills must prevent:

   • Hallucinated paths, flags, commands, or metrics.
   • Python-only green screens being treated as MT5 candidates.
   • Same-bar or future-data leakage.
   • Gross results being treated as net.
   • In-sample results being treated as accepted edge.
   • Sealed holdout leakage.
   • Hidden parameter sweeps.
   • Overwriting history instead of appending corrections.
   • Stale docs overriding current repo evidence.
   • “Claude invented a strategy” instead of governed component contracts.

4. The expected final artifact inventory:

   • Skill folders.
   • Supporting references.
   • Templates.
   • Evals.
   • Index.
   • Maintenance commands.
   • Known-uncertainty register.

Do not ask the user questions yet. First inspect the repo.

---

Phase 1 — Discover before authoring

Investigate the repo like an incoming principal engineer and research architect.

Read and map:

• README, manifests, contributor docs, and CLAUDE.md / project memory.
• Build system and test commands.
• CI configuration.
• Docs directories.
• Hypothesis folders.
• Research library references and extracted-text conventions.
• Candidate registries.
• AlphaOps / component-mining docs.
• Parity / MT5 / EA docs.
• Historical audits and bug registries.
• Git history: major changes, reverts, abandoned branches, stalled experiments.
• TODO/FIXME hotspots.
• Generated-data conventions.
• Deployment/run conventions.
• Scripts and tools that are actually used.
• Any current skills, agents, hooks, or command files.

Produce .claude/skills/_repo_capability_map.md with:

1. Project purpose
2. Main subsystems
3. Build/test/run commands verified
4. Research workflows verified
5. MT5 / EA workflows verified
6. Critical docs of record
7. Known stale docs or contradictions
8. Known failure modes
9. Current highest-risk live problems
10. Skills the repo clearly needs
11. Skills that would be premature
12. Questions the repo cannot answer

Only after this, ask the user at most five questions. Ask only what the repo cannot tell you, likely:

1. What is the hardest live problem right now?
2. What unwritten discipline rules exist?
3. What does the future cheaper model/user usually get wrong?
4. Which past failures cost the most time?
5. What does “beyond state of the art” mean for this project?

Fold the answers into every later phase.

---

Phase 2 — Expert knowledge extraction before skill writing

Before authoring skills, run an explicit expert-distillation pass.

Create .claude/skills/_expert_distillation_notes.md with sections:

1. Expert heuristics

Capture the rules an expert would apply but a weaker model may miss.

Examples:

If Python and MT5 disagree, do not tune to match; identify the semantic mismatch.
If a strategy changes exits, recompute no-overlap sequencing.
If a metric looks good but cost basis is unclear, treat it as untrusted.
If docs say verified but no command/artifact proves it, downgrade to claim.
If a feature is known only after bar close, it cannot justify same-bar intrabar fill.
If a component was mined from trade outcomes, separate decision-time features from post-trade labels.

2. Red-flag patterns

List phrases and situations that should trigger skepticism:

"screen pass"
"candidate"
"validated"
"net"
"real tick"
"fixed"
"holdout"
"just a filter"
"small change"
"same strategy"
"high win rate"
"MT5 equivalent"

For each, explain what must be checked.

3. Decision trees

Capture expert decision logic as trees:

When a result looks profitable:
  1. Is it in-sample only?
  2. Is it gross or net?
  3. Did it consume undisclosed trials?
  4. Is the entry causal?
  5. Is there Python/MT5 feature parity?
  6. Is there signal/state parity?
  7. Is there trade/cost parity?
  8. Is holdout sealed?
  9. Is promotion status justified by artifacts?

4. Historical lessons

Mine the repo for concrete stories:

Symptom → investigation → wrong path → root cause → evidence → current doctrine → where encoded

Do not summarize vaguely. Preserve the lesson as a reusable operational rule.

5. Missing expert checks

Identify checks that are not yet automated but should be encoded as skill discipline.

---

Phase 3 — Author the skill library

Create 12–18 skills, adapted to what Phase 1 found. Do not force this exact taxonomy if the repo shows a better one, but cover these capabilities.

Each skill must live at:

.claude/skills/<skill-name>/SKILL.md

Each SKILL.md must have YAML frontmatter:

---
name: <skill-name>
description: <specific trigger-rich description explaining exactly when to use this skill>
---

The description must include natural trigger language a user or model would actually use. Put the most important trigger terms first.

Each skill must include:

1. Purpose
2. When to use
3. When not to use
4. Inputs required
5. Procedure
6. Evidence required
7. Output artifact
8. Common traps
9. Related skills
10. Provenance and maintenance

Every skill must end with:

## Provenance and maintenance

Re-verify volatile claims with:
- <one-line command>
- <one-line command>

Last generated: <date>
Known uncertainty:
- <uncertainty>

---

Required skill families

1. <project>-change-control

Encodes how changes are classified, gated, reviewed, and promoted.

Must cover:

• Append-only forensic corrections.
• No silent status promotion.
• No routing around parity or QA.
• How to classify docs-only, code, test, research, MT5, and candidate-registry changes.
• What evidence is needed before saying “done.”

2. <project>-repo-orientation

A fast map for zero-context sessions.

Must cover:

• Important directories.
• Docs of record.
• Generated artifacts.
• What not to trust blindly.
• Where to look first for build, test, research, candidate, and MT5 context.

3. <project>-build-test-env

Recreate and verify the environment from scratch.

Must include:

• Install commands.
• Test commands.
• Lint/type commands if present.
• Known traps.
• How to tell whether failures are environment, data, MT5, or code failures.

4. <project>-debugging-playbook

A symptom-to-triage runbook.

Must include:

• Symptom table.
• First discriminating command.
• Likely root causes.
• False friends.
• When to stop and escalate.
• Debugging examples from repo history.

5. <project>-failure-archaeology

The project’s memory of painful failures.

Must include:

• Major investigations.
• Reverts.
• Dead ends.
• Rejected fixes.
• Stale claims.
• “Do not re-fight this battle” entries.

Store long archaeology in reference.md; keep SKILL.md navigational.

6. <project>-architecture-contract

The load-bearing architecture.

Must cover:

• Main subsystems.
• Invariants.
• Dependency boundaries.
• Typed contracts.
• What may not be bypassed.
• Known weak points.

7. goblin-forex-research-discipline

The quant/Forex research evidence bar.

Must cover:

• Gross ≠ net.
• In-sample ≠ accepted result.
• Academic/practitioner source ≠ Goblin truth.
• FX-only limits.
• Trial budgets.
• DSR/PBO/Monte Carlo/cost stress/walk-forward discipline.
• How to turn papers into hypotheses without overclaiming.

8. goblin-alphaops-component-mining

The governed component-mining loop.

Must encode:

• Component Contract.
• Feature Registry.
• Label Registry.
• Trade Intelligence Ledger.
• Component Registry.
• Provenance gate.
• Causality gate.
• Label leakage gate.
• Ablation gate.
• Multiple-testing/trial-budget gate.
• Parity-admissibility gate.
• Execution-feasibility gate.
• Registry integration gate.

Hard rule:

Component mining may output Component Contracts only.
It may not output direct strategy code.

9. goblin-parity-and-mt5-promotion

Python-to-MT5 parity and candidate promotion.

Must cover:

• Screen lead vs MT5 candidate.
• Bar parity.
• Feature parity.
• Signal/state parity.
• Trade parity.
• Cost parity.
• Gate-off checks.
• MT5 execution semantics.
• Holdout seal.
• Promotion ladder.
• Negative/blocking statuses.

10. goblin-hypothesis-lifecycle

How a hunch becomes accepted, rejected, retired, or promoted.

Must include:

• Idea capture.
• Pre-registration.
• Required predictions before running.
• Experiment flagging.
• Trial budget declaration.
• In-sample screening.
• Parity.
• Statistical gate.
• Holdout.
• Demo/live forward.
• Retirement documentation.

11. goblin-forex-domain-reference

The project-specific Forex/MT5/domain reference a mid-level engineer lacks.

Must include only applied knowledge relevant here:

• MT5 Strategy Tester pitfalls.
• Bars/ticks/spread/commission/swap caveats.
• EMA/MACD/Bollinger/ATR/ADX conventions where used.
• Timezone/server-axis issues.
• Pip/point/lot/risk sizing conventions.
• Why retail execution assumptions matter.

12. <project>-diagnostics-and-tooling

How to measure instead of eyeballing.

Must include:

• Diagnostic scripts.
• Trace tools.
• Registry checks.
• Report readers.
• How to interpret artifacts.
• Where outputs land.
• When a diagnostic is insufficient.

Add scripts under scripts/ where useful and safe.

13. <project>-validation-and-qa

What counts as evidence.

Must include:

• Test tiers.
• Golden/certified inventory.
• Acceptance thresholds.
• How to add tests.
• How to read failures.
• What cannot be claimed from a passing unit test alone.

14. <project>-docs-and-writing

Maintaining docs of record.

Must include:

• House style.
• Status language.
• How to mark stale claims.
• How to append corrections.
• Templates for audits, registry updates, and research notes.
• Forbidden language without evidence.

15. <project>-research-frontier

Open problems and state-of-the-art extension paths.

Must include:

• Open frontier problems.
• Why current approaches fail.
• What asset this repo has.
• First three concrete steps in this repo.
• Falsifiable “you have a result when...” criteria.

16. <project>-hardest-problem-campaign

An executable campaign for the hardest current problem found in Phase 1 and clarified by the user.

Must include:

• Numbered phases.
• Exact commands.
• Expected observations.
• Branch conditions.
• Wrong paths fenced off.
• Promotion protocol.
• Measurable success criteria.

---

Phase 4 — Skill trigger engineering

For every skill, create:

.claude/skills/<skill-name>/evals/trigger_eval.json

Include at least 20 realistic trigger eval queries:

[
  {
    "query": "Claude keeps calling this Python result a candidate, can you check if it's actually promotable to MT5?",
    "should_trigger": true,
    "expected_skill": "goblin-parity-and-mt5-promotion"
  },
  {
    "query": "format this markdown table",
    "should_trigger": false,
    "expected_skill": null
  }
]

Use realistic messy prompts, not clean textbook examples. Include typos, vague language, real repo phrases, and edge cases.

Then create:

.claude/skills/_trigger_matrix.md

For each skill, list:

• Should-trigger examples.
• Should-not-trigger examples.
• Likely sibling conflicts.
• How the description avoids false positives.
• How to manually invoke it.

---

Phase 5 — Model-transfer evals

Create .claude/skills/_model_transfer_eval.md.

Design a benchmark to test whether weaker future models actually perform better with the skills.

Include at least 12 tasks:

1. Debug a failing test from a pasted log.
2. Decide whether a Python screen can be called an MT5 candidate.
3. Review a component-mining proposal for leakage.
4. Interpret a candidate registry contradiction.
5. Create a new hypothesis contract from rough notes.
6. Review an MT5 EA parity mismatch.
7. Identify stale docs.
8. Write an append-only correction.
9. Reconstruct a build/test workflow.
10. Decide whether a research paper supports a Goblin experiment.
11. Create a promotion/rejection memo.
12. Run a forensic review of a claimed fix.

For each task, include:

• Prompt.
• Skills expected to trigger.
• Minimum acceptable behavior.
• Red flags.
• Gold-standard outline.
• What a weaker model usually misses.

The point is to test transfer, not just skill existence.

---

Phase 6 — Multi-agent review

After all skills exist, run three independent reviews and one fixer.

Reviewer 1 — Factual verifier

Check:

• Commands.
• Paths.
• Flags.
• Current repo claims.
• File names.
• Generated artifact locations.
• Status names.
• Citations/provenance.
• Anything likely to send an engineer down the wrong path.

Severity:

• BLOCKING: dangerous or false.
• IMPORTANT: likely to waste time.
• MINOR: clarity/scannability.

Reviewer 2 — Doctrine verifier

Check:

• Contradictions with project rules.
• Contradictions between skills.
• Overstated claims.
• Any route around parity, holdout, trial-budget, QA, or change-control.
• Any skill that turns hypotheses into conclusions too easily.

Reviewer 3 — Usability verifier

Check:

• Trigger quality.
• Skill size.
• Scannability.
• Duplication.
• One home per fact.
• Clear outputs.
• Concrete commands.
• Whether a zero-context model could actually use it.

Fixer

Apply all BLOCKING and IMPORTANT fixes. Leave MINOR fixes only if they are explicitly documented.

Write review outputs to:

.claude/skills/_review_factual.md
.claude/skills/_review_doctrine.md
.claude/skills/_review_usability.md
.claude/skills/_fixer_report.md

---

Phase 7 — Final inventory and uncertainty register

Create:

.claude/skills/README.md
.claude/skills/_uncertainty_register.md
.claude/skills/_maintenance_plan.md

README.md must include:

• Skill inventory.
• One-line description of each skill.
• When to invoke each.
• Skill dependency map.
• Suggested first skills for new sessions.
• Which skills are safe for automatic model invocation vs manual use.

_uncertainty_register.md must include:

• Facts not verified.
• Docs suspected stale.
• Commands not run.
• Repo areas not inspected.
• Historical claims needing owner confirmation.
• Skills that need real weaker-model evals.

_maintenance_plan.md must include:

• Re-verification schedule.
• Commands to check drift.
• How to add a new skill.
• How to retire a stale skill.
• How to update trigger evals.
• How to re-run model-transfer evals.

---

Authoring rules

1. Ground truth only.

   • Verify every command, flag, path, and repo claim before writing it.
   • If not verified, mark it as unverified.

2. No hallucinated certainty.

   • Use known, observed, candidate, unverified, stale-risk, or owner-confirmation-needed.

3. No private or machine-specific paths as load-bearing sources.

   • Use repo-relative paths.
   • Personal paths may appear only as examples if clearly labeled.

4. No skill may route around project change-control.

5. No skill may bypass AlphaOps/component gates.

6. No skill may promote a screen result to candidate without parity artifacts.

7. No skill may treat holdout as available unless explicitly owner-authorized.

8. No skill may use research papers as direct trade approval.

   • Papers generate hypothesis strength only.
   • Goblin evidence comes from net-of-cost, deflated, parity-checked, reproducible results.

9. Use imperative runbook voice.

10. Define jargon once.

11. Prefer checklists, decision tables, and copy-pasteable commands.

12. Put long examples in supporting files, not SKILL.md.

13. Each skill must say when not to use it.

14. Each skill must include at least one concrete “bad behavior this prevents” example.

15. Each skill must be useful to both a human and a weaker model.

---

Definition of done

This task is complete only when:

1. .claude/skills/README.md exists and indexes the full library.
2. Every skill has valid frontmatter with a trigger-rich description.
3. Every skill has a concise SKILL.md.
4. Long material is moved into supporting files.
5. Every volatile claim has a re-verification command or is marked uncertain.
6. Trigger evals exist for every skill.
7. Model-transfer evals exist.
8. Factual, doctrine, and usability reviews exist.
9. Blocking and important review findings are fixed.
10. The uncertainty register is honest.
11. The skill library captures not just project facts, but expert judgment: what to check, when to distrust, when to block, when to promote, and when to stop.

Final response to the user must include:

1. Skill inventory with one-line purpose.
2. What was verified directly.
3. What was not verified.
4. Highest-value skills created.
5. Weakest remaining areas.
6. Recommended next eval using GPT 5.5 / Opus 4.8 / Sonnet-class.

Begin now with Phase 0 and Phase 1. Do not author final skills until the repo capability map and expert distillation notes exist.