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
- shinpr/ai-coding-project-boilerplateedited, first seen Nov 8, 2026
- shinpr/codex-workflowsedited, first seen Nov 3, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- shinpr/ai-coding-project-boilerplate★ 23654% same
- shinpr/codex-workflows★ 3930% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository27 other files it gives its agents.
- ai-development-guideSkill
- coding-principlesSkill
- documentation-criteriaSkill
- external-resource-contextSkill
- implementation-approachSkill
- integration-e2e-testingSkill
- recipe-add-integration-testsSkill
- recipe-buildSkill
- recipe-designSkill
- recipe-diagnoseSkill
- recipe-front-adjustSkill
- recipe-front-buildSkill
- recipe-front-designSkill
- recipe-front-planSkill
- recipe-front-reviewSkill
- recipe-fullstack-buildSkill
- recipe-fullstack-implementSkill
- recipe-implementSkill
- recipe-planSkill
- recipe-quality-profileSkill
- recipe-reverse-engineerSkill
- recipe-reviewSkill
- recipe-update-docSkill
- requirement-convergenceSkill
- subagents-orchestration-guideSkill
- testing-principlesSkill
- typescript-rulesSkill
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
- Distinctive: line 15
Keep a prohibition only when it protects an irreversible boundary or shipped contract.
- Distinctive: line 23
Use the sections, fields, table columns, JSON keys, or checklist items the consumer uses.
- Distinctive: line 29
Prefer concrete file paths and section hints over broad module names.
- Distinctive: line 30
Follow references while they can change an in-scope decision, action, or verification result.
- Distinctive: line 41
Add only constraints that reduce ambiguity or preserve a real requirement.
- Distinctive: line 42
Keep simple downstream tasks lightweight when the target action, context, and success criteria are already clear.
- Distinctive: line 47
Use these rewrites before treating a prompt, handoff, or artifact as complete.
- Distinctive: line 63
Before sending a prompt or artifact to another consumer, verify:
- Distinctive: line 77
Before writing or finalizing a generated document:
≈ “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.
Files
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
- 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."
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 form | Rewrite as |
optional used as an unresolved choice | Required, omitted, or required only under a named condition |
| Alternatives whose choice changes a protected outcome | The governing constraint or unresolved owner decision; for reversible choices, purpose, evidence and selection criteria |
as needed / if needed | The triggering condition and required action |
per convention | The file, function, test, or documented convention to follow |
related files | Specific paths, globs, or search hints |
existing behavior | The observable behavior, source file, test, API response, or UI state to preserve |
placeholder | Exact temporary value/behavior, allowed dependencies, and verification expectation |
TBD used as a placeholder for required information | A blocking unresolved item with owner, required input, and decision effect |
appropriate / proper | A 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.
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
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.

