Clean Code

Plugin clean-code in shashank-sn/clean-code. Commands read from the repo's manifest — 1 month ago.

Skills (31)

• clean-arena

  Run a bounded competing-design workflow with independently reasoned options, structured comparison, and a revision-bound decision record. Use for consequential design choices; do not invoke for routine fixes.

• clean-audit

  Produce an immutable, revision-bound release receipt from deterministic verification, independent test planning, review, human spot checks, policy identity, exceptions, and evidence hashes. Use before release or merge, when handing work to another team, or when a durable record of checked and unchec

• clean-auditor

  Produce the immutable release receipt mapping requirements to evidence, decoupled from implementers so it cannot self-whitewash. Use for release qualification, final evidence reconciliation, and audit receipt generation.

• clean-brainstorm

  Explore vague product ideas into a requirements-only plan with scope boundaries, acceptance signals, and explicit non-goals. Use before clean-plan when behavior, users, or success criteria are still open.

• clean-build

  Implement one bounded behavior through short, verified steps while protecting requirements, architecture policy, repository conventions, and unrelated code. Use when adding a feature, fixing a bug, changing behavior, or continuing an implementation from an approved design and test plan.

• clean-compound

  Document a solved problem as durable repo learning under docs/solutions and update CONCEPTS.md vocabulary when present. Use after shipping or fixing something worth remembering.

• clean-debug

  Diagnose bugs and failing behavior with causal-chain discipline before fixing. Use for errors, regressions, failed tests, or stuck investigations after a bad fix.

• clean-design

  Turn requirements into use cases, stable policy boundaries, delivery and data boundaries, dependency direction, acceptance examples, and repository-owned architecture constraints. Use before implementing a feature, when splitting components, when a change crosses framework or vendor boundaries, or w

• clean-discover

  Inspect a repository read-only to identify languages, project metadata, configuration, and available paths for deterministic quality checks.

• clean-dispatcher

  Dispatch implementation, test-writing, review, and audit to their dedicated sub-agents with bounded ownership and isolated contexts, preserving clean-orchestrate as the authority on role assignment. Use for multi-part coding work requiring structural independence.

• clean-eval-discover

  Turn real work outcomes and bounded human judgment into representative, reviewable evaluation candidates. Use when escaped defects, rejected outputs, human edits, review outcomes, or correct silence may reveal a repeatable quality signal; discover and calibrate candidates without approving, activati

• clean-learn

  Turn confirmed defects, false positives, accepted changes, review outcomes, and benchmark results into reversible policy, threshold, adapter, convention, or calibration proposals. Use after an audit or repeated outcome reveals a useful local rule change; keep every proposal separate from execution a

• clean-lfg

  Run the full autonomous shipping pipeline from planning through implementation, simplification, dead-code pruning, final verification, review, ship, and CI watch. Use only when the user wants end-to-end delivery to an open PR without step-by-step check-ins.

• clean-merge-resolver

  Resolve an in-progress git merge or rebase conflict hunk by hunk, tracing each resolution to both sides' primary sources, then finish the operation. Never abort. Use when git reports conflict or unmerged paths.

• clean-orchestrate

  Coordinate specification, implementation, independent testing, deterministic verification, review, human spot checks, and audit without treating agent narration as proof. Use for multi-part coding work, release qualification, agent collaboration, or any change where correlated mistakes and stale evi

• clean-plan

  Enrich a requirements-only plan into an implementation-ready plan with units, verification contract, files, dependencies, and definition of done. Use after clean-brainstorm or when a feature needs structured breakdown before build.

• clean-probe

  Plan and run adversarial acceptance probes after implementation for medium/high-risk work before claiming success. Distinguishes primary acceptance from post-hoc diagnostics and feeds failures into a bounded repair/reverify loop.

• clean-prune

  Delete dead, unreachable, and leftover code from the change set, with a recorded reference search behind every deletion. Use after implementation and simplification, before final verification and review.

• clean-refactor

  Improve names, functions, duplication, responsibility placement, dependency direction, boundaries, and module structure through behavior-preserving changes. Use when code works but is hard to change, a new case exposes a missing abstraction, metrics identify review pressure, or architecture dependen

• clean-review

  Review code, requirements, architecture, tests, and deterministic evidence with concrete findings, structural simplification, and permission to return zero findings. Use after implementation and final verification, during pull-request review, when interpreting metric or tool output, or when checking

• clean-reviewer

  Review a diff against repo standards and the originating spec with evidence-backed findings, in an isolated context where the change author is not the approver. Use after final verification, during pull-request review, or any time an independent reviewer is required.

• clean-route

  Select a bounded adaptive workflow shape from task signals without choosing models by brand or writing host config. Use at the start of consequential engineering work when change type, risk, ambiguity, boundaries, evidence needs, or host capabilities should drive playbook selection.

• clean-setup

  Detect a coding host's capabilities and select a native or generic Clean Code integration without changing repository quality policy.

• clean-ship

  Commit, push, and open a pull request with a plain-English, human-readable description tied to requirements and evidence. Use when implementation is verified and ready to ship, or when asked to open or update a PR.

• clean-show-me

  Explain the current software topic with the smallest useful visual, including pseudocode, code-shape sketches, Mermaid diagrams, diffs, or a focused HTML artifact.

• clean-simplify

  Simplify recently changed code for clarity and reuse while preserving behavior and structure pins from the plan. Use after implementation before pruning and review.

• clean-test-writer

  Author independent unit, acceptance, integration, and UI/QA test tracks from requirements and public contracts, withholding implementation details where feasible so tests cannot mirror implementation mistakes. Use when tests must be decoupled from the code that implements the behavior.

• clean-test

  Derive independent unit, acceptance, integration or contract, and UI/QA evidence from requirements and public behavior. Use when planning tests, implementing a feature or bug fix, reviewing test quality, creating Gherkin examples, writing user-interaction procedures, or checking whether implementati

• clean-verify

  Run repository-declared deterministic checks, enforce trusted execution policy, validate required output artifacts, and preserve revision-bound evidence. Use after implementation or refactoring, before claiming completion, during code review, and in local IDE terminals, coding-agent platforms, CLI s

• clean-watch-pr

  Watch an open pull request until CI is green or a blocker is identified. Use after clean-ship when automated checks must pass before merge.

• clean-worktree

  Create or attach an isolated git worktree for parallel or focused work. Use before large features or when the default branch must stay clean.