aw-ecc 1.4.21

package/skills/team-builder/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: team-builder
+description: Interactive agent picker for composing and dispatching parallel teams
+origin: community
+---
+
+# Team Builder
+
+Interactive menu for browsing and composing agent teams on demand. Works with flat or domain-subdirectory agent collections.
+
+## When to Use
+
+- You have multiple agent personas (markdown files) and want to pick which ones to use for a task
+- You want to compose an ad-hoc team from different domains (e.g., Security + SEO + Architecture)
+- You want to browse what agents are available before deciding
+
+## Prerequisites
+
+Agent files must be markdown files containing a persona prompt (identity, rules, workflow, deliverables). The first `# Heading` is used as the agent name and the first paragraph as the description.
+
+Both flat and subdirectory layouts are supported:
+
+**Subdirectory layout** — domain is inferred from the folder name:
+
+```
+agents/
+├── engineering/
+│   ├── security-engineer.md
+│   └── software-architect.md
+├── marketing/
+│   └── seo-specialist.md
+└── sales/
+    └── discovery-coach.md
+```
+
+**Flat layout** — domain inferred from shared filename prefixes. A prefix counts as a domain when 2+ files share it. Files with unique prefixes go to "General". Note: the algorithm splits at the first `-`, so multi-word domains (e.g., `product-management`) should use the subdirectory layout instead:
+
+```
+agents/
+├── engineering-security-engineer.md
+├── engineering-software-architect.md
+├── marketing-seo-specialist.md
+├── marketing-content-strategist.md
+├── sales-discovery-coach.md
+└── sales-outbound-strategist.md
+```
+
+## Configuration
+
+Agent directories are probed in order and results are merged:
+
+1. `./agents/**/*.md` + `./agents/*.md` — project-local agents (both depths)
+2. `~/.claude/agents/**/*.md` + `~/.claude/agents/*.md` — global agents (both depths)
+
+Results from all locations are merged and deduplicated by agent name. Project-local agents take precedence over global agents with the same name. A custom path can be used instead if the user specifies one.
+
+## How It Works
+
+### Step 1: Discover Available Agents
+
+Glob agent directories using the probe order above. Exclude README files. For each file found:
+- **Subdirectory layout:** extract the domain from the parent folder name
+- **Flat layout:** collect all filename prefixes (text before the first `-`). A prefix qualifies as a domain only if it appears in 2 or more filenames (e.g., `engineering-security-engineer.md` and `engineering-software-architect.md` both start with `engineering` → Engineering domain). Files with unique prefixes (e.g., `code-reviewer.md`, `tdd-guide.md`) are grouped under "General"
+- Extract the agent name from the first `# Heading`. If no heading is found, derive the name from the filename (strip `.md`, replace hyphens with spaces, title-case)
+- Extract a one-line summary from the first paragraph after the heading
+
+If no agent files are found after probing all locations, inform the user: "No agent files found. Checked: [list paths probed]. Expected: markdown files in one of those directories." Then stop.
+
+### Step 2: Present Domain Menu
+
+```
+Available agent domains:
+1. Engineering — Software Architect, Security Engineer
+2. Marketing — SEO Specialist
+3. Sales — Discovery Coach, Outbound Strategist
+
+Pick domains or name specific agents (e.g., "1,3" or "security + seo"):
+```
+
+- Skip domains with zero agents (empty directories)
+- Show agent count per domain
+
+### Step 3: Handle Selection
+
+Accept flexible input:
+- Numbers: "1,3" selects all agents from Engineering and Sales
+- Names: "security + seo" fuzzy-matches against discovered agents
+- "all from engineering" selects every agent in that domain
+
+If more than 5 agents are selected, list them alphabetically and ask the user to narrow down: "You selected N agents (max 5). Pick which to keep, or say 'first 5' to use the first five alphabetically."
+
+Confirm selection:
+```
+Selected: Security Engineer + SEO Specialist
+What should they work on? (describe the task):
+```
+
+### Step 4: Spawn Agents in Parallel
+
+1. Read each selected agent's markdown file
+2. Prompt for the task description if not already provided
+3. Spawn all agents in parallel using the Agent tool:
+   - `subagent_type: "general-purpose"`
+   - `prompt: "{agent file content}\n\nTask: {task description}"`
+   - Each agent runs independently — no inter-agent communication needed
+4. If an agent fails (error, timeout, or empty output), note the failure inline (e.g., "Security Engineer: failed — [reason]") and continue with results from agents that succeeded
+
+### Step 5: Synthesize Results
+
+Collect all outputs and present a unified report:
+- Results grouped by agent
+- Synthesis section highlighting:
+  - Agreements across agents
+  - Conflicts or tensions between recommendations
+  - Recommended next steps
+
+If only 1 agent was selected, skip synthesis and present the output directly.
+
+## Rules
+
+- **Dynamic discovery only.** Never hardcode agent lists. New files in the directory auto-appear in the menu.
+- **Max 5 agents per team.** More than 5 produces diminishing returns and excessive token usage. Enforce at selection time.
+- **Parallel dispatch.** All agents run simultaneously — use the Agent tool's parallel invocation pattern.
+- **Parallel Agent calls, not TeamCreate.** This skill uses parallel Agent tool calls for independent work. TeamCreate (a Claude Code tool for multi-agent dialogue) is only needed when agents must debate or respond to each other.
+
+## Examples
+
+```
+User: team builder
+
+Claude:
+Available agent domains:
+1. Engineering (2) — Software Architect, Security Engineer
+2. Marketing (1) — SEO Specialist
+3. Sales (4) — Discovery Coach, Outbound Strategist, Proposal Strategist, Sales Engineer
+4. Support (1) — Executive Summary
+
+Pick domains or name specific agents:
+
+User: security + seo
+
+Claude:
+Selected: Security Engineer + SEO Specialist
+What should they work on?
+
+User: Review my Next.js e-commerce site before launch
+
+[Both agents spawn in parallel, each applying their specialty to the codebase]
+
+Claude:
+## Security Engineer Findings
+- [findings...]
+
+## SEO Specialist Findings
+- [findings...]
+
+## Synthesis
+Both agents agree on: [...]
+Tension: Security recommends CSP that blocks inline styles, SEO needs inline schema markup. Resolution: [...]
+Next steps: [...]
+```

package/skills/using-aw-skills/SKILL.md

@@ -0,0 +1,290 @@
+---
+name: using-aw-skills
+description: Session-start skill-first routing for the AW SDLC surface. Select the smallest correct AW skill stack before any substantive response, then load deeper stage, domain, and org-standard detail on demand.
+trigger: Every session start. Loaded automatically via session-start hook.
+---
+
+# Using AW Skills
+
+## Overview
+
+This skill is the thin router for the AW SDLC surface.
+Its job is to:
+
+- choose the smallest correct public route
+- choose the smallest correct AW skill stack
+- stop generic commentary until the stage is clear
+- load deeper references only when they materially change the decision
+
+Keep this file small.
+Stage behavior belongs in stage skills.
+Long examples, checklists, and loading guidance belong in shared references.
+
+This means the file should optimize for one thing first:
+
+- make the right next skill obvious
+
+## When to Use
+
+- at session start
+- before any substantive response
+- whenever the request might map to planning, building, investigating, testing, reviewing, deploying, or shipping work
+- whenever the user gives a vague request and the right stage still has to be selected
+
+Do not skip this skill just because the work looks small.
+
+## Skill Discovery
+
+When a task arrives, identify the current delivery phase and load the smallest correct route:
+
+```text
+Task arrives
+    │
+    ├── Vague idea, spec, or task breakdown? ───────→ /aw:plan
+    ├── Approved change to implement? ──────────────→ /aw:build
+    ├── Bug, alert, or unclear runtime failure? ────→ /aw:investigate
+    ├── Need QA proof or regression evidence? ──────→ /aw:test
+    ├── Need findings or readiness decision? ───────→ /aw:review
+    ├── Need one concrete release action? ──────────→ /aw:deploy
+    ├── Need launch or rollout closeout? ───────────→ /aw:ship
+    └── Need one-run end-to-end automation? ───────→ aw-yolo
+```
+
+Then load the supporting craft and domain skills that sharpen that route.
+If the work is in a real GHL domain, load `using-platform-skills` next.
+
+## Public Surface
+
+The public surface stays intentionally small.
+The canonical routes are the stages shown in the discovery flow above:
+
+- `/aw:plan`, `/aw:build`, `/aw:test`, `/aw:review`, `/aw:deploy`, `/aw:ship`
+- `/aw:investigate`
+
+Default delivery flow:
+
+- `/aw:plan` -> `/aw:build` -> `/aw:test` -> `/aw:review` -> `/aw:deploy` -> `/aw:ship`
+
+Conditional route:
+
+- `/aw:investigate`
+
+`/aw:investigate` is a first-class route for bugs, alerts, regressions, and unclear root cause.
+It should not be treated as a mandatory phase in every request.
+
+Compatibility entrypoints remain available during migration:
+
+- `/aw:execute` -> `/aw:build`
+- `/aw:verify` -> `/aw:test`, `/aw:review`, or the smallest correct combined verification flow
+
+There is also one explicit internal power workflow:
+
+- `aw-yolo`
+
+`aw-yolo` is for clearly end-to-end requests where the user wants one-run automation.
+It should not become the default route for normal stage-specific work.
+When it is selected, begin at the first unsatisfied stage rather than restarting the lifecycle from the top.
+
+## Core Operating Behaviors
+
+These behaviors apply across every route.
+
+### 1. Surface Assumptions
+
+Name assumptions that materially change scope, architecture, rollout, or verification.
+If an assumption could change the selected route, say it early.
+
+### 2. Manage Confusion Actively
+
+If the request, spec, code, or baseline disagree:
+
+1. stop
+2. name the contradiction
+3. state the tradeoff or blocking question
+4. do not guess through it
+
+### 3. Push Back With Concrete Tradeoffs
+
+If an approach creates obvious risk, complexity, or rollout danger:
+
+- say so directly
+- name the downside
+- propose the smallest safer alternative
+
+### 4. Enforce Simplicity
+
+Prefer the smallest route and the smallest supporting skill stack.
+Do not turn a single-stage task into a hidden multi-stage workflow.
+
+### 5. Maintain Scope Discipline
+
+Touch only the stage and supporting context required for the current request.
+Do not reopen planning, implementation, or release work without a reason.
+
+### 6. Verify, Don't Assume
+
+Every route must eventually produce evidence, not just confidence.
+Proof belongs in the right stage artifact, not only in narration.
+
+## Always-On Activation
+
+Before any substantive response, this router must select the smallest correct AW skill stack and matching public route.
+
+- explicit user command -> honor that command and load the mapped AW stage skill first
+- clear process need -> load the needed internal process skill first
+- otherwise choose the smallest correct AW primary stage skill and matching public route by intent
+- only after the required AW skills are selected, load deeper domain skills or ask clarifying questions
+
+Do not start with generic implementation, review, or deploy advice before skill selection.
+Do not leave the active skill stack or matching route implicit for non-trivial work.
+
+## The Rule
+
+If there is even a small chance that an AW process skill, stage skill, or required domain skill applies, load it before responding.
+
+Questions count.
+Clarifying questions count.
+Quick exploration counts.
+
+The AW public command is the user-facing projection of the selected primary stage skill.
+
+## Skill Priority
+
+When multiple AW skills could apply, use this order:
+
+1. process skills first:
+   - `aw-brainstorm`
+   - `aw-debug`
+   - `aw-prepare`
+   - `aw-yolo`
+2. primary stage skills second:
+   - `aw-plan`
+   - `aw-build`
+   - `aw-investigate`
+   - `aw-test`
+   - `aw-review`
+   - `aw-deploy`
+   - `aw-ship`
+3. domain and cross-cutting skills third
+
+The selected public route should reflect the primary stage skill, not hide it.
+
+## Route Selection
+
+Use one primary route unless the user explicitly asks for end-to-end orchestration.
+
+For route examples, explicit routing priority, and scope guardrails, see [`../../references/route-selection-patterns.md`](../../references/route-selection-patterns.md).
+
+## Failure Modes to Avoid
+
+These patterns look productive, but they create routing drift:
+
+1. answering quickly before selecting a route
+2. treating exploration as exempt from routing
+3. choosing `/aw:investigate` for every bug, even when the fix is already known
+4. treating `aw-yolo` as the default because it feels convenient
+5. reopening planning during `build` without a real blocker
+6. silently implementing during `test` or `review`
+7. loading every domain skill "just in case"
+8. giving a confident answer without evidence or stage artifacts
+
+## Cross-Cutting Engineering Skills
+
+After the primary stage is selected, load the portable craft skill that best sharpens the work:
+
+- `idea-refine`
+- `context-engineering`
+- `incremental-implementation`
+- `frontend-ui-engineering`
+- `api-and-interface-design`
+- `browser-testing-with-devtools`
+- `code-simplification`
+- `security-and-hardening`
+- `performance-optimization`
+- `git-workflow-and-versioning`
+- `ci-cd-and-automation`
+- `deprecation-and-migration`
+- `documentation-and-adrs`
+
+Load them because they improve the selected stage, not because they create a new public route.
+For domain families, cross-cutting guidance, and org-standard loading, see [`../../references/domain-skill-loading.md`](../../references/domain-skill-loading.md).
+
+## Platform Skill Loading
+
+After the primary AW route is known, use `using-platform-skills` when GHL platform behavior materially affects the stage.
+
+- backend and worker work -> `platform-services:*`
+- frontend and design-system work -> `platform-frontend:*` plus `platform-design:*`
+- data and migrations -> `platform-data:*`
+- infra and deploy paths -> `platform-infra:*`
+- test systems and QA governance -> `platform-sdet:*`
+- review depth and readiness -> `platform-review:*`
+- product context and business behavior -> `platform-product:*`
+
+Use `using-platform-skills` to decide the first supporting platform skills for the selected stage.
+
+## Context Loading
+
+Load context in the smallest order that reduces uncertainty without flooding the session.
+Start with repo-local contracts and approved AW artifacts before broad code search or domain docs.
+
+See [`../../references/context-loading-and-intake.md`](../../references/context-loading-and-intake.md).
+
+## Org Standards Always On
+
+When the selected stage falls inside a resolved baseline profile, the stage must honor:
+
+- `defaults/aw-sdlc/baseline-profiles.yml`
+- relevant platform playbooks
+- relevant `.aw_rules`
+
+Frontend work should still inherit HighRise, accessibility, responsive, and review expectations.
+Release work should still inherit governance, rollback, and evidence expectations.
+See [`../../references/domain-skill-loading.md`](../../references/domain-skill-loading.md).
+
+## Skill Rules
+
+1. Check for an applicable AW route before starting real work.
+2. Use one primary route unless the user explicitly asks for end-to-end orchestration.
+3. Load process skills before stage skills when the process itself changes the right path.
+4. Load domain and craft skills only after the primary route is clear.
+5. Load `using-platform-skills` when a GHL platform family materially changes the work.
+6. When in doubt between diagnosis and implementation, choose `/aw:investigate` only if root cause is still unclear.
+7. When in doubt between a normal route and `aw-yolo`, prefer the normal route.
+
+## Typical Sequences
+
+For a normal feature:
+
+```text
+/aw:plan -> /aw:build -> /aw:test -> /aw:review -> /aw:deploy -> /aw:ship
+```
+
+For a bug with unclear root cause:
+
+```text
+/aw:investigate -> /aw:build -> /aw:test -> /aw:review
+```
+
+For a release-ready change that only needs rollout work:
+
+```text
+/aw:deploy -> /aw:ship
+```
+
+For explicit one-run automation:
+
+```text
+aw-yolo -> [smallest correct internal stage sequence]
+```
+
+## Verification
+
+Before moving past routing, confirm:
+
+- [ ] the smallest correct AW skill stack was selected first
+- [ ] the public route matches the actual stage intent
+- [ ] `/aw:investigate` was only chosen when diagnosis is actually required
+- [ ] org-standard playbooks and `.aw_rules` are loaded when the baseline requires them
+- [ ] the task is not being silently broadened into extra stages
+- [ ] `aw-yolo` is used only when the user explicitly asked for end-to-end automation

package/skills/using-aw-skills/evals/skill-trigger-cases.tsv

@@ -0,0 +1,25 @@
+# mode	prompt	expected_pattern	description	expected_route	primary_skill	supporting_skills
+quick	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Create the implementation spec for the approved Communities moderation API contract. Do not make me write a PRD first.	plan;aw-plan;platform-services	Backend planning intent selects aw-plan plus backend domain support	plan	aw-plan	platform-services:development
+quick	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Help me refine this idea for an AI-powered renewal reminder flow before we write the spec.	plan;aw-plan;idea-refine	Fuzzy concept should still resolve to aw-plan while loading idea-refine first	plan	aw-plan	idea-refine
+quick	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Design a stable API contract for the approved webhook retry interface change.	plan;aw-plan;api-and-interface-design	Contract-first planning should resolve to aw-plan with api-and-interface-design support	plan	aw-plan	api-and-interface-design
+quick	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Investigate this Communities moderation worker retry failure and tell me the likely fault surface before patching.	investigate;aw-investigate;grafana	Backend investigate intent selects aw-investigate plus runtime triage support	investigate	aw-investigate	platform-infra:grafana
+quick	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Deploy this verified Communities feed MFA to staging.	deploy;aw-deploy;deploy-versioned-mfa;staging-deploy	Frontend deploy intent selects aw-deploy plus versioned MFA deploy support	deploy	aw-deploy	deploy-versioned-mfa,platform-infra:staging-deploy,platform-infra:production-readiness
+quick	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Test this UI fix in the browser and inspect the DOM, console, and network requests.	test;aw-test;browser-testing-with-devtools	Browser-runtime proof should resolve to aw-test with DevTools support	test	aw-test	browser-testing-with-devtools
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Take the approved Communities moderation API change forward and make the required code updates in the moderation queue path.	build;aw-build;platform-services;development	Backend build intent selects aw-build plus backend development support	build	aw-build	platform-services:development,quality-gate-coder
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Simplify this already-working handler without changing behavior and keep the diff easy to review.	build;aw-build;code-simplification	Simplification work should stay in build while loading the simplification craft skill	build	aw-build	code-simplification
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Harden this callback boundary and close the obvious trust and validation gaps.	build;aw-build;security-and-hardening	Hardening work should route to aw-build with security craft support	build	aw-build	security-and-hardening
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Measure why this page is slow, optimize the hot path, and keep the change bounded.	build;aw-build;performance-optimization	Measure-first optimization should route to aw-build with performance craft support	build	aw-build	performance-optimization
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Make this implementation in clean save points and keep the branch history reviewable.	build;aw-build;git-workflow-and-versioning	Git hygiene during implementation should stay in aw-build with git workflow support	build	aw-build	git-workflow-and-versioning
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Test the repaired Communities moderation API change and prove the regression guard still holds.	test;aw-test;quality-gates	Test intent selects aw-test plus quality-gate support	test	aw-test	platform-sdet:quality-gates
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Review this Communities moderation API PR and tell me if it is ready for staging.	review;aw-review;code-review-pr;quality-gates	Backend review intent selects aw-review plus review and quality gates	review	aw-review	platform-review:code-review-pr,platform-sdet:quality-gates
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Record why we chose this queueing model and update the docs the next engineer will need.	review;aw-review;documentation-and-adrs	Decision-capture work should resolve to aw-review with docs-and-adrs support	review	aw-review	documentation-and-adrs
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Take this Communities moderation API change through PR creation and staging version deployment.	ship;aw-ship;code-review-pr;staging-deploy	Backend ship intent selects aw-ship plus review and deploy support	ship	aw-ship	platform-review:code-review-pr,platform-infra:staging-deploy,platform-infra:production-readiness
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Create the implementation spec for the approved Communities feed MFA change.	plan;aw-plan;vue-development;design	Frontend planning intent selects aw-plan plus frontend/design domain support	plan	aw-plan	platform-design:system,platform-frontend:vue-development
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Plan the migration off the legacy webhook endpoint and show the deprecation path before we remove anything.	plan;aw-plan;deprecation-and-migration	Migration planning should resolve to aw-plan with deprecation support	plan	aw-plan	deprecation-and-migration
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Take the approved Communities feed MFA UI change forward and update the app accordingly.	build;aw-build;highrise;vue-development	Frontend build intent selects aw-build plus UI implementation support	build	aw-build	platform-frontend:vue-development,highrise-ui-governance,quality-gate-coder
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Test the approved Communities feed MFA UI change for responsive and accessibility regressions.	test;aw-test;a11y-review;quality-gates	Frontend test intent selects aw-test plus accessibility and quality-gate support	test	aw-test	platform-frontend:a11y-review,platform-sdet:quality-gates
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Review this Communities feed MFA PR and tell me if it is ready for staging.	review;aw-review;code-review-pr;a11y-review;design	Frontend review intent selects aw-review plus review, design, and accessibility support	review	aw-review	platform-review:code-review-pr,platform-design:review,platform-frontend:a11y-review,platform-sdet:quality-gates
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Deploy this verified Communities moderation API service to staging.	deploy;aw-deploy;staging-deploy;production-readiness	Backend deploy intent selects aw-deploy plus staging deploy support	deploy	aw-deploy	platform-infra:staging-deploy,platform-infra:deployment-strategies,platform-infra:production-readiness
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Set up the release automation, preview gates, and rollback path for this service deployment.	deploy;aw-deploy;ci-cd-and-automation	Release-automation work should resolve to aw-deploy with CI/CD craft support	deploy	aw-deploy	ci-cd-and-automation
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Take this Communities feed MFA change through PR creation and staging version deployment.	ship;aw-ship;deploy-versioned-mfa;staging-deploy	Frontend ship intent selects aw-ship plus versioned MFA deploy support	ship	aw-ship	deploy-versioned-mfa,platform-infra:staging-deploy,platform-infra:production-readiness
+full	For the request below, answer with the primary AW public stage, the primary AW stage skill, and the first supporting platform skills you would load. Request: Prepare the launch checklist, rollback notes, and monitoring plan for this release.	ship;aw-ship;documentation-and-adrs;ci-cd-and-automation	Launch-closeout work should stay in aw-ship with docs and CI/CD support	ship	aw-ship	documentation-and-adrs,ci-cd-and-automation

package/skills/using-aw-skills/evals/test-skill-triggers.sh

@@ -0,0 +1,171 @@
+#!/usr/bin/env bash
+# Test harness for verifying SDLC skill auto-triggering across AI CLIs.
+# Public AW surface under test: /aw:plan, /aw:build, /aw:investigate,
+# /aw:test, /aw:review, /aw:deploy, and /aw:ship.
+
+set -uo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+RESULTS_DIR="$SCRIPT_DIR/results"
+CASES_FILE="$SCRIPT_DIR/skill-trigger-cases.tsv"
+DEFAULT_WORKSPACE_DIR="$(cd "$SCRIPT_DIR/../../.." && pwd)"
+WORKSPACE_DIR="${WORKSPACE_DIR:-$DEFAULT_WORKSPACE_DIR}"
+TIMESTAMP=$(date +%Y%m%d_%H%M%S)
+MAX_TURNS=3
+QUICK_MODE=false
+
+mkdir -p "$RESULTS_DIR"
+
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[0;33m'
+BLUE='\033[0;34m'
+NC='\033[0m'
+
+run_with_timeout() {
+  local secs="$1"
+  shift
+  if command -v gtimeout &>/dev/null; then
+    gtimeout "$secs" "$@"
+  else
+    perl -e "
+      alarm $secs;
+      \$SIG{ALRM} = sub { kill 9, \$pid; exit 124 };
+      \$pid = fork;
+      if (\$pid == 0) { exec @ARGV; }
+      waitpid \$pid, 0;
+      exit \$? >> 8;
+    " "$@"
+  fi
+}
+
+load_test_cases() {
+  local mode_filter="$1"
+  local -n out_cases="$2"
+
+  if [ ! -f "$CASES_FILE" ]; then
+    echo "Missing cases file: $CASES_FILE" >&2
+    exit 1
+  fi
+
+  while IFS=$'\t' read -r mode prompt expected_pattern description expected_route primary_skill supporting_skills; do
+    if [ -z "${mode:-}" ] || [[ "$mode" == \#* ]]; then
+      continue
+    fi
+
+    if [ "$mode_filter" = "quick" ] && [ "$mode" != "quick" ]; then
+      continue
+    fi
+
+    out_cases+=("$prompt|$expected_pattern|$description|$expected_route|$primary_skill|$supporting_skills")
+  done < "$CASES_FILE"
+}
+
+run_prompt() {
+  local cli="$1"
+  local prompt="$2"
+  local output_file="$3"
+
+  cd "$WORKSPACE_DIR"
+
+  case "$cli" in
+    claude)
+      run_with_timeout 120 claude -p "$prompt" \
+        --output-format text \
+        --max-turns "$MAX_TURNS" \
+        > "$output_file" 2>&1 || true
+      ;;
+    codex)
+      run_with_timeout 120 codex exec --skip-git-repo-check --sandbox read-only "$prompt" \
+        > "$output_file" 2>&1 || true
+      ;;
+    cursor)
+      run_with_timeout 120 cursor -p "$prompt" > "$output_file" 2>&1 || true
+      ;;
+    opencode)
+      run_with_timeout 120 opencode -p "$prompt" > "$output_file" 2>&1 || true
+      ;;
+    *)
+      echo "Unknown CLI: $cli" > "$output_file"
+      return 1
+      ;;
+  esac
+}
+
+check_skill_triggered() {
+  local output_file="$1"
+  local expected_pattern="$2"
+
+  if [ ! -f "$output_file" ] || [ ! -s "$output_file" ]; then
+    echo "no_output"
+    return
+  fi
+
+  local content
+  content=$(cat "$output_file")
+
+  local grep_pattern="${expected_pattern//;/|}"
+  if echo "$content" | grep -qiE "$grep_pattern"; then
+    echo "triggered"
+    return
+  fi
+
+  if echo "$content" | grep -qiE "using.*skill|invoking.*skill|Skill\(skill:|I'm using the"; then
+    echo "skill_invoked_different"
+    return
+  fi
+
+  if echo "$content" | grep -qi "max turns"; then
+    echo "max_turns_hit"
+    return
+  fi
+
+  if [ ${#content} -gt 50 ]; then
+    echo "responded_no_skill"
+    return
+  fi
+
+  echo "no_response"
+}
+
+run_test() {
+  local cli="$1"
+  local prompt="$2"
+  local expected_pattern="$3"
+  local description="$4"
+  local test_id="$5"
+
+  local output_file="$RESULTS_DIR/${cli}_${test_id}_${TIMESTAMP}.txt"
+
+  printf "  [%d] %-45s " "$test_id" "$description"
+
+  run_prompt "$cli" "$prompt" "$output_file"
+
+  local result
+  result=$(check_skill_triggered "$output_file" "$expected_pattern")
+
+  case "$result" in
+    triggered)
+      printf "${GREEN}PASS${NC}\n"
+      return 0
+      ;;
+    skill_invoked_different)
+      printf "${YELLOW}PARTIAL${NC} — different skill invoked\n"
+      return 0
+      ;;
+    max_turns_hit)
+      printf "${YELLOW}PARTIAL${NC} — hit max turns (tried to use tools)\n"
+      return 0
+      ;;
+    responded_no_skill)
+      printf "${RED}FAIL${NC} — responded without skill\n"
+      head -c 100 "$output_file" 2>/dev/null | tr '\n' ' '
+      echo ""
+      return 1
+      ;;
+    no_response|no_output)
+      printf "${RED}FAIL${NC} — no output\n"
+      return 1
+      ;;
+  esac
+}

package/skills/using-aw-skills/hooks/hooks.json

@@ -0,0 +1,9 @@
+{
+  "hooks": [
+    {
+      "type": "SessionStart",
+      "script": "./session-start.sh",
+      "description": "Discovers all available AW skills and commands, loads the using-aw-skills routing skill, and injects context into the session."
+    }
+  ]
+}