cc-codeconductor 0.2.9 → 0.2.10

package/presets/agy/workflows/cc-tdd-cycle.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/workflows/cc-test-plan.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/workflows/commit.md

@@ -0,0 +1 @@
+{{COMMIT_WORKFLOW}}

package/presets/claude/CLAUDE.md

@@ -283,8 +283,8 @@ branch, declare done before running tests.
 **Pre-implementation checklist:**
 
 0. Create a Git Worktree for this session before opening any file for editing:
-   `git worktree add ../<branch>-session <branch>`
-   All changes happen inside this worktree. Never modify the main working tree directly.
+   `git worktree add ../<branch>-session <branch>` All changes happen inside
+   this worktree. Never modify the main working tree directly.
 1. Read the Technical Plan completely.
 2. Read each file listed under "Files Affected."
 3. Understand existing patterns in those files.
@@ -294,7 +294,8 @@ branch, declare done before running tests.
 **Implementation rules:**
 
 - **Work in a worktree.** Create a session worktree before touching any file.
-  All edits happen inside it. Include the worktree path in the Implementation Summary.
+  All edits happen inside it. Include the worktree path in the Implementation
+  Summary.
 - **Minimal diff.** Change only what the plan specifies.
 - **Follow existing patterns.** Match naming conventions, error handling, and
   module structure already present in the codebase.
@@ -566,6 +567,14 @@ operations, or Alembic migrations, apply `.claude/skills/sqlalchemy/SKILL.md`.
 When the user asks to create a Spring Boot feature (entity, service, controller,
 or tests), apply `.claude/skills/spring-boot-feature/SKILL.md`.
 
+When the active task requires web performance analysis, Core Web Vitals
+auditing, PageSpeed Insights data, or optimization of LCP, TBT, CLS, FCP, or
+TTFB, apply `.claude/skills/pagespeed-perf/SKILL.md` and
+`.claude/skills/pagespeed-insights/SKILL.md`.
+
+When the user asks about discovering, searching, or installing agent skills or
+extending capabilities, apply `.claude/skills/find-skills/SKILL.md`.
+
 ---
 
 ## What Never Changes
@@ -590,6 +599,7 @@ or tests), apply `.claude/skills/spring-boot-feature/SKILL.md`.
 - Keep solutions simple and direct.
 - User instructions always override this file.
 - When using tools, be precise and minimal with context.
+{{LANGUAGE_INSTRUCTIONS}}
 
 ## Context Budget
 

package/presets/claude/claude.json

@@ -0,0 +1,6 @@
+{
+  "autoConnectIde": true,
+  "autoInstallIdeExtension": false,
+  "externalEditorContext": true,
+  "teammateDefaultModel": "sonnet"
+}

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

@@ -0,0 +1,103 @@
+# PageSpeed Performance Audit
+
+Audit web performance using the PageSpeed Insights API. Applies the 80/20
+principle: identify the 20% of changes that produce 80% of the performance gain.
+Produces a prioritized report in the current working directory.
+
+## Usage
+
+```
+/cc-pagespeed --url <url> [--strategy mobile|desktop|both]
+```
+
+## Parameters
+
+| Parameter     | Required | Description                                                    |
+| ------------- | -------- | -------------------------------------------------------------- |
+| `--url`       | Yes      | Full URL to audit (must include scheme: https://...)           |
+| `--strategy`  | No       | Analysis strategy: `mobile`, `desktop`, or `both` (default: `both`) |
+
+## Requirements
+
+### `PAGESPEED_API_KEY` — Optional but strongly recommended
+
+| Mode         | Lab data | CrUX field data | Rate limits      |
+| ------------ | -------- | --------------- | ---------------- |
+| **With key** | ✅        | ✅ (real users)  | 25,000 req/day   |
+| **Without**  | ✅        | ❌               | ~2 req/s shared  |
+
+Without the key, Core Web Vitals field data (real user experience via CrUX) is
+unavailable. Lab data from Lighthouse still runs.
+
+Set the key before invoking the command:
+
+```powershell
+# Windows PowerShell
+$env:PAGESPEED_API_KEY = "your-api-key"
+
+# macOS / Linux
+export PAGESPEED_API_KEY="your-api-key"
+```
+
+Get a free key (Google account required):
+<https://developers.google.com/speed/docs/insights/v5/get-started>
+
+## Workflow
+
+When `/cc-pagespeed` is invoked, load the `pagespeed-perf` skill and execute
+the following steps in order:
+
+1. **Pre-flight** — Read `$env:PAGESPEED_API_KEY` from the environment. Compute
+   the output filename: `{YYYY-MM-DD}_pagespeed-{hostname}-claude.md`.
+
+2. **Collect** — Call the PageSpeed Insights API for the requested strategy
+   (`mobile`, `desktop`, or `both`). Prefer the Bun scripts in
+   `~/.claude/skills/pagespeed-perf/scripts/run.ts` if Bun is available.
+   Otherwise, use `WebFetch` to call the PSI endpoint directly.
+
+3. **Analyze** — Extract Core Web Vitals (LCP, INP, CLS, FCP, TTFB, TBT),
+   identify the LCP element, enumerate third-party scripts by blocking time,
+   and inspect resource hints in the HTML `<head>`.
+
+4. **Prioritize** — Score each identified optimization using the 80/20 matrix:
+   `Impact × Ease` (each 1–5). Order findings by descending score. Highlight
+   the top actions with Score ≥ 20 as the critical 20%.
+
+5. **Report** — Write the structured markdown report to
+   `{YYYY-MM-DD}_pagespeed-{hostname}-claude.md` in the current directory.
+
+## Output File
+
+The report is saved as `{YYYY-MM-DD}_pagespeed-{hostname}-claude.md`.
+
+- Hostname characters outside `[a-zA-Z0-9]` are replaced with `-`.
+- Example: `https://www.example.com` → `2026-06-07_pagespeed-www-example-com-claude.md`
+
+## Skills Loaded
+
+- `pagespeed-perf` — Web Performance Engineering: PSI API, Core Web Vitals
+  thresholds, 80/20 optimization matrix, resource-hint analysis, third-party
+  script auditing, framework-specific implementation templates.
+
+## Examples
+
+```bash
+# Full audit — mobile + desktop
+/cc-pagespeed --url https://www.example.com
+
+# Mobile only
+/cc-pagespeed --url https://www.example.com --strategy mobile
+
+# Desktop only
+/cc-pagespeed --url https://www.example.com --strategy desktop
+```
+
+## Hard Rules
+
+- **GET only.** Never send POST, PUT, or DELETE to the target URL.
+- **No auth.** Never include cookies, tokens, or auth headers.
+- **No external crawling.** Audit only the provided URL.
+- **Quantify every finding.** Never write "it would improve LCP". Always cite
+  the observed value and estimated gain (e.g., "reduces LCP from 4.2 s to ~3.0 s").
+- **No generic recommendations.** Every finding must be backed by data from
+  the audit of this specific URL.