agentleFS
GustavoGutierrezGustavoGutierrez/engineering-skills/skills/context-engineer/SKILL.md

context-engineer

Skill0 starsChanged 5 months agoMITView on GitHub

Optimize and structure context for agents and LLMs by reducing noise, prioritizing relevance, organizing memory, defining constraints, and managing token budgets.

9 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 32

    Distinctive

    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:

    Use this skill to optimize and structure context for agents and LLMs.

    line 22
  2. Distinctive:

    Use this skill when the user asks to:

    line 28
  3. Distinctive:

    Do not use this skill to solve the underlying domain task directly.

    line 38
  4. Distinctive:

    Separate facts from instructions: Keep task facts, rules, constraints, examples, memory, and open questions in distinct sections.

    line 45
  5. Distinctive:

    Prefer structured context: Use tables, bullets, labels, and stable IDs instead of long narrative blocks.

    line 46
  6. Distinctive:

    Respect privacy and safety: Remove secrets, credentials, unnecessary personal data, and irrelevant sensitive information.

    line 51
  7. Distinctive:

    Use these techniques deliberately:

    line 84
  8. Distinctive:

    Retrieval gating: Keep low-priority context outside the prompt until needed.

    line 91
  9. Distinctive:

    Conflict marking: Keep conflicting facts visible until resolved instead of silently choosing one.

    line 92
  10. Distinctive:

    Token-aware formatting: Prefer compact tables and bullets over prose.

    line 93
  11. Distinctive:

    Put task objective and hard constraints first.

    line 115
  12. Distinctive:

    Add relevant facts, decisions, and dependencies.

    line 116
  13. Distinctive:

    Add output format and quality bar.

    line 117
  14. Distinctive:

    Add retrieval or memory notes for deferred information.

    line 118
  15. Distinctive:

    Check that a downstream agent can act without guessing.

    line 122
  16. Distinctive:

    Check that no irrelevant or sensitive data remains.

    line 123
  17. Distinctive:

    Check that constraints are not weakened by summarization.

    line 124
  18. Distinctive:

    Check that token budget is respected.

    line 125
  19. Distinctive:

    Use this format when producing an optimized context package:

    line 129
  20. Distinctive:

    When organizing memory or long-running context:

    line 173
  21. Distinctive:

    Keep summaries updateable and avoid copying entire histories.

    line 179
  22. Distinctive:

    Keep role-specific instructions separate from global rules.

    line 189
  23. Distinctive:

    Avoid leaking unrelated agent reasoning or irrelevant task history.

    line 191
  24. Distinctive:

    Put non-negotiable constraints before optional background.

    line 196
  25. Distinctive:

    Prefer compact summaries over raw transcripts.

    line 197
  26. Distinctive:

    Prefer references or retrieval instructions for large artifacts.

    line 198
  27. Distinctive:

    Keep recent raw context only when exact wording matters.

    line 201
  28. Distinctive:

    If budget is tight, preserve constraints, current state, decisions, and verification criteria first.

    line 202
  29. Distinctive:

    Before presenting the context package, verify:

    line 206
  30. Distinctive:

    No project-specific names, client names, vendors, or unnecessary concrete technologies were invented.

    line 217
  31. Distinctive:

    Use headings, bullets, and tables.

    line 222
  32. Distinctive:

    Prefer exact constraints and summarized background.

    line 223

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “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 Engineer

Purpose

Use this skill to optimize and structure context for agents and LLMs. The agent treats context as a scarce resource, reduces noise, prioritizes relevance, organizes memory, defines constraints, and produces compact context packages that improve output quality while reducing token use.

This skill is domain-generic. It must work for any agent workflow, prompt, memory system, multi-agent process, or LLM-assisted task without embedding project-specific assumptions.

When to Use

Use this skill when the user asks to:

  • Improve context quality for an AI agent or LLM.
  • Reduce token usage without losing important meaning.
  • Organize long conversations, documents, memories, or task context.
  • Prepare handoff context for another agent.
  • Define constraints, rules, and priorities for prompt engineering.
  • Design context strategy for multi-agent systems.
  • Decide what information should be included, summarized, retrieved, masked, or omitted.

Do not use this skill to solve the underlying domain task directly. Use it to shape the information environment that helps another agent or LLM perform the task correctly.

Core Operating Rules

  1. Treat context as a scarce resource. Include only information that changes the answer, decision, or execution path.
  2. Preserve fidelity over volume. Compress wording, not meaning. Never remove constraints, decisions, risks, or facts needed for correctness.
  3. Prioritize task relevance. Rank context by current task, user intent, constraints, recency, authority, and dependency impact.
  4. Separate facts from instructions. Keep task facts, rules, constraints, examples, memory, and open questions in distinct sections.
  5. Prefer structured context. Use tables, bullets, labels, and stable IDs instead of long narrative blocks.
  6. Minimize duplication. Merge repeated facts and keep one authoritative version.
  7. Expose uncertainty. Mark unknowns, stale information, conflicting facts, and assumptions explicitly.
  8. Design retrieval boundaries. Decide what belongs in immediate context, what should be retrieved on demand, and what should be excluded.
  9. Optimize for downstream agents. Context packages must be easy for another agent to execute without re-reading irrelevant material.
  10. Respect privacy and safety. Remove secrets, credentials, unnecessary personal data, and irrelevant sensitive information.

Context Taxonomy

Classify information before including it:

CategoryInclude WhenHandling Rule
ObjectiveIt defines the task outcome.Always include in the first section.
User IntentIt explains what the user wants or values.Preserve exact meaning; summarize only if long.
Hard ConstraintIt limits allowed behavior or output.Always include; never compress ambiguously.
Soft PreferenceIt influences style or tradeoffs.Include if relevant to current task.
DecisionIt records a chosen direction.Include with rationale and date/context if known.
FactIt describes current state or inputs.Include only if needed for execution.
DependencyIt blocks or sequences work.Include near tasks or execution plan.
ExampleIt clarifies expected pattern.Include minimal representative examples only.
MemoryIt comes from prior sessions or long-term context.Include if relevant, current, and non-conflicting.
NoiseIt does not affect the task.Omit.

Relevance Scoring

Score candidate context using this rubric:

ScoreMeaningAction
5Required for correctness or safety.Include verbatim or near-verbatim.
4Strongly affects implementation or decision quality.Include compactly.
3Useful background, but not decisive.Summarize briefly or retrieve on demand.
2Possibly useful later.Move to deferred context or memory index.
1Irrelevant, duplicated, stale, or distracting.Omit.

Noise Reduction Techniques

Use these techniques deliberately:

  • Deduplication: Merge repeated facts, instructions, and examples.
  • Abstraction: Replace verbose details with stable concepts when specifics are not required.
  • Chunking: Group related facts under clear headings.
  • Summarization: Compress long history into decisions, constraints, and current state.
  • Observation masking: Hide irrelevant observations while preserving the current task state.
  • Retrieval gating: Keep low-priority context outside the prompt until needed.
  • Conflict marking: Keep conflicting facts visible until resolved instead of silently choosing one.
  • Token-aware formatting: Prefer compact tables and bullets over prose.

Execution Workflow

Phase 1: Context Intake

  1. Identify the downstream task and expected output.
  2. Collect candidate context from user input, documents, memory, constraints, and examples.
  3. Separate current task context from historical or background context.
  4. Detect secrets, sensitive data, duplicates, stale facts, and conflicts.

Phase 2: Context Selection

  1. Score each context item for relevance.
  2. Include required objectives, constraints, decisions, dependencies, and validation criteria.
  3. Summarize useful but non-critical context.
  4. Exclude noise and defer low-priority context.
  5. Mark open questions and assumptions.

Phase 3: Context Structuring

  1. Organize context into a compact package.
  2. Put task objective and hard constraints first.
  3. Add relevant facts, decisions, and dependencies.
  4. Add output format and quality bar.
  5. Add retrieval or memory notes for deferred information.

Phase 4: Context Validation

  1. Check that a downstream agent can act without guessing.
  2. Check that no irrelevant or sensitive data remains.
  3. Check that constraints are not weakened by summarization.
  4. Check that token budget is respected.

Required Output Structure

Use this format when producing an optimized context package:

# <Context Package Title>

## 1. Task Objective
- Goal:
- Expected output:
- Success criteria:

## 2. Hard Constraints
- <Non-negotiable rule or limitation>

## 3. Relevant Facts
| Fact | Source/Confidence | Why It Matters |
| --- | --- | --- |

## 4. Decisions and Rationale
| Decision | Rationale | Impact |
| --- | --- | --- |

## 5. Dependencies and Blockers
| Item | Type | Blocks | Resolution |
| --- | --- | --- | --- |

## 6. Working Assumptions
- <Assumption and reason>

## 7. Open Questions
- <Question that affects correctness or execution>

## 8. Deferred Context
| Item | Why Deferred | Retrieve When |
| --- | --- | --- |

## 9. Output Contract for Downstream Agent
- Required sections:
- Forbidden actions:
- Quality bar:
- Verification method:

Memory Organization Rules

When organizing memory or long-running context:

  • Store stable decisions separately from transient observations.
  • Store user preferences separately from project facts.
  • Store constraints with rationale and scope.
  • Mark stale or superseded information.
  • Keep summaries updateable and avoid copying entire histories.
  • Include retrieval keys or labels when useful.
  • Preserve conflict notes until explicitly resolved.

Multi-Agent Context Rules

For multi-agent systems:

  • Give each agent only the context required for its role.
  • Include shared constraints consistently across agents.
  • Keep role-specific instructions separate from global rules.
  • Provide handoff summaries with outputs, decisions, risks, and unresolved questions.
  • Avoid leaking unrelated agent reasoning or irrelevant task history.
  • Define what each agent may read, write, decide, and escalate.

Token Budget Rules

  • Put non-negotiable constraints before optional background.
  • Prefer compact summaries over raw transcripts.
  • Prefer references or retrieval instructions for large artifacts.
  • Remove duplicate examples.
  • Replace verbose logs with relevant events and error signatures.
  • Keep recent raw context only when exact wording matters.
  • If budget is tight, preserve constraints, current state, decisions, and verification criteria first.

Quality Checklist

Before presenting the context package, verify:

  • The output is written in English.
  • The downstream task is explicit.
  • Hard constraints are preserved.
  • Relevant facts are prioritized.
  • Noise, duplicates, and stale information are removed or marked.
  • Assumptions and open questions are visible.
  • Sensitive data and secrets are excluded.
  • Deferred context includes retrieval conditions.
  • The package is compact enough for the intended context window.
  • No project-specific names, client names, vendors, or unnecessary concrete technologies were invented.

Response Style

  • Be concise, structured, and token-aware.
  • Use headings, bullets, and tables.
  • Prefer exact constraints and summarized background.
  • State what was omitted and why when omission could affect confidence in the result.
  • Mark unknowns as TBD instead of inventing context.

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.