context-engineering skill

Signs a project needs the context-engineering skill

The skill's description lists four triggers: starting a new session, a drop in agent output quality, switching between tasks, and configuring rules files and context for a project. Its "When to Use" list adds two more: setting up a new project for AI-assisted development, and an agent that is not following project conventions.

The symptoms it describes are specific enough to check against your own sessions:

• The agent uses the wrong patterns or calls APIs that do not exist in your codebase.
• It ignores conventions you have already explained.
• It re-implements utilities that already exist in the codebase.
• Quality falls mid-task as the conversation grows, because failed attempts, replaced drafts and verbose tool output are never trimmed.

The skill gives the reason in its overview. With too little context the agent hallucinates, and with too much it loses focus. It defines context engineering as deliberately curating what the agent sees, when it sees it, and how that material is structured. Each fix it suggests either adds missing context or removes stale context from the context window.

Applying the context hierarchy in a working session

The five levels map onto a routine you can follow at the start of each task. The steps and example prompts below come from the SKILL.md.

1. Write a rules file once. Use CLAUDE.md for Claude Code, .cursorrules or .cursor/rules/*.md for Cursor, .windsurfrules for Windsurf, .github/copilot-instructions.md for GitHub Copilot, or AGENTS.md for OpenAI Codex. The sample template has sections for tech stack, commands (build, test, lint, dev, type check), code conventions, boundaries such as "Ask before modifying database schema", and one short example of a component written in your style.
2. Load only the spec section you need. The skill recommends "Here's the authentication section of our spec" over pasting an entire 5,000-word spec when the work only touches auth.
3. Load source files before editing. Read the files you will modify, read their tests, find one similar pattern already in the codebase, and read any type definitions or interfaces involved.
4. Feed back the specific error. Give the agent a line like "The test failed with: TypeError: Cannot read property 'id' of undefined at UserService.ts:42" rather than 500 lines of test output when only one test failed.
5. Manage the conversation history. Start a fresh session when you move to a different major feature. Summarize progress when the context gets long ("So far we've completed X, Y, Z. Now working on W."), and compact before critical work if your tool supports it.

The skill presents step 5 as a last resort. Its context budget section is meant to keep you from reaching that point: decide early what to cut, what to protect, and when to compress material instead of dropping it.

Handing off between sessions without losing state

The restartable session boundary is the most concrete procedure in the file. The skill says a fresh session is safe at a completed task boundary, not at an arbitrary token count. Before you leave the current session, it says to persist five things:

1. the accepted scope and decisions, in the spec or plan
2. the current task status and the next pending task
3. the files changed and the working-tree state
4. the exact verification commands and their outcomes
5. unresolved questions, risks and required approvals

Commit the finished task only when the user or the repository workflow authorizes it. Otherwise leave the working tree as it is and write down that the changes are uncommitted.

In the new session, the agent first reads the rules, spec, plan and task status, then checks the actual git status. It re-runs verification when the recorded baseline is missing, when the code has moved, or when the next task depends on it. It should not assume approval from an earlier conversation unless a durable artifact records that approval.

The skill also describes an external harness that exits and restarts sessions automatically between tasks. That harness has to treat the artifacts and repository state as the source of truth, keep human approval gates in place, and tell a completed task apart from a crashed process. The skill defines this handoff contract but leaves process supervision to the harness. For long-term memory across sessions, the persistence here is plain files in the repo, with no separate store.

How it lines up with common context engineering strategies

Many context engineering guides sort techniques into four groups: writing, selecting, compressing and isolating context. This skill covers all four through manual habits and adds no tooling.

• Write: rules files that load in every session, plus the plan, spec and task-status artifacts that a handoff persists.
• Select: the selective include packing strategy, loading one spec section instead of the whole document, and reading only the files a task touches.
• Compress: the hierarchical summary strategy, progress summaries, deliberate compaction, and the budget rule to compress before you drop anything.
• Isolate: fresh sessions per major feature, and the trust ladder, which treats instruction-like text in config, fixtures, external docs or third-party API responses as data to show the user, not commands to follow.

The alternatives listed on this page (context-mode, memsearch, planning-with-files and memU) are separate projects. The difference that matters is whether you want guidance or tooling. If you want a checklist your agent follows in Claude Code, Cursor, Copilot or Codex, this skill is enough on its own. If you want something that stores and retrieves context for you, pick a memory tool and keep this skill for rules-file and handoff discipline.