aw-ecc 1.4.21

package/commands/ship.md

@@ -0,0 +1,77 @@
+---
+name: aw:ship
+description: Own launch, rollout safety, rollback readiness, and release closeout after the requested release action has been prepared or executed.
+argument-hint: "<release context, rollout goal, monitoring links, or launch request>"
+status: active
+stage: ship
+internal_skill: aw-ship
+---
+
+# Ship
+
+Use `/aw:ship` for launch discipline, not as the old composite "do everything" shortcut.
+
+## Role
+
+Confirm the release is ready to launch, roll it out safely, document rollback readiness, and close out the release with the right operational evidence.
+
+## Modes
+
+| Mode | Use when | Primary outputs |
+|---|---|---|
+| `launch-readiness` | a go/no-go launch decision is needed | `release.md`, `state.json` |
+| `rollout` | staged or production rollout needs monitoring and checkpoints | `release.md`, `state.json` |
+| `closeout` | the release action happened and needs operational closeout | `release.md`, `state.json` |
+
+## Required Inputs
+
+- reviewed work
+- deploy outcome or explicit release target
+- rollback plan or blocker
+- monitoring or health-check context when available
+
+## Outputs
+
+- `.aw_docs/features/<feature_slug>/release.md`
+- updated `.aw_docs/features/<feature_slug>/state.json`
+- launch recommendation, rollout checkpoints, rollback path, and closeout notes
+
+## Shipping Rules
+
+1. Treat rollout safety as its own stage.
+2. Run the internal `aw-prepare` gate when release context, workspace state, or artifact readiness is unclear before continuing with shipping work.
+3. Continue until the selected shipping scope is covered or explicitly blocked.
+4. Confirm rollback readiness before claiming launch readiness.
+5. Capture post-deploy evidence, monitoring links, and known risks.
+6. For frontend releases, include versioned entry, smoke, and accessibility or design-signoff notes when relevant.
+7. Do not use `ship` as a synonym for composite orchestration.
+
+## Internal Phase Routing
+
+| Phase | Internal owner | Purpose |
+|---|---|---|
+| `prepare` | `aw-prepare` | verify release context, artifact readiness, and workspace safety before risky shipping work |
+| `ship` | `aw-ship` | own launch readiness, rollout safety, rollback posture, and closeout evidence |
+
+## Must Not Do
+
+- must not quietly rerun the whole SDLC under the name `ship`
+- must not claim launch safety without rollback or monitoring context
+- must not bypass org-specific release gates
+
+## Recommended Next Commands
+
+- none required
+- `/aw:review` if new launch blockers appear
+
+## Final Output Shape
+
+Always end with:
+
+- `Mode`
+- `Launch Readiness`
+- `Rollout Plan`
+- `Rollback Path`
+- `Evidence`
+- `Outcome`
+- `Next`

package/commands/skill-create.md

@@ -0,0 +1,174 @@
+---
+name: skill-create
+description: Analyze local git history to extract coding patterns and generate SKILL.md files. Local version of the Skill Creator GitHub App.
+allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
+---
+
+# /aw:skill-create - Local Skill Generation
+
+Analyze your repository's git history to extract coding patterns and generate SKILL.md files that teach Claude your team's practices.
+
+## Usage
+
+```bash
+/skill-create                    # Analyze current repo
+/skill-create --commits 100      # Analyze last 100 commits
+/skill-create --output ./skills  # Custom output directory
+/skill-create --instincts        # Also generate instincts for continuous-learning-v2
+```
+
+## What It Does
+
+1. **Parses Git History** - Analyzes commits, file changes, and patterns
+2. **Detects Patterns** - Identifies recurring workflows and conventions
+3. **Generates SKILL.md** - Creates valid Claude Code skill files
+4. **Optionally Creates Instincts** - For the continuous-learning-v2 system
+
+## Analysis Steps
+
+### Step 1: Gather Git Data
+
+```bash
+# Get recent commits with file changes
+git log --oneline -n ${COMMITS:-200} --name-only --pretty=format:"%H|%s|%ad" --date=short
+
+# Get commit frequency by file
+git log --oneline -n 200 --name-only | grep -v "^$" | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -20
+
+# Get commit message patterns
+git log --oneline -n 200 | cut -d' ' -f2- | head -50
+```
+
+### Step 2: Detect Patterns
+
+Look for these pattern types:
+
+| Pattern | Detection Method |
+|---------|-----------------|
+| **Commit conventions** | Regex on commit messages (feat:, fix:, chore:) |
+| **File co-changes** | Files that always change together |
+| **Workflow sequences** | Repeated file change patterns |
+| **Architecture** | Folder structure and naming conventions |
+| **Testing patterns** | Test file locations, naming, coverage |
+
+### Step 3: Generate SKILL.md
+
+Output format:
+
+```markdown
+---
+name: {repo-name}-patterns
+description: Coding patterns extracted from {repo-name}
+version: 1.0.0
+source: local-git-analysis
+analyzed_commits: {count}
+---
+
+# {Repo Name} Patterns
+
+## Commit Conventions
+{detected commit message patterns}
+
+## Code Architecture
+{detected folder structure and organization}
+
+## Workflows
+{detected repeating file change patterns}
+
+## Testing Patterns
+{detected test conventions}
+```
+
+### Step 4: Generate Instincts (if --instincts)
+
+For continuous-learning-v2 integration:
+
+```yaml
+---
+id: {repo}-commit-convention
+trigger: "when writing a commit message"
+confidence: 0.8
+domain: git
+source: local-repo-analysis
+---
+
+# Use Conventional Commits
+
+## Action
+Prefix commits with: feat:, fix:, chore:, docs:, test:, refactor:
+
+## Evidence
+- Analyzed {n} commits
+- {percentage}% follow conventional commit format
+```
+
+## Example Output
+
+Running `/aw:skill-create` on a TypeScript project might produce:
+
+```markdown
+---
+name: my-app-patterns
+description: Coding patterns from my-app repository
+version: 1.0.0
+source: local-git-analysis
+analyzed_commits: 150
+---
+
+# My App Patterns
+
+## Commit Conventions
+
+This project uses **conventional commits**:
+- `feat:` - New features
+- `fix:` - Bug fixes
+- `chore:` - Maintenance tasks
+- `docs:` - Documentation updates
+
+## Code Architecture
+
+```
+src/
+├── components/     # React components (PascalCase.tsx)
+├── hooks/          # Custom hooks (use*.ts)
+├── utils/          # Utility functions
+├── types/          # TypeScript type definitions
+└── services/       # API and external services
+```
+
+## Workflows
+
+### Adding a New Component
+1. Create `src/components/ComponentName.tsx`
+2. Add tests in `src/components/__tests__/ComponentName.test.tsx`
+3. Export from `src/components/index.ts`
+
+### Database Migration
+1. Modify `src/db/schema.ts`
+2. Run `pnpm db:generate`
+3. Run `pnpm db:migrate`
+
+## Testing Patterns
+
+- Test files: `__tests__/` directories or `.test.ts` suffix
+- Coverage target: 80%+
+- Framework: Vitest
+```
+
+## GitHub App Integration
+
+For advanced features (10k+ commits, team sharing, auto-PRs), use the [Skill Creator GitHub App](https://github.com/apps/skill-creator):
+
+- Install: [github.com/apps/skill-creator](https://github.com/apps/skill-creator)
+- Comment `/skill-creator analyze` on any issue
+- Receives PR with generated skills
+
+## Related Commands
+
+- `/aw:instinct-import` - Import generated instincts
+- `/aw:instinct-status` - View learned instincts
+- `/aw:evolve` - Cluster instincts into skills/agents
+
+---
+
+*Part of [Everything Claude Code](https://github.com/affaan-m/everything-claude-code)*

package/commands/skill-health.md

@@ -0,0 +1,54 @@
+---
+name: skill-health
+description: Show skill portfolio health dashboard with charts and analytics
+command: true
+---
+
+# Skill Health Dashboard
+
+Shows a comprehensive health dashboard for all skills in the portfolio with success rate sparklines, failure pattern clustering, pending amendments, and version history.
+
+## Implementation
+
+Run the skill health CLI in dashboard mode:
+
+```bash
+ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
+node "$ECC_ROOT/scripts/skills-health.js" --dashboard
+```
+
+For a specific panel only:
+
+```bash
+ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
+node "$ECC_ROOT/scripts/skills-health.js" --dashboard --panel failures
+```
+
+For machine-readable output:
+
+```bash
+ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','everything-claude-code');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
+node "$ECC_ROOT/scripts/skills-health.js" --dashboard --json
+```
+
+## Usage
+
+```
+/skill-health                    # Full dashboard view
+/skill-health --panel failures   # Only failure clustering panel
+/skill-health --json             # Machine-readable JSON output
+```
+
+## What to Do
+
+1. Run the skills-health.js script with --dashboard flag
+2. Display the output to the user
+3. If any skills are declining, highlight them and suggest running /evolve
+4. If there are pending amendments, suggest reviewing them
+
+## Panels
+
+- **Success Rate (30d)** — Sparkline charts showing daily success rates per skill
+- **Failure Patterns** — Clustered failure reasons with horizontal bar chart
+- **Pending Amendments** — Amendment proposals awaiting review
+- **Version History** — Timeline of version snapshots per skill

package/commands/tdd.md

@@ -0,0 +1,20 @@
+---
+name: aw:tdd
+description: Compatibility alias for aw:build in code mode when the user wants test-driven implementation.
+argument-hint: "<approved implementation task>"
+status: alias
+stage: build
+aliases-to: aw:build
+---
+
+# TDD
+
+`/aw:tdd` is a compatibility alias.
+
+The canonical implementation surface is `/aw:build`, which may run in code mode using a TDD-oriented workflow when appropriate.
+
+See:
+
+- `commands/build.md` for the public build contract
+- `skills/aw-build/SKILL.md` for the canonical build-stage behavior
+- `references/testing-patterns.md` for failure-first and TDD guidance

package/commands/test-coverage.md

@@ -0,0 +1,77 @@
+# Test Coverage
+
+Analyze test coverage, identify gaps, and generate missing tests to reach 80%+ coverage.
+
+## Step 1: Detect Test Framework
+
+| Indicator | Coverage Command |
+|-----------|-----------------|
+| `jest.config.*` or `package.json` jest | `npx jest --coverage --coverageReporters=json-summary` |
+| `vitest.config.*` | `npx vitest run --coverage` |
+| `pytest.ini` / `pyproject.toml` pytest | `pytest --cov=src --cov-report=json` |
+| `Cargo.toml` | `cargo llvm-cov --json` |
+| `pom.xml` with JaCoCo | `mvn test jacoco:report` |
+| `go.mod` | `go test -coverprofile=coverage.out ./...` |
+
+## Step 2: Analyze Coverage Report
+
+1. Run the coverage command
+2. Parse the output (JSON summary or terminal output)
+3. List files **below 80% coverage**, sorted worst-first
+4. For each under-covered file, identify:
+   - Untested functions or methods
+   - Missing branch coverage (if/else, switch, error paths)
+   - Dead code that inflates the denominator
+
+## Step 3: Generate Missing Tests
+
+For each under-covered file, generate tests following this priority:
+
+1. **Happy path** — Core functionality with valid inputs
+2. **Error handling** — Invalid inputs, missing data, network failures
+3. **Edge cases** — Empty arrays, null/undefined, boundary values (0, -1, MAX_INT)
+4. **Branch coverage** — Each if/else, switch case, ternary
+
+### Test Generation Rules
+
+- Place tests adjacent to source: `foo.ts` → `foo.test.ts` (or project convention)
+- Use existing test patterns from the project (import style, assertion library, mocking approach)
+- Mock external dependencies (database, APIs, file system)
+- Each test should be independent — no shared mutable state between tests
+- Name tests descriptively: `test_create_user_with_duplicate_email_returns_409`
+
+## Step 4: Verify
+
+1. Run the full test suite — all tests must pass
+2. Re-run coverage — verify improvement
+3. If still below 80%, repeat Step 3 for remaining gaps
+
+## Step 5: Report
+
+Show before/after comparison:
+
+```
+Coverage Report
+──────────────────────────────
+File                   Before  After
+src/services/auth.ts   45%     88%
+src/utils/validation.ts 32%    82%
+──────────────────────────────
+Overall:               67%     84%  ✅
+```
+
+## Focus Areas
+
+- Functions with complex branching (high cyclomatic complexity)
+- Error handlers and catch blocks
+- Utility functions used across the codebase
+- API endpoint handlers (request → response flow)
+- Edge cases: null, undefined, empty string, empty array, zero, negative numbers
+
+---
+
+## GHL Platform Integration
+
+Also activate the matching `platform-sdet-*` agent.
+Also activate the matching platform domain family resolved by `using-aw-skills`.
+For ALL activated agents: read frontmatter → load each skill from `skills:` array.

package/commands/test.md

@@ -0,0 +1,64 @@
+---
+name: aw:test
+description: Produce fresh QA evidence for a feature, bugfix, or release scope using the resolved repo and org quality gates.
+argument-hint: "<feature, fix, branch, diff, artifact, or release scope>"
+status: active
+stage: test
+internal_skill: aw-test
+---
+
+# Test
+
+Use `/aw:test` to prove the requested scope works with current evidence.
+
+## Role
+
+Run the smallest correct QA scope for the requested feature, fix, or release and write the evidence down clearly enough for review and deploy to trust it.
+
+## Modes
+
+| Mode | Use when | Primary outputs |
+|---|---|---|
+| `feature` | validating a scoped implementation | `verification.md`, `state.json` |
+| `bugfix` | proving a repaired behavior and regression guard | `verification.md`, `state.json` |
+| `release` | validating the broader release-ready scope | `verification.md`, `state.json` |
+| `ui-runtime` | frontend runtime, responsive, and interaction proof | `verification.md`, `state.json` |
+
+## Outputs
+
+- `.aw_docs/features/<feature_slug>/verification.md`
+- updated `.aw_docs/features/<feature_slug>/state.json`
+- fresh evidence for local validation, E2E, external validation, or targeted runtime checks
+
+## QA Rules
+
+1. Select the smallest correct test scope, not the loudest available suite.
+2. Inherit the resolved GHL baseline profile for local validation, E2E, sandbox, and quality-gate expectations.
+3. For bugfixes, prove the failing signal and the regression guard.
+4. For frontend work, include responsive, accessibility-aware, and runtime evidence when relevant.
+5. Continue until the requested QA scope is covered or explicitly blocked.
+6. Mark unavailable checks as unavailable instead of inventing a pass.
+7. Hand off to `/aw:review` when findings, governance, or readiness still need a decision.
+
+## Must Not Do
+
+- must not silently reuse stale evidence after code changed
+- must not implement code while testing
+- must not collapse feature QA and release readiness into one vague summary
+
+## Recommended Next Commands
+
+- `/aw:review`
+- `/aw:build` if a failure requires repair
+
+## Final Output Shape
+
+Always end with:
+
+- `Mode`
+- `Scope`
+- `Checks Run`
+- `Evidence`
+- `Failures`
+- `Unavailable`
+- `Next`

package/commands/update-codemaps.md

@@ -0,0 +1,72 @@
+# Update Codemaps
+
+Analyze the codebase structure and generate token-lean architecture documentation.
+
+## Step 1: Scan Project Structure
+
+1. Identify the project type (monorepo, single app, library, microservice)
+2. Find all source directories (src/, lib/, app/, packages/)
+3. Map entry points (main.ts, index.ts, app.py, main.go, etc.)
+
+## Step 2: Generate Codemaps
+
+Create or update codemaps in `docs/CODEMAPS/` (or `.reports/codemaps/`):
+
+| File | Contents |
+|------|----------|
+| `architecture.md` | High-level system diagram, service boundaries, data flow |
+| `backend.md` | API routes, middleware chain, service → repository mapping |
+| `frontend.md` | Page tree, component hierarchy, state management flow |
+| `data.md` | Database tables, relationships, migration history |
+| `dependencies.md` | External services, third-party integrations, shared libraries |
+
+### Codemap Format
+
+Each codemap should be token-lean — optimized for AI context consumption:
+
+```markdown
+# Backend Architecture
+
+## Routes
+POST /api/users → UserController.create → UserService.create → UserRepo.insert
+GET  /api/users/:id → UserController.get → UserService.findById → UserRepo.findById
+
+## Key Files
+src/services/user.ts (business logic, 120 lines)
+src/repos/user.ts (database access, 80 lines)
+
+## Dependencies
+- PostgreSQL (primary data store)
+- Redis (session cache, rate limiting)
+- Stripe (payment processing)
+```
+
+## Step 3: Diff Detection
+
+1. If previous codemaps exist, calculate the diff percentage
+2. If changes > 30%, show the diff and request user approval before overwriting
+3. If changes <= 30%, update in place
+
+## Step 4: Add Metadata
+
+Add a freshness header to each codemap:
+
+```markdown
+<!-- Generated: 2026-02-11 | Files scanned: 142 | Token estimate: ~800 -->
+```
+
+## Step 5: Save Analysis Report
+
+Write a summary to `.reports/codemap-diff.txt`:
+- Files added/removed/modified since last scan
+- New dependencies detected
+- Architecture changes (new routes, new services, etc.)
+- Staleness warnings for docs not updated in 90+ days
+
+## Tips
+
+- Focus on **high-level structure**, not implementation details
+- Prefer **file paths and function signatures** over full code blocks
+- Keep each codemap under **1000 tokens** for efficient context loading
+- Use ASCII diagrams for data flow instead of verbose descriptions
+- Run after major feature additions or refactoring sessions

package/commands/update-docs.md

@@ -0,0 +1,84 @@
+# Update Documentation
+
+Sync documentation with the codebase, generating from source-of-truth files.
+
+## Step 1: Identify Sources of Truth
+
+| Source | Generates |
+|--------|-----------|
+| `package.json` scripts | Available commands reference |
+| `.env.example` | Environment variable documentation |
+| `openapi.yaml` / route files | API endpoint reference |
+| Source code exports | Public API documentation |
+| `Dockerfile` / `docker-compose.yml` | Infrastructure setup docs |
+
+## Step 2: Generate Script Reference
+
+1. Read `package.json` (or `Makefile`, `Cargo.toml`, `pyproject.toml`)
+2. Extract all scripts/commands with their descriptions
+3. Generate a reference table:
+
+```markdown
+| Command | Description |
+|---------|-------------|
+| `npm run dev` | Start development server with hot reload |
+| `npm run build` | Production build with type checking |
+| `npm test` | Run test suite with coverage |
+```
+
+## Step 3: Generate Environment Documentation
+
+1. Read `.env.example` (or `.env.template`, `.env.sample`)
+2. Extract all variables with their purposes
+3. Categorize as required vs optional
+4. Document expected format and valid values
+
+```markdown
+| Variable | Required | Description | Example |
+|----------|----------|-------------|---------|
+| `DATABASE_URL` | Yes | PostgreSQL connection string | `postgres://user:pass@host:5432/db` |
+| `LOG_LEVEL` | No | Logging verbosity (default: info) | `debug`, `info`, `warn`, `error` |
+```
+
+## Step 4: Update Contributing Guide
+
+Generate or update `docs/CONTRIBUTING.md` with:
+- Development environment setup (prerequisites, install steps)
+- Available scripts and their purposes
+- Testing procedures (how to run, how to write new tests)
+- Code style enforcement (linter, formatter, pre-commit hooks)
+- PR submission checklist
+
+## Step 5: Update Runbook
+
+Generate or update `docs/RUNBOOK.md` with:
+- Deployment procedures (step-by-step)
+- Health check endpoints and monitoring
+- Common issues and their fixes
+- Rollback procedures
+- Alerting and escalation paths
+
+## Step 6: Staleness Check
+
+1. Find documentation files not modified in 90+ days
+2. Cross-reference with recent source code changes
+3. Flag potentially outdated docs for manual review
+
+## Step 7: Show Summary
+
+```
+Documentation Update
+──────────────────────────────
+Updated:  docs/CONTRIBUTING.md (scripts table)
+Updated:  docs/ENV.md (3 new variables)
+Flagged:  docs/DEPLOY.md (142 days stale)
+Skipped:  docs/API.md (no changes detected)
+──────────────────────────────
+```
+
+## Rules
+
+- **Single source of truth**: Always generate from code, never manually edit generated sections
+- **Preserve manual sections**: Only update generated sections; leave hand-written prose intact
+- **Mark generated content**: Use `<!-- AUTO-GENERATED -->` markers around generated sections
+- **Don't create docs unprompted**: Only create new doc files if the command explicitly requests it

package/commands/verify.md

@@ -0,0 +1,55 @@
+---
+name: aw:verify
+description: Compatibility entrypoint for the older verification stage. Route to aw:test, aw:review, or the smallest correct combined verification flow.
+argument-hint: "<branch, PR, diff, artifact, or readiness request>"
+status: active
+stage: compatibility
+internal_skill: aw-verify
+---
+
+# Verify
+
+Use `/aw:verify` only as a compatibility entrypoint.
+The canonical public model is now:
+
+- `/aw:test` for QA and fresh evidence
+- `/aw:review` for findings, governance, and readiness
+
+## Role
+
+Preserve legacy muscle memory while routing to the smallest correct modern verification flow.
+This entrypoint inherits the same rule that the selected test or review scope should be completed or blocked explicitly before handoff.
+
+## Compatibility Mapping
+
+| Legacy intent | Canonical route |
+|---|---|
+| feature QA, regression proof, runtime validation | `/aw:test` |
+| findings-oriented review, governance, readiness | `/aw:review` |
+| broad "verify this" requests | `/aw:test -> /aw:review` when both are needed |
+
+## Outputs
+
+- `.aw_docs/features/<feature_slug>/verification.md`
+- updated `.aw_docs/features/<feature_slug>/state.json`
+
+## Must Not Do
+
+- must not preserve the old overloaded verify semantics when a narrower stage is clear
+- must not bypass fresh evidence requirements
+
+## Recommended Next Commands
+
+- `/aw:test`
+- `/aw:review`
+- `/aw:deploy`
+
+## Final Output Shape
+
+Always end with:
+
+- `Compatibility Route`
+- `Canonical Flow`
+- `Evidence`
+- `Outcome`
+- `Next`