context-engineering-global

Purpose

Help users maintain a lean, stable, long-term reusable global context layer.

This skill is only responsible for the "globally persistent" layer, not for project-local rules or the temporary context of the current task.

This skill does four things:

1. Review and streamline the existing global rules file
2. Assess whether a candidate rule is truly worth entering the global layer
3. Provide rewrite text and insertion positions that can be directly applied
4. When collaboration friction arises, first determine whether the problem should really land in the global layer

Official standard sources (re-fetch the latest version when needed):

• https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• https://code.claude.com/docs/en/best-practices

Boundaries

Belongs to this skill

• ~/.claude/CLAUDE.md or an equivalent global rules file
• Behavioral constraints that hold stably across tasks, projects, and sessions
• Role settings, output preferences, a small number of high-leverage collaboration rules
• Judgments such as "should this rule go into the global prompt"

Does not belong to this skill

• Repository-level or directory-level AGENTS.md / CLAUDE.md
• Context setup when onboarding a new project
• Which specs, source, tests, and errors the current task should read
• Session compression, module switching, task-level context packing
• Skill false triggers, missed triggers, description and routing fixes

Hand the above problems to context-engineering-project。

Input modes

Users usually trigger this in four ways:

Mode 1: Describe collaboration friction

The user describes a type of long-term, repeatedly occurring unsatisfactory scenario.

Approach:

1. First determine whether the root cause is a global-layer problem, rather than project context, tooling, skills, model capability boundaries, or insufficient information for the current task
2. If it is a global-layer problem, propose specific rule changes
3. If not, clearly point out the layer where it should truly land

Mode 2: Evaluate a change proposal

The user directly provides content they want to write into the global rules file.

Approach:

1. Read the current global rules file
2. Check the proposed content item by item using the evaluation checklist
3. Give a judgment for each item: suitable for global / should go in the project layer / should go in a skill / should be handed to tooling / not needed
4. For content suitable for global, provide the rewritten specific text and insertion position
5. For content that does not belong in global, explain where it should truly land

Mode 3: Review the existing global context

The user does not provide specific content and asks to directly optimize the existing global file.

Approach:

1. Read the current global rules file
2. Review each existing rule item by item using the evaluation checklist
3. Output a review report: keep / streamline / delete / migrate to the project layer or skill, with a reason for each item
4. Provide the complete rewritten global context

Mode 4: Extract from information

The user gives an instruction for you to read files, read conversations, search materials, or summarize friction, and then extract candidate global context content from it.

Approach:

1. Perform the context gathering requested by the user
2. Filter out from the information what may affect the global layer
3. Process according to the evaluation flow of Mode 2

Root cause filtering

Before suggesting "write it into the global prompt", first rule out the following more common real causes:

1. Missing project context — requires a repo-local rules file, spec summary, relevant source code, or error output
2. Rules placed at the wrong layer — clearly a project rule, skill protocol, or tooling check
3. Insufficient information for the current task — the model did not read the files it should have read
4. Model capability boundary — not something that can be fixed by writing one more global rule

Evaluation criteria

For each candidate rule, check in order:

1. Cross-task applicability — does it hold across most tasks? If not, do not put it in the global layer
2. Cross-project applicability — is it independent of a particular repository, tech stack, or team-local convention?
3. Cross-session applicability — is it worth being resident in every conversation? Do not make it resident if it is only effective at a certain stage
4. Non-inferability — can the model infer it on its own from the request, code, or context? What can be inferred does not need to be written
5. Observability — can a violation be seen from the output? Unobservable rules are hard to verify
6. Non-redundancy — is it clearly different from the model's default behavior? Repeating defaults only adds noise
7. Conciseness — is it already the shortest effective wording?
8. Having rationale — does it explain why? Explaining the rationale is usually more effective than piling on MUSTs
9. Non-contradiction — does it conflict with existing global rules?

Official standard reference

Principles for keeping the global rules file concise

Source:https://code.claude.com/docs/en/best-practices

• Treat the rules file as code: review, prune, test
• If deleting a line would not cause the model to make mistakes, delete it
• An overly long global file causes rules to be ignored

Content suitable for the global layer

1. Role setting — a one-sentence role description focused on behavior and tone
2. Clear and direct collaboration rules — constraints on unambiguous, observable behavior
3. Preferences with rationale — explain why, use heavy-handed commands sparingly
4. A small number of output preferences — write them only when the preference clearly differs from the default
5. High-frequency and high-leverage suppressions — for example, the tendency toward over-engineering

Content not suitable for the global layer

1. Specialized workflows — should be put into a skill and loaded on demand
2. Project-specific rules — should be placed at the project level AGENTS.md / CLAUDE.md
3. Task-level context packing — specs, source code, and error output should be provided per task
4. Rules that can be deterministically enforced by tooling — replace with hooks, tests, linters, scripts
5. Over-instruction — no need to pile on CRITICAL/MUST emphasis
6. Redundant rules — content consistent with default behavior is noise
7. Content that can be inferred from the code — architecture, file paths, local code style, etc.

Output requirements

Regardless of which input mode is used, the final output includes:

1. Global-layer determination

For each candidate item, first give a conclusion:

• Enter the global layer
• Do not enter the global layer, and note the actual placement

2. Global context changes

For each change:

• Change type: add / modify / delete
• Change content: the specific rewritten text
• Evaluation basis: which items in the evaluation checklist are cited
• Insertion position: which section of the existing file it should be placed in

3. Non-global suggestions

For each item that does not enter the global layer:

• Which layer it should belong to: project layer / skill / tooling / current task context
• One-sentence reason
• If necessary, give the next minimal action

4. Content not adopted

For each item not adopted, explain the reason.

Execution discipline

• Read the existing global files before making suggestions; do not write from thin air
• Global context is extremely precious; better to have one fewer item than one too many
• First rule out project context and tooling-layer issues, then decide whether to modify the global layer
• Do not repeat the model's default behavior
• Explain why, rather than shouting MUST in uppercase letters
• Changes should be specific enough to be directly applied as text; do not give only abstract suggestions