cc-codeconductor 0.2.9 → 0.2.10

package/presets/agy/skills/cc-tdd-cycle/SKILL.md

@@ -0,0 +1,226 @@
+---
+name: cc-tdd-cycle
+description: >-
+  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 `/cc:tdd-cycle` with
+the next scenario. One cycle = one behavior.

package/presets/agy/skills/cc-test-plan/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: cc-test-plan
+description:
+  Generate a structured test plan for a feature or module — covers unit,
+  integration, contract, and edge cases without writing any implementation code.
+---
+
+# Test Plan Workflow
+
+Scope: $ARGUMENTS
+
+Specify what to plan tests for. Examples:
+
+- A feature name: `user authentication`
+- A module or file path: `src/orders/OrderService.kt`
+- A Task Card title: `Add paginated product listing endpoint`
+- A PR or branch: `feature/payment-retry`
+
+If $ARGUMENTS is empty, describe the scope in your next message before invoking
+`tester`.
+
+---
+
+## Step 1 — Scope confirmation
+
+Before invoking `tester`, confirm the scope is well-defined.
+
+A valid scope includes:
+
+- The behavior or module under test
+- The acceptance criteria or expected behavior (from the Task Card if available)
+- Known edge cases or failure modes
+
+If the scope is vague (e.g., "test the whole service"), ask one clarifying
+question and wait for the answer.
+
+---
+
+## Step 2 — Test plan generation (tester)
+
+Invoke `tester` in planning mode — produce a test plan document, not test code.
+The plan will be used as input when tests are actually written.
+
+tester must produce a Test Plan covering the following layers:
+
+**Unit tests**
+
+- Individual functions or methods in isolation
+- One test per behavior, not per method
+- Input/output contracts, null handling, type coercion
+
+**Integration tests**
+
+- Interactions between two or more components
+- Database read/write cycles (if applicable)
+- External service boundaries (mocked or stubbed)
+
+**Contract tests**
+
+- API endpoint contracts: request shape, response shape, status codes
+- Event schema contracts (if event-driven components are in scope)
+
+**Edge cases**
+
+- Empty inputs, boundary values, max/min limits
+- Concurrent access (if shared state is involved)
+- Failure paths: what happens when a dependency is unavailable
+
+**Regression cases**
+
+- Known past bugs that must not recur (include reference if available)
+
+---
+
+## Step 3 — Test Plan format
+
+tester produces the plan in this format:
+
+```markdown
+## Test Plan — [Scope Name]
+
+### Scope
+
+[What is being tested and why]
+
+### Unit Tests
+
+| Test ID | Target | Scenario | Expected Result |
+| ------- | ------ | -------- | --------------- |
+| U-001   | ...    | ...      | ...             |
+
+### Integration Tests
+
+| Test ID | Components | Scenario | Expected Result |
+| ------- | ---------- | -------- | --------------- |
+| I-001   | ...        | ...      | ...             |
+
+### Contract Tests
+
+| Test ID | Endpoint/Event | Property | Expected Value |
+| ------- | -------------- | -------- | -------------- |
+| C-001   | ...            | ...      | ...            |
+
+### Edge Cases
+
+| Test ID | Input/Condition | Expected Behavior |
+| ------- | --------------- | ----------------- |
+| E-001   | ...             | ...               |
+
+### Regression Cases
+
+| Test ID | Reference | Scenario | Must Not Happen |
+| ------- | --------- | -------- | --------------- |
+| R-001   | ...       | ...      | ...             |
+
+### Coverage Targets
+
+- Minimum unit coverage: [%] (or "all acceptance criteria covered")
+- Integration scenarios: [count]
+- Contract validations: [count]
+
+### Out of Scope
+
+[What this test plan explicitly does not cover and why]
+```
+
+---
+
+## Step 4 — Human review
+
+Show the Test Plan to the human before any tests are written.
+
+The Test Plan is an artifact for review and approval. Writing test code is a
+separate action — invoke `/cc:feature` or add a test task to the board to
+implement from this plan.
+
+---
+
+## Completion
+
+Deliver the complete Test Plan document. Save it as
+`docs/test-plans/[scope-slug].md` if the human requests persistence.
+
+This command produces a plan, not test files. No production code and no test
+code is written during this command.

package/presets/agy/skills/commit/SKILL.md

@@ -0,0 +1,5 @@
+---
+name: commit
+description: Genera un commit en inglés siguiendo Conventional Commits basado en los cambios staged
+---
+{{COMMIT_WORKFLOW}}

package/presets/agy/workflows/cc-api-contract.md

@@ -0,0 +1,71 @@
+---
+name: cc-api-contract
+description:
+  Run the API contract workflow for request/response shape changes,
+  compatibility constraints, contract tests, documentation, and review.
+---
+
+# API Contract Workflow
+
+API contract request: $ARGUMENTS
+
+## Step 1 — Task Card validation (task-coach)
+
+Invoke `task-coach` with the request above.
+
+The Task Card must classify the task as `feature` or `refactor` with `high`
+risk unless the human provides a narrower validated risk. It must include:
+
+- affected endpoint, command, or public interface
+- request and response examples
+- backward compatibility and versioning impact
+- consumers that must remain compatible
+- contract tests and documentation acceptance criteria
+
+**STOP here. Show the Task Card and wait for human confirmation.**
+
+---
+
+## Step 2 — Technical Plan (architect)
+
+Invoke `architect` with the approved Task Card.
+
+architect must define the API contract, compatibility strategy, validation
+rules, docs/OpenAPI impact, and migration path for consumers.
+
+**STOP here. Show the Technical Plan and wait for explicit human approval.**
+
+---
+
+## Step 3 — Implementation (implementer)
+
+Invoke `implementer` with the approved plan.
+
+implementer must apply the minimal diff, preserve compatible behavior unless a
+breaking change was explicitly approved, and update only the files named in the
+plan.
+
+---
+
+## Step 4 — Contract tests (tester)
+
+Invoke `tester`.
+
+tester must add or update contract tests covering request shape, response shape,
+status/error behavior, and backward compatibility constraints.
+
+---
+
+## Step 5 — Review (reviewer)
+
+Invoke `reviewer`.
+
+reviewer must block on missing contract tests, undocumented breaking changes,
+or docs/OpenAPI drift.
+
+---
+
+## Completion
+
+Report the final Task Card, Technical Plan, implementation summary, test report,
+review report, docs updated, compatibility impact, and residual risks.

package/presets/agy/workflows/cc-db-migration.md

@@ -0,0 +1,70 @@
+---
+name: cc-db-migration
+description:
+  Run the database migration workflow for schema/data changes, operational
+  sequencing, tests, and review.
+---
+
+# Database Migration Workflow
+
+Migration request: $ARGUMENTS
+
+## Step 1 — Task Card validation (task-coach)
+
+Invoke `task-coach` with the request above.
+
+The Task Card must classify the task as `high` risk and include:
+
+- tables, collections, models, or migration files in scope
+- data backfill or data cleanup requirements
+- deployment ordering and compatibility window
+- rollback or forward-fix strategy
+- lock risk, data risk, and verification commands
+
+**STOP here. Show the Task Card and wait for human confirmation.**
+
+---
+
+## Step 2 — Migration Plan (architect)
+
+Invoke `architect` with the approved Task Card.
+
+architect must define the schema/data plan, operational sequencing,
+compatibility strategy, rollback/forward-fix notes, and test approach.
+
+**STOP here. Show the Technical Plan and wait for explicit human approval.**
+
+---
+
+## Step 3 — Implementation (implementer)
+
+Invoke `implementer` with the approved plan.
+
+implementer must keep model and migration changes together, avoid unrelated
+refactors, and preserve the deployment order specified by architect.
+
+---
+
+## Step 4 — Migration tests (tester)
+
+Invoke `tester`.
+
+tester must cover migration-sensitive behavior where the stack supports it,
+including happy path, existing-data edge cases, and rollback/forward-fix notes
+when automated rollback tests are not practical.
+
+---
+
+## Step 5 — Review (reviewer)
+
+Invoke `reviewer`.
+
+reviewer must block on missing migration tests, missing data-risk notes,
+undocumented deployment sequencing, or model/migration drift.
+
+---
+
+## Completion
+
+Report migration files changed, model files changed, tests run, lock risk, data
+risk, operational sequencing, rollback/forward-fix notes, and residual risk.

package/presets/agy/workflows/cc-feature.md

@@ -0,0 +1,115 @@
+---
+name: cc-feature
+description:
+  Run the full feature workflow — task validation, technical design,
+  implementation, testing, review, and documentation.
+---
+
+# Feature Workflow
+
+Feature request: $ARGUMENTS
+
+## Step 1 — Task Card validation (task-coach)
+
+Invoke `task-coach` with the feature description above.
+
+task-coach must produce a complete Task Card before any other agent runs. The
+Task Card is ready when it contains: title, type, risk classification, scope,
+context, acceptance criteria, and constraints.
+
+If any field is missing or ambiguous, task-coach must ask one clarifying
+question at a time and wait for the answer. Do not proceed with an incomplete
+Task Card.
+
+**STOP here. Show the completed Task Card and wait for human confirmation before
+continuing.**
+
+---
+
+## Step 2 — Technical Plan (architect)
+
+Invoke `architect` with the validated Task Card from Step 1.
+
+architect must produce a Technical Plan that covers:
+
+- Chosen approach and rationale
+- Affected files and modules
+- Data model changes (if any)
+- API contract changes (if any)
+- Identified risks and mitigations
+- Open questions that require a human decision
+
+**STOP here. Show the Technical Plan and wait for explicit human approval. Do
+not invoke implementer until the plan is approved.**
+
+---
+
+## Step 3 — Implementation (implementer)
+
+Invoke `implementer` with the approved Technical Plan and the Task Card.
+Implementer creates a Git Worktree before touching any file; all edits happen inside it.
+
+implementer must:
+
+1. Read the Technical Plan before touching any file
+2. Apply the minimal diff — only what the plan specifies
+3. Run the project test suite after implementation
+4. Produce an Implementation Summary: what changed, which files, how to verify
+   locally
+
+---
+
+## Step 4 — Test coverage (tester)
+
+Invoke `tester` with the Implementation Summary and the Task Card.
+
+tester must:
+
+1. Write or extend tests to cover the new behavior
+2. Ensure all acceptance criteria from the Task Card have at least one test
+3. Run the full test suite and confirm it passes
+4. Produce a Coverage Summary: test files added or modified, cases covered
+
+---
+
+## Step 5 — Code review (reviewer)
+
+Invoke `reviewer` with the complete diff and the Task Card.
+
+reviewer must produce a Review Report with findings categorized as:
+
+- CRITICAL — must be fixed before merge
+- WARNING — must be resolved before merge
+- SUGGESTION — optional improvement
+
+If any CRITICAL findings exist, **STOP and report them**. Do not proceed until
+they are resolved and re-reviewed.
+
+---
+
+## Step 6 — Documentation (docs)
+
+Invoke `docs` only if any of the following changed:
+
+- A public API endpoint was added or modified
+- A public interface or module was introduced
+- Behavior visible to end users changed
+
+docs must update: README (if applicable), OpenAPI spec (if applicable),
+CHANGELOG (always), ADR (if an architectural decision was made).
+
+---
+
+## Completion
+
+Report the following to the human:
+
+- Task Card (final)
+- Technical Plan (approved)
+- Implementation Summary
+- Coverage Summary
+- Review Report (all findings resolved)
+- List of documentation files updated (if any)
+
+The feature is complete only when: all tests pass, no CRITICAL review findings
+remain, and documentation reflects the implemented behavior.