context-engineering

Context Engineering

Active Stack

echo "--- Tech Stack ---"
_rts="${CLAUDE_PLUGIN_ROOT:-.}/scripts/resolve-tech-stack.sh"; [ -f "$_rts" ] || _rts="scripts/resolve-tech-stack.sh"
if [ -f "$_rts" ]; then bash "$_rts" --explain "$PWD" 2>&1; echo; else cat .claude/tech-stack 2>/dev/null || echo "(not set)"; fi
if [ -f .claude/tech-stack-pm ]; then echo "--- Package Manager ---"; cat .claude/tech-stack-pm; fi

Overview

Good output depends on good context. Context is the complete information payload the model sees at generation time — load the minimum relevant part needed to act correctly, then refresh it when the task shifts.

Context Operations (Write / Select / Compress / Isolate)

The four moves of context engineering. MTK already implements each; the names give them a shared vocabulary (borrow: LangChain / jihoo-kim context-engineering taxonomy).

Operation	What it means	Where MTK does it
Write	Persist state outside the window so it survives compaction/handoff	auto-memory + tasks/lessons.md, workflow-artifacts, handoff
Select	Pull in only what the current step needs	rules INDEX.md wake-up layer, path-scoped applyTo reference loading (below)
Compress	Shrink what must stay in-window without losing signal	.claude/references/output-compression.md, mtk-compress.sh
Isolate	Give a sub-task its own fresh window	subagent-implementation (one implementer per batch), review agents (context: fork)

When To Use

• Starting a new session
• Switching from planning to implementation or implementation to review
• Entering an unfamiliar area of the codebase
• When the model starts making assumptions or drifting from project norms

When NOT To Use

• As an excuse to endlessly read without acting

Workflow

1. Start with CLAUDE.md when present.
2. Load only the shared references relevant to the task.
3. Path-scoped auto-load. Reference entries in .claude/manifest.json may declare an applyTo glob array. When the current task has a known set of files in scope (from the spec's change_manifest or from git diff --name-only HEAD):
   • MCP-first: If mtk_resolve_references tool is available, call it with the list of touched files. It returns deterministic glob matches against the manifest's applyTo arrays. Use its output directly.
   • Fallback: If the MCP tool is unavailable, manually test each touched file against the globs (bash case / fnmatch semantics).
   • Load references whose globs match at least one touched file.
   • Skip references whose globs match nothing — they're not relevant to this task.
   • References without applyTo are always-on when needed (e.g. coding-guidelines, framework-patterns); load on demand per phase.
4. Read the exact file to be changed and 2-3 neighboring files that establish local patterns.
5. Separate trusted local standards from untrusted external inputs.
6. Before a new phase, summarize what matters now:
   • current goal
   • files in scope
   • governing rules
   • open risks
   • which applyTo references activated and why
7. Refresh context when the scope or failure mode changes. If new files enter scope, re-run the path-scoped match and load any newly-applicable references.