aw-ecc 1.4.21

package/skills/aw-test/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: aw-test
+description: Produce fresh QA evidence for feature, bugfix, frontend runtime, and release scopes using repo and org quality gates.
+trigger: User requests QA, validation, regression proof, runtime proof, or a legacy verify request resolves to the testing stage.
+---
+
+# AW Test
+
+## Overview
+
+`aw-test` owns QA proof.
+It turns implementation into current, scoped evidence that review and deploy can trust, and it should continue until the requested QA scope is actually covered.
+
+## When to Use
+
+- the request is to test a feature or bugfix
+- the work needs fresh validation after build
+- frontend behavior needs runtime proof
+- release preparation needs broader QA evidence
+- a legacy `/aw:verify` request is primarily about testing
+
+Do not use for findings-oriented review or launch closeout.
+
+## Workflow
+
+1. Select the smallest correct QA scope.
+   Use `../../references/test-scope-and-evidence.md`.
+   Distinguish feature QA, bugfix regression proof, UI runtime proof, and release QA.
+2. Resolve org standards.
+   Load the resolved GHL baseline profile.
+   Pull in the required local validation, E2E, external validation, sandbox, and quality-gate expectations.
+3. Run the right checks.
+   Use `../../references/testing-patterns.md` for test structure.
+   For frontend work, load `../../references/frontend-quality-checklist.md`.
+   For accessibility-sensitive UI, load `../../references/accessibility-checklist.md`.
+   For substantial UI validation, load `frontend-ui-engineering`.
+   For live browser, DOM, console, network, or runtime-proof work, load `browser-testing-with-devtools`.
+   For performance-sensitive paths, load `performance-optimization` and `../../references/performance-checklist.md`.
+4. Continue through the requested QA scope.
+   Do not stop after the first passing check if the requested feature, bugfix, UI-runtime, or release scope still has missing evidence.
+   Only stop early when the remaining work clearly belongs to another stage or a blocker prevents additional testing.
+5. Record evidence, not vibes.
+   Name which commands ran, what passed, what failed, what was unavailable, and what still remains unproven.
+6. Decide the handoff.
+   Route to `aw-review` when findings, governance, or readiness decisions remain.
+   Route to `aw-build` when a failure needs repair.
+   If the stage is blocked, name the blocker and the smallest safe next action explicitly.
+7. Persist the result.
+   Write `verification.md` and update `state.json`.
+
+## Completion Contract
+
+Testing is complete only when one of these is true:
+
+- the requested QA scope has fresh enough evidence for the next stage
+- a failure sends the work back to `aw-build`
+- a blocker prevents additional proof and that blocker is explicit
+
+Every testing handoff must make these things obvious:
+
+- which scope was tested
+- which checks ran
+- which evidence passed or failed
+- which gaps are still unavailable or unresolved
+- which exact next command should run next
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "Review can cover testing later." | Review is stronger when QA evidence is already concrete. |
+| "The unit tests are enough for this frontend change." | UI work may also need responsive, accessibility, and runtime proof. |
+| "The check doesn't exist, so I can treat it as passed." | Unavailable is not the same as passed. Record the gap explicitly. |
+
+## Red Flags
+
+- stale evidence after code changed
+- no regression proof for a bugfix
+- frontend changes have no runtime or responsive evidence
+- release QA is described vaguely instead of by concrete checks
+
+## State File
+
+`state.json` should record at least:
+
+- `feature_slug`
+- `stage: "test"`
+- `mode`
+- `status`
+- written artifacts
+- commands run
+- evidence artifacts
+- failures
+- unavailable checks
+- blockers
+- recommended next commands
+
+## Verification
+
+Before leaving test, confirm:
+
+- [ ] the QA scope is explicit and proportional
+- [ ] org-standard baseline checks were applied where available
+- [ ] unavailable checks are marked unavailable, not silently passed
+- [ ] fresh evidence is written to `verification.md`
+- [ ] `state.json` is updated with checks, failures, and next action
+
+## Final Output Shape
+
+Always end with:
+
+- `Mode`
+- `Scope`
+- `Checks Run`
+- `Evidence`
+- `Failures`
+- `Unavailable`
+- `Next`

package/skills/aw-verify/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: aw-verify
+description: Compatibility skill for the older verify stage. Resolve the request into aw-test, aw-review, or the smallest correct combined verification flow.
+trigger: Internal compatibility only. Invoked when older docs, habits, or commands still reference aw-verify.
+---
+
+# AW Verify
+
+## Overview
+
+`aw-verify` is a compatibility layer.
+The canonical public verification model is now:
+
+- `aw-test` for QA evidence
+- `aw-review` for findings, governance, and readiness
+
+## When to Use
+
+- a legacy `/aw:verify` request arrives
+- an older doc still frames testing and review as one overloaded stage
+
+## Workflow
+
+1. Identify the real need.
+   If the request is mostly QA, route to `aw-test`.
+   If it is mostly findings, governance, or readiness, route to `aw-review`.
+   If both are clearly needed, use `aw-test -> aw-review`.
+2. Preserve the compatibility artifact contract.
+   Keep writing `verification.md` and `state.json`.
+3. Preserve stage continuation as well as stage boundaries.
+   Do not stop after partial evidence if the selected test or review scope still remains.
+4. Do not preserve old ambiguity.
+   Prefer the narrowest modern stage once the intent is clear.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "Verify can keep meaning everything forever." | Overloaded stages make routing and ownership unclear. |
+
+## Red Flags
+
+- verification requests are not decomposed into test or review intent
+- old verify language is used to hide missing evidence or findings
+
+## Verification
+
+- [ ] the request resolved to `aw-test`, `aw-review`, or both
+- [ ] the selected test or review scope was completed or blocked explicitly
+- [ ] compatibility did not create a second verification workflow
+- [ ] `verification.md` and `state.json` stayed consistent with the resolved canonical flow

package/skills/aw-yolo/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: aw-yolo
+description: Explicit internal orchestration skill for one-run end-to-end automation across plan, build, test, review, deploy, and ship.
+trigger: Internal only. Use when the user clearly asks for one-run end-to-end automation instead of stage-by-stage progress.
+---
+
+# AW YOLO
+
+## Overview
+
+`aw-yolo` is the explicit full-flow orchestration skill.
+It exists so `ship` can stay a real shipping stage instead of an overloaded composite label.
+Use it to orchestrate the smallest correct remaining multi-stage path from the current state to a safe release outcome.
+
+## When to Use
+
+- the user explicitly asks to handle the full flow in one run
+- the request spans multiple AW stages and the user wants automation, not manual stage boundaries
+- the starting point is already partway through the lifecycle, but the user still wants the rest handled end to end
+
+Do not use by default.
+If the user asked for one stage, stay in that stage.
+
+## Workflow
+
+1. Confirm the request really wants orchestration.
+   `aw-yolo` is only correct when the user wants the remaining workflow handled in one pass.
+   If they only asked to deploy, ship, review, or test, stay in that stage.
+2. Classify the current starting state.
+   Identify which stage artifacts already exist and which stages are still unsatisfied.
+   Use this table as the default operating model:
+
+   | Starting state | Smallest correct remaining flow |
+   |---|---|
+   | only an idea, PRD, or vague approved direction | `aw-plan -> aw-build -> aw-test -> aw-review -> aw-deploy -> aw-ship` |
+   | approved spec/tasks or otherwise build-ready inputs | `aw-build -> aw-test -> aw-review -> aw-deploy -> aw-ship` |
+   | implementation exists but fresh evidence is missing | `aw-test -> aw-review -> aw-deploy -> aw-ship` |
+   | verification is complete and the user wants release action plus closeout | `aw-deploy -> aw-ship` |
+   | deploy action is complete and only rollout closeout remains | `aw-ship` |
+
+   Do not reopen already satisfied stages unless the current stage fails and forces a backward step.
+3. Execute one stage at a time.
+   Run the first unsatisfied stage, write its required artifacts, then reassess the next smallest safe stage.
+   Typical full sequence:
+   - `aw-plan`
+   - `aw-build`
+   - `aw-test`
+   - `aw-review`
+   - `aw-deploy`
+   - `aw-ship`
+   Do not leave a stage early just because one slice, one check, or one note succeeded.
+   A stage only hands off when its own completion contract is met or it is blocked explicitly.
+4. Preserve stage artifacts.
+   Internal orchestration is not permission to skip `execution.md`, `verification.md`, `release.md`, or `state.json`.
+   A stage is not done until its required artifacts are written.
+5. Respect stage boundaries.
+   `aw-yolo` coordinates stages, but it does not collapse them together.
+   Build still cannot self-certify.
+   Test still cannot quietly implement.
+   Deploy still cannot skip verify.
+   Ship still owns rollout closeout rather than implementation or release execution.
+6. Respect org standards at each stage.
+   Use the resolved GHL baseline profile, platform playbooks, and `.aw_rules`.
+7. Stop cleanly on blockers.
+   Stop immediately if a stage fails, evidence is missing, deploy configuration is unknown, or approval assumptions become unsafe.
+   Name the blocking stage and the smallest safe next action.
+   Name:
+   - the blocking stage
+   - what was completed
+   - the smallest safe next action
+8. End with a real terminal state.
+   The run is complete only when:
+   - the final remaining stage is finished and its artifact exists, or
+   - the workflow stops at a named blocker with a clear handoff
+
+## Final Output Shape
+
+Always end with:
+
+- `Current Stage`
+- `Completed Stages`
+- `Artifacts Written`
+- `Blockers`
+- `Recommended Next`
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "If the user said ship, I should always use yolo." | `ship` is now its own stage. `aw-yolo` is only for explicit whole-flow automation. |
+| "One-run automation means I can skip stage evidence." | Orchestration still owes every required artifact. |
+| "The request mentioned several stages, so I should always start from plan." | Start from the first unsatisfied stage, not from the beginning by habit. |
+| "If test or review fails, I should push through to deploy anyway." | `aw-yolo` must stop at the failing stage and hand back the blocker clearly. |
+
+## Red Flags
+
+- the request only named one stage but yolo was selected anyway
+- stage artifacts are skipped because the flow is internal
+- rollout safety is collapsed into deploy
+- already satisfied stages are reopened without a concrete reason
+- the run reaches deploy or ship even though test or review evidence failed
+- the final output does not say which stage the workflow ended on
+
+## Verification
+
+- [ ] the user explicitly wanted full-flow automation
+- [ ] the selected flow is the smallest correct end-to-end sequence
+- [ ] the chosen starting stage matches the current repo/artifact state
+- [ ] each stage still writes its required artifacts
+- [ ] failed stages stop the flow instead of being hand-waved away
+- [ ] blockers name the exact stage where the run stopped