ensure-quality
Local quality gate for the current worktree: review for risk/correctness (break, leak, undo intent), standards, spec, and anti-slop; then test, document, lint. Mechanical one-liner auto-fix and HITL for ask-user findings; ship-readiness summary. Use when the user asks to ensure quality, run the quality gate, validate before commit, or gate changes; after finishing substantive or AI-generated code changes; and always before the agent commits. For commit plus pull request, use to-quality-pr instead (it runs this gate first).
- License 许可
- GPL-2.0
- 所属仓库
- gambitph/Cimo
- 最近更新
- 2026-10-15
- Stars
- ★ 2
- Forks
- 0
01 前言 Front Matter
- name
- ensure-quality
- description
- Local quality gate for the current worktree: review for risk/correctness (break, leak, undo intent), standards, spec, and anti-slop; then test, document, lint. Mechanical one-liner auto-fix and HITL for ask-user findings; ship-readiness summary. Use when the user asks to ensure quality, run the quality gate, validate before commit, or gate changes; after finishing substantive or AI-generated code changes; and always before the agent commits. For commit plus pull request, use to-quality-pr instead (it runs this gate first).
02 资源文件 11
- 参考文档agents/openai.yaml111 B
- 参考文档reference/anti-slop.md4.7 KB
- 参考文档reference/discover.md3.9 KB
- 参考文档reference/findings.md2.7 KB
- 参考文档reference/smells.md2.2 KB
- 参考文档references/01-reader-prompt.md616 B
- 参考文档references/04-disclosure-block.md626 B
- 参考文档stages/document.md1.3 KB
- 参考文档stages/lint.md888 B
- 参考文档stages/review.md7.8 KB
- 参考文档stages/test.md2.5 KB
03 SKILL.md 正文
Ensure quality
Inner-loop quality gate: risk/correctness review plus anti-AI-slop.
Asks whether the change will break, leak, or silently undo what the user wanted, and catches parallel structure, hand-synced catalogues, phantom names, and other common agent failure modes early.
Moves review, test, docs, and lint closer to the work before it leaves the machine.
No daemon, no second worktree, no push/PR - this skill is the gate.
To gate then commit and open a triage PR, use to-quality-pr.
Self-contained: everything needed lives under this skill folder. Project-agnostic: discover how this repo tests, lints, documents, and states maintainability rules - do not assume a stack.
Stages (order): review → test → document → lint.
Load each stage file only when that stage runs.
Load reference/discover.md once during preconditions.
Anti-slop baseline: reference/anti-slop.md (always on during review; repo rules override on conflict).
When to run
Fire this skill when any of these hold:
- The user asks to ensure quality / validate / gate / check before commit.
- You just finished substantive source changes (feature, fix, refactor).
- You are about to create a git commit (local only). If the next step is also a pull request, invoke
to-quality-prinstead.
Skip auto-invoke for pure Q&A, exploration with no edits, or when the user said to keep iterating without gating.
Preconditions
- Synthesize intent. Capture what the user set out to accomplish - goal, constraints, tradeoffs, ruled-in/out approaches - in their terms, enriched with decisions you made while working. A thin "fixed stuff" line is not enough; rewrite from conversation context first. This intent is authoritative acceptance criteria for the review stage.
- Discover the project. Follow
reference/discover.md. Record the chosen test commands, lint commands, standards sources, anti-slop / maintainability docs, checklists, and doc surfaces for this run. - Pin the fixed point. Default: merge-base of the current
HEAD(and dirty worktree) against the first existing of: upstream tracking remote's default branch, thenorigin/develop,origin/main,origin/master, then localdevelop/main/master. Honor an explicit user override (since abc123,origin/main, …). Confirm the ref resolves. - Scope the diff. Include committed commits since the fixed point and uncommitted/staged work. Warn if on a default branch; still proceed.
- Skip flags. Run all four stages unless the user explicitly skips one (
skip lint,lint only, …). Auto-invoke never skips.
Completion: intent written, discovery recorded, fixed point named, diff non-empty (or report ready with nothing to gate and stop).
Pipeline loop
For each stage in order:
- Read
stages/<stage>.mdand run it. - Collect findings using the taxonomy in
reference/findings.md. - Auto-fix every
auto-fixfinding without asking, then re-run the stage. Cap at 2 auto-fix rounds for that stage; leftover findings escalate to HITL.- Review stage:
auto-fixis mechanical one-liners only. After any review fix, follow the root-cause fixer rules and adversarial re-review instages/review.md(treat fixer output as untrusted new code). - Test / document / lint: mechanical/low-risk auto-fix as each stage file allows.
- Review stage:
- If any
ask-userfindings remain, pause - see HITL pause. Do not start the next stage until the pause resolves. no-opfindings are reported only; nothing to do.- If the stage stays red after rounds / declined fixes, go to Blocked.
Leave all quality fixes uncommitted unless the user already asked you to commit or ship.
HITL pause
Batch every current-stage ask-user finding in one message.
Present each like a grill round - question, options, recommendation - then wait.
When review recorded risk_level: high, prefer recommending careful fix over casual approve/skip.
⏸ **Quality gate - <stage>** (<n> ask-user findings)
❓ **F1** - **<short title>**: <verbatim finding: file, description, why it challenges intent or product behavior>
Options:
- **fix** - apply a fix (optionally with your guidance)
- **approve** - accept as-is and continue
- **skip** - drop this finding for this run
- **abort** - stop the whole gate
➡️ <your recommended option and one-line why>
Translate the user's answers into actions, apply agreed fixes, re-run the stage, then continue.
For review-stage fixes agreed in HITL, still apply fixer discipline and adversarial re-review from stages/review.md.
Do not paraphrase away finding detail.
Do not continue past unresolved ask-user findings.
Blocked
Stop the pipeline. Leave fixes dirty. Emit the Summary with Ship readiness: blocked and the remaining findings. Do not commit. Do not claim green. Do not silently skip the failing stage.
Summary
Always end a completed or blocked run with this fixed brief (this order):
- Intent - short paragraph
- Risk - Low / Med / High + one sentence why (use the review-stage risk assessment when review ran)
- Diff scope - fixed point → worktree; key files
- Findings - counts by stage; call out risk-lens and anti-slop hits; auto-fixed vs HITL vs accepted vs remaining
- Tests run - commands + pass/fail; note skipped suites and why
- Docs - updated / checked / none needed
- Lint - commands + result
- Ship readiness -
readyorblocked+ what's left - Uncommitted fix set - bullets if any quality fixes were applied
04 同仓库更多 Skills
writing-for-agents
Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.
wp-rest-api
Use when building, extending, or debugging WordPress REST API endpoints/routes: register_rest_route, WP_REST_Controller/controller classes, schema/argument validation, permission_callback/authentication, response shaping, register_rest_field/register_meta, or exposing CPTs/taxonomies via show_in_rest.
wp-project-triage
Use when you need a deterministic inspection of a WordPress repository (plugin/theme/block theme/WP core/Gutenberg/full site) including tooling/tests/version hints, and a structured JSON report to guide workflows and guardrails.
wp-plugin-directory-guidelines
Use when reviewing WordPress plugins for GPL compliance, checking license headers or compatibility, evaluating upsell/freemium/trialware patterns, validating plugin naming or trademark rules, checking plugin slugs, understanding why a plugin was rejected from WordPress.org, or answering any question about the 18 WordPress.org Plugin Directory guidelines — even if the user doesn't mention 'guidelines' explicitly.
wp-plugin-development
Use when developing WordPress plugins: architecture and hooks, activation/deactivation/uninstall, admin UI and Settings API, data storage, cron/tasks, security (nonces/capabilities/sanitization/escaping), and release packaging.
wp-performance
Use when investigating or improving WordPress performance (backend-only agent): profiling and measurement (WP-CLI profile/doctor, Server-Timing, Query Monitor via REST headers), database/query optimization, autoloaded options, object caching, cron, HTTP API calls, and safe verification.