aw-ecc 1.4.21

package/commands/cpp-test.md

@@ -0,0 +1,252 @@
+---
+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 `/aw: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: /aw: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
+
+- `/aw:cpp-build` - Fix build errors
+- `/aw:cpp-review` - Review code after implementation
+- `/aw:test` - Run targeted QA and proof
+- `/aw:review` - Run readiness and findings review
+
+## Related
+
+- Skill: `skills/cpp-testing/`
+- Skill: `skills/tdd-workflow/`

package/commands/deploy.md

@@ -0,0 +1,75 @@
+---
+name: aw:deploy
+description: Create one requested release outcome for work that already has the required QA, review, and readiness evidence.
+argument-hint: "<reviewed work, target environment, or release request>"
+status: active
+stage: deploy
+internal_skill: aw-deploy
+---
+
+# Deploy
+
+Use `/aw:deploy` to turn reviewed work into a PR, branch handoff, or deployment outcome.
+
+## Role
+
+Perform one explicit release action with the correct GHL provider and mechanism for the current repo archetype.
+
+## Modes
+
+| Mode | Use when | Primary outputs |
+|---|---|---|
+| `pr` | work should be handed off for review or merge | PR URL, `release.md`, `state.json` |
+| `branch` | work should remain on a branch | branch name, `release.md`, `state.json` |
+| `staging` | reviewed work should go to staging | deploy evidence, `release.md`, `state.json` |
+| `production` | explicitly approved work should go to production | deploy evidence, `release.md`, `state.json` |
+
+## Required Inputs
+
+- passing test and review outcome, or a compatible verified state that resolves to the same evidence
+- branch or change set
+- relevant release context
+- resolved deploy profile when present
+
+## Outputs
+
+- `.aw_docs/features/<feature_slug>/release.md`
+- updated `.aw_docs/features/<feature_slug>/state.json`
+- one concrete release outcome artifact:
+  - PR URL
+  - branch name
+  - staging URL
+  - deployment reference
+  - build links
+  - status summary
+
+## Deploy Rules
+
+1. Do one release action at a time.
+2. Resolve the provider and mechanism from repo archetype and baseline profile.
+3. Finish the selected release action for the chosen mode or record the blocker explicitly.
+4. Record deterministic evidence even when external execution is blocked.
+5. Hand off to `/aw:ship` when launch, rollout, rollback readiness, or release closeout is requested after deploy.
+
+## Must Not Do
+
+- must not bypass test and review evidence
+- must not silently choose the wrong provider
+- must not reopen planning during deployment
+
+## Recommended Next Commands
+
+- `/aw:ship`
+
+## Final Output Shape
+
+Always end with:
+
+- `Selected Mode`
+- `Provider`
+- `Resolved Mechanism`
+- `Build Links`
+- `Execution Evidence`
+- `Rollback Path`
+- `Outcome`
+- `Next`

package/commands/devfleet.md

@@ -0,0 +1,92 @@
+---
+description: Orchestrate parallel Claude Code agents via Claude DevFleet — plan projects from natural language, dispatch agents in isolated worktrees, monitor progress, and read structured reports.
+---
+
+# DevFleet — Multi-Agent Orchestration
+
+Orchestrate parallel Claude Code agents via Claude DevFleet. Each agent runs in an isolated git worktree with full tooling.
+
+Requires the DevFleet MCP server: `claude mcp add devfleet --transport http http://localhost:18801/mcp`
+
+## Flow
+
+```
+User describes project
+  → plan_project(prompt) → mission DAG with dependencies
+  → Show plan, get approval
+  → dispatch_mission(M1) → Agent spawns in worktree
+  → M1 completes → auto-merge → M2 auto-dispatches (depends_on M1)
+  → M2 completes → auto-merge
+  → get_report(M2) → files_changed, what_done, errors, next_steps
+  → Report summary to user
+```
+
+## Workflow
+
+1. **Plan the project** from the user's description:
+
+```
+mcp__devfleet__plan_project(prompt="<user's description>")
+```
+
+This returns a project with chained missions. Show the user:
+- Project name and ID
+- Each mission: title, type, dependencies
+- The dependency DAG (which missions block which)
+
+2. **Wait for user approval** before dispatching. Show the plan clearly.
+
+3. **Dispatch the first mission** (the one with empty `depends_on`):
+
+```
+mcp__devfleet__dispatch_mission(mission_id="<first_mission_id>")
+```
+
+The remaining missions auto-dispatch as their dependencies complete (because `plan_project` creates them with `auto_dispatch=true`). When manually creating missions with `create_mission`, you must explicitly set `auto_dispatch=true` for this behavior.
+
+4. **Monitor progress** — check what's running:
+
+```
+mcp__devfleet__get_dashboard()
+```
+
+Or check a specific mission:
+
+```
+mcp__devfleet__get_mission_status(mission_id="<id>")
+```
+
+Prefer polling with `get_mission_status` over `wait_for_mission` for long-running missions, so the user sees progress updates.
+
+5. **Read the report** for each completed mission:
+
+```
+mcp__devfleet__get_report(mission_id="<mission_id>")
+```
+
+Call this for every mission that reached a terminal state. Reports contain: files_changed, what_done, what_open, what_tested, what_untested, next_steps, errors_encountered.
+
+## All Available Tools
+
+| Tool | Purpose |
+|------|---------|
+| `plan_project(prompt)` | AI breaks description into chained missions with `auto_dispatch=true` |
+| `create_project(name, path?, description?)` | Create a project manually, returns `project_id` |
+| `create_mission(project_id, title, prompt, depends_on?, auto_dispatch?)` | Add a mission. `depends_on` is a list of mission ID strings. |
+| `dispatch_mission(mission_id, model?, max_turns?)` | Start an agent |
+| `cancel_mission(mission_id)` | Stop a running agent |
+| `wait_for_mission(mission_id, timeout_seconds?)` | Block until done (prefer polling for long tasks) |
+| `get_mission_status(mission_id)` | Check progress without blocking |
+| `get_report(mission_id)` | Read structured report |
+| `get_dashboard()` | System overview |
+| `list_projects()` | Browse projects |
+| `list_missions(project_id, status?)` | List missions |
+
+## Guidelines
+
+- Always confirm the plan before dispatching unless the user said "go ahead"
+- Include mission titles and IDs when reporting status
+- If a mission fails, read its report to understand errors before retrying
+- Agent concurrency is configurable (default: 3). Excess missions queue and auto-dispatch as slots free up. Check `get_dashboard()` for slot availability.
+- Dependencies form a DAG — never create circular dependencies
+- Each agent auto-merges its worktree on completion. If a merge conflict occurs, the changes remain on the worktree branch for manual resolution.

package/commands/docs.md

@@ -0,0 +1,31 @@
+---
+description: Look up current documentation for a library or topic via Context7.
+---
+
+# /aw:docs
+
+## Purpose
+
+Look up up-to-date documentation for a library, framework, or API and return a summarized answer with relevant code snippets. Uses the Context7 MCP (resolve-library-id and query-docs) so answers reflect current docs, not training data.
+
+## Usage
+
+```
+/docs [library name] [question]
+```
+
+Use quotes for multi-word arguments so they are parsed as a single token. Example: `/docs "Next.js" "How do I configure middleware?"`
+
+If library or question is omitted, prompt the user for:
+1. The library or product name (e.g. Next.js, Prisma, Supabase).
+2. The specific question or task (e.g. "How do I set up middleware?", "Auth methods").
+
+## Workflow
+
+1. **Resolve library ID** — Call the Context7 tool `resolve-library-id` with the library name and the user's question to get a Context7-compatible library ID (e.g. `/vercel/next.js`).
+2. **Query docs** — Call `query-docs` with that library ID and the user's question.
+3. **Summarize** — Return a concise answer and include relevant code examples from the fetched documentation. Mention the library (and version if relevant).
+
+## Output
+
+The user receives a short, accurate answer backed by current docs, plus any code snippets that help. If Context7 is not available, say so and answer from training data with a note that docs may be outdated.