Claude Skill

context-engineering

Use when a long session has accumulated stale or conflicting context or the user asks to refresh it. Not for remote, credential, publish, deploy, or irreversible changes.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download outlinedriven-outline-driven-development-.devin_skills_context-engineering-b0e8ce8.zip · 1 KB
Part of outlinedriven/outline-driven-development — 145 skills

Install

skills CLI npx skills add https://github.com/OutlineDriven/outline-driven-development/tree/main/.devin/skills/context-engineering
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install outlinedriven-outline-driven-development@llmmart
Git git clone https://github.com/OutlineDriven/outline-driven-development.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole outlinedriven/outline-driven-development collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Context engineering

Contract

Field Bound contract
Trigger Long session has accumulated stale or conflicting context, or the user asks to refresh or recheck context before continuing.
Authority Reversible local: writes only an optional scratch state note; rollback is undo. No remote mutation.
Side effect Optional scratch state note only; no project files touched.
Done Acting context is provably current and minimal; stale items are dropped with the user informed.

Inputs

  • The current acting context present in the session: stated facts, assumptions, inferred file state, and prior decisions.
  • The source of truth for each item being rechecked: repository files, tool output, or user-stated ground truth.
  • Optional: a user-named subset to recheck. If omitted, recheck the full acting context.

Procedure

  1. Enumerate every item in the acting context: stated facts, assumptions, inferred file state, and prior decisions. Done when: every acting-context item is enumerated.
  2. For each item, recheck it against its source of truth by the narrowest action that settles it: read the file, re-run the tool, or ask the user. Classify the item as current, stale, or contradicted. Done when: every item is classified current, stale, or contradicted.
  3. Drop stale and contradicted items from the acting context. Replace a dropped item with the corrected value only when the source of truth supplies one. Done when: stale and contradicted items are dropped and replaced where a corrected value exists.
  4. Remove redundant or duplicate items so the acting context holds only items that are provably current and needed for the remaining work. Done when: no redundant or duplicate items remain.
  5. Tell the user which items were dropped and why, and identify any item that could not be settled because its source of truth was unreachable. Done when: dropped items and reasons are reported and unsettled items are identified.
  6. Optionally write a scratch state note recording the settled context and the dropped items. Do not touch any project file. Done when: the scratch note is written or skipped, and no project file is touched.

Failure and recovery

  • Unreachable source of truth: leave the dependent item flagged as unsettled, do not drop or replace it, and report it to the user. Never assert an item is current without a settled source.
  • Contradiction between sources: report both sources and ask the user which to keep. Do not silently pick one.
  • Partial result: deliver the subset that was settled and explicitly list the unsettled remainder. Never present a partial refresh as complete.
  • Non-mutation boundary: if any step would require touching a project file or remote state, stop and report the boundary rather than widening authority.

Output

Refreshed acting context (only provably current, minimal items) → user-facing list of dropped items with reasons → optional scratch state note. Unsettled items listed separately and remain flagged.

Files (outline-driven-development)
  • agents
    • openai.yaml 216 B
      interface:
        display_name: "Context Engineering"
        short_description: "Use when a long session has accumulated stale or conflicting context or the user asks to refresh it."
      policy:
        allow_implicit_invocation: false
      
  • SKILL.md 3.2 KB
    ---
    name: context-engineering
    description: 'Use when a long session has accumulated stale or conflicting context or the user asks to refresh it. Not for remote, credential, publish, deploy, or irreversible changes.'
    disable-model-invocation: true
    ---
    
    # Context engineering
    
    ## Contract
    
    | Field | Bound contract |
    |---|---|
    | Trigger | Long session has accumulated stale or conflicting context, or the user asks to refresh or recheck context before continuing. |
    | Authority | Reversible local: writes only an optional scratch state note; rollback is undo. No remote mutation. |
    | Side effect | Optional scratch state note only; no project files touched. |
    | Done | Acting context is provably current and minimal; stale items are dropped with the user informed. |
    
    ## Inputs
    
    - The current acting context present in the session: stated facts, assumptions, inferred file state, and prior decisions.
    - The source of truth for each item being rechecked: repository files, tool output, or user-stated ground truth.
    - Optional: a user-named subset to recheck. If omitted, recheck the full acting context.
    
    ## Procedure
    
    1. Enumerate every item in the acting context: stated facts, assumptions, inferred file state, and prior decisions. Done when: every acting-context item is enumerated.
    2. For each item, recheck it against its source of truth by the narrowest action that settles it: read the file, re-run the tool, or ask the user. Classify the item as current, stale, or contradicted. Done when: every item is classified current, stale, or contradicted.
    3. Drop stale and contradicted items from the acting context. Replace a dropped item with the corrected value only when the source of truth supplies one. Done when: stale and contradicted items are dropped and replaced where a corrected value exists.
    4. Remove redundant or duplicate items so the acting context holds only items that are provably current and needed for the remaining work. Done when: no redundant or duplicate items remain.
    5. Tell the user which items were dropped and why, and identify any item that could not be settled because its source of truth was unreachable. Done when: dropped items and reasons are reported and unsettled items are identified.
    6. Optionally write a scratch state note recording the settled context and the dropped items. Do not touch any project file. Done when: the scratch note is written or skipped, and no project file is touched.
    
    ## Failure and recovery
    - Unreachable source of truth: leave the dependent item flagged as unsettled, do not drop or replace it, and report it to the user. Never assert an item is current without a settled source.
    - Contradiction between sources: report both sources and ask the user which to keep. Do not silently pick one.
    - Partial result: deliver the subset that was settled and explicitly list the unsettled remainder. Never present a partial refresh as complete.
    - Non-mutation boundary: if any step would require touching a project file or remote state, stop and report the boundary rather than widening authority.
    
    ## Output
    Refreshed acting context (only provably current, minimal items) → user-facing list of dropped items with reasons → optional scratch state note. Unsettled items listed separately and remain flagged.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related