agentleFS
shinprshinpr/claude-code-workflows/skills/llm-friendly-context/SKILL.md

llm-friendly-context

Skill712 starsChanged 8 months agoMITView on GitHub

Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream consumers can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.

2 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep a prohibition only when it protects an irreversible boundary or shipped contract.

    line 15
  2. Distinctive:

    Use the sections, fields, table columns, JSON keys, or checklist items the consumer uses.

    line 23
  3. Distinctive:

    Prefer concrete file paths and section hints over broad module names.

    line 29
  4. Distinctive:

    Follow references while they can change an in-scope decision, action, or verification result.

    line 30
  5. Distinctive:

    Add only constraints that reduce ambiguity or preserve a real requirement.

    line 41
  6. Distinctive:

    Keep simple downstream tasks lightweight when the target action, context, and success criteria are already clear.

    line 42
  7. Distinctive:

    Use these rewrites before treating a prompt, handoff, or artifact as complete.

    line 47
  8. Distinctive:

    Before sending a prompt or artifact to another consumer, verify:

    line 63
  9. Distinctive:

    Before writing or finalizing a generated document:

    line 77

≈ “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

LLM-Friendly Context

The goal is stable downstream execution: the next consumer should know what to read, what to do, what counts as success, and which unresolved decisions can change the result.

Core Rules

  1. Use positive, executable instructions
    • State what the next consumer should do.
    • Convert quality policies into positive criteria.
    • Keep a prohibition only when it protects an irreversible boundary or shipped contract. Name the protected condition and the allowed action.
    • Example: "Preserve existing public API behavior across the documented compatibility cases."
  2. Make vague instructions concrete
    • Clarify wording when plausible interpretations would change the outcome, scope, authority or proof. Supply purpose, evidence and selection criteria for reversible choices; reserve exact selections for actual consumer contracts and user-owned decisions.
    • Terms that often need clarification when they leave a decision to the next consumer: appropriate, proper, related, existing behavior, optional, as needed, if needed, per convention, unresolved alternatives, TBD, placeholder.
  3. Specify output shape
    • Use the sections, fields, table columns, JSON keys, or checklist items the consumer uses.
    • For handoffs, include only produced artifact paths and status fields that control the next transition.
  4. Provide the smallest sufficient context
    • Sufficient means sufficient for the assigned action, not complete background: every item you include is consumed by that action or by the result it must produce.
    • Include the purpose, source artifacts, hard constraints, accepted decisions, and unresolved conditions that action consumes.
    • Prefer concrete file paths and section hints over broad module names.
    • Follow references while they can change an in-scope decision, action, or verification result.
  5. Decompose complex work into verifiable steps
    • Expose real dependencies and their completion evidence. Let independent reversible work follow the route suited to the task.
    • Each step needs a checkpoint: what evidence proves it is complete.
  6. Permit uncertainty explicitly
    • Resolve missing operational detail from referenced artifacts and repository evidence before treating it as unresolved.
    • Record remaining uncertainty with its effect, required input, and decision owner. Make reversible repository-local choices when governing evidence resolves them.
  7. Keep constraints proportionate
    • Add only constraints that reduce ambiguity or preserve a real requirement.
    • Keep simple downstream tasks lightweight when the target action, context, and success criteria are already clear.
    • Interpret minimal as the least downstream complexity that fully solves the problem. An explicit user diff limit is a constraint; otherwise necessary corrections are not bounded by a line count.

Rewrite Patterns

Use these rewrites before treating a prompt, handoff, or artifact as complete.

Ambiguous formRewrite as
optional used as an unresolved choiceRequired, omitted, or required only under a named condition
Alternatives whose choice changes a protected outcomeThe governing constraint or unresolved owner decision; for reversible choices, purpose, evidence and selection criteria
as needed / if neededThe triggering condition and required action
per conventionThe file, function, test, or documented convention to follow
related filesSpecific paths, globs, or search hints
existing behaviorThe observable behavior, source file, test, API response, or UI state to preserve
placeholderExact temporary value/behavior, allowed dependencies, and verification expectation
TBD used as a placeholder for required informationA blocking unresolved item with owner, required input, and decision effect
appropriate / properA measurable criterion or checklist

Handoff Checklist

Before sending a prompt or artifact to another consumer, verify:

  • The target action is explicit.
  • Required input paths, source artifacts, and decision-relevant facts are named.
  • Every included context item is consumed by the target action or its required result.
  • Accepted decisions and constraints use one canonical wording.
  • Output format or expected status fields are specified.
  • Success criteria are observable.
  • Outcome-relevant ambiguities are resolved or assigned to their decision owner; harmless execution flexibility remains.
  • Each instruction states the allowed action; each retained prohibition names the protected condition and allowed alternative.
  • The next consumer can complete its scope from the supplied purpose, sources, criteria, and evidence, or return the exact unresolved decision and owner.

Generated Artifact Checklist

Before writing or finalizing a generated document:

  • Each requirement, claim, task, test skeleton, or review finding has enough source context to trace why it exists.
  • Every executable instruction names the target, action, and expected result.
  • Verification steps say what to run or observe and what result proves success.
  • Each instruction states the allowed action; each retained prohibition names the protected condition and allowed alternative.
  • If an artifact is derived from another artifact, copied decisions stay consistent in wording and meaning.
  • If downstream work is blocked by missing information, the artifact records the missing input, decision owner, and effect.

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.