aw-setup

Solid

One-time (but safely re-runnable) setup flow that scaffolds a project's aw-tester aw-target: detects auth strategy, captures storage state, writes .claude/aw-targets/local.yml, and validates with a smoke spec. Re-runs detect the existing aw-target and only re-prompt for what broke or changed. Triggers on "/aw-setup", "setup aw-tester", "scaffold aw-target".

AI & Automation 13 stars 2 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 86/100

Stars 20%
38
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# aw-setup — Aw-Target Scaffolding for aw-tester Interactive, idempotent setup flow that scaffolds the `.claude/aw-targets/` config that `aw-tester` needs to run specs. Run it **once** before the first autonomous PR that touches UI. Re-run it when auth drifts, fixtures change, or base URL moves. > **This is the prerequisite for spec-driven UI verification in the > autonomous-workflow.** Without an aw-target file, `aw-tester` cannot run and > the executor's Phase 4 spec verification step skips cleanly. --- ## When to run - **First time:** before running any autonomous feature that touches UI. - **Re-run:** when `aw-tester` reports `auth-refresh-failed`, when the base URL changes, or when seed fixtures are restructured. - **Never auto-triggered by the planner.** The planner halts and tells the user to run `/aw-setup`. The user runs it explicitly. --- ## Idempotency contract **First run:** full guided scaffolding (Phases A–E). **Re-run:** detect `.claude/aw-targets/local.yml` exists, validate each field: - Auth storage state: does the file exist? Is it fresh (< N days old)? - Fixtures: does the seed command resolve? Do references point to env vars that exist? - Smoke spec: run it. If green, done — no prompts needed. - Only prompt for what broke or is missing. - Show a unified diff before overwriting any field in the aw-target file. - Never silently overwrite the auth storage-state file (`.auth/*.json`, or the repo's own convention such as `.browser/auth-state*.jso...

Details

Author
mthines
Repository
mthines/agent-skills
Created
4 months ago
Last Updated
yesterday
Language
JavaScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

aw

Ships autonomous, end-to-end coding work — implement a feature or fix, all the way to a tested draft PR — from a single opt-in entry point. Detects the task tier (Micro / Lite / Full) and routes: Micro/Lite run single-pass in this context; Full hands off to the aw-planner → aw-executor agents. Use when the user asks to do a task "autonomously", "independently", "in isolation", "in a worktree", "end-to-end", "all the way to a PR", to "ship this", "land this", "take care of this", or "handle this without me" — or invokes `/aw` directly. Opt-in, not a wrapper on casual edits; the routing rule's exclusion list governs when to hold back. Triggers on "implement autonomously", "end-to-end", "in a worktree", "ship this", "/aw".

13 Updated yesterday
mthines
AI & Automation Solid

autonomous-workflow

The phase-based machinery (0–7) behind the `aw` dispatcher — task intake through tested PR delivery in an isolated Git worktree, with optional companion skills for planning, quality gates, TDD, UX, code quality, docs, and CI verification. Companions skip silently if not installed. NOT the entry point and not auto-triggered: a natural-language request to do work autonomously, end-to-end, in isolation, or in a worktree belongs to the `aw` skill, which detects the task tier and routes. Reach for this skill only to read or run the phase machinery directly, bypassing tier detection — invoke with /autonomous-workflow.

13 Updated yesterday
mthines
Testing & QA Solid

aw-tester-chrome

Runs UI verification specs in-session through the claude-in-chrome extension — the Chrome sibling of the aw-tester agent. Reads the same specs.md and aw-target.yml, drives Chrome interactively (navigate → read → act → assert, seeing the page between steps), and emits the same compact verdict block. Runs in the current session against an already-logged-in Chrome, so it is faster than the Playwright sub-agent for local runs, but it needs the browser extension and does not work in remote / CI envs. Falls back to aw-tester when the extension is not connected. Triggers on "run the spec in chrome", "verify with the chrome driver", "aw-tester-chrome", or a "preview-spec run --driver chrome" dispatch.

13 Updated yesterday
mthines