Reduce changes on your own branch before opening or updating a pull request. Review added architecture and tests, remove unnecessary complexity, and verify that the smaller change still fixes the original problem and preserves supported behavior.
Simplify your own change to its smallest complete fix. Use before opening a PR, before pushing large repairs to one, or when asked to shrink a PR or clean up slop.
Review changes on your own branch and reduce them to the smallest fix that meets the goal. The skill compares the request with the complete diff, removing unnecessary state management, wrappers that only forward calls, and duplicate implementations. It also checks the specific failure each added or modified test catches, retaining tests for necessary boundaries.
Use it before opening a PR or after adding substantial repairs. If the change has grown too large, it identifies a coherent part that can be integrated first. Leaving the code unchanged is also a valid result when the existing structure has a reason to remain.
The work follows the AGENTS.md rules that apply to the affected files and the scope of changes authorized by the request. A review-only request produces findings without edits. This is a step before review and does not replace review. After simplifying, it runs reproduction steps or focused validation. Publication and merging follow the existing workflow.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.
The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 19, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
An editing pass by the change's author: run it on your own branch before you open the PR, and again before you push large repairs. It precedes review and never replaces it. Inherit the task's scope and repair authority; a review-only request gets findings instead of edits. The chosen maintainer workflow owns publication, review and merge.
The diff is a proposal. Passing tests show it works, not that its architecture or every added test is needed.
Rules: the root AGENTS.md sections "Design priorities", "One owner, complete cutover", "Runtime and code safeguards" and "Product and validation", plus the nearest scoped AGENTS.md. Steps 2 and 3 apply every rule to every changed file.
Read the user's outcome and latest scope, the complete diff against the target merge base, and retained proof. Reuse session context already gathered. Then ask:
Starting from the base, what is the smallest complete fix using the owners already present? Would I still introduce this architecture?
Inspect the largest added modules, state, adapters and test scaffolding first. Read their direct callers and relevant history: apparently redundant behavior may protect a shipped configuration or an earlier regression. Scope is the changed system and the paths it replaces.
Trace every changed hunk to the stated outcome. A hunk that serves another goal leaves this change: drop it or move it to its own PR.
Count the non-mechanical changed lines. Above about 800, or about 500 for complex logic, name the smallest coherent stage that can land first and cut the change to that stage.
Done when you can state the defect, the required invariant, and the smallest complete fix in one sentence each, and every remaining hunk serves that fix.
Apply each supported simplification in the diff:
try/catch blocks that match the surrounding module and guard real states;as any, as unknown as T, widen-then-assert);Preserve the requested fix and supported behavior, not the proposal's accidental design. Keep real domain differences and justified public compatibility. When history (git log -p -S <symbol>) leaves a path's purpose unclear, keep it and report it. Report new product decisions, breaking contracts, unrelated cleanup and destructive branch replacement as findings for the owner.
For each added or changed test group and its setup helpers, name the distinct observable failure it catches.
Keep regressions for the actual defect and distinct boundaries: ordering, cancellation, stale authority, restart, rejection, real errors and affected consumer differences. Keep static contract guards that independently protect a real boundary. Remove duplicate same-path cases, mock echoes, incidental field-copy or wording assertions, assertions on statically defined values, tests that only prove removed logic is gone, tests of obsolete implementations, and scaffolding or test-only production hooks. Consolidate useful cases in an existing owner suite.
Removing tests never weakens the assertions, coverage of real boundaries or baselines that remain.
Done when every remaining test group has a named failure.
Batch the edits, then rerun the reproduction and focused checks for the changed contracts and affected consumers. Reuse proof whose inputs are unchanged. A preserved restart, upgrade or transport claim needs applicable proof. The existing workflow selects broader checks.
Done when the complete diff is inspected, every rule has a verdict for each changed file, supported simplifications are applied, superseded paths are unreachable and affected behavior still has proof. No change is a valid result when the existing shape is justified. Aim for net-negative code, not a deletion quota.
Report in the PR body or existing task evidence: the responsibility or machinery that disappeared, the behavior still protected, and production/test deltas against the merge base. Label a reduction against an earlier revision separately from the whole-change delta. Name any necessary remaining growth or unresolved decision.
Then open or update the PR. After later repairs, simplify only the new changes and the owners they touch before pushing them.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Set up and authenticate the 1Password CLI, then supply stored passwords and API keys to commands or configuration. The skill covers desktop integration, service accounts, and interactive sign-in while keeping secrets out of chat and logs.
Route requests from OpenClaw to external coding agents such as Claude Code or Cursor. Start or continue sessions using ACP, a protocol for connecting agents, or relay prompts directly through acpx while preserving conversation context.
Add a model provider to OpenClaw and verify it with a real response. The skill validates configuration, keeps credentials in environment or file references, and reports test results and any default model changes.
Prepare an agent activity transcript for a GitHub pull request or issue. Extract relevant prompts, decisions, and results from local logs, remove sensitive material, and preview the edited record before separately authorized publication.
Manage Apple Notes on macOS through memo, a command-line tool. Create, browse, search, edit, delete, and move notes between folders, or export selected notes to HTML or Markdown for use outside the app.
Manage Apple Reminders from your Mac with remindctl, a terminal tool. View tasks by date, add or edit reminders, organize lists, and mark tasks complete or delete them, including personal to-dos that sync to iOS.