llm-friendly-context

# 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** - Replace subjective terms with observable conditions, paths, commands, schemas, examples, or decision rules. - 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 necessary context** - Include the purpose, source artifacts, hard constraints, accepted decisions, and unresolved conditions. - Prefer concrete file paths and section hints over broad module names. - Follow references while they can change ...