When to use
Use this for quick validation while a change is still in progress, or when asked to inspect intermediate local changes.
This is a lightweight local correctness pass, not a formal PR review. It is intended for:
- Build agents validating their own non-trivial work
- Plan/read-only agents inspecting intermediate user changes
- Review agents adding a secondary local correctness pass
Scope
Focus on touched code and nearby paths needed to assess local correctness. Use loaded domain skills only where they apply to the inspected change:
- spelling, naming, and obvious consistency mistakes
- suspicious conditionals, branches, or data flow
- missed edge cases or incomplete state handling
- missing error handling or cleanup
- incomplete propagation within the touched path
- obvious local test gaps or weak assertions
Do not broaden into architecture, abstraction boundaries, API shape, test strategy, merge risk, or PR-readiness. Leave formal review judgment to the review agent.
Lifecycle
- Trigger: confirm this is a quick validation of in-progress local changes, intermediate user changes, or a secondary local correctness pass.
- Domain skill routing: identify the primary language, framework, runtime, or domain of the touched files.
- Domain skill loading: before inspecting, load every relevant domain-specific skill that exists.
Examples: load
go-code for Go files and Go packages; load shell-code for shell scripts.
- Inspection: use this skill for the lightweight local correctness workflow, and use loaded domain skills as focused checklists for domain-specific issues.
- Scope control: check only the touched code and directly relevant local paths needed to assess local correctness.
- Feedback: report findings that materially affect correctness, confidence, maintainability, or the next implementation step.
- No edits: do not make code changes unless explicitly asked.
Domain skills are additive to change-inspection; they do not replace this inspection workflow. If multiple domains are materially touched, load each relevant domain skill.
Output
- Change summary
- Inspection findings
- Suggested fixes and improvements, if any
1---2name: change-inspection3description: Inspect in-progress local changes for quick correctness, edge-case, error-handling, and consistency feedback.4---56# When to use78Use this for quick validation while a change is still in progress, or when asked to inspect intermediate local changes.910This is a lightweight local correctness pass, not a formal PR review. It is intended for:11- Build agents validating their own non-trivial work12- Plan/read-only agents inspecting intermediate user changes13- Review agents adding a secondary local correctness pass1415# Scope1617Focus on touched code and nearby paths needed to assess local correctness. Use loaded domain skills only where they apply to the inspected change:18- spelling, naming, and obvious consistency mistakes19- suspicious conditionals, branches, or data flow20- missed edge cases or incomplete state handling21- missing error handling or cleanup22- incomplete propagation within the touched path23- obvious local test gaps or weak assertions2425Do not broaden into architecture, abstraction boundaries, API shape, test strategy, merge risk, or PR-readiness. Leave formal review judgment to the review agent.2627# Lifecycle28291. Trigger: confirm this is a quick validation of in-progress local changes, intermediate user changes, or a secondary local correctness pass.302. Domain skill routing: identify the primary language, framework, runtime, or domain of the touched files.313. Domain skill loading: before inspecting, load every relevant domain-specific skill that exists.32 Examples: load `go-code` for Go files and Go packages; load `shell-code` for shell scripts.334. Inspection: use this skill for the lightweight local correctness workflow, and use loaded domain skills as focused checklists for domain-specific issues.345. Scope control: check only the touched code and directly relevant local paths needed to assess local correctness.356. Feedback: report findings that materially affect correctness, confidence, maintainability, or the next implementation step.367. No edits: do not make code changes unless explicitly asked.3738Domain skills are additive to `change-inspection`; they do not replace this inspection workflow. If multiple domains are materially touched, load each relevant domain skill.3940# Output4142- Change summary43- Inspection findings44- Suggested fixes and improvements, if any
alesker