How do I install the Draft skill?

Run npx skillmds@latest add mk668a/draft in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Draft safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Draft?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Draft free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

mk668a (@mk668a) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Draft by mk668a — Agent Skill

Name: Draft
Author: mk668a

Draft

Use when the user wants to produce a client deliverable or check how complete one is — a risk register, findings report, stakeholder map, etc. (e.g. "draft the risk register for Acme", "write up findings", "how complete is the integration spec"). Fills the deliverable's typed schema from engagement notes AND pre-populates slots from what past engagements taught (candidate ×n priors, paved slots), then reports coverage and refreshes the dashboard.

mk668a 5d4de25 3.6 KB Updated Sep 17, 2026

File contents

fde-draft — draft a typed deliverable with schema inheritance

The compounding wedge. A deliverable is not a blank doc — it is a typed schema of slots, and the schema is a versioned prior that hardens with evidence: drafting engagement N's risk register starts from everything engagements 1..N-1 taught.

Steps

Resolve the engagement (<client>) and the deliverable <type> (one of the ids in .fde/config.yml → deliverable_types).
Load the schema: .fde/schemas/<type>.schema.yml — slot ids, labels, required flags, prompts, plus any evolved_slots that past engagements paved in (each carries a paved_from: provenance line).
Inherit priors from .fde/corpus/<type>.yml. Every entry has a sightings counter and a paved flag — respect the tiering:
- paved: true → pre-fill the slot by default; it earned that at 3+ sightings. Still mark it [paved: confirm].
- paved: false → offer it as [candidate ×<sightings>: confirm]. A ×1 candidate is one engagement's opinion; say so.
Fill from this engagement: read engagements/<client>/notes/*.md. Fill slots from real, client-specific evidence. Client evidence overrides an inherited prior — never let a past client's detail leak into this draft as fact.
Flag gaps: list every required slot still empty, with the exact question the user should answer (from the slot's prompt).
Detect novel slots: if this engagement surfaced a recurring dimension the schema lacks, propose it — /fde:promote will stage it as a candidate with a stable key; the schema only changes when the Rule-of-Three counter says so.
Write two files (the two-layer split):
- engagements/<client>/deliverables/<type>.md — the human-readable draft.
- engagements/<client>/deliverables/<type>.slots.yml — the machine state:
```
schema: <type>
schema_version: <n>
slots:
  <slot_id>: "<filled value, or empty for a gap>"
sources:
  <slot_id>: inherited      # pre-filled from the corpus (confirmed)
  <slot_id>: engagement     # filled from this client's evidence
  # omit a slot here if it is still empty
```
  Format contract: one line per slot, flat scalars — the deterministic spine (fde-coverage.sh, fde-dashboard.sh) counts lines, not YAML trees. Fold list-ish content into one quoted line.
Report coverage and refresh the wall deterministically:
```
.fde/bin/fde-coverage.sh <client> <type>
.fde/bin/fde-dashboard.sh
```
Show the user filled/total — inherited · new. Watching the inherited share climb across engagements is the whole product.

Hard rules

Inherited values are suggestions to confirm, never asserted as this client's facts. Everything in the corpus was anonymized on the way in — re-ground it in this engagement's notes.
Always write sources: alongside slots:; the dashboard's colors and the coverage breakdown are only as honest as that block.
No runtime cloud LLM, no external service. This skill runs on the user's own Claude Code; the spine scripts are plain shell.

---name: draftdescription: Use when the user wants to produce a client deliverable or check how complete one is — a risk register, findings report, stakeholder map, etc. (e.g. "draft the risk register for Acme", "write up findings", "how complete is the integration spec"). Fills the deliverable's typed schema from engagement notes AND pre-populates slots from what past engagements taught (candidate ×n priors, paved slots), then reports coverage and refreshes the dashboard.---# fde-draft — draft a typed deliverable with schema inheritanceThe compounding wedge. A deliverable is not a blank doc — it is a typed schemaof **slots**, and the schema is a versioned prior that hardens with evidence:drafting engagement N's risk register starts from everything engagements1..N-1 taught.## Steps1. **Resolve** the engagement (`<client>`) and the deliverable `<type>` (one of the ids in `.fde/config.yml` → `deliverable_types`).2. **Load the schema**: `.fde/schemas/<type>.schema.yml` — slot ids, labels, required flags, prompts, plus any `evolved_slots` that past engagements paved in (each carries a `paved_from:` provenance line).3. **Inherit priors** from `.fde/corpus/<type>.yml`. Every entry has a `sightings` counter and a `paved` flag — respect the tiering: - `paved: true` → **pre-fill the slot by default**; it earned that at 3+ sightings. Still mark it `[paved: confirm]`. - `paved: false` → offer it as `[candidate ×<sightings>: confirm]`. A ×1 candidate is one engagement's opinion; say so.4. **Fill from this engagement**: read `engagements/<client>/notes/*.md`. Fill slots from real, client-specific evidence. Client evidence **overrides** an inherited prior — never let a past client's detail leak into this draft as fact.5. **Flag gaps**: list every `required` slot still empty, with the exact question the user should answer (from the slot's `prompt`).6. **Detect novel slots**: if this engagement surfaced a recurring dimension the schema lacks, propose it — `/fde:promote` will stage it as a candidate with a stable key; the schema only changes when the Rule-of-Three counter says so.7. **Write two files** (the two-layer split): - `engagements/<client>/deliverables/<type>.md` — the human-readable draft. - `engagements/<client>/deliverables/<type>.slots.yml` — the machine state: ```yaml schema: <type> schema_version: <n> slots: <slot_id>: "<filled value, or empty for a gap>" sources: <slot_id>: inherited # pre-filled from the corpus (confirmed) <slot_id>: engagement # filled from this client's evidence # omit a slot here if it is still empty ``` **Format contract**: one line per slot, flat scalars — the deterministic spine (`fde-coverage.sh`, `fde-dashboard.sh`) counts lines, not YAML trees. Fold list-ish content into one quoted line.8. **Report coverage and refresh the wall** deterministically: ```bash .fde/bin/fde-coverage.sh <client> <type> .fde/bin/fde-dashboard.sh ``` Show the user `filled/total — inherited · new`. Watching the inherited share climb across engagements is the whole product.## Hard rules- Inherited values are **suggestions to confirm**, never asserted as this client's facts. Everything in the corpus was anonymized on the way in — re-ground it in this engagement's notes.- Always write `sources:` alongside `slots:`; the dashboard's colors and the coverage breakdown are only as honest as that block.- No runtime cloud LLM, no external service. This skill runs on the user's own Claude Code; the spine scripts are plain shell.

Frequently asked questions