refactor(skills): wire code-quality-review and security-audit into reviews

Rename thermo-nuclear-code-quality-review to code-quality-review and drop the dramatic wording; allow security-audit model invocation. Both now run as extra axes in the implementation-orchestrator and orchestrate-herdr review steps.
2026-10-06 18:47:42 -04:00
parent abf9b8e7ec
commit fcdd3f7a8c
4 changed files with 5 additions and 6 deletions
@@ -1,10 +1,10 @@
 ---
-name: thermo-nuclear-code-quality-review
-description: Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.
+name: code-quality-review
+description: Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a code quality review, deep code quality audit, or especially harsh maintainability review.
 disable-model-invocation: true
 ---

-# Thermo-Nuclear Code Quality Review
+# Code Quality Review

 Use this skill for an unusually strict review focused on implementation quality, maintainability, abstraction quality, and codebase health.

@@ -44,7 +44,7 @@ Comments are the message board. Record claims, status, evidence, questions, deci
 4. **Implement.** Launch one worker per ticket with `pi-subagents` in an isolated worktree, maximum three in flight by default. Pass the complete ticket, comments, acceptance criteria, non-goals, linked context, and validation contract. Each worker makes only ticket-scoped changes, commits them, and reports changed files and checks.
 5. **Escalate.** For missing requirements, unsafe ambiguity, credentials, unrelated scope, or a product/architecture decision, stop. For human review or judgment, assign the ticket to the configured human reviewer, apply `workflow:ready-for-human`, and comment the exact request. If no human identity is configured, ask before assigning and changing the state. Use `workflow:blocked` for non-human blockers. Preserve the worktree on failure.
 6. **PR.** Run documented local checks. Push the branch and create exactly one PR/MR for the ticket. Link the ticket's tracker ID and title in the PR/MR, set `workflow:pr-open`, and comment the PR/MR URL on the ticket. Keep the worktree.
-7. **Review.** Set `workflow:review`. Run a fresh-context `code-review` review with correctness/spec and standards axes separate. Post findings through the PR/MR comment/review function. For actionable findings, set `workflow:changes-requested`, send one fix worker, rerun checks, and repeat. Allow at most three rounds.
+7. **Review.** Set `workflow:review`. Run a fresh-context `code-review` review with correctness/spec and standards axes separate. Then run the `security-audit` and `code-quality-review` both in their own `reviewer` subagent. Post findings through the PR/MR comment/review function. For actionable findings, set `workflow:changes-requested`, send one fix worker, rerun checks, and repeat. Allow at most three rounds.
 8. **Conflict.** Set `workflow:conflict`, then follow `resolving-merge-conflicts`. Inspect both intents, preserve them where possible, never invent behavior, never abort, rerun local checks, and update the PR/MR. If judgment is needed, assign the PR/MR and ticket to the configured human reviewer, apply `workflow:ready-for-human`, and comment the request in both places. If no human identity is configured, ask before assigning.
 9. **Merge.** Merge only after independent review is clean, local checks pass, forge CI is green, the target is still the expected default branch, and no human decision or blocker remains. Comment the merge receipt and outcome, close the ticket, apply `workflow:merged` when supported, verify integration, then remove the worktree.
 10. **Finish.** Report merged tickets and PR/MR URLs, human handoffs, blocked tickets, failed checks, review rounds, and remaining eligible tickets. Report `done` only when no open implementation or human tickets remain in the selected scope. If only human tickets remain, report `waiting-on-human`.
@@ -30,7 +30,7 @@ Each implementer gets the full ticket and acceptance criteria, relevant context
 - merge the latest integration branch into its task branch before reporting done;
 - report changed files, commit, checks, and any blockers; do not merge to the integration branch or open a PR.

-When an implementer finishes, have a **new independent reviewer agent** run the `code-review` skill against that task branch, using the current integration branch as the base. Resolve all actionable findings in a fresh scoped fix agent and rerun the review until clear. Only then use a fresh merger agent to merge the task branch into the integration branch. Verify the merge and update tracker state before dispatching newly unblocked tickets. Reconcile uncertain Git or tracker outcomes before retrying.
+When an implementer finishes, have a **new independent reviewer agent** run the `code-review`, `security-audit` and `code-quality-review` skill against that task branch, using the current integration branch as the base. Resolve all actionable findings in a fresh scoped fix agent and rerun the review until clear. Only then use a fresh merger agent to merge the task branch into the integration branch. Verify the merge and update tracker state before dispatching newly unblocked tickets. Reconcile uncertain Git or tracker outcomes before retrying.

 ## 3. Final review and completion

@@ -1,7 +1,6 @@
 ---
 name: security-audit
 description: Comprehensive security and correctness audit of a branch's changes. Use for deep review requests, or branch/PR diff audits focused on bugs, breaking changes, security issues, devex regressions, and feature-gate leaks.
-disable-model-invocation: true
 ---

 # Security Audit Skill