compact-agent 1.10.1 → 1.11.0

package/resources/ecc/commands/cpp-test.md

@@ -0,0 +1,251 @@
+---
+description: Enforce TDD workflow for C++. Write GoogleTest tests first, then implement. Verify coverage with gcov/lcov.
+---
+
+# 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/resources/ecc/commands/ecc-guide.md

@@ -0,0 +1,93 @@
+---
+description: Navigate ECC's current agents, skills, commands, hooks, install profiles, and docs from the live repository surface.
+---
+
+# /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/resources/ecc/commands/evolve.md

@@ -0,0 +1,178 @@
+---
+name: evolve
+description: Analyze instincts and suggest or generate evolved structures
+command: true
+---
+
+# 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/resources/ecc/commands/fastapi-review.md

@@ -0,0 +1,39 @@
+---
+description: Review a FastAPI application for architecture, async correctness, dependency injection, Pydantic schemas, security, performance, and testability.
+---
+
+# 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/resources/ecc/commands/feature-dev.md

@@ -0,0 +1,49 @@
+---
+description: Guided feature development with codebase understanding and architecture focus
+---
+
+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