AGENT SKILL

audit-and-fix

Run an audit-then-implement pipeline: produce an audit, cluster findings into PR-sized chunks, and spawn parallel subagents to implement fixes as draft PRs. Triggers on: "audit and fix", "clean up domain", "overnight cleanup".

License 许可
MIT
最近更新
2026-10-26
Stars
★ 0
Forks
0

01 前言 Front Matter

name
audit-and-fix
description
Run an audit-then-implement pipeline: produce an audit, cluster findings into PR-sized chunks, and spawn parallel subagents to implement fixes as draft PRs. Triggers on: "audit and fix", "clean up domain", "overnight cleanup".
argument-hint
[domain]

03 SKILL.md 正文

Run a long-horizon audit-then-implement pipeline: produce a structured audit, cluster findings into PR-sized chunks, and spawn parallel subagents to implement fixes as draft PRs.

Trigger: when the user asks for "audit and fix", wants to clean up a domain, or kicks off an overnight cleanup run. Also triggered directly via /audit-and-fix <domain>.

Arguments: $ARGUMENTS — the audit domain (e.g. "hardcoded business logic", "unused exports in moneyballer/pkg/db", "deprecated Storage API calls"). Required — if empty, ask the user.

Steps

  1. Run the audit. Invoke the /create-audit skill. This produces docs/audits/<topic-slug>-<YYYY-MM-DD>.md with Findings and Issues tables. Commit the audit file on a new branch audit/<topic-slug>-<date> and push.

  2. Cluster findings into PR groups. Read the audit's Issues table and group findings by:

    • Same file or package → same cluster
    • Same severity AND same fix pattern → same cluster
    • Cross-cutting infra changes (test harness, CI config) → their own cluster

    Produce 4–8 clusters, not 30 single-finding PRs. Each cluster is one PR. Print the clustering plan as a table before dispatching:

    Cluster Findings Blast Radius Recommended Title
    1 3 low "Remove unused exports in pkg/db"
  3. Initialize the status file.

    # Audit-and-Fix Status — <topic> — <YYYY-MM-DD>
    
    Audit: docs/audits/<topic-slug>-<date>.md
    
    | Cluster | PR  | Branch | State   | Last Update |
    | ------- | --- | ------ | ------- | ----------- |
    | 1       | —   | —      | pending | <timestamp> |
    

    Write to docs/audits/<topic-slug>-<date>-status.md.

  4. Dispatch parallel cluster implementers. Use the Agent tool with subagent_type: "general-purpose" in a single message with multiple tool calls — one agent per cluster, cap at 6 concurrent. Each subagent receives:

    • The audit file path and the specific findings in its cluster
    • Instructions: create a worktree off main, implement the fixes, write or update tests, open a draft PR with required sections (Summary, Test plan, Spec ID if applicable), wait for CI, address Copilot comments autonomously
    • A strict rule: never merge. Leave the PR as draft when done.
    • Required output: {cluster, pr_url, branch, final_state} where final_state ∈ {ready, ci-failing, review-pending, blocked}
  5. Monitor and update the status file every 5 minutes while subagents run. For each cluster, record: PR URL, branch, current state, last-update timestamp. If a subagent fails (worktree disappears, CI times out), mark its cluster blocked and record the reason rather than retrying silently.

  6. Post the final summary table when all clusters reach ready or blocked:

    Cluster PR State Notes
    1 #201 ready 0 Copilot comments
    2 #202 blocked rebase conflict on pkg/foo.go

    Do not merge. The user decides which PRs to merge (use /merge-pr per PR).

Rules

  • Never merge. This command produces draft PRs only.
  • Never force-push. Never use destructive git operations in subagents.
  • If a worktree path disappears mid-run, recreate it — do not fail the whole run.
  • Cap parallelism at 6 concurrent subagents. Batch the rest.
  • Every draft PR must include the audit file path in its Summary section so reviewers can trace the finding.
  • Keep the status file updated even on failures — silence is worse than partial information.
  • If clustering produces more than 8 PRs, STOP and ask the user to narrow the audit scope.

Compute scope

The Frontier floor describes the coordinator's consumer requirement. Native skill frontmatter does not enforce that floor. Keep the existing general-purpose worker dispatch, inheritance, tools, worktrees and draft-only merge prohibition. This declaration adds no enforced worker-floor guarantee and does not set a worker's model or effort. Report coordinator and worker observations separately when they are available; an unavailable observation remains unknown.

04 同仓库更多 Skills

kaiohenricunha
kaiohenricunha/dotbabel

yolo

Start temporary autonomy for the current task or an explicit scope with a required --for expiry. Codex permits scoped pushes, merges, deploys, and releases after strict testing and validation; Full access is a separate runtime setting. Claude Code uses a session permission hook with a protected-action denylist.

开发工程师
★ 0
kaiohenricunha
kaiohenricunha/dotbabel

veracity-audit

Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace <label> (single source end-to-end). Invoke when: "audit pipeline", "veracity check", "scoring math correct?", "check gates", "trace source", "verify quality gates", "formula correct?".

律师与法务Skill与智能体开发
★ 0
kaiohenricunha
kaiohenricunha/dotbabel

validate-spec

Audit an already-implemented spec against the codebase. Walks each constraint (ARCH-N, PERF-N, KD-N, etc.) and acceptance criterion, grounds findings in file:line evidence, runs the spec.json acceptance_commands, and writes a single audit doc to docs/audits/. Use whenever the user asks to "validate a spec", "audit a spec", "check if spec is implemented", "verify the spec is done", "is this spec really done", or otherwise wants closure on spec-driven work. Read-only against the spec — produces an audit, never modifies the spec itself.

★ 0
kaiohenricunha
kaiohenricunha/dotbabel

terragrunt-specialist

Deep-dive Terragrunt hierarchy review, DRY pattern audits, and run-all orchestration analysis. Use for structured investigations of multi-environment Terragrunt layouts, dependency graphs, remote state config, and hook correctness. Triggers on: "Terragrunt audit", "run-all review", "dependency block", "DRY pattern review", "env hierarchy audit", "mock_outputs", "terragrunt hooks".

运维与部署
★ 0
kaiohenricunha
kaiohenricunha/dotbabel

terraform-specialist

Deep-dive Terraform architecture review, module design, state management, and migration. Use for structured investigations of Terraform workspaces, provider configuration, module coupling, import workflows, and test coverage. Triggers on: "Terraform audit", "module review", "state management", "Terraform import", "workspace design", "provider config review", "Terraform testing".

测试与质量运维与部署
★ 0
kaiohenricunha
kaiohenricunha/dotbabel

spec

Create structured engineering specs through interactive pairing. Use when the user wants to create a spec, design doc, technical specification, architecture document, RFC, or engineering plan. Triggers on "let's spec this out", "create a spec", "design doc", "write a technical plan", "plan the architecture". Works for greenfield and brownfield projects. Outputs to docs/specs/.

设计师视觉设计
★ 0