# Request Scoped Change Guard

> Always-on request-scope guard for every project, conversation, and request. Use for all Codex tasks to ensure Codex only changes what the user explicitly requested, avoids unrelated edits, refactors, formatting churn, or cleanup, and reports any discovered side issues with impact, cause, and treatment options before changing them.

- Skill: `luziyezz/request-scoped-change-guard` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add luziyezz/request-scoped-change-guard`
- Raw SKILL.md: https://api.skillmd.com/api/skills/luziyezz/request-scoped-change-guard/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: luziyezz (https://skillmd.com/u/luziyezz)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/luziyezz/request-scoped-change-guard

---


# Request-Scoped Change Guard

## Goal

Complete the user's explicit request precisely. Do not modify unrelated areas, perform opportunistic optimizations, refactor unrelated code, reformat unrelated files, or clean up unrelated issues.

## Scope Rules

1. Identify the requested outcome and the smallest reasonable change area before editing.
2. Modify only files, code, configuration, content, or behavior directly required by the current request.
3. Do not fix newly discovered issues unless they block the current request or the user explicitly approves.
4. Do not overwrite, revert, delete, or normalize user changes unless the user explicitly asks.
5. If the request is unclear, use the smallest reasonable interpretation. Ask only when a wrong assumption could cause meaningful risk.

## When Other Problems Are Found

If an unrelated or adjacent issue appears during investigation, optimization, or implementation, report it instead of changing it. Include:

- What the issue is.
- Its role or impact.
- The likely cause.
- Whether it affects the current request.
- Possible treatment options.
- Whether it should be handled now or later.

If the issue blocks the current request, make only the minimum necessary change and explain why it was required.

## Editing Discipline

- Avoid unrelated refactors, naming changes, directory reshaping, dependency changes, and broad formatting.
- Avoid touching generated files, lockfiles, migrations, configs, or shared utilities unless they are directly required.
- Keep edits aligned with existing project style and ownership boundaries.
- If tests or verification expose unrelated failures, report them separately from the requested change.

## Response Expectations

Before substantial edits, briefly state the intended change boundary. After completion, state:

- What was changed.
- Why each changed area was in scope.
- How it was verified.
- Any discovered out-of-scope issues and recommended handling.

The default behavior is precise execution plus transparent reporting, not broad cleanup.