Promote

Skill mk668a/FDE-SKILLS/skills/promote

Use when a deliverable taught something reusable and the user wants it to benefit future engagements (e.g. "promote these learnings", "save this to the corpus", "make this reusable across clients"). Anonymizes the learnings, stages them with stable pattern keys, and runs the deterministic promote script — which counts sightings and, at the third, paves the pattern into the schema.From its SKILL.md

Install

npx -y skills add mk668a/FDE-SKILLS --skill promote

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.5 KB, 805 tokens by cl100k_base, as published. Nobody here has run it

fde-promote — count sightings, pave at three

The write side of compounding, and the only path by which anything leaves an engagement's confidential boundary. Rule of Three (Fowler, Refactoring), made mechanical: a pattern enters the corpus as a candidate (×1), becomes recurring (×2), and at the third sighting is paved into the schema — evolved_slots gains the slot, version bumps, and git diff .fde/schemas/ shows exactly what three engagements taught you. Two-layer by design: you (LLM) decide what is durable and paraphrase out the client; the script counts, redacts, gates, and paves.

Steps

Resolve <client> and <type>. Read the deliverable's .md and .slots.yml.
Read the corpus first: .fde/corpus/<type>.yml. Sighting counting works by key reuse — if a learning matches an existing entry's meaning, you MUST reuse that entry's key (that's what increments the counter). Only mint a new kebab-case key for a genuinely new pattern.
Semantic anonymization (LLM): rewrite each learning you want to keep as a generalizable pattern, not this client's situation. Strip names, people, internal system names, industries-if-identifying, specific figures. If a learning is too client-specific to generalize, drop it. If it names a person or system the scripts can't know about, also add that token to anonymization.extra_identifiers in .fde/config.yml so the gate can enforce it forever.

Stage the patterns as engagements/<client>/deliverables/<type>.promote.yml:

schema: <type>
patterns:
  - key: sso-auth-integration     # reused key -> sighting +1
    slot: technical_risks         # existing slot id, or a proposed new one
    label: ""                     # label+prompt only for NEW-slot proposals
    prompt: ""
    pattern: "one-line generalized learning, already anonymized"

Run the deterministic promote:
```
.fde/bin/fde-promote.sh <client> <type>
```
The script redacts figures + identifiers, merges into the corpus with sighting counters, refuses to touch the corpus if the merged result would leak an identifier, paves anything that hit the threshold, and re-runs fde-validate.sh. Report its output verbatim — especially PAVED: lines and LEAK BLOCKED: failures.
If something paved, refresh the wall (.fde/bin/fde-dashboard.sh) and show the user the schema diff (git diff .fde/schemas/ if the workspace is a repo). That diff is the payoff.

Hard rules

The script's redaction is a backstop, not the primary control. Do the semantic anonymization first; never rely on regex to catch a client name you could have paraphrased away.
If the script prints LEAK BLOCKED, treat it as a hard failure: fix the staged pattern text, don't work around the gate.
Promote patterns, not client deliverables. The corpus is a library of reusable structure, not a copy of past clients' documents.
Never edit .fde/corpus/*.yml or a schema's evolved_slots by hand — the script is the only writer, so the counters stay trustworthy.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.