skills/context-engineering/SKILL.md
Route durable rules and context to the right layer — task, project, skill, tooling, hooks, MCP, or global — and produce the smallest directly applicable edit. Use for global rules files (~/.claude/CLAUDE.md, global AGENTS.md), repo-local AGENTS.md/CLAUDE.md, task context packs, hook placement (Codex/Claude Code settings.json), collaboration friction diagnosis, and rule-placement decisions.
npx skillsauth add plimeor/agent-skills context-engineeringInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Place every durable rule or context fragment at the lowest layer that holds it — task < project < skill / tooling / hooks / MCP < global — and produce the smallest directly applicable edit. Preserve the user's requested artifact and boundary; do not edit adjacent layers without authorization.
For "do/check/inject X on event Y" behaviors (pre/post tool, prompt-submit, stop, session-start), route to hooks in settings.json — the harness executes hooks; text-layer rules only describe behavior and the model may skip them.
Reject rules that are task-local, already enforceable by lint/test/CI/hooks, duplicate model defaults, or describe a specialized workflow that belongs in a skill. Use absolute words (must, never, always, only) only for safety, irreversible actions, exact output contracts, or tool syntax.
Read the target artifact first — the rules file, candidate text, or friction evidence. When asserting a project convention, cite one existing file or command. Fetch external prompt guidance only when the user asks to align with it. Stop reading once classification and edit text are supported.
Omit empty sections. Stop once classification, edit text, and routing are clear. Ask one narrow question only when missing information would change the layer, authorization boundary, or artifact.
tools
Decide whether and how to use authorized sub-agents, then coordinate delegated work while preserving the main agent's context. Use when the user asks for orchestration, parallel agents, delegation, background workers, context isolation, or when another skill needs delegated research, review, implementation, or verification. Owns host-policy checks, delegation packets, non-overlap, report verification, and stop rules. Do not use to bypass tool policy, infer user authorization, or add coordination overhead to simple single-threaded tasks.
development
Use before finalizing a non-trivial answer, recommendation, review, or decision to reconsider it and raise its quality, especially when shallow reasoning, context inertia, false framing, overconfidence, unfit analogy transfer, or an obvious-but-missed defect could distort the result. Trigger especially before applying external evidence, familiar frameworks, or comparisons to the user's specific request, and when the user asks to reconsider, double-check, take a second look, or sanity-check an answer. Reconsider the draft against its most likely failure mode, and use independent scrutiny only when it is useful and authorized.
development
Review concrete code plan drafts, specs, diffs, and implementation shapes. Use for code-review requests, serious code-plan design critique, and judging whether a proposed direction is sound. Prioritize solution direction, premise validity, logic chain, constraints, alternatives, design shape, contracts, tests, local fit, and actionable findings. Near miss: use code-plan to create or revise plans; use code-scope-gate for pre-spec scope shaping.
development
Write evidence-backed coding plans for implementation, debugging, refactoring, migrations, design parity work, and long-running agent tasks. Use when defining, clarifying, refining, or validating a development plan, /goal prompt, implementation approach, scope and non-goals, work sequence, acceptance criteria, regression evidence, verification strategy, or stop condition. Near miss: use code-review when judging an existing diff, spec, or already drafted plan rather than drafting or revising a plan. Also use when the user says `design twice` after a plan and wants an APOSD-style second-design pass over the completed plan.