aw-ecc 1.4.31 → 1.4.47

package/.cursor/skills/security-and-hardening/SKILL.md

@@ -1,70 +0,0 @@
----
-name: security-and-hardening
-description: Hardens code and system boundaries against misuse. Use when working with authentication, user input, secrets, external integrations, sensitive data, or any new trust boundary.
-origin: ECC
----
-
-# Security And Hardening
-
-## Overview
-
-Security is boundary work.
-This skill makes the agent classify trust boundaries, harden them deliberately, and prove the risky paths were reviewed rather than assumed safe.
-
-## When to Use
-
-- adding or changing authentication or authorization
-- handling user input, uploads, webhooks, or external API traffic
-- working with secrets, tokens, session state, or encryption
-- storing or transmitting sensitive or regulated data
-- introducing a new integration, endpoint, or background execution path
-
-**When NOT to use**
-
-- purely local changes with no user, network, secret, or boundary impact
-
-## Workflow
-
-1. Classify the boundaries first.
-   Identify:
-   - external input boundaries
-   - authz and identity boundaries
-   - data storage boundaries
-   - outbound trust boundaries
-2. Harden the entry points.
-   Validate input, apply authn/authz, enforce tenant or ownership scoping, and reject malformed or over-broad requests early.
-3. Protect secrets and configuration.
-   Use `../../references/security-checklist.md`.
-   Secrets must stay out of source, logs, screenshots, and error payloads.
-4. Reduce abuse and blast radius.
-   Add rate limits, safe defaults, least privilege, error handling, and logging that helps operators without leaking sensitive data.
-5. Review dependencies and operational posture.
-   Check whether packages, headers, storage settings, or integration modes introduce known risk.
-6. Prove the risky path was considered.
-   Name what was hardened, what remains risky, and what follow-up work is still required.
-
-## Common Rationalizations
-
-| Rationalization | Reality |
-|---|---|
-| "It's internal, so the security bar is lower." | Internal paths still become attack surfaces and privilege boundaries. |
-| "The framework handles that automatically." | Framework defaults help, but boundary ownership still belongs to the implementation. |
-| "We'll secure it after the happy path works." | Security debt compounds quickly once an interface is already in use. |
-| "Nobody will hit that edge case." | Attackers and accidental misuse both live in edge cases. |
-
-## Red Flags
-
-- trust boundaries are unclear or unnamed
-- secrets appear in code, logs, or test fixtures
-- auth exists without authorization checks
-- outbound integrations accept overly broad input or destination control
-
-## Verification
-
-After hardening, confirm:
-
-- [ ] the relevant trust boundaries are explicit
-- [ ] input, auth, and secret handling were reviewed deliberately
-- [ ] abusive or malformed requests fail safely
-- [ ] logs and errors avoid leaking sensitive data
-- [ ] remaining security risks or follow-ups are documented

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

@@ -1,290 +0,0 @@
----
-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/.cursor/skills/using-aw-skills/evals/skill-trigger-cases.tsv

@@ -1,25 +0,0 @@
-# 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/.cursor/skills/using-aw-skills/evals/test-skill-triggers.sh

@@ -1,171 +0,0 @@
-#!/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/.cursor/skills/using-aw-skills/hooks/hooks.json

@@ -1,9 +0,0 @@
-{
-  "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."
-    }
-  ]
-}

package/.cursor/skills/using-aw-skills/hooks/session-start.sh

@@ -1,67 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-LOCAL_ROOT=""
-SEARCH_ROOT="$SCRIPT_DIR"
-while [[ "$SEARCH_ROOT" != "/" ]]; do
-  if [[ -f "$SEARCH_ROOT/skills/using-aw-skills/SKILL.md" ]]; then
-    LOCAL_ROOT="$SEARCH_ROOT"
-    break
-  fi
-  SEARCH_ROOT="$(dirname "$SEARCH_ROOT")"
-done
-
-AW_REGISTRY_ROOT=""
-SEARCH_ROOT="$SCRIPT_DIR"
-while [[ "$SEARCH_ROOT" != "/" ]]; do
-  if [[ -d "$SEARCH_ROOT/.aw_registry" ]]; then
-    AW_REGISTRY_ROOT="$SEARCH_ROOT/.aw_registry"
-    break
-  fi
-  if [[ "$(basename "$SEARCH_ROOT")" == ".aw_registry" ]]; then
-    AW_REGISTRY_ROOT="$SEARCH_ROOT"
-    break
-  fi
-  SEARCH_ROOT="$(dirname "$SEARCH_ROOT")"
-done
-
-if [[ -z "$LOCAL_ROOT" && -z "$AW_REGISTRY_ROOT" ]]; then
-  echo '{"hookSpecificOutput": {"hookEventName": "SessionStart", "additionalContext": "WARNING: .aw_registry not found. AW skills unavailable."}}'
-  exit 0
-fi
-
-CONTEXT="# AW Session Context
-
-## First Response Rule
-Before any substantive response, select the smallest correct AW skill stack from the repo-local router.
-Honor an explicit AW command and its mapped stage skill first.
-Otherwise choose the needed process skill, primary stage skill, and matching route by intent, then load deeper domain skills.
-Do not start with generic implementation, review, or deploy advice before skill selection.
-
-## Primary Routes
-- /aw:plan -> ideas, specs, task breakdown, architecture direction
-- /aw:build -> approved implementation work
-- /aw:investigate -> bugs, alerts, or unclear runtime failures
-- /aw:test -> QA proof and regression evidence
-- /aw:review -> findings, risk review, and readiness
-- /aw:deploy -> rollout or release execution
-- /aw:ship -> release closeout and final handoff
-
-## Compatibility Routes
-- /aw:execute -> compatibility route; resolve to /aw:build
-- /aw:verify -> compatibility route; resolve to /aw:test or /aw:review
-
-## Router Source
-Use skills/using-aw-skills/SKILL.md as the repo-local router.
-Load domain, platform, and craft skills only after the smallest correct AW route is selected."
-
-# --- Output in Claude Code hookSpecificOutput format ---
-# Escape for JSON: newlines, quotes, backslashes
-JSON_CONTEXT=$(printf '%s' "$CONTEXT" | python3 -c '
-import sys, json
-content = sys.stdin.read()
-print(json.dumps(content))
-' 2>/dev/null || printf '%s' "$CONTEXT" | sed 's/\\/\\\\/g; s/"/\\"/g; s/\t/\\t/g' | awk '{printf "%s\\n", $0}')
-
-echo "{\"hookSpecificOutput\": {\"hookEventName\": \"SessionStart\", \"additionalContext\": ${JSON_CONTEXT}}}"