agentleFS
darkroomengineeringdarkroomengineering/cc-settings/skills/context-doc/SKILL.md

context-doc

Skill52 starsChanged 49 days agoMITView on GitHub

Build CONTEXT.md (domain glossary) and docs/adr/ through an interview. Triggers "domain language", "glossary", "ADR", or inconsistent terminology across the codebase.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If a question can be answered by reading code, read the code instead.

    line 21
  2. Very specific:

    Challenge against the glossary: When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out: "Your …

    line 25
  3. Distinctive:

    Sharpen fuzzy language: When the user uses vague or overloaded terms, propose a precise canonical term.

    line 27
  4. Distinctive:

    Discuss concrete scenarios: When domain relationships are being discussed, stress-test them with specific scenarios.

    line 29
  5. Distinctive:

    Cross-reference with code: When the user states how something works, check whether the code agrees.

    line 31
  6. Very specific:

    Update CONTEXT.md inline: When a term is resolved, update the file right there.

    line 33
  7. Very specific:

    Don't couple CONTEXT.md to implementation: Only include terms meaningful to domain experts.

    line 35

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Context doc — domain language + ADRs

Two persistent artifacts that stop agent drift across sessions:

  • CONTEXT.md — the project's glossary. The terms domain experts and engineers both use. Updated inline as decisions crystallize.
  • docs/adr/ — architecture decision records. One paragraph per hard-to-reverse trade-off.

This skill produces both. Other skills read them via DOMAIN-AWARENESS.md (consumer rules in the same directory).

Workflow

Interview the user relentlessly about every aspect of the plan, terminology, or area in question until you reach shared understanding. Walk down each branch of the design tree, resolving dependencies one at a time. For each question, propose a recommended answer.

Ask in rounds (AGENTS.md "Clarify Before Full Work Mode"): at most 4 related questions per round through the host's question tool, recommended answer first. The first round is exactly one question, the one that most reduces ambiguity, with no side requests for examples or other repos; later rounds ask only what earlier answers opened.

If a question can be answered by reading code, read the code instead. Don't ask the user what git blame will tell you.

During the session

Challenge against the glossary. When the user uses a term that conflicts with the existing language in CONTEXT.md, call it out: "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"

Sharpen fuzzy language. When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."

Discuss concrete scenarios. When domain relationships are being discussed, stress-test them with specific scenarios. Invent edge cases that force the user to be precise about boundaries between concepts.

Cross-reference with code. When the user states how something works, check whether the code agrees. Surface contradictions: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is it?"

Update CONTEXT.md inline. When a term is resolved, update the file right there. Don't batch. Format: see CONTEXT-FORMAT.md.

Don't couple CONTEXT.md to implementation. Only include terms meaningful to domain experts. "Timeout" is generic; "ShipmentDispatched" is domain.

File structure

For the directory layout (single-context vs multi-context with CONTEXT-MAP.md), see DOMAIN-AWARENESS.md. Create files lazily — no CONTEXT.md? Create one when the first term is resolved. No docs/adr/? Create it when the first ADR is needed.

Offer ADRs sparingly

See ADR-FORMAT.md for the three-criterion threshold (hard to reverse, surprising without context, real trade-off) and the format. If a decision misses any criterion, skip the ADR. Most decisions don't qualify.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.