@baselane/packs 0.1.5 → 0.1.7

package/packs/full-harness/rendered/.claude/commands/cpp-review.md

@@ -0,0 +1,6 @@
+---
+description: Comprehensive C++ code review for memory safety, modern C++ idioms, concurrency, and security. Invokes the cpp-reviewer agent.
+argument-hint: [optional arguments]
+---
+
+# C++ Code Review This command invokes the **cpp-reviewer** agent for comprehensive C++-specific code review. ## What This Command Does 1. **Identify C++ Changes**: Find modified `.cpp`, `.hpp`, `.cc`, `.h` files via `git diff` 2. **Run Static Analysis**: Execute `clang-tidy` and `cppcheck` 3. **Memory Safety Scan**: Check for raw new/delete, buffer overflows, use-after-free 4. **Concurrency Review**: Analyze thread safety, mutex usage, data races 5. **Modern C++ Check**: Verify code follows C++17/20 conventions and best practices 6. **Generate Report**: Categorize issues by severity ## When to Use Use `/cpp-review` when: - After writing or modifying C++ code - Before committing C++ changes - Reviewing pull requests with C++ code - Onboarding to a new C++ codebase - Checking for memory safety issues ## Review Categories ### CRITICAL (Must Fix) - Raw `new`/`delete` without RAII - Buffer overflows and use-after-free - Data races without synchronization - Command injection via `system()` - Uninitialized variable reads - Null pointer dereferences ### HIGH (Should Fix) - Rule of Five violations - Missing `std::lock_guard` / `std::scoped_lock` - Detached threads without proper lifetime management - C-style casts instead of `static_cast`/`dynamic_cast` - Missing `const` correctness ### MEDIUM (Consider) - Unnecessary copies (pass by value instead of `const&`) - Missing `reserve()` on known-size containers - `using namespace std;` in headers - Missing `[[nodiscard]]` on important return values - Overly complex template metaprogramming ## Automated Checks Run ```bash # Static analysis clang-tidy --checks='*,-llvmlibc-*' src/*.cpp -- -std=c++17 # Additional analysis cppcheck --enable=all --suppress=missingIncludeSystem src/ # Build with warnings cmake --build build -- -Wall -Wextra -Wpedantic ``` ## Example Usage ```text User: /cpp-review Agent: # C++ Code Review Report ## Files Reviewed - src/handler/user.cpp (modified) - src/service/auth.cpp (modified) ## Static Analysis Results ✓ clang-tidy: 2 warnings ✓ cppcheck: No issues ## Issues Found [CRITICAL] Memory Leak File: src/service/auth.cpp:45 Issue: Raw `new` without matching `delete` ```cpp auto* session = new Session(userId); // Memory leak! cache[userId] = session; ``` Fix: Use `std::unique_ptr` ```cpp auto session = std::make_unique<Session>(userId); cache[userId] = std::move(session); ``` [HIGH] Missing const Reference File: src/handler/user.cpp:28 Issue: Large object passed by value ```cpp void processUser(User user) { // Unnecessary copy ``` Fix: Pass by const reference ```cpp void processUser(const User& user) { ``` ## Summary - CRITICAL: 1 - HIGH: 1 - MEDIUM: 0 Recommendation: FAIL: Block merge until CRITICAL issue is fixed ``` ## Approval Criteria | Status | Condition | |--------|-----------| | PASS: Approve | No CRITICAL or HIGH issues | | WARNING: Warning | Only MEDIUM issues (merge with caution) | | FAIL: Block | CRITICAL or HIGH issues found | ## Integration with Other Commands - Use `/cpp-test` first to ensure tests pass - Use `/cpp-build` if build errors occur - Use `/cpp-review` before committing - Use `/code-review` for non-C++ specific concerns ## Related - Agent: `agents/cpp-reviewer.md` - Skills: `skills/cpp-coding-standards/`, `skills/cpp-testing/`

package/packs/full-harness/rendered/.claude/commands/cpp-test.md

@@ -0,0 +1,6 @@
+---
+description: Enforce TDD workflow for C++. Write GoogleTest tests first, then implement. Verify coverage with gcov/lcov.
+argument-hint: [optional arguments]
+---
+
+# C++ TDD Command This command enforces test-driven development methodology for C++ code using GoogleTest/GoogleMock with CMake/CTest. ## What This Command Does 1. **Define Interfaces**: Scaffold class/function signatures first 2. **Write Tests**: Create comprehensive GoogleTest test cases (RED) 3. **Run Tests**: Verify tests fail for the right reason 4. **Implement Code**: Write minimal code to pass (GREEN) 5. **Refactor**: Improve while keeping tests green 6. **Check Coverage**: Ensure 80%+ coverage ## When to Use Use `/cpp-test` when: - Implementing new C++ functions or classes - Adding test coverage to existing code - Fixing bugs (write failing test first) - Building critical business logic - Learning TDD workflow in C++ ## TDD Cycle ``` RED → Write failing GoogleTest test GREEN → Implement minimal code to pass REFACTOR → Improve code, tests stay green REPEAT → Next test case ``` ## Example Session ```` User: /cpp-test I need a function to validate email addresses Agent: # TDD Session: Email Validator ## Step 1: Define Interface ```cpp // validator/email.hpp #pragma once #include <string> #include <expected> enum class EmailError { Empty, InvalidFormat }; std::expected<void, EmailError> validate_email(const std::string& email); ``` ## Step 2: Write Tests (RED) ```cpp // validator/email_test.cpp #include <gtest/gtest.h> #include "email.hpp" TEST(ValidateEmail, AcceptsSimpleEmail) { auto result = validate_email("user@example.com"); EXPECT_TRUE(result.has_value()); } TEST(ValidateEmail, AcceptsSubdomain) { EXPECT_TRUE(validate_email("user@mail.example.com").has_value()); } TEST(ValidateEmail, AcceptsPlus) { EXPECT_TRUE(validate_email("user+tag@example.com").has_value()); } TEST(ValidateEmail, RejectsEmpty) { auto result = validate_email(""); ASSERT_FALSE(result.has_value()); EXPECT_EQ(result.error(), EmailError::Empty); } TEST(ValidateEmail, RejectsNoAtSign) { EXPECT_FALSE(validate_email("userexample.com").has_value()); } TEST(ValidateEmail, RejectsNoDomain) { EXPECT_FALSE(validate_email("user@").has_value()); } TEST(ValidateEmail, RejectsNoLocalPart) { EXPECT_FALSE(validate_email("@example.com").has_value()); } ``` ## Step 3: Run Tests - Verify FAIL ```bash $ cmake --build build && ctest --test-dir build --output-on-failure 1/1 Test #1: email_validator_test .....***Failed --- undefined reference to `validate_email` FAIL ``` ✓ Tests fail as expected (unimplemented). ## Step 4: Implement Minimal Code (GREEN) ```cpp // validator/email.cpp #include "email.hpp" #include <regex> std::expected<void, EmailError> validate_email(const std::string& email) { if (email.empty()) { return std::unexpected(EmailError::Empty); } static const std::regex pattern(R"([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})"); if (!std::regex_match(email, pattern)) { return std::unexpected(EmailError::InvalidFormat); } return {}; } ``` ## Step 5: Run Tests - Verify PASS ```bash $ cmake --build build && ctest --test-dir build --output-on-failure 1/1 Test #1: email_validator_test ..... Passed 0.01 sec 100% tests passed. ``` ✓ All tests passing! ## Step 6: Check Coverage ```bash $ cmake -DCMAKE_CXX_FLAGS="--coverage" -B build && cmake --build build $ ctest --test-dir build $ lcov --capture --directory build --output-file coverage.info $ lcov --list coverage.info validator/email.cpp | 100% ``` ✓ Coverage: 100% ## TDD Complete! ```` ## Test Patterns ### Basic Tests ```cpp TEST(SuiteName, TestName) { EXPECT_EQ(add(2, 3), 5); EXPECT_NE(result, nullptr); EXPECT_TRUE(is_valid); EXPECT_THROW(func(), std::invalid_argument); } ``` ### Fixtures ```cpp class DatabaseTest : public ::testing::Test { protected: void SetUp() override { db_ = create_test_db(); } void TearDown() override { db_.reset(); } std::unique_ptr<Database> db_; }; TEST_F(DatabaseTest, InsertsRecord) { db_->insert("key", "value"); EXPECT_EQ(db_->get("key"), "value"); } ``` ### Parameterized Tests ```cpp class PrimeTest : public ::testing::TestWithParam<std::pair<int, bool>> {}; TEST_P(PrimeTest, ChecksPrimality) { auto [input, expected] = GetParam(); EXPECT_EQ(is_prime(input), expected); } INSTANTIATE_TEST_SUITE_P(Primes, PrimeTest, ::testing::Values( std::make_pair(2, true), std::make_pair(4, false), std::make_pair(7, true) )); ``` ## Coverage Commands ```bash # Build with coverage cmake -DCMAKE_CXX_FLAGS="--coverage" -DCMAKE_EXE_LINKER_FLAGS="--coverage" -B build # Run tests cmake --build build && ctest --test-dir build # Generate coverage report lcov --capture --directory build --output-file coverage.info lcov --remove coverage.info '/usr/*' --output-file coverage.info genhtml coverage.info --output-directory coverage_html ``` ## Coverage Targets | Code Type | Target | |-----------|--------| | Critical business logic | 100% | | Public APIs | 90%+ | | General code | 80%+ | | Generated code | Exclude | ## TDD Best Practices **DO:** - Write test FIRST, before any implementation - Run tests after each change - Use `EXPECT_*` (continues) over `ASSERT_*` (stops) when appropriate - Test behavior, not implementation details - Include edge cases (empty, null, max values, boundary conditions) **DON'T:** - Write implementation before tests - Skip the RED phase - Test private methods directly (test through public API) - Use `sleep` in tests - Ignore flaky tests ## Related Commands - `/cpp-build` - Fix build errors - `/cpp-review` - Review code after implementation - `verification-loop` skill - Run full verification loop ## Related - Skill: `skills/cpp-testing/` - Skill: `skills/tdd-workflow/`

package/packs/full-harness/rendered/.claude/commands/ecc-guide.md

@@ -0,0 +1,6 @@
+---
+description: Navigate ECC's current agents, skills, commands, hooks, install profiles, and docs from the live repository surface.
+argument-hint: [optional arguments]
+---
+
+# /ecc-guide Use this command as a conversational map of Everything Claude Code. It should help the user discover the right ECC surface for their task without dumping the entire README or stale catalog counts. ## Usage ```text /ecc-guide /ecc-guide setup /ecc-guide skills /ecc-guide commands /ecc-guide hooks /ecc-guide install /ecc-guide find: <query> /ecc-guide <feature-or-file-name> ``` ## Operating Rules 1. Read current repository files before answering when the checkout is available. 2. Prefer current filesystem/catalog data over hard-coded counts. 3. Keep the first answer short, then offer specific drill-down paths. 4. Link users to canonical files instead of copying long sections. 5. Do not invent commands, skills, agents, or install profiles that are not present. ## What To Inspect Use these files as the canonical map: - `README.md` for install paths, reset/uninstall guidance, and high-level positioning - `AGENTS.md` for contributor and project-structure guidance - `agent.yaml` for exported agent and command surface - `commands/` for maintained slash-command shims - `skills/*/SKILL.md` for reusable skill workflows - `agents/*.md` for delegated agent roles - `hooks/README.md` and `hooks/hooks.json` for hook behavior - `manifests/install-*.json` for selective install modules, components, and profiles - `scripts/ci/catalog.js --json` for live catalog counts when running inside ECC ## Response Patterns ### No Arguments Give a compact menu: - setup and install - choosing skills - command compatibility shims - agents and delegation - hooks and safety - troubleshooting an install - finding a specific feature Then ask what they want to do next. ### Topic Lookup For topics like `skills`, `commands`, `hooks`, `install`, or `agents`: 1. Summarize the current surface in 3-6 bullets. 2. Point to the canonical directories/files. 3. Suggest one or two commands that can verify the state. 4. Avoid exhaustive lists unless the user asks for one. ### Search Mode For `find: <query>`: 1. Search the relevant files with `rg`. 2. Group results by surface: skills, commands, agents, rules, docs, hooks. 3. Return the strongest matches first with file paths. 4. Recommend the next action for each match. ### Feature Lookup For a specific feature name: 1. Check exact paths first, such as `skills/<name>/SKILL.md`, `commands/<name>.md`, and `agents/<name>.md`. 2. If exact lookup fails, search with `rg`. 3. Explain what the feature does, when to use it, and what file is canonical. 4. Mention adjacent features only when they reduce confusion. ## Related Commands - `/project-init` for stack-aware ECC onboarding of a target project - `/harness-audit` for deterministic repo readiness scoring - `/skill-health` for skill quality checks - `/skill-create` for extracting a new skill from local git history - `/security-scan` for Claude/OpenCode configuration security review

package/packs/full-harness/rendered/.claude/commands/epic-claim.md

@@ -0,0 +1,6 @@
+---
+description: Claim an epic issue, stamp coordination state, and sync local ownership.
+argument-hint: [optional arguments]
+---
+
+# /epic-claim Claim one epic issue as the source of truth for a unit of work. Use the coordination script: ```bash node scripts/github-coordination.js claim <issue-number> --repo <owner/repo> --actor <login> ``` What this does: 1. Loads the issue body and coordination block. 2. Marks the epic as claimed in GitHub issue state. 3. Updates labels and the local SQLite cache. 4. Appends an audit comment for the claim. Compatibility aliases: - `/orch-add-feature` - `/orch-change-feature` - `/prp-implement`

package/packs/full-harness/rendered/.claude/commands/epic-decompose.md

@@ -0,0 +1,6 @@
+---
+description: Break an epic into task children without creating task branches.
+argument-hint: [optional arguments]
+---
+
+# /epic-decompose Reconcile the task breakdown for one epic issue. ```bash node scripts/github-coordination.js decompose <issue-number> --repo <owner/repo> ``` What this does: 1. Reads the epic issue body for task checklists and dependency references. 2. Stores the decomposition in the coordination block. 3. Leaves task branches out of the workflow. 4. Appends a concise audit comment. Compatibility aliases: - `/plan` - `/prp-plan`

package/packs/full-harness/rendered/.claude/commands/epic-publish.md

@@ -0,0 +1,6 @@
+---
+description: Publish a validated epic update back to the issue and local cache.
+argument-hint: [optional arguments]
+---
+
+# /epic-publish Publish a validated coordination update to GitHub. ```bash node scripts/github-coordination.js publish <issue-number> --repo <owner/repo> ``` What this does: 1. Re-validates the epic before publishing. 2. Updates the coordination block in the issue body. 3. Appends a concise publish comment. 4. Records the final local snapshot. Compatibility aliases: - `/pr` - `/prp-pr`

package/packs/full-harness/rendered/.claude/commands/epic-review.md

@@ -0,0 +1,6 @@
+---
+description: Mark epic review requested, approved, or changes requested.
+argument-hint: [optional arguments]
+---
+
+# /epic-review Coordinate review state for an epic issue. ```bash node scripts/github-coordination.js review <issue-number> --repo <owner/repo> --review approved ``` What this does: 1. Updates the review state in the coordination block. 2. Syncs review labels to GitHub. 3. Records the review outcome in an audit comment. 4. Keeps the local cache aligned with the issue body. Compatibility aliases: - `/review-pr` - `/code-review`

package/packs/full-harness/rendered/.claude/commands/epic-sync.md

@@ -0,0 +1,6 @@
+---
+description: Sync epic issue bodies, labels, and local coordination snapshots from GitHub.
+argument-hint: [optional arguments]
+---
+
+# /epic-sync Run a deterministic sync for epic issues. ```bash node scripts/github-coordination.js sync --repo <owner/repo> ``` What this does: 1. Reads issue bodies as the canonical epic state. 2. Reconciles the coordination block with labels. 3. Writes a fresh local snapshot for each epic issue. 4. Keeps the SQLite cache aligned with GitHub. Compatibility aliases: - `/projects` - `/work-items sync-github`

package/packs/full-harness/rendered/.claude/commands/epic-unblock.md

@@ -0,0 +1,6 @@
+---
+description: Sweep blocked epic issues and reopen anything whose dependencies are closed.
+argument-hint: [optional arguments]
+---
+
+# /epic-unblock Sweep blocked epics whose declared dependencies are complete. ```bash node scripts/github-coordination.js unblock --repo <owner/repo> ``` What this does: 1. Scans epic issues in the repository. 2. Checks each blocked epic's dependency list. 3. Moves fully unblocked epics to ready. 4. Updates labels, comments, and local snapshots. Compatibility aliases: - `/loop-status`

package/packs/full-harness/rendered/.claude/commands/epic-validate.md

@@ -0,0 +1,6 @@
+---
+description: Validate epic readiness, dependencies, and coordination policy.
+argument-hint: [optional arguments]
+---
+
+# /epic-validate Validate a single epic issue before publishing or review handoff. ```bash node scripts/github-coordination.js validate <issue-number> --repo <owner/repo> ``` What this checks: 1. Coordination state exists and is parseable. 2. Validation state is satisfied by policy. 3. Declared dependencies are closed. 4. The epic is ready for the next workflow stage. Compatibility aliases: - `/quality-gate`

package/packs/full-harness/rendered/.claude/commands/evolve.md

@@ -0,0 +1,6 @@
+---
+description: Analyze instincts and suggest or generate evolved structures
+argument-hint: [optional arguments]
+---
+
+# Evolve Command ## Implementation Run the instinct CLI using the plugin root path: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" evolve [--generate] ``` Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation): ```bash python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [--generate] ``` Analyzes instincts and clusters related ones into higher-level structures: - **Commands**: When instincts describe user-invoked actions - **Skills**: When instincts describe auto-triggered behaviors - **Agents**: When instincts describe complex, multi-step processes ## Usage ``` /evolve # Analyze all instincts and suggest evolutions /evolve --generate # Also generate files under evolved/{skills,commands,agents} ``` ## Evolution Rules ### → Command (User-Invoked) When instincts describe actions a user would explicitly request: - Multiple instincts about "when user asks to..." - Instincts with triggers like "when creating a new X" - Instincts that follow a repeatable sequence Example: - `new-table-step1`: "when adding a database table, create migration" - `new-table-step2`: "when adding a database table, update schema" - `new-table-step3`: "when adding a database table, regenerate types" → Creates: **new-table** command ### → Skill (Auto-Triggered) When instincts describe behaviors that should happen automatically: - Pattern-matching triggers - Error handling responses - Code style enforcement Example: - `prefer-functional`: "when writing functions, prefer functional style" - `use-immutable`: "when modifying state, use immutable patterns" - `avoid-classes`: "when designing modules, avoid class-based design" → Creates: `functional-patterns` skill ### → Agent (Needs Depth/Isolation) When instincts describe complex, multi-step processes that benefit from isolation: - Debugging workflows - Refactoring sequences - Research tasks Example: - `debug-step1`: "when debugging, first check logs" - `debug-step2`: "when debugging, isolate the failing component" - `debug-step3`: "when debugging, create minimal reproduction" - `debug-step4`: "when debugging, verify fix with test" → Creates: **debugger** agent ## What to Do 1. Detect current project context 2. Read project + global instincts (project takes precedence on ID conflicts) 3. Group instincts by trigger/domain patterns 4. Identify: - Skill candidates (trigger clusters with 2+ instincts) - Command candidates (high-confidence workflow instincts) - Agent candidates (larger, high-confidence clusters) 5. Show promotion candidates (project -> global) when applicable 6. If `--generate` is passed, write files to: - Project scope: `~/.claude/homunculus/projects/<project-id>/evolved/` - Global fallback: `~/.claude/homunculus/evolved/` ## Output Format ``` ============================================================ EVOLVE ANALYSIS - 12 instincts Project: my-app (a1b2c3d4e5f6) Project-scoped: 8 | Global: 4 ============================================================ High confidence instincts (>=80%): 5 ## SKILL CANDIDATES 1. Cluster: "adding tests" Instincts: 3 Avg confidence: 82% Domains: testing Scopes: project ## COMMAND CANDIDATES (2) /adding-tests From: test-first-workflow [project] Confidence: 84% ## AGENT CANDIDATES (1) adding-tests-agent Covers 3 instincts Avg confidence: 82% ``` ## Flags - `--generate`: Generate evolved files in addition to analysis output ## Generated File Format ### Command ```markdown --- name: new-table description: Create a new database table with migration, schema update, and type generation command: /new-table evolved_from: - new-table-migration - update-schema - regenerate-types --- # New Table Command [Generated content based on clustered instincts] ## Steps 1. ... 2. ... ``` ### Skill ```markdown --- name: functional-patterns description: Enforce functional programming patterns evolved_from: - prefer-functional - use-immutable - avoid-classes --- # Functional Patterns Skill [Generated content based on clustered instincts] ``` ### Agent ```markdown --- name: debugger description: Systematic debugging agent model: sonnet evolved_from: - debug-check-logs - debug-isolate - debug-reproduce --- # Debugger Agent [Generated content based on clustered instincts] ```

package/packs/full-harness/rendered/.claude/commands/fastapi-review.md

@@ -0,0 +1,6 @@
+---
+description: Review a FastAPI application for architecture, async correctness, dependency injection, Pydantic schemas, security, performance, and testability.
+argument-hint: [optional arguments]
+---
+
+# FastAPI Review Invoke the `fastapi-reviewer` agent for a focused FastAPI review. ## Usage ```text /fastapi-review [file-or-directory] ``` ## Review Areas - App factory, router boundaries, middleware, and exception handlers. - Pydantic request and response schema separation. - Dependency injection for database sessions, auth, pagination, and settings. - Async database and external HTTP patterns. - CORS, auth, rate limits, logging, and secret handling. - OpenAPI metadata and documented response models. - Test client setup and dependency overrides. ## Expected Output ```text [SEVERITY] Short issue title File: path/to/file.py:42 Issue: What is wrong and why it matters. Fix: Concrete change to make. ``` ## Related - Agent: `fastapi-reviewer` - Skill: `fastapi-patterns` - Command: `/python-review` - Skill: `security-scan`

package/packs/full-harness/rendered/.claude/commands/feature-dev.md

@@ -0,0 +1,6 @@
+---
+description: Guided feature development with codebase understanding and architecture focus
+argument-hint: [optional arguments]
+---
+
+A structured feature-development workflow that emphasizes understanding existing code before writing new code. ## Phases ### 1. Discovery - read the feature request carefully - identify requirements, constraints, and acceptance criteria - ask clarifying questions if the request is ambiguous ### 2. Codebase Exploration - use `code-explorer` to analyze the relevant existing code - trace execution paths and architecture layers - understand integration points and conventions ### 3. Clarifying Questions - present findings from exploration - ask targeted design and edge-case questions - wait for user response before proceeding ### 4. Architecture Design - use `code-architect` to design the feature - provide the implementation blueprint - wait for approval before implementing ### 5. Implementation - implement the feature following the approved design - prefer TDD where appropriate - keep commits small and focused ### 6. Quality Review - use `code-reviewer` to review the implementation - address critical and important issues - verify test coverage ### 7. Summary - summarize what was built - list follow-up items or limitations - provide testing instructions

package/packs/full-harness/rendered/.claude/commands/flutter-build.md

@@ -0,0 +1,6 @@
+---
+description: Fix Dart analyzer errors and Flutter build failures incrementally. Invokes the dart-build-resolver agent for minimal, surgical fixes.
+argument-hint: [optional arguments]
+---
+
+# Flutter Build and Fix This command invokes the **dart-build-resolver** agent to incrementally fix Dart/Flutter build errors with minimal changes. ## What This Command Does 1. **Run Diagnostics**: Execute `flutter analyze`, `flutter pub get` 2. **Parse Errors**: Group by file and sort by severity 3. **Fix Incrementally**: One error at a time 4. **Verify Each Fix**: Re-run analysis after each change 5. **Report Summary**: Show what was fixed and what remains ## When to Use Use `/flutter-build` when: - `flutter analyze` reports errors - `flutter build` fails for any platform - `dart pub get` / `flutter pub get` fails with version conflicts - `build_runner` fails to generate code - After pulling changes that break the build ## Diagnostic Commands Run ```bash # Analysis flutter analyze 2>&1 # Dependencies flutter pub get 2>&1 # Code generation (if project uses build_runner) dart run build_runner build --delete-conflicting-outputs 2>&1 # Platform builds flutter build apk 2>&1 flutter build web 2>&1 ``` ## Example Session ````text User: /flutter-build Agent: # Flutter Build Resolution ## Initial Diagnostics ``` $ flutter analyze Analyzing project... error • lib/features/user/data/user_repository_impl.dart:34:16 • A value of type 'String?' can't be assigned to a variable of type 'String'. • invalid_assignment error • lib/features/cart/presentation/cart_page.dart:58:5 • The method 'add' isn't defined for the type 'List<Item>'. Try correcting the name to the name of an existing method, or defining a method named 'add'. • undefined_method 2 errors found. ``` ## Fix 1: Null Safety File: lib/features/user/data/user_repository_impl.dart:34 Error: A value of type 'String?' can't be assigned to type 'String' Changed: ```dart final id = response.id; ``` To: ```dart final id = response.id ?? ''; ``` ``` $ flutter analyze 1 error found. ``` ## Fix 2: Immutable List File: lib/features/cart/presentation/cart_page.dart:58 Error: The method 'add' isn't defined for the type 'List<Item>' Cause: State holds an unmodifiable list; mutation goes through Cubit Changed: ```dart state.items.add(item); ``` To: ```dart context.read<CartCubit>().addItem(item); // Note: Cubit exposes named methods (addItem, removeItem); // .add(event) is the BLoC event API — don't mix them. ``` ``` $ flutter analyze No issues found! ``` ## Final Verification ``` $ flutter test All tests passed. ``` ## Summary | Metric | Count | |--------|-------| | Analysis errors fixed | 2 | | Files modified | 2 | | Remaining issues | 0 | Build Status: PASS ✓ ```` ## Common Errors Fixed | Error | Typical Fix | |-------|-------------| | `A value of type 'X?' can't be assigned to 'X'` | Add `?? default` or null guard | | `The name 'X' isn't defined` | Add import or fix typo | | `Non-nullable instance field must be initialized` | Add initializer or `late` | | `Version solving failed` | Adjust version constraints in pubspec.yaml | | `Missing concrete implementation of 'X'` | Implement missing interface method | | `build_runner: Part of X expected` | Delete stale `.g.dart` and rebuild | ## Fix Strategy 1. **Analysis errors first** — code must be error-free 2. **Warning triage second** — fix warnings that could cause runtime bugs 3. **pub conflicts third** — fix dependency resolution 4. **One fix at a time** — verify each change 5. **Minimal changes** — don't refactor, just fix ## Stop Conditions The agent will stop and report if: - Same error persists after 3 attempts - Fix introduces more errors - Requires architectural changes - Package upgrade conflicts need user decision ## Related Commands - `/flutter-test` — Run tests after build succeeds - `/flutter-review` — Review code quality - `verification-loop` skill — Full verification loop ## Related - Agent: `agents/dart-build-resolver.md` - Skill: `skills/flutter-dart-code-review/`

package/packs/full-harness/rendered/.claude/commands/flutter-review.md

@@ -0,0 +1,6 @@
+---
+description: Review Flutter/Dart code for idiomatic patterns, widget best practices, state management, performance, accessibility, and security. Invokes the flutter-reviewer agent.
+argument-hint: [optional arguments]
+---
+
+# Flutter Code Review This command invokes the **flutter-reviewer** agent to review Flutter/Dart code changes. ## What This Command Does 1. **Gather Context**: Review `git diff --staged` and `git diff` 2. **Inspect Project**: Check `pubspec.yaml`, `analysis_options.yaml`, state management solution 3. **Security Pre-scan**: Check for hardcoded secrets and critical security issues 4. **Full Review**: Apply the complete review checklist 5. **Report Findings**: Output issues grouped by severity with fix guidance ## Prerequisites Before running `/flutter-review`, ensure: 1. **Build passes** — run `/flutter-build` first; a review on broken code is incomplete 2. **Tests pass** — run `/flutter-test` to confirm no regressions 3. **No merge conflicts** — resolve all conflicts so the diff reflects only intentional changes 4. **`flutter analyze` is clean** — fix analyzer warnings before review ## When to Use Use `/flutter-review` when: - Before submitting a PR with Flutter/Dart changes (after build and tests pass) - After implementing a new feature to catch issues early - When reviewing someone else's Flutter code - To audit a widget, state management component, or service class - Before a production release ## Review Areas | Area | Severity | |------|----------| | Hardcoded secrets, cleartext HTTP | CRITICAL | | Architecture violations, state management anti-patterns | CRITICAL | | Widget rebuild issues, resource leaks | HIGH | | Missing `dispose()`, `BuildContext` after await | HIGH | | Dart null safety, missing error/loading states | HIGH | | Const propagation, widget composition | HIGH | | Performance: expensive work in `build()` | HIGH | | Accessibility, semantic labels | MEDIUM | | Missing tests for state transitions | HIGH | | Hardcoded strings (l10n) | MEDIUM | | Pub dependency hygiene | LOW | ## Example Session ````text User: /flutter-review Agent: # Flutter Code Review ## Context Changed files: - lib/features/auth/presentation/login_page.dart - lib/features/auth/data/auth_repository_impl.dart State management: Riverpod (detected from pubspec.yaml) Architecture: feature-first ## Security Pre-scan ✓ No hardcoded secrets detected ✓ No cleartext HTTP calls ## Review Findings [HIGH] BuildContext used after async gap without mounted check File: lib/features/auth/presentation/login_page.dart:67 Issue: `context.go('/home')` called after `await auth.login(...)` with no `mounted` check. Fix: Add `if (!context.mounted) return;` before any navigation after awaits (Flutter 3.7+). [HIGH] AsyncValue error state not handled File: lib/features/auth/presentation/login_page.dart:42 Issue: `ref.watch(authProvider)` switches on loading/data but has no `error` branch. Fix: Add error case to the switch expression or `when()` call to show a user-facing error message. [MEDIUM] Hardcoded string not localized File: lib/features/auth/presentation/login_page.dart:89 Issue: `Text('Login')` — user-visible string not using localization system. Fix: Use the project's l10n accessor: `Text(context.l10n.loginButton)`. ## Review Summary | Severity | Count | Status | |----------|-------|--------| | CRITICAL | 0 | pass | | HIGH | 2 | block | | MEDIUM | 1 | info | | LOW | 0 | note | Verdict: BLOCK — HIGH issues must be fixed before merge. ```` ## Approval Criteria - **Approve**: No CRITICAL or HIGH issues - **Block**: Any CRITICAL or HIGH issues must be fixed before merge ## Related Commands - `/flutter-build` — Fix build errors first - `/flutter-test` — Run tests before reviewing - `/code-review` — General code review (language-agnostic) ## Related - Agent: `agents/flutter-reviewer.md` - Skill: `skills/flutter-dart-code-review/` - Rules: `rules/dart/`

package/packs/full-harness/rendered/.claude/commands/flutter-test.md

@@ -0,0 +1,6 @@
+---
+description: Run Flutter/Dart tests, report failures, and incrementally fix test issues. Covers unit, widget, golden, and integration tests.
+argument-hint: [optional arguments]
+---
+
+# Flutter Test This command runs the Flutter test suite and reports results. When failures occur, it diagnoses and fixes issues incrementally. ## What This Command Does 1. **Run Tests**: Execute `flutter test` (or scope to changed files) 2. **Parse Failures**: Identify failing tests by type and cause 3. **Fix Incrementally**: One failure at a time where possible 4. **Verify**: Re-run after each fix 5. **Report**: Show coverage summary and remaining failures ## When to Use Use `/flutter-test` when: - After implementing a feature to verify nothing broke - After running `/flutter-build` to ensure tests pass - To check test coverage on new code - When a specific test file is failing - Before submitting a PR ## Commands Run ```bash # Run all tests flutter test 2>&1 # Run with coverage flutter test --coverage 2>&1 # Run specific test file flutter test test/unit/domain/usecases/get_user_test.dart 2>&1 # Run tests matching a name pattern flutter test --name "CartBloc" 2>&1 # Run integration tests (requires device/emulator) flutter test integration_test/ 2>&1 # Update golden files when intentional visual changes are made flutter test --update-goldens 2>&1 ``` ## Example Session ````text User: /flutter-test Agent: # Flutter Test Run ## Test Execution ``` $ flutter test 00:05 +42 -2: Some tests failed. FAILED: test/unit/data/user_repository_test.dart UserRepository getById returns null when user not found Expected: null Actual: User(id: 'test-id', name: 'Test User') FAILED: test/widget/cart_page_test.dart CartPage shows empty state when cart is empty Expected: exactly one widget with text 'Your cart is empty' Found: no widget with text 'Your cart is empty' ``` ## Fix 1: Repository Test File: test/unit/data/user_repository_test.dart Failure: `getById` returns a user when it should return null for missing ID Root cause: Test setup adds a user with ID 'test-id' but queries with 'missing-id'. Fix: Updated test to query with 'missing-id' — setup was correct, query was wrong. ``` $ flutter test test/unit/data/user_repository_test.dart 1 test passed. ``` ## Fix 2: Widget Test File: test/widget/cart_page_test.dart Failure: Empty state text widget not found Root cause: Empty state message was renamed from 'Your cart is empty' to 'Cart is empty' in the widget. Fix: Updated test string to match current widget copy. ``` $ flutter test test/widget/cart_page_test.dart 1 test passed. ``` ## Final Run ``` $ flutter test --coverage All 44 tests passed. Coverage: 84.2% (target: 80%) ``` ## Summary | Metric | Value | |--------|-------| | Total tests | 44 | | Passed | 44 | | Failed | 0 | | Coverage | 84.2% | Test Status: PASS ✓ ```` ## Common Test Failures | Failure | Typical Fix | |---------|-------------| | `Expected: <X> Actual: <Y>` | Update assertion or fix implementation | | `Widget not found` | Fix finder selector or update test after widget rename | | `Golden file not found` | Run `flutter test --update-goldens` to generate | | `Golden mismatch` | Inspect diff; run `--update-goldens` if change was intentional | | `MissingPluginException` | Mock platform channel in test setup | | `LateInitializationError` | Initialize `late` fields in `setUp()` | | `pumpAndSettle timed out` | Replace with explicit `pump(Duration)` calls | ## Related Commands - `/flutter-build` — Fix build errors before running tests - `/flutter-review` — Review code after tests pass - `tdd-workflow` skill — Test-driven development workflow ## Related - Agent: `agents/flutter-reviewer.md` - Agent: `agents/dart-build-resolver.md` - Skill: `skills/flutter-dart-code-review/` - Rules: `rules/dart/testing.md`

package/packs/full-harness/rendered/.claude/commands/gan-build.md

@@ -0,0 +1,6 @@
+---
+description: Run a generator/evaluator build loop for implementation tasks with bounded iterations and scoring.
+argument-hint: [optional arguments]
+---
+
+Parse the following from $ARGUMENTS: 1. `brief` — the user's one-line description of what to build 2. `--max-iterations N` — (optional, default 15) maximum generator-evaluator cycles 3. `--pass-threshold N` — (optional, default 7.0) weighted score to pass 4. `--skip-planner` — (optional) skip planner, assume spec.md already exists 5. `--eval-mode MODE` — (optional, default "playwright") one of: playwright, screenshot, code-only ## GAN-Style Harness Build This command orchestrates a three-agent build loop inspired by Anthropic's March 2026 harness design paper. ### Phase 0: Setup 1. Create `gan-harness/` directory in project root 2. Create subdirectories: `gan-harness/feedback/`, `gan-harness/screenshots/` 3. Initialize git if not already initialized 4. Log start time and configuration ### Phase 1: Planning (Planner Agent) Unless `--skip-planner` is set: 1. Launch the `gan-planner` agent via Task tool with the user's brief 2. Wait for it to produce `gan-harness/spec.md` and `gan-harness/eval-rubric.md` 3. Display the spec summary to the user 4. Proceed to Phase 2 ### Phase 2: Generator-Evaluator Loop ``` iteration = 1 while iteration <= max_iterations: # GENERATE Launch gan-generator agent via Task tool: - Read spec.md - If iteration > 1: read feedback/feedback-{iteration-1}.md - Build/improve the application - Ensure dev server is running - Commit changes # Wait for generator to finish # EVALUATE Launch gan-evaluator agent via Task tool: - Read eval-rubric.md and spec.md - Test the live application (mode: playwright/screenshot/code-only) - Score against rubric - Write feedback to feedback/feedback-{iteration}.md # Wait for evaluator to finish # CHECK SCORE Read feedback/feedback-{iteration}.md Extract weighted total score if score >= pass_threshold: Log "PASSED at iteration {iteration} with score {score}" Break if iteration >= 3 and score has not improved in last 2 iterations: Log "PLATEAU detected — stopping early" Break iteration += 1 ``` ### Phase 3: Summary 1. Read all feedback files 2. Display final scores and iteration history 3. Show score progression: `iteration 1: 4.2 → iteration 2: 5.8 → ... → iteration N: 7.5` 4. List any remaining issues from the final evaluation 5. Report total time and estimated cost ### Output ```markdown ## GAN Harness Build Report **Brief:** [original prompt] **Result:** PASS/FAIL **Iterations:** N / max **Final Score:** X.X / 10 ### Score Progression | Iter | Design | Originality | Craft | Functionality | Total | |------|--------|-------------|-------|---------------|-------| | 1 | ... | ... | ... | ... | X.X | | 2 | ... | ... | ... | ... | X.X | | N | ... | ... | ... | ... | X.X | ### Remaining Issues - [Any issues from final evaluation] ### Files Created - gan-harness/spec.md - gan-harness/eval-rubric.md - gan-harness/feedback/feedback-001.md through feedback-NNN.md - gan-harness/generator-state.md - gan-harness/build-report.md ``` Write the full report to `gan-harness/build-report.md`.

package/packs/full-harness/rendered/.claude/commands/gan-design.md

@@ -0,0 +1,6 @@
+---
+description: Run a generator/evaluator design loop for frontend or visual work with bounded iterations and scoring.
+argument-hint: [optional arguments]
+---
+
+Parse the following from $ARGUMENTS: 1. `brief` — the user's description of the design to create 2. `--max-iterations N` — (optional, default 10) maximum design-evaluate cycles 3. `--pass-threshold N` — (optional, default 7.5) weighted score to pass (higher default for design) ## GAN-Style Design Harness A two-agent loop (Generator + Evaluator) focused on frontend design quality. No planner — the brief IS the spec. This is the same mode Anthropic used for their frontend design experiments, where they saw creative breakthroughs like the 3D Dutch art museum with CSS perspective and doorway navigation. ### Setup 1. Create `gan-harness/` directory 2. Write the brief directly as `gan-harness/spec.md` 3. Write a design-focused `gan-harness/eval-rubric.md` with extra weight on Design Quality and Originality ### Design-Specific Eval Rubric ```markdown ### Design Quality (weight: 0.35) ### Originality (weight: 0.30) ### Craft (weight: 0.25) ### Functionality (weight: 0.10) ``` Note: Originality weight is higher (0.30 vs 0.20) to push for creative breakthroughs. Functionality weight is lower since design mode focuses on visual quality. ### Loop Same as `/project:gan-build` Phase 2, but: - Skip the planner - Use the design-focused rubric - Generator prompt emphasizes visual quality over feature completeness - Evaluator prompt emphasizes "would this win a design award?" over "do all features work?" ### Key Difference from gan-build The Generator is told: "Your PRIMARY goal is visual excellence. A stunning half-finished app beats a functional ugly one. Push for creative leaps — unusual layouts, custom animations, distinctive color work."

package/packs/full-harness/rendered/.claude/commands/go-build.md

@@ -0,0 +1,6 @@
+---
+description: Fix Go build errors, go vet warnings, and linter issues incrementally. Invokes the go-build-resolver agent for minimal, surgical fixes.
+argument-hint: [optional arguments]
+---
+
+# Go Build and Fix This command invokes the **go-build-resolver** agent to incrementally fix Go build errors with minimal changes. ## What This Command Does 1. **Run Diagnostics**: Execute `go build`, `go vet`, `staticcheck` 2. **Parse Errors**: Group by file and sort by severity 3. **Fix Incrementally**: One error at a time 4. **Verify Each Fix**: Re-run build after each change 5. **Report Summary**: Show what was fixed and what remains ## When to Use Use `/go-build` when: - `go build ./...` fails with errors - `go vet ./...` reports issues - `golangci-lint run` shows warnings - Module dependencies are broken - After pulling changes that break the build ## Diagnostic Commands Run ```bash # Primary build check go build ./... # Static analysis go vet ./... # Extended linting (if available) staticcheck ./... golangci-lint run # Module issues go mod verify go mod tidy -v ``` ## Example Session ```text User: /go-build Agent: # Go Build Resolution ## Initial Diagnostics ```bash $ go build ./... internal/service/user.go:25:15: undefined: UserRepository internal/handler/api.go:42:9: cannot use x (type string) as type int internal/handler/api.go:58:2: missing return at end of function ``` Errors found: 3 ## Fix 1: Undefined Identifier File: internal/service/user.go:25 Error: undefined: UserRepository Cause: Missing import ```go // Added import import "project/internal/repository" // Changed var repo UserRepository // To var repo repository.UserRepository ``` ```bash $ go build ./... # 2 errors remaining ``` ## Fix 2: Type Mismatch File: internal/handler/api.go:42 Error: cannot use x (type string) as type int ```go // Changed count := params.Get("count") // To countStr := params.Get("count") count, _ := strconv.Atoi(countStr) ``` ```bash $ go build ./... # 1 error remaining ``` ## Fix 3: Missing Return File: internal/handler/api.go:58 Error: missing return at end of function ```go func GetUser(id string) (*User, error) { if id == "" { return nil, ErrInvalidID } user := findUser(id) // Added missing return return user, nil } ``` ```bash $ go build ./... # Build successful! ``` ## Final Verification ```bash $ go vet ./... # No issues $ go test ./... ok project/internal/service 0.015s ok project/internal/handler 0.023s ``` ## Summary | Metric | Count | |--------|-------| | Build errors fixed | 3 | | Vet warnings fixed | 0 | | Files modified | 2 | | Remaining issues | 0 | Build Status: PASS: SUCCESS ``` ## Common Errors Fixed | Error | Typical Fix | |-------|-------------| | `undefined: X` | Add import or fix typo | | `cannot use X as Y` | Type conversion or fix assignment | | `missing return` | Add return statement | | `X does not implement Y` | Add missing method | | `import cycle` | Restructure packages | | `declared but not used` | Remove or use variable | | `cannot find package` | `go get` or `go mod tidy` | ## Fix Strategy 1. **Build errors first** - Code must compile 2. **Vet warnings second** - Fix suspicious constructs 3. **Lint warnings third** - Style and best practices 4. **One fix at a time** - Verify each change 5. **Minimal changes** - Don't refactor, just fix ## Stop Conditions The agent will stop and report if: - Same error persists after 3 attempts - Fix introduces more errors - Requires architectural changes - Missing external dependencies ## Related Commands - `/go-test` - Run tests after build succeeds - `/go-review` - Review code quality - `verification-loop` skill - Full verification loop ## Related - Agent: `agents/go-build-resolver.md` - Skill: `skills/golang-patterns/`

package/packs/full-harness/rendered/.claude/commands/go-review.md

@@ -0,0 +1,6 @@
+---
+description: Comprehensive Go code review for idiomatic patterns, concurrency safety, error handling, and security. Invokes the go-reviewer agent.
+argument-hint: [optional arguments]
+---
+
+# Go Code Review This command invokes the **go-reviewer** agent for comprehensive Go-specific code review. ## What This Command Does 1. **Identify Go Changes**: Find modified `.go` files via `git diff` 2. **Run Static Analysis**: Execute `go vet`, `staticcheck`, and `golangci-lint` 3. **Security Scan**: Check for SQL injection, command injection, race conditions 4. **Concurrency Review**: Analyze goroutine safety, channel usage, mutex patterns 5. **Idiomatic Go Check**: Verify code follows Go conventions and best practices 6. **Generate Report**: Categorize issues by severity ## When to Use Use `/go-review` when: - After writing or modifying Go code - Before committing Go changes - Reviewing pull requests with Go code - Onboarding to a new Go codebase - Learning idiomatic Go patterns ## Review Categories ### CRITICAL (Must Fix) - SQL/Command injection vulnerabilities - Race conditions without synchronization - Goroutine leaks - Hardcoded credentials - Unsafe pointer usage - Ignored errors in critical paths ### HIGH (Should Fix) - Missing error wrapping with context - Panic instead of error returns - Context not propagated - Unbuffered channels causing deadlocks - Interface not satisfied errors - Missing mutex protection ### MEDIUM (Consider) - Non-idiomatic code patterns - Missing godoc comments on exports - Inefficient string concatenation - Slice not preallocated - Table-driven tests not used ## Automated Checks Run ```bash # Static analysis go vet ./... # Advanced checks (if installed) staticcheck ./... golangci-lint run # Race detection go build -race ./... # Security vulnerabilities govulncheck ./... ``` ## Example Usage ```text User: /go-review Agent: # Go Code Review Report ## Files Reviewed - internal/handler/user.go (modified) - internal/service/auth.go (modified) ## Static Analysis Results ✓ go vet: No issues ✓ staticcheck: No issues ## Issues Found [CRITICAL] Race Condition File: internal/service/auth.go:45 Issue: Shared map accessed without synchronization ```go var cache = map[string]*Session{} // Concurrent access! func GetSession(id string) *Session { return cache[id] // Race condition } ``` Fix: Use sync.RWMutex or sync.Map ```go var ( cache = map[string]*Session{} cacheMu sync.RWMutex ) func GetSession(id string) *Session { cacheMu.RLock() defer cacheMu.RUnlock() return cache[id] } ``` [HIGH] Missing Error Context File: internal/handler/user.go:28 Issue: Error returned without context ```go return err // No context ``` Fix: Wrap with context ```go return fmt.Errorf("get user %s: %w", userID, err) ``` ## Summary - CRITICAL: 1 - HIGH: 1 - MEDIUM: 0 Recommendation: FAIL: Block merge until CRITICAL issue is fixed ``` ## Approval Criteria | Status | Condition | |--------|-----------| | PASS: Approve | No CRITICAL or HIGH issues | | WARNING: Warning | Only MEDIUM issues (merge with caution) | | FAIL: Block | CRITICAL or HIGH issues found | ## Integration with Other Commands - Use `/go-test` first to ensure tests pass - Use `/go-build` if build errors occur - Use `/go-review` before committing - Use `/code-review` for non-Go specific concerns ## Related - Agent: `agents/go-reviewer.md` - Skills: `skills/golang-patterns/`, `skills/golang-testing/`

package/packs/full-harness/rendered/.claude/commands/go-test.md

@@ -0,0 +1,6 @@
+---
+description: Enforce TDD workflow for Go. Write table-driven tests first, then implement. Verify 80%+ coverage with go test -cover.
+argument-hint: [optional arguments]
+---
+
+# Go TDD Command This command enforces test-driven development methodology for Go code using idiomatic Go testing patterns. ## What This Command Does 1. **Define Types/Interfaces**: Scaffold function signatures first 2. **Write Table-Driven Tests**: Create comprehensive test cases (RED) 3. **Run Tests**: Verify tests fail for the right reason 4. **Implement Code**: Write minimal code to pass (GREEN) 5. **Refactor**: Improve while keeping tests green 6. **Check Coverage**: Ensure 80%+ coverage ## When to Use Use `/go-test` when: - Implementing new Go functions - Adding test coverage to existing code - Fixing bugs (write failing test first) - Building critical business logic - Learning TDD workflow in Go ## TDD Cycle ``` RED → Write failing table-driven test GREEN → Implement minimal code to pass REFACTOR → Improve code, tests stay green REPEAT → Next test case ``` ## Example Session ```` User: /go-test I need a function to validate email addresses Agent: # TDD Session: Email Validator ## Step 1: Define Interface ```go // validator/email.go package validator // ValidateEmail checks if the given string is a valid email address. // Returns nil if valid, error describing the issue otherwise. func ValidateEmail(email string) error { panic("not implemented") } ``` ## Step 2: Write Table-Driven Tests (RED) ```go // validator/email_test.go package validator import ( "testing" ) func TestValidateEmail(t *testing.T) { tests := []struct { name string email string wantErr bool }{ // Valid emails {"simple email", "user@example.com", false}, {"with subdomain", "user@mail.example.com", false}, {"with plus", "user+tag@example.com", false}, {"with dots", "first.last@example.com", false}, // Invalid emails {"empty string", "", true}, {"no at sign", "userexample.com", true}, {"no domain", "user@", true}, {"no local part", "@example.com", true}, {"double at", "user@@example.com", true}, {"spaces", "user @example.com", true}, {"no tld", "user@example", true}, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { err := ValidateEmail(tt.email) if tt.wantErr && err == nil { t.Errorf("ValidateEmail(%q) = nil; want error", tt.email) } if !tt.wantErr && err != nil { t.Errorf("ValidateEmail(%q) = %v; want nil", tt.email, err) } }) } } ``` ## Step 3: Run Tests - Verify FAIL ```bash $ go test ./validator/... --- FAIL: TestValidateEmail (0.00s) --- FAIL: TestValidateEmail/simple_email (0.00s) panic: not implemented FAIL ``` ✓ Tests fail as expected (panic). ## Step 4: Implement Minimal Code (GREEN) ```go // validator/email.go package validator import ( "errors" "regexp" ) var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`) var ( ErrEmailEmpty = errors.New("email cannot be empty") ErrEmailInvalid = errors.New("email format is invalid") ) func ValidateEmail(email string) error { if email == "" { return ErrEmailEmpty } if !emailRegex.MatchString(email) { return ErrEmailInvalid } return nil } ``` ## Step 5: Run Tests - Verify PASS ```bash $ go test ./validator/... PASS ok project/validator 0.003s ``` ✓ All tests passing! ## Step 6: Check Coverage ```bash $ go test -cover ./validator/... PASS coverage: 100.0% of statements ok project/validator 0.003s ``` ✓ Coverage: 100% ## TDD Complete! ```` ## Test Patterns ### Table-Driven Tests ```go tests := []struct { name string input InputType want OutputType wantErr bool }{ {"case 1", input1, want1, false}, {"case 2", input2, want2, true}, } for _, tt := range tests { t.Run(tt.name, func(t *testing.T) { got, err := Function(tt.input) // assertions }) } ``` ### Parallel Tests ```go for _, tt := range tests { tt := tt // Capture t.Run(tt.name, func(t *testing.T) { t.Parallel() // test body }) } ``` ### Test Helpers ```go func setupTestDB(t *testing.T) *sql.DB { t.Helper() db := createDB() t.Cleanup(func() { db.Close() }) return db } ``` ## Coverage Commands ```bash # Basic coverage go test -cover ./... # Coverage profile go test -coverprofile=coverage.out ./... # View in browser go tool cover -html=coverage.out # Coverage by function go tool cover -func=coverage.out # With race detection go test -race -cover ./... ``` ## Coverage Targets | Code Type | Target | |-----------|--------| | Critical business logic | 100% | | Public APIs | 90%+ | | General code | 80%+ | | Generated code | Exclude | ## TDD Best Practices **DO:** - Write test FIRST, before any implementation - Run tests after each change - Use table-driven tests for comprehensive coverage - Test behavior, not implementation details - Include edge cases (empty, nil, max values) **DON'T:** - Write implementation before tests - Skip the RED phase - Test private functions directly - Use `time.Sleep` in tests - Ignore flaky tests ## Related Commands - `/go-build` - Fix build errors - `/go-review` - Review code after implementation - `verification-loop` skill - Run full verification loop ## Related - Skill: `skills/golang-testing/` - Skill: `skills/tdd-workflow/`

package/packs/full-harness/rendered/.claude/commands/gradle-build.md

@@ -0,0 +1,6 @@
+---
+description: Fix Gradle build errors for Android and KMP projects
+argument-hint: [optional arguments]
+---
+
+# Gradle Build Fix Incrementally fix Gradle build and compilation errors for Android and Kotlin Multiplatform projects. ## Step 1: Detect Build Configuration Identify the project type and run the appropriate build: | Indicator | Build Command | |-----------|---------------| | `build.gradle.kts` + `composeApp/` (KMP) | `./gradlew composeApp:compileKotlinMetadata 2>&1` | | `build.gradle.kts` + `app/` (Android) | `./gradlew app:compileDebugKotlin 2>&1` | | `settings.gradle.kts` with modules | `./gradlew assemble 2>&1` | | Detekt configured | `./gradlew detekt 2>&1` | Also check `gradle.properties` and `local.properties` for configuration. ## Step 2: Parse and Group Errors 1. Run the build command and capture output 2. Separate Kotlin compilation errors from Gradle configuration errors 3. Group by module and file path 4. Sort: configuration errors first, then compilation errors by dependency order ## Step 3: Fix Loop For each error: 1. **Read the file** — Full context around the error line 2. **Diagnose** — Common categories: - Missing import or unresolved reference - Type mismatch or incompatible types - Missing dependency in `build.gradle.kts` - Expect/actual mismatch (KMP) - Compose compiler error 3. **Fix minimally** — Smallest change that resolves the error 4. **Re-run build** — Verify fix and check for new errors 5. **Continue** — Move to next error ## Step 4: Guardrails Stop and ask the user if: - Fix introduces more errors than it resolves - Same error persists after 3 attempts - Error requires adding new dependencies or changing module structure - Gradle sync itself fails (configuration-phase error) - Error is in generated code (Room, SQLDelight, KSP) ## Step 5: Summary Report: - Errors fixed (module, file, description) - Errors remaining - New errors introduced (should be zero) - Suggested next steps ## Common Gradle/KMP Fixes | Error | Fix | |-------|-----| | Unresolved reference in `commonMain` | Check if the dependency is in `commonMain.dependencies {}` | | Expect declaration without actual | Add `actual` implementation in each platform source set | | Compose compiler version mismatch | Align Kotlin and Compose compiler versions in `libs.versions.toml` | | Duplicate class | Check for conflicting dependencies with `./gradlew dependencies` | | KSP error | Run `./gradlew kspCommonMainKotlinMetadata` to regenerate | | Configuration cache issue | Check for non-serializable task inputs |

package/packs/full-harness/rendered/.claude/commands/harness-audit.md

@@ -0,0 +1,6 @@
+---
+description: Run a deterministic repository harness audit and return a prioritized scorecard.
+argument-hint: [optional arguments]
+---
+
+# Harness Audit Command Run a deterministic repository harness audit and return a prioritized scorecard. ## Usage `/harness-audit [scope] [--format text|json] [--root path]` - `scope` (optional): `repo` (default), `hooks`, `skills`, `commands`, `agents` - `--format`: output style (`text` default, `json` for automation) - `--root`: audit a specific path instead of the current working directory ## Deterministic Engine Always run: ```bash node scripts/harness-audit.js <scope> --format <text|json> [--root <path>] ``` This script is the source of truth for scoring and checks. Do not invent additional dimensions or ad-hoc points. Rubric version: `2026-05-19`. The script computes up to 12 fixed categories (`0-10` normalized each). The first seven are always applicable; GitHub Integration is always applicable; deploy-target categories are applicable only when a matching marker is detected. 1. Tool Coverage 2. Context Efficiency 3. Quality Gates 4. Memory Persistence 5. Eval Coverage 6. Security Guardrails 7. Cost Efficiency 8. GitHub Integration 9. Vercel Integration *(when `vercel.json` or `.vercel/` is present)* 10. Netlify Integration *(when `netlify.toml` or `.netlify/` is present)* 11. Cloudflare Integration *(when `wrangler.toml` or `wrangler.jsonc` is present)* 12. Fly Integration *(when `fly.toml` is present)* Scores are derived from explicit file/rule checks and are reproducible for the same commit. The script audits the current working directory by default and auto-detects whether the target is the ECC repo itself or a consumer project using ECC. ## Output Contract Return: 1. `overall_score` out of `max_score`. `max_score` depends on which categories are applicable to the target; never assume a fixed total. 2. `applicable_categories[]` and `category_count` describing which categories contributed. 3. Category scores and concrete findings. 4. Failed checks with exact file paths. 5. Top 3 actions from the deterministic output (`top_actions`). 6. Suggested ECC skills to apply next. ## Checklist - Use script output directly; do not rescore manually. - If `--format json` is requested, return the script JSON unchanged. - If text is requested, summarize failing checks and top actions. - Include exact file paths from `checks[]` and `top_actions[]`. ## Example Result ```text Harness Audit (repo, repo): 71/80 - Tool Coverage: 10/10 (10/10 pts) - Context Efficiency: 9/10 (9/10 pts) - Quality Gates: 10/10 (10/10 pts) - GitHub Integration: 2/10 (2/10 pts) Top 3 Actions: 1) [GitHub Integration] Add at least one workflow under .github/workflows/. (.github/workflows/) 2) [Security Guardrails] Add prompt/tool preflight security guards in hooks/hooks.json. (hooks/hooks.json) 3) [Eval Coverage] Increase automated test coverage across scripts/hooks/lib. (tests/) ``` ## Arguments $ARGUMENTS: - `repo|hooks|skills|commands|agents` (optional scope) - `--format text|json` (optional output format)

package/packs/full-harness/rendered/.claude/commands/hookify-configure.md

@@ -0,0 +1,6 @@
+---
+description: Enable or disable hookify rules interactively
+argument-hint: [optional arguments]
+---
+
+Interactively enable or disable existing hookify rules. ## Steps 1. Find all `.claude/hookify.*.local.md` files 2. Read the current state of each rule 3. Present the list with current enabled / disabled status 4. Ask which rules to toggle 5. Update the `enabled:` field in the selected rule files 6. Confirm the changes

package/packs/full-harness/rendered/.claude/commands/hookify-help.md

@@ -0,0 +1,6 @@
+---
+description: Get help with the hookify system
+argument-hint: [optional arguments]
+---
+
+Display comprehensive hookify documentation. ## Hook System Overview Hookify creates rule files that integrate with Claude Code's hook system to prevent unwanted behaviors. ### Event Types - `bash`: triggers on Bash tool use and matches command patterns - `file`: triggers on Write/Edit tool use and matches file paths - `stop`: triggers when a session ends - `prompt`: triggers on user message submission and matches input patterns - `all`: triggers on all events ### Rule File Format Files are stored as `.claude/hookify.{name}.local.md`: ```yaml --- name: descriptive-name enabled: true event: bash|file|stop|prompt|all action: block|warn pattern: "regex pattern to match" --- Message to display when rule triggers. Supports multiple lines. ``` ### Commands - `/hookify [description]` creates new rules and auto-analyzes the conversation when no description is given - `/hookify-list` lists configured rules - `/hookify-configure` toggles rules on or off ### Pattern Tips - use regex syntax - for `bash`, match against the full command string - for `file`, match against the file path - test patterns before deploying

package/packs/full-harness/rendered/.claude/commands/hookify-list.md

@@ -0,0 +1,6 @@
+---
+description: List all configured hookify rules
+argument-hint: [optional arguments]
+---
+
+Find and display all hookify rules in a formatted table. ## Steps 1. Find all `.claude/hookify.*.local.md` files 2. Read each file's frontmatter: - `name` - `enabled` - `event` - `action` - `pattern` 3. Display them as a table: | Rule | Enabled | Event | Pattern | File | |------|---------|-------|---------|------| 4. Show the rule count and remind the user that `/hookify-configure` can change state later.

package/packs/full-harness/rendered/.claude/commands/hookify.md

@@ -0,0 +1,6 @@
+---
+description: Create hooks to prevent unwanted behaviors from conversation analysis or explicit instructions
+argument-hint: [optional arguments]
+---
+
+Create hook rules to prevent unwanted Claude Code behaviors by analyzing conversation patterns or explicit user instructions. ## Usage `/hookify [description of behavior to prevent]` If no arguments are provided, analyze the current conversation to find behaviors worth preventing. ## Workflow ### Step 1: Gather Behavior Info - With arguments: parse the user's description of the unwanted behavior - Without arguments: use the `conversation-analyzer` agent to find: - explicit corrections - frustrated reactions to repeated mistakes - reverted changes - repeated similar issues ### Step 2: Present Findings Show the user: - behavior description - proposed event type - proposed pattern or matcher - proposed action ### Step 3: Generate Rule Files For each approved rule, create a file at `.claude/hookify.{name}.local.md`: ```yaml --- name: rule-name enabled: true event: bash|file|stop|prompt|all action: block|warn pattern: "regex pattern" --- Message shown when rule triggers. ``` ### Step 4: Confirm Report created rules and how to manage them with `/hookify-list` and `/hookify-configure`.

package/packs/full-harness/rendered/.claude/commands/instinct-export.md

@@ -0,0 +1,6 @@
+---
+description: Export instincts from project/global scope to a file
+argument-hint: [optional arguments]
+---
+
+# Instinct Export Command Exports instincts to a shareable format. Perfect for: - Sharing with teammates - Transferring to a new machine - Contributing to project conventions ## Usage ``` /instinct-export # Export all personal instincts /instinct-export --domain testing # Export only testing instincts /instinct-export --min-confidence 0.7 # Only export high-confidence instincts /instinct-export --output team-instincts.yaml /instinct-export --scope project --output project-instincts.yaml ``` ## What to Do 1. Detect current project context 2. Load instincts by selected scope: - `project`: current project only - `global`: global only - `all`: project + global merged (default) 3. Apply filters (`--domain`, `--min-confidence`) 4. Write YAML-style export to file (or stdout if no output path provided) ## Output Format Creates a YAML file: ```yaml # Instincts Export # Generated: 2025-01-22 # Source: personal # Count: 12 instincts --- id: prefer-functional-style trigger: "when writing new functions" confidence: 0.8 domain: code-style source: session-observation scope: project project_id: a1b2c3d4e5f6 project_name: my-app --- # Prefer Functional Style ## Action Use functional patterns over classes. ``` ## Flags - `--domain <name>`: Export only specified domain - `--min-confidence <n>`: Minimum confidence threshold - `--output <file>`: Output file path (prints to stdout when omitted) - `--scope <project|global|all>`: Export scope (default: `all`)

package/packs/full-harness/rendered/.claude/commands/instinct-import.md

@@ -0,0 +1,6 @@
+---
+description: Import instincts from file or URL into project/global scope
+argument-hint: [optional arguments]
+---
+
+# Instinct Import Command ## Implementation Run the instinct CLI using the plugin root path: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" import <file-or-url> [--dry-run] [--force] [--min-confidence 0.7] [--scope project|global] ``` Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation): ```bash python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py import <file-or-url> ``` Import instincts from local file paths or HTTP(S) URLs. ## Usage ``` /instinct-import team-instincts.yaml /instinct-import https://github.com/org/repo/instincts.yaml /instinct-import team-instincts.yaml --dry-run /instinct-import team-instincts.yaml --scope global --force ``` ## What to Do 1. Fetch the instinct file (local path or URL) 2. Parse and validate the format 3. Check for duplicates with existing instincts 4. Merge or add new instincts 5. Save to inherited instincts directory: - Project scope: `~/.claude/homunculus/projects/<project-id>/instincts/inherited/` - Global scope: `~/.claude/homunculus/instincts/inherited/` ## Import Process ``` Importing instincts from: team-instincts.yaml ================================================ Found 12 instincts to import. Analyzing conflicts... ## New Instincts (8) These will be added: ✓ use-zod-validation (confidence: 0.7) ✓ prefer-named-exports (confidence: 0.65) ✓ test-async-functions (confidence: 0.8) ... ## Duplicate Instincts (3) Already have similar instincts: WARNING: prefer-functional-style Local: 0.8 confidence, 12 observations Import: 0.7 confidence → Keep local (higher confidence) WARNING: test-first-workflow Local: 0.75 confidence Import: 0.9 confidence → Update to import (higher confidence) Import 8 new, update 1? ``` ## Merge Behavior When importing an instinct with an existing ID: - Higher-confidence import becomes an update candidate - Equal/lower-confidence import is skipped - User confirms unless `--force` is used ## Source Tracking Imported instincts are marked with: ```yaml source: inherited scope: project imported_from: "team-instincts.yaml" project_id: "a1b2c3d4e5f6" project_name: "my-project" ``` ## Flags - `--dry-run`: Preview without importing - `--force`: Skip confirmation prompt - `--min-confidence <n>`: Only import instincts above threshold - `--scope <project|global>`: Select target scope (default: `project`) ## Output After import: ``` PASS: Import complete! Added: 8 instincts Updated: 1 instinct Skipped: 3 instincts (equal/higher confidence already exists) New instincts saved to: ~/.claude/homunculus/instincts/inherited/ Run /instinct-status to see all instincts. ```

package/packs/full-harness/rendered/.claude/commands/instinct-status.md

@@ -0,0 +1,6 @@
+---
+description: Show learned instincts (project + global) with confidence
+argument-hint: [optional arguments]
+---
+
+# Instinct Status Command Shows learned instincts for the current project plus global instincts, grouped by domain. ## Implementation Run the instinct CLI, resolving the active ECC plugin root the same way `hooks/hooks.json` and the other slash commands (`/sessions`, `/skill-health`) do — env var → standard install → known plugin roots → plugin cache → fallback. This avoids the divergence that happens when `CLAUDE_PLUGIN_ROOT` is unset while a legacy `~/.claude/skills/continuous-learning-v2/` directory still exists (#2037). ```bash ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var r=(function(){var p=require('path'),f=require('fs'),o=require('os');var e=process.env.CLAUDE_PLUGIN_ROOT;if(e&&e.trim())return e.trim();var d=p.join(o.homedir(),'.claude');function L(x){try{return require(p.join(x,'scripts','lib','resolve-ecc-root')).resolveEccRoot()}catch(_){return null}}var r=L(d);if(r)return r;var s=['ecc','ecc@ecc','marketplaces/ecc','everything-claude-code','everything-claude-code@everything-claude-code','marketplaces/everything-claude-code'];for(var i=0;i<s.length;i++){r=L(p.join(d,'plugins',s[i]));if(r)return r}try{var g=['ecc','everything-claude-code'];for(var j=0;j<g.length;j++){var c=p.join(d,'plugins','cache',g[j]);var O=f.readdirSync(c);for(var k=0;k<O.length;k++){var q=p.join(c,O[k]);var V=f.readdirSync(q);for(var m=0;m<V.length;m++){r=L(p.join(q,V[m]));if(r)return r}}}}catch(_){}return d})();console.log(r)")}" python3 "$ECC_ROOT/skills/continuous-learning-v2/scripts/instinct-cli.py" status ``` ## Usage ``` /instinct-status ``` ## What to Do 1. Detect current project context (git remote/path hash) 2. Read project instincts from `~/.claude/homunculus/projects/<project-id>/instincts/` 3. Read global instincts from `~/.claude/homunculus/instincts/` 4. Merge with precedence rules (project overrides global when IDs collide) 5. Display grouped by domain with confidence bars and observation stats ## Output Format ``` ============================================================ INSTINCT STATUS - 12 total ============================================================ Project: my-app (a1b2c3d4e5f6) Project instincts: 8 Global instincts: 4 ## PROJECT-SCOPED (my-app) ### WORKFLOW (3) ███████░░░ 70% grep-before-edit [project] trigger: when modifying code ## GLOBAL (apply to all projects) ### SECURITY (2) █████████░ 85% validate-user-input [global] trigger: when handling user input ```

package/packs/full-harness/rendered/.claude/commands/jira.md

@@ -0,0 +1,6 @@
+---
+description: Retrieve a Jira ticket, analyze requirements, update status, or add comments. Uses the jira-integration skill and MCP or REST API.
+argument-hint: [optional arguments]
+---
+
+# Jira Command Interact with Jira tickets directly from your workflow — fetch tickets, analyze requirements, add comments, and transition status. ## Usage ``` /jira get <TICKET-KEY> # Fetch and analyze a ticket /jira comment <TICKET-KEY> # Add a progress comment /jira transition <TICKET-KEY> # Change ticket status /jira search <JQL> # Search issues with JQL ``` ## What This Command Does 1. **Get & Analyze** — Fetch a Jira ticket and extract requirements, acceptance criteria, test scenarios, and dependencies 2. **Comment** — Add structured progress updates to a ticket 3. **Transition** — Move a ticket through workflow states (To Do → In Progress → Done) 4. **Search** — Find issues using JQL queries ## How It Works ### `/jira get <TICKET-KEY>` 1. Fetch the ticket from Jira (via MCP `jira_get_issue` or REST API) 2. Extract all fields: summary, description, acceptance criteria, priority, labels, linked issues 3. Optionally fetch comments for additional context 4. Produce a structured analysis: ``` Ticket: PROJ-1234 Summary: [title] Status: [status] Priority: [priority] Type: [Story/Bug/Task] Requirements: 1. [extracted requirement] 2. [extracted requirement] Acceptance Criteria: - [ ] [criterion from ticket] Test Scenarios: - Happy Path: [description] - Error Case: [description] - Edge Case: [description] Dependencies: - [linked issues, APIs, services] Recommended Next Steps: - /plan to create implementation plan - `tdd-workflow` skill to implement with tests first ``` ### `/jira comment <TICKET-KEY>` 1. Summarize current session progress (what was built, tested, committed) 2. Format as a structured comment 3. Post to the Jira ticket ### `/jira transition <TICKET-KEY>` 1. Fetch available transitions for the ticket 2. Show options to user 3. Execute the selected transition ### `/jira search <JQL>` 1. Execute the JQL query against Jira 2. Return a summary table of matching issues ## Prerequisites This command requires Jira credentials. Choose one: **Option A — MCP Server (recommended):** Add `jira` to your `mcpServers` config (see `mcp-configs/mcp-servers.json` for the template). **Option B — Environment variables:** ```bash export JIRA_URL="https://yourorg.atlassian.net" export JIRA_EMAIL="your.email@example.com" export JIRA_API_TOKEN="your-api-token" ``` If credentials are missing, stop and direct the user to set them up. ## Integration with Other Commands After analyzing a ticket: - Use `/plan` to create an implementation plan from the requirements - Use the `tdd-workflow` skill to implement with test-driven development - Use `/code-review` after implementation - Use `/jira comment` to post progress back to the ticket - Use `/jira transition` to move the ticket when work is complete ## Related - **Skill:** `skills/jira-integration/` - **MCP config:** `mcp-configs/mcp-servers.json` → `jira`

package/packs/full-harness/rendered/.claude/commands/kotlin-build.md

@@ -0,0 +1,6 @@
+---
+description: Fix Kotlin/Gradle build errors, compiler warnings, and dependency issues incrementally. Invokes the kotlin-build-resolver agent for minimal, surgical fixes.
+argument-hint: [optional arguments]
+---
+
+# Kotlin Build and Fix This command invokes the **kotlin-build-resolver** agent to incrementally fix Kotlin build errors with minimal changes. ## What This Command Does 1. **Run Diagnostics**: Execute `./gradlew build`, `detekt`, `ktlintCheck` 2. **Parse Errors**: Group by file and sort by severity 3. **Fix Incrementally**: One error at a time 4. **Verify Each Fix**: Re-run build after each change 5. **Report Summary**: Show what was fixed and what remains ## When to Use Use `/kotlin-build` when: - `./gradlew build` fails with errors - Kotlin compiler reports errors - `./gradlew detekt` reports violations - Gradle dependency resolution fails - After pulling changes that break the build ## Diagnostic Commands Run ```bash # Primary build check ./gradlew build 2>&1 # Static analysis ./gradlew detekt 2>&1 || echo "detekt not configured" ./gradlew ktlintCheck 2>&1 || echo "ktlint not configured" # Dependency issues ./gradlew dependencies --configuration runtimeClasspath 2>&1 | head -100 # Optional deep refresh when caches or dependency metadata are suspect ./gradlew build --refresh-dependencies ``` ## Example Session ````text User: /kotlin-build Agent: # Kotlin Build Resolution ## Initial Diagnostics ```bash $ ./gradlew build e: src/main/kotlin/com/example/service/UserService.kt:25:15 Unresolved reference: UserRepository e: src/main/kotlin/com/example/routes/UserRoutes.kt:42:9 Type mismatch: inferred type is String but Int was expected e: src/main/kotlin/com/example/routes/UserRoutes.kt:58:5 'when' expression must be exhaustive ``` Errors found: 3 ## Fix 1: Unresolved Reference File: src/main/kotlin/com/example/service/UserService.kt:25 Error: Unresolved reference: UserRepository Cause: Missing import ```kotlin // Added import import com.example.repository.UserRepository ``` ```bash $ ./gradlew build # 2 errors remaining ``` ## Fix 2: Type Mismatch File: src/main/kotlin/com/example/routes/UserRoutes.kt:42 Error: Type mismatch: inferred type is String but Int was expected ```kotlin // Changed val count = call.parameters["count"] // To val count = call.parameters["count"]?.toIntOrNull() ?: return@get call.respond(HttpStatusCode.BadRequest, "Invalid count") ``` ```bash $ ./gradlew build # 1 error remaining ``` ## Fix 3: Non-Exhaustive When File: src/main/kotlin/com/example/routes/UserRoutes.kt:58 Error: 'when' expression must be exhaustive ```kotlin // Added missing branch when (user.role) { Role.ADMIN -> handleAdmin(user) Role.USER -> handleUser(user) Role.MODERATOR -> handleModerator(user) // Added } ``` ```bash $ ./gradlew build # Build successful! ``` ## Final Verification ```bash $ ./gradlew detekt # No issues $ ./gradlew test # All tests passed ``` ## Summary | Metric | Count | |--------|-------| | Build errors fixed | 3 | | Detekt issues fixed | 0 | | Files modified | 2 | | Remaining issues | 0 | Build Status: PASS: SUCCESS ```` ## Common Errors Fixed | Error | Typical Fix | |-------|-------------| | `Unresolved reference: X` | Add import or dependency | | `Type mismatch` | Fix type conversion or assignment | | `'when' must be exhaustive` | Add missing sealed class branches | | `Suspend function can only be called from coroutine` | Add `suspend` modifier | | `Smart cast impossible` | Use local `val` or `let` | | `None of the following candidates is applicable` | Fix argument types | | `Could not resolve dependency` | Fix version or add repository | ## Fix Strategy 1. **Build errors first** - Code must compile 2. **Detekt violations second** - Fix code quality issues 3. **ktlint warnings third** - Fix formatting 4. **One fix at a time** - Verify each change 5. **Minimal changes** - Don't refactor, just fix ## Stop Conditions The agent will stop and report if: - Same error persists after 3 attempts - Fix introduces more errors - Requires architectural changes - Missing external dependencies ## Related Commands - `/kotlin-test` - Run tests after build succeeds - `/kotlin-review` - Review code quality - `verification-loop` skill - Full verification loop ## Related - Agent: `agents/kotlin-build-resolver.md` - Skill: `skills/kotlin-patterns/`

package/packs/full-harness/rendered/.claude/commands/kotlin-review.md

@@ -0,0 +1,6 @@
+---
+description: Comprehensive Kotlin code review for idiomatic patterns, null safety, coroutine safety, and security. Invokes the kotlin-reviewer agent.
+argument-hint: [optional arguments]
+---
+
+# Kotlin Code Review This command invokes the **kotlin-reviewer** agent for comprehensive Kotlin-specific code review. ## What This Command Does 1. **Identify Kotlin Changes**: Find modified `.kt` and `.kts` files via `git diff` 2. **Run Build & Static Analysis**: Execute `./gradlew build`, `detekt`, `ktlintCheck` 3. **Security Scan**: Check for SQL injection, command injection, hardcoded secrets 4. **Null Safety Review**: Analyze `!!` usage, platform type handling, unsafe casts 5. **Coroutine Review**: Check structured concurrency, dispatcher usage, cancellation 6. **Generate Report**: Categorize issues by severity ## When to Use Use `/kotlin-review` when: - After writing or modifying Kotlin code - Before committing Kotlin changes - Reviewing pull requests with Kotlin code - Onboarding to a new Kotlin codebase - Learning idiomatic Kotlin patterns ## Review Categories ### CRITICAL (Must Fix) - SQL/Command injection vulnerabilities - Force-unwrap `!!` without justification - Platform type null safety violations - GlobalScope usage (structured concurrency violation) - Hardcoded credentials - Unsafe deserialization ### HIGH (Should Fix) - Mutable state where immutable suffices - Blocking calls inside coroutine context - Missing cancellation checks in long loops - Non-exhaustive `when` on sealed types - Large functions (>50 lines) - Deep nesting (>4 levels) ### MEDIUM (Consider) - Non-idiomatic Kotlin (Java-style patterns) - Missing trailing commas - Scope function misuse or nesting - Missing sequence for large collection chains - Redundant explicit types ## Automated Checks Run ```bash # Build check ./gradlew build # Static analysis ./gradlew detekt # Formatting check ./gradlew ktlintCheck # Tests ./gradlew test ``` ## Example Usage ````text User: /kotlin-review Agent: # Kotlin Code Review Report ## Files Reviewed - src/main/kotlin/com/example/service/UserService.kt (modified) - src/main/kotlin/com/example/routes/UserRoutes.kt (modified) ## Static Analysis Results ✓ Build: Successful ✓ detekt: No issues WARNING: ktlint: 2 formatting warnings ## Issues Found [CRITICAL] Force-Unwrap Null Safety File: src/main/kotlin/com/example/service/UserService.kt:28 Issue: Using !! on nullable repository result ```kotlin val user = repository.findById(id)!! // NPE risk ``` Fix: Use safe call with error handling ```kotlin val user = repository.findById(id) ?: throw UserNotFoundException("User $id not found") ``` [HIGH] GlobalScope Usage File: src/main/kotlin/com/example/routes/UserRoutes.kt:45 Issue: Using GlobalScope breaks structured concurrency ```kotlin GlobalScope.launch { notificationService.sendWelcome(user) } ``` Fix: Use the call's coroutine scope ```kotlin launch { notificationService.sendWelcome(user) } ``` ## Summary - CRITICAL: 1 - HIGH: 1 - MEDIUM: 0 Recommendation: FAIL: Block merge until CRITICAL issue is fixed ```` ## Approval Criteria | Status | Condition | |--------|-----------| | PASS: Approve | No CRITICAL or HIGH issues | | WARNING: Warning | Only MEDIUM issues (merge with caution) | | FAIL: Block | CRITICAL or HIGH issues found | ## Integration with Other Commands - Use `/kotlin-test` first to ensure tests pass - Use `/kotlin-build` if build errors occur - Use `/kotlin-review` before committing - Use `/code-review` for non-Kotlin-specific concerns ## Related - Agent: `agents/kotlin-reviewer.md` - Skills: `skills/kotlin-patterns/`, `skills/kotlin-testing/`

package/packs/full-harness/rendered/.claude/commands/kotlin-test.md

@@ -0,0 +1,6 @@
+---
+description: Enforce TDD workflow for Kotlin. Write Kotest tests first, then implement. Verify 80%+ coverage with Kover.
+argument-hint: [optional arguments]
+---
+
+# Kotlin TDD Command This command enforces test-driven development methodology for Kotlin code using Kotest, MockK, and Kover. ## What This Command Does 1. **Define Types/Interfaces**: Scaffold function signatures first 2. **Write Kotest Tests**: Create comprehensive test specs (RED) 3. **Run Tests**: Verify tests fail for the right reason 4. **Implement Code**: Write minimal code to pass (GREEN) 5. **Refactor**: Improve while keeping tests green 6. **Check Coverage**: Ensure 80%+ coverage with Kover ## When to Use Use `/kotlin-test` when: - Implementing new Kotlin functions or classes - Adding test coverage to existing Kotlin code - Fixing bugs (write failing test first) - Building critical business logic - Learning TDD workflow in Kotlin ## TDD Cycle ``` RED -> Write failing Kotest test GREEN -> Implement minimal code to pass REFACTOR -> Improve code, tests stay green REPEAT -> Next test case ``` ## Example Session ````text User: /kotlin-test I need a function to validate user registration requests Agent: # TDD Session: Registration Validator ## Step 1: Define Interface ```kotlin // validator/RegistrationValidator.kt package com.example.validator data class RegistrationRequest( val name: String, val email: String, val password: String, ) sealed class ValidationResult { data object Valid : ValidationResult() data class Invalid(val errors: List<String>) : ValidationResult() } fun validateRegistration(request: RegistrationRequest): ValidationResult { TODO("not implemented") } ``` ## Step 2: Write Kotest Tests (RED) ```kotlin // validator/RegistrationValidatorTest.kt package com.example.validator import io.kotest.core.spec.style.FunSpec import io.kotest.matchers.shouldBe import io.kotest.matchers.types.shouldBeInstanceOf class RegistrationValidatorTest : FunSpec({ test("valid registration returns Valid") { val request = RegistrationRequest( name = "Alice", email = "alice@example.com", password = "SecureP@ss1", ) val result = validateRegistration(request) result.shouldBeInstanceOf<ValidationResult.Valid>() } test("blank name returns Invalid") { val request = RegistrationRequest( name = "", email = "alice@example.com", password = "SecureP@ss1", ) val result = validateRegistration(request) val invalid = result.shouldBeInstanceOf<ValidationResult.Invalid>() invalid.errors shouldBe listOf("Name is required") } test("invalid email returns Invalid") { val request = RegistrationRequest( name = "Alice", email = "not-an-email", password = "SecureP@ss1", ) val result = validateRegistration(request) val invalid = result.shouldBeInstanceOf<ValidationResult.Invalid>() invalid.errors shouldBe listOf("Invalid email format") } test("short password returns Invalid") { val request = RegistrationRequest( name = "Alice", email = "alice@example.com", password = "short", ) val result = validateRegistration(request) val invalid = result.shouldBeInstanceOf<ValidationResult.Invalid>() invalid.errors shouldBe listOf("Password must be at least 8 characters") } test("multiple errors returns all errors") { val request = RegistrationRequest( name = "", email = "bad", password = "short", ) val result = validateRegistration(request) val invalid = result.shouldBeInstanceOf<ValidationResult.Invalid>() invalid.errors.size shouldBe 3 } }) ``` ## Step 3: Run Tests - Verify FAIL ```bash $ ./gradlew test RegistrationValidatorTest > valid registration returns Valid FAILED kotlin.NotImplementedError: An operation is not implemented FAILED (5 tests, 0 passed, 5 failed) ``` ✓ Tests fail as expected (NotImplementedError). ## Step 4: Implement Minimal Code (GREEN) ```kotlin // validator/RegistrationValidator.kt package com.example.validator private val EMAIL_REGEX = Regex("^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$") private const val MIN_PASSWORD_LENGTH = 8 fun validateRegistration(request: RegistrationRequest): ValidationResult { val errors = buildList { if (request.name.isBlank()) add("Name is required") if (!EMAIL_REGEX.matches(request.email)) add("Invalid email format") if (request.password.length < MIN_PASSWORD_LENGTH) add("Password must be at least $MIN_PASSWORD_LENGTH characters") } return if (errors.isEmpty()) ValidationResult.Valid else ValidationResult.Invalid(errors) } ``` ## Step 5: Run Tests - Verify PASS ```bash $ ./gradlew test RegistrationValidatorTest > valid registration returns Valid PASSED RegistrationValidatorTest > blank name returns Invalid PASSED RegistrationValidatorTest > invalid email returns Invalid PASSED RegistrationValidatorTest > short password returns Invalid PASSED RegistrationValidatorTest > multiple errors returns all errors PASSED PASSED (5 tests, 5 passed, 0 failed) ``` ✓ All tests passing! ## Step 6: Check Coverage ```bash $ ./gradlew koverHtmlReport Coverage: 100.0% of statements ``` ✓ Coverage: 100% ## TDD Complete! ```` ## Test Patterns ### StringSpec (Simplest) ```kotlin class CalculatorTest : StringSpec({ "add two positive numbers" { Calculator.add(2, 3) shouldBe 5 } }) ``` ### BehaviorSpec (BDD) ```kotlin class OrderServiceTest : BehaviorSpec({ Given("a valid order") { When("placed") { Then("should be confirmed") { /* ... */ } } } }) ``` ### Data-Driven Tests ```kotlin class ParserTest : FunSpec({ context("valid inputs") { withData("2026-01-15", "2026-12-31", "2000-01-01") { input -> parseDate(input).shouldNotBeNull() } } }) ``` ### Coroutine Testing ```kotlin class AsyncServiceTest : FunSpec({ test("concurrent fetch completes") { runTest { val result = service.fetchAll() result.shouldNotBeEmpty() } } }) ``` ## Coverage Commands ```bash # Run tests with coverage ./gradlew koverHtmlReport # Verify coverage thresholds ./gradlew koverVerify # XML report for CI ./gradlew koverXmlReport # Open HTML report open build/reports/kover/html/index.html # Run specific test class ./gradlew test --tests "com.example.UserServiceTest" # Run with verbose output ./gradlew test --info ``` ## Coverage Targets | Code Type | Target | |-----------|--------| | Critical business logic | 100% | | Public APIs | 90%+ | | General code | 80%+ | | Generated code | Exclude | ## TDD Best Practices **DO:** - Write test FIRST, before any implementation - Run tests after each change - Use Kotest matchers for expressive assertions - Use MockK's `coEvery`/`coVerify` for suspend functions - Test behavior, not implementation details - Include edge cases (empty, null, max values) **DON'T:** - Write implementation before tests - Skip the RED phase - Test private functions directly - Use `Thread.sleep()` in coroutine tests - Ignore flaky tests ## Related Commands - `/kotlin-build` - Fix build errors - `/kotlin-review` - Review code after implementation - `verification-loop` skill - Run full verification loop ## Related - Skill: `skills/kotlin-testing/` - Skill: `skills/tdd-workflow/`

package/packs/full-harness/rendered/.claude/commands/learn-eval.md

@@ -0,0 +1,6 @@
+---
+description: Extract reusable patterns from the session, self-evaluate quality before saving, and determine the right save location (Global vs Project).
+argument-hint: [optional arguments]
+---
+
+# /learn-eval - Extract, Evaluate, then Save Extends `/learn` with a quality gate, save-location decision, and knowledge-placement awareness before writing any skill file. ## What to Extract Look for: 1. **Error Resolution Patterns** — root cause + fix + reusability 2. **Debugging Techniques** — non-obvious steps, tool combinations 3. **Workarounds** — library quirks, API limitations, version-specific fixes 4. **Project-Specific Patterns** — conventions, architecture decisions, integration patterns ## Process 1. Review the session for extractable patterns 2. Identify the most valuable/reusable insight 3. **Determine save location:** - Ask: "Would this pattern be useful in a different project?" - **Global** (`~/.claude/skills/learned/`): Generic patterns usable across 2+ projects (bash compatibility, LLM API behavior, debugging techniques, etc.) - **Project** (`.claude/skills/learned/` in current project): Project-specific knowledge (quirks of a particular config file, project-specific architecture decisions, etc.) - When in doubt, choose Global (moving Global → Project is easier than the reverse) 4. Draft the skill file using this format: ```markdown --- name: pattern-name description: "Under 130 characters" user-invocable: false origin: auto-extracted --- # [Descriptive Pattern Name] **Extracted:** [Date] **Context:** [Brief description of when this applies] ## Problem [What problem this solves - be specific] ## Solution [The pattern/technique/workaround - with code examples] ## When to Use [Trigger conditions] ``` 5. **Quality gate — Checklist + Holistic verdict** ### 5a. Required checklist (verify by actually reading files) Execute **all** of the following before evaluating the draft: - [ ] Grep `~/.claude/skills/` and relevant project `.claude/skills/` files by keyword to check for content overlap - [ ] Check MEMORY.md (both project and global) for overlap - [ ] Consider whether appending to an existing skill would suffice - [ ] Confirm this is a reusable pattern, not a one-off fix ### 5b. Holistic verdict Synthesize the checklist results and draft quality, then choose **one** of the following (Step 6 defines the action each verdict triggers): | Verdict | Meaning | |---------|---------| | **Save** | Unique, specific, well-scoped | | **Improve then Save** | Valuable but needs refinement | | **Absorb into [X]** | Should be appended to an existing skill | | **Drop** | Trivial, redundant, or too abstract | **Guideline dimensions** (informing the verdict, not scored): - **Specificity & Actionability**: Contains code examples or commands that are immediately usable - **Scope Fit**: Name, trigger conditions, and content are aligned and focused on a single pattern - **Uniqueness**: Provides value not covered by existing skills (informed by checklist results) - **Reusability**: Realistic trigger scenarios exist in future sessions 6. **Verdict-specific confirmation flow** - **Improve then Save**: Present the required improvements + revised draft + updated checklist/verdict after one re-evaluation; if the revised verdict is **Save**, save after user confirmation, otherwise follow the new verdict - **Save**: Present save path + checklist results + 1-line verdict rationale + full draft → save after user confirmation - **Absorb into [X]**: Present target path + additions (diff format) + checklist results + verdict rationale → append after user confirmation - **Drop**: Show checklist results + reasoning only (no confirmation needed) 7. Save / Absorb to the determined location ## Output Format for Step 5 ``` ### Checklist - [x] skills/ grep: no overlap (or: overlap found → details) - [x] MEMORY.md: no overlap (or: overlap found → details) - [x] Existing skill append: new file appropriate (or: should append to [X]) - [x] Reusability: confirmed (or: one-off → Drop) ### Verdict: Save / Improve then Save / Absorb into [X] / Drop **Rationale:** (1-2 sentences explaining the verdict) ``` ## Design Rationale This version replaces the previous 5-dimension numeric scoring rubric (Specificity, Actionability, Scope Fit, Non-redundancy, Coverage scored 1-5) with a checklist-based holistic verdict system. Modern frontier models (Opus 4.6+) have strong contextual judgment — forcing rich qualitative signals into numeric scores loses nuance and can produce misleading totals. The holistic approach lets the model weigh all factors naturally, producing more accurate save/drop decisions while the explicit checklist ensures no critical check is skipped. ## Notes - Don't extract trivial fixes (typos, simple syntax errors) - Don't extract one-time issues (specific API outages, etc.) - Focus on patterns that will save time in future sessions - Keep skills focused — one pattern per skill - When the verdict is Absorb, append to the existing skill rather than creating a new file

package/packs/full-harness/rendered/.claude/commands/learn.md

@@ -0,0 +1,6 @@
+---
+description: Extract reusable patterns from the current session and save them as candidate skills or guidance.
+argument-hint: [optional arguments]
+---
+
+# /learn - Extract Reusable Patterns Analyze the current session and extract any patterns worth saving as skills. ## Trigger Run `/learn` at any point during a session when you've solved a non-trivial problem. ## What to Extract Look for: 1. **Error Resolution Patterns** - What error occurred? - What was the root cause? - What fixed it? - Is this reusable for similar errors? 2. **Debugging Techniques** - Non-obvious debugging steps - Tool combinations that worked - Diagnostic patterns 3. **Workarounds** - Library quirks - API limitations - Version-specific fixes 4. **Project-Specific Patterns** - Codebase conventions discovered - Architecture decisions made - Integration patterns ## Output Format Create a skill file at `~/.claude/skills/learned/[pattern-name].md`: ```markdown # [Descriptive Pattern Name] **Extracted:** [Date] **Context:** [Brief description of when this applies] ## Problem [What problem this solves - be specific] ## Solution [The pattern/technique/workaround] ## Example [Code example if applicable] ## When to Use [Trigger conditions - what should activate this skill] ``` ## Process 1. Review the session for extractable patterns 2. Identify the most valuable/reusable insight 3. Draft the skill file 4. Ask user to confirm before saving 5. Save to `~/.claude/skills/learned/` ## Notes - Don't extract trivial fixes (typos, simple syntax errors) - Don't extract one-time issues (specific API outages, etc.) - Focus on patterns that will save time in future sessions - Keep skills focused - one pattern per skill

package/packs/full-harness/rendered/.claude/commands/loop-start.md

@@ -0,0 +1,6 @@
+---
+description: Start a managed autonomous loop pattern with safety defaults and explicit stop conditions.
+argument-hint: [optional arguments]
+---
+
+# Loop Start Command Start a managed autonomous loop pattern with safety defaults. ## Usage `/loop-start [pattern] [--mode safe|fast]` - `pattern`: `sequential`, `continuous-pr`, `rfc-dag`, `infinite` - `--mode`: - `safe` (default): strict quality gates and checkpoints - `fast`: reduced gates for speed ## Flow 1. Confirm repository state and branch strategy. 2. Select loop pattern and model tier strategy. 3. Enable required hooks/profile for the chosen mode. 4. Create loop plan and write runbook under `.claude/plans/`. 5. Print commands to start and monitor the loop. ## Required Safety Checks - Verify tests pass before first loop iteration. - Ensure `ECC_HOOK_PROFILE` is not disabled globally. - Ensure loop has explicit stop condition. ## Arguments $ARGUMENTS: - `<pattern>` optional (`sequential|continuous-pr|rfc-dag|infinite`) - `--mode safe|fast` optional

package/packs/full-harness/rendered/.claude/commands/loop-status.md

@@ -0,0 +1,6 @@
+---
+description: Inspect active loop state, progress, failure signals, and recommended intervention.
+argument-hint: [optional arguments]
+---
+
+# Loop Status Command Inspect active loop state, progress, and failure signals. This slash command can only run after the current session dequeues it. If you need to inspect a wedged or sibling session, run the packaged CLI from another terminal: ```bash npx --package ecc-universal ecc loop-status --json ``` The CLI scans local Claude transcript JSONL files under `~/.claude/projects/**` and reports stale `ScheduleWakeup` calls or `Bash` tool calls that have no matching `tool_result`. ## Usage `/loop-status [--watch]` ## What to Report - active loop pattern - current phase and last successful checkpoint - failing checks (if any) - estimated time/cost drift - recommended intervention (continue/pause/stop) ## Cross-Session CLI - `ecc loop-status --json` emits machine-readable status for recent local Claude transcripts. - `ecc loop-status --home <dir>` scans a different home directory when inspecting another local profile or mounted workspace. - `ecc loop-status --transcript <session.jsonl>` inspects one transcript directly. - `ecc loop-status --bash-timeout-seconds 1800` adjusts the stale Bash threshold. - `ecc loop-status --exit-code` exits `2` when stale loop or tool signals are found, or `1` when transcripts cannot be scanned. - `--exit-code` with `--watch` requires `--watch-count` so watchdog scripts do not wait forever for a process exit. - `ecc loop-status --watch` refreshes status until interrupted. - `ecc loop-status --watch --watch-count 3 --exit-code` refreshes a bounded number of times, then exits with the highest status seen. - `ecc loop-status --watch --watch-count 3` emits a bounded watch stream for scripts and handoffs. - `ecc loop-status --watch --write-dir ~/.claude/loops` maintains `index.json` and per-session JSON snapshots for sibling terminals or watchdog scripts. ## Watch Mode When `--watch` is present, refresh status periodically. With `--json`, each refresh is emitted as one JSON object per line so another terminal or script can consume the stream. ## Snapshot Files Use `--write-dir <dir>` when a separate process needs to inspect loop state without waiting for the current Claude session to dequeue `/loop-status`. The CLI writes: - `index.json` with one row per inspected session. - `<session-id>.json` with the full status payload for that session. These files are snapshots of local transcript analysis. They do not control or timeout Claude Code runtime tool calls. ## Arguments $ARGUMENTS: - `--watch` optional

package/packs/full-harness/rendered/.claude/commands/marketing-campaign.md

@@ -0,0 +1,6 @@
+---
+description: Plan and execute a full marketing campaign. Accepts a product brief and returns positioning, landing page copy, email sequence, social posts, ad variants, video scripts, and a content calendar. Can also review existing copy for conversion quality.
+argument-hint: [optional arguments]
+---
+
+# /marketing-campaign Plan and execute a marketing campaign from brief to full content suite. ## Usage ``` /marketing-campaign # Prompt for brief interactively /marketing-campaign [product brief] # Full campaign from inline brief /marketing-campaign copy [type] # Single deliverable only /marketing-campaign review [file-or-brief] # Copy audit for conversion and brand consistency ``` ## What It Does 1. **Research** — Profiles the target audience and maps competitors before writing anything 2. **Positioning** — Locks the campaign angle and tone profile first 3. **Copy production** — Generates the full content suite in the right order (landing page → emails → social → ads → video scripts → calendar) 4. **Review** — Gates all output through a conversion and brand consistency checklist ## Modes ### Full Campaign Mode Provide a product brief containing: - Product name and description - Target audience (specific, not generic) - Core problem the product solves - Core benefit / outcome - Tone guidance - Channels required - Launch goal or timeline The agent returns all campaign deliverables in order, with a copy review summary at the end. ### Single Deliverable Mode ``` /marketing-campaign copy landing-page /marketing-campaign copy email-sequence /marketing-campaign copy social-posts /marketing-campaign copy ads /marketing-campaign copy video-scripts ``` Requires positioning to be defined first. Run full mode or provide the angle before requesting a single deliverable. ### Copy Review Mode ``` /marketing-campaign review path/to/copy.md /marketing-campaign review "paste copy here" ``` Returns a structured audit against: - 5-second clarity test (above-fold copy) - CTA quality (specific, earned, one per piece) - Brand tone consistency - Claim specificity and supportability - Platform-native fit - Cross-channel consistency ## Brief Template ```markdown Product: [name] Description: [1-3 sentences on what it does] Audience: [who, specifically] Problem: [the specific pain the product solves] Benefit: [the outcome the user gets] Tone: [adjectives + what to avoid] Channels: [landing page, email, LinkedIn, X, ads, video] Goal: [launch, waitlist, signups, awareness — and timeline] ``` ## Output Location When saving campaign assets, the convention is `.claude/campaigns/{campaign-name}/`: ``` .claude/campaigns/product-launch/ ├── positioning.md ├── landing-page.md ├── email-sequence.md ├── social-posts.md ├── ad-copy.md ├── video-scripts.md └── content-calendar.md ``` Confirm the save location before writing files. ## Examples ``` /marketing-campaign Build a 7-day launch campaign for an AI career platform for UK university students. ``` ``` /marketing-campaign copy landing-page ``` ``` /marketing-campaign review .claude/campaigns/the-key/landing-page.md ``` ## Agent Delegation This command invokes: - `marketing-agent` — campaign planning and copy production - `brand-voice` — voice capture when tone needs locking across multiple outputs - `content-engine` — platform-native social content production - `crosspost` — multi-platform distribution - `market-research` — deep audience or competitive intelligence ## Related Commands - `/plan` — Strategic planning before a campaign - `/plan-prd` — Product requirements document before briefing a campaign - `/code-review` — Review code behind a landing page implementation --- *Part of [Everything Claude Code](https://github.com/affaan-m/everything-claude-code)*

package/packs/full-harness/rendered/.claude/commands/model-route.md

@@ -0,0 +1,6 @@
+---
+description: Recommend the best model tier for the current task based on complexity, risk, and budget.
+argument-hint: [optional arguments]
+---
+
+# Model Route Command Recommend the best model tier for the current task by complexity and budget. ## Usage `/model-route [task-description] [--budget low|med|high]` ## Routing Heuristic - `haiku`: deterministic, low-risk mechanical changes - `sonnet`: default for implementation and refactors - `opus`: architecture, deep review, ambiguous requirements ## Required Output - recommended model - confidence level - why this model fits - fallback model if first attempt fails ## Arguments $ARGUMENTS: - `[task-description]` optional free-text - `--budget low|med|high` optional

package/packs/full-harness/rendered/.claude/commands/multi-backend.md

@@ -0,0 +1,6 @@
+---
+description: Run a backend-focused multi-model workflow for APIs, algorithms, data, and business logic.
+argument-hint: [optional arguments]
+---
+
+# Backend - Backend-Focused Development Backend-focused workflow (Research → Ideation → Plan → Execute → Optimize → Review), Codex-led. > **Prerequisite:** Requires the external `ccg-workflow` runtime, which is **not** part of the base ECC install. Initialize it with `npx ccg-workflow` to provision `~/.claude/bin/codeagent-wrapper` and the `~/.claude/.ccg/prompts/*` role files this command depends on. Without that runtime, this command will not run correctly. ## Usage ```bash /backend <backend task description> ``` ## Context - Backend task: $ARGUMENTS - Codex-led, Gemini for auxiliary reference - Applicable: API design, algorithm implementation, database optimization, business logic ## Your Role You are the **Backend Orchestrator**, coordinating multi-model collaboration for server-side tasks (Research → Ideation → Plan → Execute → Optimize → Review). **Collaborative Models**: - **Codex** – Backend logic, algorithms (**Backend authority, trustworthy**) - **Gemini** – Frontend perspective (**Backend opinions for reference only**) - **Claude (self)** – Orchestration, planning, execution, delivery --- ## Multi-Model Call Specification **Call Syntax**: ``` # New session call Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex - \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)> Context: <project context and analysis from previous phases> </TASK> OUTPUT: Expected output format EOF", run_in_background: false, timeout: 3600000, description: "Brief description" }) # Resume session call Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend codex resume <SESSION_ID> - \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)> Context: <project context and analysis from previous phases> </TASK> OUTPUT: Expected output format EOF", run_in_background: false, timeout: 3600000, description: "Brief description" }) ``` **Role Prompts**: | Phase | Codex | |-------|-------| | Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` | | Planning | `~/.claude/.ccg/prompts/codex/architect.md` | | Review | `~/.claude/.ccg/prompts/codex/reviewer.md` | **Session Reuse**: Each call returns `SESSION_ID: xxx`, use `resume xxx` for subsequent phases. Save `CODEX_SESSION` in Phase 2, use `resume` in Phases 3 and 5. --- ## Communication Guidelines 1. Start responses with mode label `[Mode: X]`, initial is `[Mode: Research]` 2. Follow strict sequence: `Research → Ideation → Plan → Execute → Optimize → Review` 3. Use `AskUserQuestion` tool for user interaction when needed (e.g., confirmation/selection/approval) --- ## Core Workflow ### Phase 0: Prompt Enhancement (Optional) `[Mode: Prepare]` - If ace-tool MCP available, call `mcp__ace-tool__enhance_prompt`, **replace original $ARGUMENTS with enhanced result for subsequent Codex calls**. If unavailable, use `$ARGUMENTS` as-is. ### Phase 1: Research `[Mode: Research]` - Understand requirements and gather context 1. **Code Retrieval** (if ace-tool MCP available): Call `mcp__ace-tool__search_context` to retrieve existing APIs, data models, service architecture. If unavailable, use built-in tools: `Glob` for file discovery, `Grep` for symbol/API search, `Read` for context gathering, `Task` (Explore agent) for deeper exploration. 2. Requirement completeness score (0-10): >=7 continue, <7 stop and supplement ### Phase 2: Ideation `[Mode: Ideation]` - Codex-led analysis **MUST call Codex** (follow call specification above): - ROLE_FILE: `~/.claude/.ccg/prompts/codex/analyzer.md` - Requirement: Enhanced requirement (or $ARGUMENTS if not enhanced) - Context: Project context from Phase 1 - OUTPUT: Technical feasibility analysis, recommended solutions (at least 2), risk assessment **Save SESSION_ID** (`CODEX_SESSION`) for subsequent phase reuse. Output solutions (at least 2), wait for user selection. ### Phase 3: Planning `[Mode: Plan]` - Codex-led planning **MUST call Codex** (use `resume <CODEX_SESSION>` to reuse session): - ROLE_FILE: `~/.claude/.ccg/prompts/codex/architect.md` - Requirement: User's selected solution - Context: Analysis results from Phase 2 - OUTPUT: File structure, function/class design, dependency relationships Claude synthesizes plan, save to `.claude/plan/task-name.md` after user approval. ### Phase 4: Implementation `[Mode: Execute]` - Code development - Strictly follow approved plan - Follow existing project code standards - Ensure error handling, security, performance optimization ### Phase 5: Optimization `[Mode: Optimize]` - Codex-led review **MUST call Codex** (follow call specification above): - ROLE_FILE: `~/.claude/.ccg/prompts/codex/reviewer.md` - Requirement: Review the following backend code changes - Context: git diff or code content - OUTPUT: Security, performance, error handling, API compliance issues list Integrate review feedback, execute optimization after user confirmation. ### Phase 6: Quality Review `[Mode: Review]` - Final evaluation - Check completion against plan - Run tests to verify functionality - Report issues and recommendations --- ## Key Rules 1. **Codex backend opinions are trustworthy** 2. **Gemini backend opinions for reference only** 3. External models have **zero filesystem write access** 4. Claude handles all code writes and file operations

package/packs/full-harness/rendered/.claude/commands/multi-execute.md

@@ -0,0 +1,6 @@
+---
+description: Execute a multi-model implementation plan while preserving Claude as the only filesystem writer.
+argument-hint: [optional arguments]
+---
+
+# Execute - Multi-Model Collaborative Execution Multi-model collaborative execution - Get prototype from plan → Claude refactors and implements → Multi-model audit and delivery. > **Prerequisite:** Requires the external `ccg-workflow` runtime, which is **not** part of the base ECC install. Initialize it with `npx ccg-workflow` to provision `~/.claude/bin/codeagent-wrapper` and the `~/.claude/.ccg/prompts/*` role files this command depends on. Without that runtime, this command will not run correctly. $ARGUMENTS --- ## Core Protocols - **Language Protocol**: Use **English** when interacting with tools/models, communicate with user in their language - **Code Sovereignty**: External models have **zero filesystem write access**, all modifications by Claude - **Dirty Prototype Refactoring**: Treat Codex/Gemini Unified Diff as "dirty prototype", must refactor to production-grade code - **Stop-Loss Mechanism**: Do not proceed to next phase until current phase output is validated - **Prerequisite**: Only execute after user explicitly replies "Y" to `/ccg:plan` output (if missing, must confirm first) --- ## Multi-Model Call Specification **Call Syntax** (parallel: use `run_in_background: true`): ``` # Resume session call (recommended) - Implementation Prototype Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <task description> Context: <plan content + target files> </TASK> OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications. EOF", run_in_background: true, timeout: 3600000, description: "Brief description" }) # New session call - Implementation Prototype Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <task description> Context: <plan content + target files> </TASK> OUTPUT: Unified Diff Patch ONLY. Strictly prohibit any actual modifications. EOF", run_in_background: true, timeout: 3600000, description: "Brief description" }) ``` **Audit Call Syntax** (Code Review / Audit): ``` Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Scope: Audit the final code changes. Inputs: - The applied patch (git diff / final unified diff) - The touched files (relevant excerpts if needed) Constraints: - Do NOT modify any files. - Do NOT output tool commands that assume filesystem access. </TASK> OUTPUT: 1) A prioritized list of issues (severity, file, rationale) 2) Concrete fixes; if code changes are needed, include a Unified Diff Patch in a fenced code block. EOF", run_in_background: true, timeout: 3600000, description: "Brief description" }) ``` **Model Parameter Notes**: - `{{GEMINI_MODEL_FLAG}}`: When using `--backend gemini`, replace with `--gemini-model gemini-3-pro-preview` (note trailing space); use empty string for codex **Role Prompts**: | Phase | Codex | Gemini | |-------|-------|--------| | Implementation | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/frontend.md` | | Review | `~/.claude/.ccg/prompts/codex/reviewer.md` | `~/.claude/.ccg/prompts/gemini/reviewer.md` | **Session Reuse**: If `/ccg:plan` provided SESSION_ID, use `resume <SESSION_ID>` to reuse context. **Wait for Background Tasks** (max timeout 600000ms = 10 minutes): ``` TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 }) ``` **IMPORTANT**: - Must specify `timeout: 600000`, otherwise default 30 seconds will cause premature timeout - If still incomplete after 10 minutes, continue polling with `TaskOutput`, **NEVER kill the process** - If waiting is skipped due to timeout, **MUST call `AskUserQuestion` to ask user whether to continue waiting or kill task** --- ## Execution Workflow **Execute Task**: $ARGUMENTS ### Phase 0: Read Plan `[Mode: Prepare]` 1. **Identify Input Type**: - Plan file path (e.g., `.claude/plan/xxx.md`) - Direct task description 2. **Read Plan Content**: - If plan file path provided, read and parse - Extract: task type, implementation steps, key files, SESSION_ID 3. **Pre-Execution Confirmation**: - If input is "direct task description" or plan missing `SESSION_ID` / key files: confirm with user first - If cannot confirm user replied "Y" to plan: must confirm again before proceeding 4. **Task Type Routing**: | Task Type | Detection | Route | |-----------|-----------|-------| | **Frontend** | Pages, components, UI, styles, layout | Gemini | | **Backend** | API, interfaces, database, logic, algorithms | Codex | | **Fullstack** | Contains both frontend and backend | Codex ∥ Gemini parallel | --- ### Phase 1: Quick Context Retrieval `[Mode: Retrieval]` **If ace-tool MCP is available**, use it for quick context retrieval: Based on "Key Files" list in plan, call `mcp__ace-tool__search_context`: ``` mcp__ace-tool__search_context({ query: "<semantic query based on plan content, including key files, modules, function names>", project_root_path: "$PWD" }) ``` **Retrieval Strategy**: - Extract target paths from plan's "Key Files" table - Build semantic query covering: entry files, dependency modules, related type definitions - If results insufficient, add 1-2 recursive retrievals **If ace-tool MCP is NOT available**, use Claude Code built-in tools as fallback: 1. **Glob**: Find target files from plan's "Key Files" table (e.g., `Glob("src/components/**/*.tsx")`) 2. **Grep**: Search for key symbols, function names, type definitions across the codebase 3. **Read**: Read the discovered files to gather complete context 4. **Task (Explore agent)**: For broader exploration, use `Task` with `subagent_type: "Explore"` **After Retrieval**: - Organize retrieved code snippets - Confirm complete context for implementation - Proceed to Phase 3 --- ### Phase 3: Prototype Acquisition `[Mode: Prototype]` **Route Based on Task Type**: #### Route A: Frontend/UI/Styles → Gemini **Limit**: Context < 32k tokens 1. Call Gemini (use `~/.claude/.ccg/prompts/gemini/frontend.md`) 2. Input: Plan content + retrieved context + target files 3. OUTPUT: `Unified Diff Patch ONLY. Strictly prohibit any actual modifications.` 4. **Gemini is frontend design authority, its CSS/React/Vue prototype is the final visual baseline** 5. **WARNING**: Ignore Gemini's backend logic suggestions 6. If plan contains `GEMINI_SESSION`: prefer `resume <GEMINI_SESSION>` #### Route B: Backend/Logic/Algorithms → Codex 1. Call Codex (use `~/.claude/.ccg/prompts/codex/architect.md`) 2. Input: Plan content + retrieved context + target files 3. OUTPUT: `Unified Diff Patch ONLY. Strictly prohibit any actual modifications.` 4. **Codex is backend logic authority, leverage its logical reasoning and debug capabilities** 5. If plan contains `CODEX_SESSION`: prefer `resume <CODEX_SESSION>` #### Route C: Fullstack → Parallel Calls 1. **Parallel Calls** (`run_in_background: true`): - Gemini: Handle frontend part - Codex: Handle backend part 2. Wait for both models' complete results with `TaskOutput` 3. Each uses corresponding `SESSION_ID` from plan for `resume` (create new session if missing) **Follow the `IMPORTANT` instructions in `Multi-Model Call Specification` above** --- ### Phase 4: Code Implementation `[Mode: Implement]` **Claude as Code Sovereign executes the following steps**: 1. **Read Diff**: Parse Unified Diff Patch returned by Codex/Gemini 2. **Mental Sandbox**: - Simulate applying Diff to target files - Check logical consistency - Identify potential conflicts or side effects 3. **Refactor and Clean**: - Refactor "dirty prototype" to **highly readable, maintainable, enterprise-grade code** - Remove redundant code - Ensure compliance with project's existing code standards - **Do not generate comments/docs unless necessary**, code should be self-explanatory 4. **Minimal Scope**: - Changes limited to requirement scope only - **Mandatory review** for side effects - Make targeted corrections 5. **Apply Changes**: - Use Edit/Write tools to execute actual modifications - **Only modify necessary code**, never affect user's other existing functionality 6. **Self-Verification** (strongly recommended): - Run project's existing lint / typecheck / tests (prioritize minimal related scope) - If failed: fix regressions first, then proceed to Phase 5 --- ### Phase 5: Audit and Delivery `[Mode: Audit]` #### 5.1 Automatic Audit **After changes take effect, MUST immediately parallel call** Codex and Gemini for Code Review: 1. **Codex Review** (`run_in_background: true`): - ROLE_FILE: `~/.claude/.ccg/prompts/codex/reviewer.md` - Input: Changed Diff + target files - Focus: Security, performance, error handling, logic correctness 2. **Gemini Review** (`run_in_background: true`): - ROLE_FILE: `~/.claude/.ccg/prompts/gemini/reviewer.md` - Input: Changed Diff + target files - Focus: Accessibility, design consistency, user experience Wait for both models' complete review results with `TaskOutput`. Prefer reusing Phase 3 sessions (`resume <SESSION_ID>`) for context consistency. #### 5.2 Integrate and Fix 1. Synthesize Codex + Gemini review feedback 2. Weigh by trust rules: Backend follows Codex, Frontend follows Gemini 3. Execute necessary fixes 4. Repeat Phase 5.1 as needed (until risk is acceptable) #### 5.3 Delivery Confirmation After audit passes, report to user: ```markdown ## Execution Complete ### Change Summary | File | Operation | Description | |------|-----------|-------------| | path/to/file.ts | Modified | Description | ### Audit Results - Codex: <Passed/Found N issues> - Gemini: <Passed/Found N issues> ### Recommendations 1. [ ] <Suggested test steps> 2. [ ] <Suggested verification steps> ``` --- ## Key Rules 1. **Code Sovereignty** – All file modifications by Claude, external models have zero write access 2. **Dirty Prototype Refactoring** – Codex/Gemini output treated as draft, must refactor 3. **Trust Rules** – Backend follows Codex, Frontend follows Gemini 4. **Minimal Changes** – Only modify necessary code, no side effects 5. **Mandatory Audit** – Must perform multi-model Code Review after changes --- ## Usage ```bash # Execute plan file /ccg:execute .claude/plan/feature-name.md # Execute task directly (for plans already discussed in context) /ccg:execute implement user authentication based on previous plan ``` --- ## Relationship with /ccg:plan 1. `/ccg:plan` generates plan + SESSION_ID 2. User confirms with "Y" 3. `/ccg:execute` reads plan, reuses SESSION_ID, executes implementation