<objective> Apply Robert C. Martin's Clean Code principles to make code readable, maintainable, and clean. Two modes: audit existing code (review) or guide code writing (guide). </objective>

<prime_directive> READABILITY AND SIMPLICITY ALWAYS WIN.

Clean Code rules are tools, not dogma. If strictly applying a rule makes the code harder to understand, less simple, or more complex overall — DO NOT apply it.

Before applying any rule, ask: "Does this change make the code easier to understand for the next developer?" If the answer is NO or UNCERTAIN → skip the change, explain why.

Examples where NOT to apply Clean Code blindly:

Extracting a 3-line helper function that will only ever be called once → adds indirection without clarity
Renaming a well-understood abbreviation (url, id, i) to a verbose name → noise, not clarity
Splitting a simple 25-line function that reads naturally as a single block → fragmentation hurts comprehension
Applying polymorphism to a switch with 2 cases that will never grow → over-engineering
Extracting a boolean condition into a named function when the condition is already obvious

The goal is a codebase that any developer can read fluently. Rules serve that goal — not the other way around. </prime_directive>

<objective> Apply Robert C. Martin's Clean Code principles to make code readable, maintainable, and clean. Two modes: audit existing code (review) or guide code writing (guide). </objective>

<prime_directive> READABILITY AND SIMPLICITY ALWAYS WIN.

Clean Code rules are tools, not dogma. If strictly applying a rule makes the code harder to understand, less simple, or more complex overall — DO NOT apply it.

Before applying any rule, ask: "Does this change make the code easier to understand for the next developer?" If the answer is NO or UNCERTAIN → skip the change, explain why.

Examples where NOT to apply Clean Code blindly:

Extracting a 3-line helper function that will only ever be called once → adds indirection without clarity
Renaming a well-understood abbreviation (url, id, i) to a verbose name → noise, not clarity
Splitting a simple 25-line function that reads naturally as a single block → fragmentation hurts comprehension
Applying polymorphism to a switch with 2 cases that will never grow → over-engineering
Extracting a boolean condition into a named function when the condition is already obvious

The goal is a codebase that any developer can read fluently. Rules serve that goal — not the other way around. </prime_directive>

Flag	Description
`-a`	Auto mode: apply all fixes without confirmation
`-e`	Economy mode: no subagents, direct tools only
`-r`	Report only: produce the report without applying fixes
`--guide`	Guide mode: load principles to guide code writing

Variable	Type	Description
`{target}`	string	File, feature or folder to analyze
`{auto_mode}`	boolean	`-a`: apply without confirmation
`{economy_mode}`	boolean	`-e`: no subagents
`{report_only}`	boolean	`-r`: report only, no fixes
`{guide_mode}`	boolean	`--guide`: writing mode

Step	File	Purpose
01	`steps/step-01-analyze.md`	Read code, identify violations
02	`steps/step-02-fix.md`	Apply corrections

Clean Code

Clean Code

REVIEW mode (default)

GUIDE mode (`--guide`)

Openclaw Release Maintainer

Verify

Flow

Fix

Hygiene

Add Policy

Clean Code

Clean Code

REVIEW mode (default)

GUIDE mode (--guide)

Openclaw Release Maintainer

Verify

Flow

Fix

Hygiene

Add Policy

GUIDE mode (`--guide`)