fable-seed

name	fable-seed
description	Generate or refresh local AGENTS.md convention files for a codebase by reading the code that already exists, so later work follows the project's real conventions instead of model defaults. Use when starting work in an unfamiliar module, when conventions keep getting violated, or when asked to "seed", "init", or "write AGENTS.md for" a directory. Pulled on demand; not always-on.

fable-seed — write the AGENTS.md the code already implies

This skill turns a measured result into an action. In a controlled A/B (eval/technique-ab/run-autoseed.mjs, GPT-5.5-judged), a short local AGENTS.md stating a module's convention raised oracle adherence from 33% (no seed) to 100% (hand-written) — and a file auto-generated by reading the module's existing code reached 89% (GPT-5.5 oracle), and 100% on the deterministic regex check (vs the hand-written file's 78% there). So auto-generation preserves ~89% of the hand-written lift (and matches or beats it on the deterministic check): the highest-value, lowest-effort thing you can do before working in a module is to surface its conventions into a local file the work sits next to.

Your job: read what's there, write down the rules it already follows — don't invent conventions the code doesn't show.

When NOT to use this

• A trivial one-file change, or a repo that already has good AGENTS.md/CLAUDE.md coverage → just read those and work; seeding again is over-building.
• You haven't read any of the module's code yet → read first; a seed written from a guess is worse than none.

Procedure

1. Pick the scope. One AGENTS.md per coherent module/package (the directory where related code lives), not one giant root file and not one per file. For a large tree, seed the directories where work is actually happening; hierarchy is the point.
2. Read representative code. Open 3–6 existing files in that directory. Look for the conventions that are actually and consistently followed, e.g.:
   • units/domain types (money in integer cents? durations in ms? dates as UTC ISO-8601?)
   • error handling (throw vs a Result/{ ok } object)
   • data access (parameterized queries vs string interpolation)
   • module shape (named vs default exports; handler return shape; logging via a structured logger vs console)
   • id generation, input validation at boundaries, naming.
3. Write the file — short and rule-shaped. Aim for ~4–8 bullet lines, ≤ ~80 words. State each as a rule a new contributor must follow, not a description of the code. The validated generator prompt: "state the rules as rules, do not restate the code." Bad: "addPrices adds two cent values." Good: "Money is integer cents; functions take and return cents; format to dollars only at the boundary."
4. Only what the code shows. If a convention isn't evidenced by the files you read, leave it out — an asserted-but-false rule is worse than silence. If two files disagree, say the dominant one and note the exception, or omit it.
5. Don't clobber. If an AGENTS.md already exists, show the proposed change as a diff and merge rather than overwrite; never silently replace a human-written file.
6. Report. Name each file you wrote and the conventions you captured, in one line each, and flag any convention you were unsure of as (unverified — confirm).

Honest bound

The A/B handed the generated file to the model, so it measures the value of the convention being present and specific; the additional value of an agent auto-discovering the file near the code is real but untested, so the true effect is ≥ the measured 89%. This is a style/convention aid — it does not change behavior the code doesn't already exhibit.