القائمة
Run only the first-principles analysis lens from the improve workflow on a target file, directory, or glob, producing read-only findings without applying edits.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Review-first aggressive code simplification for a target file, directory, or glob, producing numbered findings and applying only user-selected changes.
Ask the other coding agent (Claude ↔ Codex) to review the relevant changes
Split a multi-finding worktree into per-finding commits via non-interactive `git add -p`. Use when an `/improve` or `/review` pass has edited several distinct findings into the worktree together and they need to land as separate commits. Refuses to run on secret-rendering templates.
Run only the prior-art and convention lens from the improve workflow on a target file, directory, or glob, producing read-only findings based on mature implementations and local sibling patterns.
Run only the security and threat-model lens from the improve workflow on a target file, directory, or glob, producing read-only adversarial findings.
Run only the radical-simplification lens from the improve workflow on a target file, directory, or glob, producing read-only findings about subtractive or restructuring improvements.
| name | improve-analysis |
| description | Run only the first-principles analysis lens from the improve workflow on a target file, directory, or glob, producing read-only findings without applying edits. |
Read ../improve/references/target-and-agent-contract.md first.
When called directly, resolve the target and build the context brief from the shared contract. When called by $improve, use the provided target paths, usage scenarios, target summary, test-file flag, and optional <user_note>.
Stay read-only. Return findings using the unified return contract.
Analyze the target from first principles. Do not assume AGENTS.md, CLAUDE.md, README files, or other documentation has the right answer. Read the code and judge it directly.
Mentally walk the usage scenarios. Look for gaps that surface against real use: unsupported invocation shapes, ambiguous output, untreated user input flowing into templates, awkward parameter ergonomics, missing extension points, undocumented load-bearing assumptions, and missing or weak tests where tests are warranted.
Stay in this lane:
For test targets, use two lenses:
The target is primary, but proposed changes may touch callers, tests, or sibling files when the finding requires it or repository consistency calls for it. Do not propose stylistic preference alone; every change needs a concrete correctness, complexity, security, ergonomics, consistency, or readability reason.
