cc-codeconductor 0.2.1

package/presets/claude/commands/cc/fix.md

@@ -0,0 +1,121 @@
+---
+description: >-
+  [cc: alias] Run the bug fix workflow — risk-based routing through task
+  validation, implementation, testing, and optional review.
+---
+
+# Bug Fix Workflow
+
+Bug description: $ARGUMENTS
+
+Provide the following information in $ARGUMENTS:
+
+- What is the incorrect behavior (actual)
+- What is the expected behavior
+- Steps to reproduce
+- Environment or version where the bug occurs (if known)
+- Any relevant error messages or stack traces
+
+---
+
+## Step 1 — Task Card validation (Task Coach role)
+
+Adopt the **Task Coach** role as defined in `CLAUDE.md`.
+
+Produce a Task Card that includes:
+
+- A clear statement of actual vs. expected behavior
+- Reproduction steps (or a note that they are unknown)
+- Risk classification: `low`, `medium`, or `high`
+- Scope: which files or modules are likely affected
+
+If reproduction steps are missing, ask for them before classifying risk. A bug
+without a reproduction path cannot be classified reliably.
+
+**STOP here. Show the Task Card and wait for human confirmation.**
+
+---
+
+## Step 2 — Route by risk
+
+Read the risk field from the Task Card and follow the corresponding route.
+
+### Low-risk route
+
+Applies when: the bug is isolated to a single component, existing tests cover
+the affected code, and no public API or shared state is involved.
+
+Route: Task Coach → Implementer → Tester
+
+Proceed directly to Step 3a.
+
+### Medium or high-risk route
+
+Applies when: the bug touches shared state, a public API, auth or payment paths,
+database writes, or the root cause is not yet understood.
+
+Route: Task Coach → Architect → Implementer → Tester → Reviewer
+
+Adopt the **Architect** role before implementation. Architect must:
+
+- Identify the root cause (or document that it is unknown)
+- Define the fix approach and affected files
+- Flag any regression risk to adjacent components
+- Produce a Technical Plan
+
+**STOP here if high-risk. Show the Technical Plan and wait for human approval
+before continuing.**
+
+---
+
+## Step 3a — Implementation, low-risk (Implementer role)
+
+Adopt the **Implementer** role as defined in `CLAUDE.md`. Use the Task Card.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+1. Locate the defect using the reproduction steps.
+2. Apply the minimal fix — no unrelated changes.
+3. Run the test suite.
+4. Produce an Implementation Summary: root cause, fix applied, files changed.
+
+---
+
+## Step 3b — Implementation, medium/high-risk (Implementer role)
+
+Adopt the **Implementer** role as defined in `CLAUDE.md`. Use the approved
+Technical Plan and the Task Card.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+Follow the plan exactly. Any deviation requires a new Technical Plan approval.
+After implementation, run the full test suite.
+
+---
+
+## Step 4 — Regression tests (Tester role)
+
+Adopt the **Tester** role as defined in `CLAUDE.md`. Apply for all risk levels.
+
+1. Write a regression test that reproduces the original bug (fails before the
+   fix, passes after).
+2. Verify that existing tests still pass.
+3. Produce a Test Report: test added, case covered.
+
+---
+
+## Step 5 — Review (Reviewer role) — medium/high-risk only
+
+Adopt the **Reviewer** role as defined in `CLAUDE.md`. Use the diff and Task
+Card.
+
+Produce a Review Report with CRITICAL / WARNING / SUGGESTION findings. If any
+CRITICAL findings exist, **STOP**. Do not close the fix until they are resolved.
+
+---
+
+## Completion
+
+Report: Task Card, Implementation Summary, regression test added, Review Report
+(if applicable).
+
+The fix is complete only when: the regression test passes, the full suite
+passes, and no CRITICAL review findings remain.

package/presets/claude/commands/cc/refactor.md

@@ -0,0 +1,148 @@
+---
+description: >-
+  [cc: alias] Run the refactor workflow — mandatory architectural justification,
+  test verification, risk-based implementation, and scope enforcement.
+---
+
+# Refactor Workflow
+
+Refactor description: $ARGUMENTS
+
+Describe what you want to refactor and why. Include:
+
+- The current structure or pattern being changed
+- The target structure or pattern
+- The motivation (performance, readability, architectural alignment, etc.)
+- Known risk areas or dependencies
+
+---
+
+## Prerequisite — Test coverage check
+
+Before any role is adopted, verify that the code being refactored has adequate
+test coverage.
+
+A refactor without tests is not a refactor — it is a rewrite with unknown
+behavioral consequences.
+
+If coverage is insufficient:
+
+1. **STOP**. Report the coverage gap.
+2. Suggest running `/test-plan` first to establish coverage.
+3. Do not proceed with the refactor until coverage is confirmed.
+
+---
+
+## Step 1 — Architectural justification (Architect role)
+
+Adopt the **Architect** role as defined in `CLAUDE.md`. Always invoke this step
+first, regardless of risk level. A refactor without a written justification is
+scope creep in disguise.
+
+Produce a Refactor Plan that includes:
+
+- Statement of the problem with the current structure
+- Proposed target structure and rationale
+- Affected files and module boundaries
+- Risk level: `low`, `medium`, or `high`
+- Behavioral invariants that must not change
+- Open questions requiring human input
+
+**Scope creep warning:** If during planning you identify unrelated improvements,
+list them separately as "Out of scope." They are not part of this refactor.
+
+**STOP here. Show the Refactor Plan and wait for explicit human approval. Do not
+proceed without written approval of the plan.**
+
+---
+
+## Step 2 — Route by risk
+
+Read the risk field from the Refactor Plan and follow the corresponding route.
+
+### Low-risk route
+
+Applies when: the refactor is purely internal, no public interfaces change, full
+test coverage exists for the affected code, and behavioral impact is isolated to
+the refactored module.
+
+Route: Architect (done) → Implementer
+
+Proceed to Step 3a.
+
+### Medium or high-risk route
+
+Applies when: module boundaries change, shared interfaces are affected,
+performance characteristics may change, or the refactor touches more than two
+files with behavioral impact.
+
+Route: Architect (done) → Implementer → Reviewer
+
+Proceed to Step 3b.
+
+---
+
+## Step 3a — Implementation, low-risk (Implementer role)
+
+Adopt the **Implementer** role as defined in `CLAUDE.md`. Use the approved
+Refactor Plan.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+1. Read the Refactor Plan before opening any file.
+2. Apply only the changes specified in the plan.
+3. Run the full test suite before and after — both runs must pass.
+4. Produce an Implementation Summary: what changed, what did not change, test
+   results before and after.
+
+Any deviation from the plan — including "obvious improvements" encountered
+during implementation — must be flagged and held for a separate task.
+
+---
+
+## Step 3b — Implementation, medium/high-risk (Implementer role)
+
+Same rules as Step 3a. Additionally:
+
+- Document any unexpected complexity discovered during implementation.
+- Pause and report if complexity changes the risk assessment.
+- If new risks are found, **STOP** and report before continuing.
+
+---
+
+## Step 4 — Test suite verification
+
+For all risk levels, confirm:
+
+- All tests that existed before the refactor still pass.
+- No test was deleted or commented out to make the suite pass.
+- Behavior documented in the Task Card remains unchanged.
+
+If any test fails that was passing before, the refactor has introduced a
+regression. **STOP and report.**
+
+---
+
+## Step 5 — Code review (Reviewer role) — medium/high-risk only
+
+Adopt the **Reviewer** role as defined in `CLAUDE.md`. Use the diff and Refactor
+Plan.
+
+Verify:
+
+- The implementation matches the approved plan.
+- No behavior was changed beyond the plan's scope.
+- No unrelated files were modified.
+
+Review Report must include CRITICAL / WARNING / SUGGESTION findings. CRITICAL
+findings block completion.
+
+---
+
+## Completion
+
+Report: Refactor Plan (approved), Implementation Summary, test results before
+and after, Review Report (if applicable).
+
+The refactor is complete only when: all pre-existing tests still pass, the
+implementation matches the approved plan exactly, and no CRITICAL review
+findings remain.

package/presets/claude/commands/cc/review.md

@@ -0,0 +1,126 @@
+---
+description: >-
+  [cc: alias] Run a structured code review — produces a Review Report with
+  CRITICAL, WARNING, and SUGGESTION findings; CRITICAL findings block merge.
+---
+
+# Code Review Workflow
+
+Review target: $ARGUMENTS
+
+Specify what to review. Accepted formats:
+
+- A branch name: `feature/my-branch`
+- A file or set of files: `src/api/UserController.kt`
+- A pull request reference: `PR #42`
+- Empty — defaults to the current working diff (`git diff`)
+
+---
+
+## Step 1 — Diff collection
+
+Before adopting the Reviewer role, collect the diff for the specified target.
+
+If $ARGUMENTS is empty or not provided:
+
+- Use `git diff HEAD` as the review target.
+
+If $ARGUMENTS is a branch name:
+
+- Use `git diff main...$ARGUMENTS` (or `develop` if main is not the base).
+
+If $ARGUMENTS is a PR reference:
+
+- Retrieve the PR diff and the PR description for context.
+
+If $ARGUMENTS is a file path:
+
+- Use `git diff HEAD -- $ARGUMENTS`.
+
+Show the diff summary (files changed, lines added/removed) before proceeding.
+
+---
+
+## Step 2 — Code review (Reviewer role)
+
+Adopt the **Reviewer** role as defined in `CLAUDE.md`.
+
+Evaluate the diff against the following checklist:
+
+**Correctness**
+
+- Does the implementation match the stated intent?
+- Are there logic errors, off-by-one errors, or unhandled edge cases?
+
+**Architecture alignment**
+
+- Does the change follow existing module boundaries?
+- Does it introduce unplanned coupling or layering violations?
+
+**Security**
+
+- Are inputs validated before use?
+- Is there any credential, token, or secret in the diff?
+- Are there SQL injection, XSS, or injection risks?
+
+**Performance**
+
+- Does the change introduce N+1 queries, blocking I/O, or O(n²) loops?
+
+**Test coverage**
+
+- Do tests exist for the new or changed behavior?
+- Are assertions meaningful (not just checking that no exception is thrown)?
+
+**Documentation**
+
+- Are public interfaces documented?
+- Is CHANGELOG updated if behavior changed?
+
+---
+
+## Step 3 — Review Report
+
+Produce a structured Review Report with findings in three categories:
+
+```markdown
+## Review Report
+
+### CRITICAL
+[Findings that must be fixed before merge — file:line, description, suggested resolution]
+
+### WARNING
+[Findings that should be resolved before merge — same format as CRITICAL]
+
+### SUGGESTION
+[Optional improvements — style, readability, future-proofing. These do not block merge.]
+
+### Summary
+- Files reviewed: N
+- Total findings: N (X critical, Y warnings, Z suggestions)
+- Merge recommendation: APPROVED | BLOCKED
+```
+
+---
+
+## Step 4 — Merge decision
+
+If any CRITICAL findings exist:
+
+- The Review Report status is **BLOCKED**.
+- Report all CRITICAL findings.
+- Do not proceed until each CRITICAL finding is resolved.
+- After resolution, run `/review` again on the same target.
+
+If no CRITICAL findings exist:
+
+- The Review Report status is **APPROVED**.
+- Report any WARNINGs and SUGGESTIONs for human awareness.
+- The human makes the final merge decision.
+
+---
+
+## Completion
+
+Deliver the complete Review Report. Never summarize or omit findings. Every
+finding must include a location and an actionable description.

package/presets/claude/commands/cc/tdd-cycle.md

@@ -0,0 +1,226 @@
+---
+description: >-
+  [cc: alias] Run a structured Red-Green-Refactor TDD cycle — write a failing
+  test first, implement the minimum code to pass it, then refactor with the
+  suite green.
+---
+
+# TDD Cycle — Red → Green → Refactor
+
+Scope: $ARGUMENTS
+
+Describe what behavior you want to implement. Include:
+
+- The function, method, or feature to implement
+- The expected behavior (inputs and outputs, or acceptance criteria)
+- Any known constraints or edge cases
+- Relevant files or modules (if known)
+
+---
+
+## Before you begin — mandatory pre-check
+
+This command enforces strict TDD discipline. The three phases are sequential and
+non-negotiable:
+
+1. **RED** — a failing test exists before any implementation code is written
+2. **GREEN** — the minimum implementation to make the test pass (no more)
+3. **REFACTOR** — clean up the code while keeping all tests green
+
+Do not write implementation code during RED. Do not refactor during GREEN.
+Mixing phases invalidates the cycle.
+
+---
+
+## Phase 1 — RED (Tester role)
+
+Adopt the **Tester** role as defined in `CLAUDE.md`.
+
+### 1a — Scope clarification
+
+Before writing any test, confirm:
+
+- What is the unit of behavior being tested? (function, method, endpoint, domain
+  rule)
+- What are the inputs and expected outputs?
+- What are the failure cases?
+
+If the scope is ambiguous, ask one clarifying question and wait for the answer.
+
+### 1b — Write the failing test
+
+Write a test that:
+
+- Targets exactly the behavior described in the scope
+- Fails for the right reason (not a compile error, not a missing dependency —
+  the logic does not exist yet)
+- Has a name that describes the behavior: `given_X_when_Y_then_Z` or equivalent
+  in the project's test naming convention
+- Covers at minimum: one happy path, one edge case, one failure case
+
+Do not write the implementation. Do not make the test pass by any means other
+than the implementation that will follow in Phase 2.
+
+### 1c — Run the test suite and confirm RED
+
+Run the test suite. The new test must fail. Existing tests must pass.
+
+If the new test passes without implementation, the test is wrong. Fix the test
+before continuing.
+
+**RED Phase Report:**
+
+```
+## RED Phase Report
+
+**Test file**: [path/to/test/file]
+**Tests written**:
+- [test name] — [what it verifies]
+
+**Suite result**: [X passing, Y failing]
+**New test status**: FAIL ✓
+**Failure reason**: [quoted error or assertion message]
+**Existing tests**: [all passing | N failing — list]
+```
+
+**STOP. Show the RED Phase Report. Do not proceed to GREEN without
+confirmation.**
+
+---
+
+## Phase 2 — GREEN (Implementer role)
+
+Adopt the **Implementer** role as defined in `CLAUDE.md`.
+
+### 2a — Read the failing test before writing any code
+
+Understand exactly what the test asserts. Write only the code that satisfies
+that assertion. Nothing more.
+
+### 2b — Implement the minimum
+
+Rules for GREEN phase:
+
+- Write the smallest amount of code that makes the failing test pass
+- Do not add features not tested
+- Do not clean up or restructure existing code — that is Refactor's job
+- Do not add new tests — that is another RED cycle
+- Hardcoding a return value is acceptable if it makes the test pass (the
+  Refactor phase will generalize it)
+
+### 2c — Run the test suite and confirm GREEN
+
+Run the test suite. The new test must pass. All previously passing tests must
+still pass.
+
+If any previously passing test now fails, you introduced a regression. Fix it
+before continuing.
+
+**GREEN Phase Report:**
+
+```
+## GREEN Phase Report
+
+**Files changed**:
+- [path/to/file] — [what was added, one sentence]
+
+**Implementation approach**: [one sentence — what the code does]
+**Suite result**: [X passing, Y failing]
+**New test status**: PASS ✓
+**Regressions**: [none | list failing tests]
+```
+
+**STOP. Show the GREEN Phase Report. Do not proceed to REFACTOR without
+confirmation.**
+
+---
+
+## Phase 3 — REFACTOR (Implementer role, then Reviewer role)
+
+Adopt the **Implementer** role as defined in `CLAUDE.md`.
+
+### 3a — Assess what needs cleaning
+
+Before touching any code, identify:
+
+- Duplication introduced during GREEN
+- Names that do not clearly express intent
+- Abstractions that belong in a separate function or module
+- Logic that is hardcoded and should be generalized
+
+Do not invent improvements. Only address what is directly in the implementation
+written in Phase 2.
+
+### 3b — Refactor
+
+Rules for REFACTOR phase:
+
+- All tests must remain GREEN throughout — run the suite after each change
+- Do not add new behavior
+- Do not add new tests (if you discover untested behavior, note it for a new RED
+  cycle)
+- Do not change function signatures unless the original was clearly wrong
+
+### 3c — Run the test suite and confirm GREEN after refactor
+
+The full suite must pass. If any test fails during refactor, undo the last
+change and investigate.
+
+### 3d — Review (Reviewer role)
+
+Adopt the **Reviewer** role as defined in `CLAUDE.md`.
+
+Review only the refactored code against these axes:
+
+| Axis          | What to check                                                   |
+| ------------- | --------------------------------------------------------------- |
+| Scope         | Did the refactor change any behavior?                           |
+| Correctness   | Does the logic still satisfy the original test intent?          |
+| Architecture  | Does the code follow existing project patterns?                 |
+| Test coverage | Are all written tests still meaningful (not trivially passing)? |
+
+Produce a Review Report. CRITICAL findings block completion.
+
+**REFACTOR Phase Report:**
+
+```
+## REFACTOR Phase Report
+
+**Changes made**:
+- [path/to/file] — [what was cleaned up]
+
+**Suite result**: [X passing, Y failing]
+**Behavioral changes**: none (refactor only)
+
+### Review findings
+**CRITICAL**: (none) | [list]
+**WARNING**: (none) | [list]
+**SUGGESTION**: (none) | [list]
+
+**Verdict**: approved | approved with warnings | blocked
+```
+
+---
+
+## Completion
+
+The TDD cycle is complete when:
+
+- RED: at least one failing test was written and confirmed failing
+- GREEN: the minimum implementation makes the test pass
+- REFACTOR: the code is clean, all tests pass, no CRITICAL review findings
+
+**Final Summary:**
+
+```
+## TDD Cycle Summary
+
+**Behavior implemented**: [one sentence]
+**Tests written**: [count] — [list test names]
+**Files changed**: [list]
+**Suite result**: [X passing, Y failing]
+**Cycle status**: complete | blocked (reason)
+```
+
+If the behavior requires additional test cases, start a new `/tdd-cycle` with
+the next scenario. One cycle = one behavior.