# Skills

Weyaw installs project-local skills for coding agents. Initialize the project,
then select the integration target:

```bash
aw init "Short project summary"
aw install --target agents
```

Use `--target claude-code` for Claude Code, `--target codex` for Codex, or
`--target all` for every supported target.

## Common skills

The generated bundle contains these fifteen user-facing skills:

- `$aw` — load lightweight project workflow context without starting a task.
- `$aw-init` — initialize or reconcile the project profile.
- `$aw-help` — suggest a project-aware next action.
- `$aw-blueprint` — update durable design language and standards. It follows explicit `## Components` links, edits the canonical root or child source, validates the graph, and never writes a flattened aggregate.
- `$aw-commit` — stage and commit one active task in source and workflow repositories after explicit confirmation; task worktrees rebase onto the current main checkout, rerun required verification, and integrate only by fast-forward.
- `$aw-config` — inspect, explain, or modify typed project configuration through Weyaw-owned config commands rather than editing `config.toml` directly.
- `$aw-index` — inspect index capability, freshness, and discovery surfaces.
- `$aw-roadmap` — maintain roadmap phases and items without creating tasks.
- `$aw-uiux` — provide UI/UX, visual, interaction, or motion-design guidance only when the user explicitly requests that judgment.
- `$aw-task <intention>` — create or locate one roadmap-linked task and run its lifecycle.
- `$aw-resume <task-id>` — continue the recorded next step.
- `$aw-status` — summarize task lifecycle and blockers.
- `$aw-health` — diagnose or repair workflow integrity; after explicit approval it routes an archived `worktree_pending_removal` finding through `aw task retire-worktree <task-id> --reason <reason> --confirm` rather than force-removing the checkout.
- `$aw-dream` — diagnose post-onboarding blueprint-versus-code drift through a normal task without assuming either side is authoritative or applying fixes itself.
- `$aw-goal <item ids>` — run a bounded ordered batch, committing after each archived task.

## Static and dynamic guidance

Installed `SKILL.md` files define stable orchestration rules. At activation,
skills load dynamic guidance from the current project, including core context
from `.aw/blueprint/aw.md`. One centralized guidance block also provides the
absolute path to the version-matched product docs shipped with the installed
package; individual skill files do not repeat that path. Dynamic guidance can narrow evidence, render matching official Agent triggers, or describe runtime boundaries; it does not replace direct source reads. `complex.reasoning` may activate in any Weyaw context, while project-writing AGT-X is limited to official Brainstorm, Analyze, and Execute triggers with frozen-worktree, common-sandbox, and explicit write-root readiness evidence. `$aw-task` and `$aw-resume` may also render `control.aw-cli-chain` to open one temporary broad `aw **` capability under a device-local runtime owner; the harness cannot edit workflow files directly and the Host reconciles compact mutation receipts, rereading only when the receipt cannot safely determine the next route.

Task-scoped step guidance is intentionally a delta after the router has loaded stable protocol and core context: it keeps task-sensitive index, Agent readiness, capability, recovery, fallback, and config facts without expanding the same core, product-doc, host-boundary, or overlapping wildcard definition text again. It also returns a bounded deterministic `command_specs[]` list derived from the compiled Clap tree. Skills trust each listed `usage`, never query broad or parent help, and permit at most one exact-leaf help fallback when a needed spec is absent or a listed invocation is rejected.

At task creation or resume, the Host inspects its own Agent environment for a real `name=version` and supplies it through `aw create --agent-runtime` or `aw task config <task-id> --agent-runtime`. Skills must stop when that evidence is unavailable; they do not infer it from project config, copy a prior task value, or emit `unknown`/`unrecorded`. Every changed task JSON root records that semantic-author runtime and the executing AW runtime, while JSONL and action-specific evidence retain their record-level provenance.

Use the packaged `aw` command in installed projects. Within the Weyaw source
checkout, use `node bin/aw-debug.js` so guidance reflects the current code.

## Host-owned step todos

The `$aw-task` Host seeds and updates durable ordered todo DAGs for `brainstorm`, `analyze`, `plan`, `verify`, and `review` through `aw step todo add`, `update`, and `remove`. Each stable node has a bounded `id`, short title, required `abstract` of at most 256 display columns, explicit `depends_on[]`, and `todo|doing|done` status. Repeat `--depends-on <id>` to set edges or use `--clear-depends-on` to remove them; missing references, self-edges, duplicate edges, and cycles are rejected. Multiple nodes may be `doing` when every predecessor is Host-accepted `done`, and every retained node must be done before close-out. Compact receipts return normalized rows, `doing_ids`, `ready_ids`, and progress. The complete-list `replace --input '<json>'` or `--input-file <path|->` operation is reserved for repair.

Blueprint roots may use ordered rows shaped like `- [Concepts](concepts.md)` under `## Components`. Only those links compose; ordinary links remain references, directory contents are never auto-included, and `aw docs --compose <root-id>` is the explicit read surface.

Normal structured task artifacts use semantic `aw artifact` subcommands, so the Host sends typed scalar or repeatable argv instead of staging whole JSON payloads. Registered Markdown uses section or exact text mutations. Exactly-one opaque payloads use mutually exclusive `--input` or `--input-file <path|->`, where dash reads stdin; `aw write` remains a complete-document creation and repair boundary. Structural replacement selectors use `--match`. Typed semantic fields remain direct argv.

`execute` uses `plan.json` plus `execution.json` instead of task-status todos. Plan-backed nodes inherit ids, titles, abstracts, and dependencies from Plan, while execution rows own status and evidence; their execution `depends_on[]` remains empty. Newly discovered execution-only rows provide their own title, abstract, explicit dependencies over the merged graph, and deviation evidence before work starts. The approved Plan is not silently rewritten, and no second progress or scheduler artifact is created.

## Agent ownership and authority

Task Agent runs keep durable task-linked session evidence. Generic non-task reasoning and control operations use device-local runtime-operation owners instead of creating placeholder tasks. Project config selects worker order and narrows bounded turns, fan-out, and content budgets per official Agent Action; Trigger config owns permitted activation disablement. Additive `local.*` Actions and Triggers may extend one official binding but cannot override official ids or widen context, executor, writable, root, resource, or project-access authority.

Agent Action prompt contracts own role, objective, scope, behavior, ordered execution, retry behavior, and evidence reporting. Project-content authority uses the same ordered `AccessMode = none < read < write` as Plan. Each Action declares a resource-bounded `project_access_ceiling`, and each resolved invocation carries an effective `project_access` grant; Core rejects any grant whose mode or roots exceed the ceiling. The Host compares Plan required access, invocation grant, and Action ceiling before launch and requests the minimum grant. Existing generic `writable` and `write_roots` still bound filesystem mutation such as workflow-only control Actions, so project access is not inferred from sandbox writability. Public `read-only|read-write` and `AGT-R|AGT-X` values remain boundary mappings: project `none|read` is AGT-R and project `write` is AGT-X, while a workflow-only artifact writer retains its existing AGT-X sandbox behavior. No AGT-N exists.

Every parallel-safe official Action defaults to `fan_out=8`, including complex reasoning, while `control.aw-cli-chain` remains fixed at `1`; task-step configuration may use any positive `u32` value. Effective Action, group, project, and worker limits remain finite running-capacity gates. The Host derives each complete stable-order logical Wave from canonical task artifacts without splitting it by node count, `fan_out`, capacity, available slots, or queue state. When at least two assignments are Agent-safe, the Host publishes all of them in one group and excess assignments remain queued; exactly one stays Host-owned. The Host may continue dependency-, write-scope-, and resource-disjoint work while Agents run. Agent completion and joins are candidate evidence only: the Host validates the original node before marking it done and unlocking successors. Core hard gates own official Trigger/context matching, Trigger-to-Action resolution, task or operation identity, access and writable agreement, frozen worktree selection, canonical root containment, readiness, and resource conflicts. The Host remains the sole owner of workflow gates, artifact semantics, acceptance, lifecycle, and commits.

See [Concepts](concepts.md) and [Artifacts](artifacts.md).
