refactor(skills): use .agents/ instead of .agent/ for phased execution

Standardize on the .agents/ directory across all phased-execution
skills (phase state, reports, sessions, validate.sh, PLAN.md, and
per-story/feature/workflow trees). Legacy dot-less agent/ fallbacks
in migration scripts are untouched.

phase-authoring/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: phase-authoring
-description: The required entry point for ANY new work on a .agent/phases/ project. Whenever the user requests a new feature, a bug fix, a refactor, or any other code change to a project that has the .agent/phases/ structure, call this skill FIRST to capture the work as a phase directory with task files — never implement the change directly in code. Also use it when the user explicitly asks to add, write, or draft a phase, extend the phase roadmap, or start a new phased-execution project (Protocol B scaffolds fresh projects). Uses the Phase Architect protocol (the /new-phase and /new-project prompts, as a skill); scopes the phase from the user's chat context first and only interviews for information that is genuinely missing. This skill writes phase directories (a 00_phase.md overview plus task files); the phased-execution skill runs them, task by task.
+description: The required entry point for ANY new work on a .agents/phases/ project. Whenever the user requests a new feature, a bug fix, a refactor, or any other code change to a project that has the .agents/phases/ structure, call this skill FIRST to capture the work as a phase directory with task files — never implement the change directly in code. Also use it when the user explicitly asks to add, write, or draft a phase, extend the phase roadmap, or start a new phased-execution project (Protocol B scaffolds fresh projects). Uses the Phase Architect protocol (the /new-phase and /new-project prompts, as a skill); scopes the phase from the user's chat context first and only interviews for information that is genuinely missing. This skill writes phase directories (a 00_phase.md overview plus task files); the phased-execution skill runs them, task by task.
 ---
 
 # Phase Authoring
@@ -14,10 +14,10 @@ master plan.
 
 Phase state lives in files, not chat:
 
-- `.agent/PLAN.md` — master plan; **LOCKED DECISIONS** are binding
-- `.agent/phases/todo/NN_name/` — a pending phase: `00_phase.md` overview + `NN_task.md` task files (task sort order = execution order)
-- `.agent/phases/todo/NN_name.md` — legacy single-file phase (still valid; migrate or split it)
-- `.agent/phases/complete/` — finished phases, mirroring the todo/ layout (read-only history)
+- `.agents/PLAN.md` — master plan; **LOCKED DECISIONS** are binding
+- `.agents/phases/todo/NN_name/` — a pending phase: `00_phase.md` overview + `NN_task.md` task files (task sort order = execution order)
+- `.agents/phases/todo/NN_name.md` — legacy single-file phase (still valid; migrate or split it)
+- `.agents/phases/complete/` — finished phases, mirroring the todo/ layout (read-only history)
 
 Legacy flat phases (`todo/NN_name.md`) are still executed as a single unit.
 `bash scripts/migrate-phases-to-tasks.sh [project-root]` (resolve `scripts/`
@@ -29,8 +29,8 @@ into real task files is this skill's job.
 
 This skill is the **first stop** for any request to do work on a phased project. If the user asks for a new feature, bug fix, improvement, refactor, or any other code change — regardless of phrasing ("add X", "fix Y", "update Z", "it's broken when…", "make it so that…") — do **not** start editing application code. Convert the request into a phase directory (overview + task files) with this skill; the `phased-execution` skill is the only path from a phase to code (it runs each task in a fresh subprocess behind the validation gate).
 
-- **Phased project** (`.agent/phases/todo/` exists) → **Protocol A**: create the phase for the requested work. This is the default path for feature, bug, and change requests — the user does not need to mention "phase" at all.
-- **Fresh project** (no `.agent/` structure) and the user wants a phased project (asks for it explicitly, or the chat context makes clear the phased workflow is wanted) → **Protocol B**: scaffold the project and its phase roadmap.
+- **Phased project** (`.agents/phases/todo/` exists) → **Protocol A**: create the phase for the requested work. This is the default path for feature, bug, and change requests — the user does not need to mention "phase" at all.
+- **Fresh project** (no `.agents/` structure) and the user wants a phased project (asks for it explicitly, or the chat context makes clear the phased workflow is wanted) → **Protocol B**: scaffold the project and its phase roadmap.
 - **Not phased and no sign of phased intent** → this skill does not apply; do the work normally, and if the work is substantial, suggest the `convert-to-phased` skill.
 - Only if the user **explicitly** asks to bypass the phase workflow should code be edited directly — in that case note that the change skips the phase's test and validation gates.
 
@@ -59,10 +59,10 @@ Rules:
 
 Before writing anything, you must:
 
-1. Read `.agent/PLAN.md` — project goals, architecture, and **LOCKED DECISIONS**.
+1. Read `.agents/PLAN.md` — project goals, architecture, and **LOCKED DECISIONS**.
 2. Read `AGENTS.md` if present — project rules may add requirements (e.g. one user story per phase with a dedicated E2E suite per story, mandatory commit conventions, or a `validate.sh` gate).
 3. Run `bash scripts/phase-status.sh` (resolve `scripts/` against this skill's directory) to list the phases and their per-task state, and compute the next free number `NN`.
-4. Read the `00_phase.md` files in `.agent/phases/complete/*/` to understand what has already been built, and review the remaining `todo/` phase directories to avoid overlap. Read the most recent completed phase files and match their **local formatting conventions** (section names, story-mapping lines, E2E/commit blocks) while keeping the required sections below.
+4. Read the `00_phase.md` files in `.agents/phases/complete/*/` to understand what has already been built, and review the remaining `todo/` phase directories to avoid overlap. Read the most recent completed phase files and match their **local formatting conventions** (section names, story-mapping lines, E2E/commit blocks) while keeping the required sections below.
 
 ### Phase 2: Scope the New Phase (context first, interview only if needed)
 
@@ -86,7 +86,7 @@ Derive from the chat context (see "Scoping from chat context" above):
 
 ### Phase 3: Design & Create the Phase
 
-Create **exactly one** new phase directory at `.agent/phases/todo/NN_name/`,
+Create **exactly one** new phase directory at `.agents/phases/todo/NN_name/`,
 where `NN` comes from Phase 1 (next free number, counting `todo/` and
 `complete/` together) and `name` is a short `snake_case` description. It
 contains the phase overview and the phase's task files:
@@ -112,7 +112,7 @@ earlier ones within the phase.
 **Design Mandates:**
 
 - **Independent Viability:** the phase must leave the project functional and launchable on its own once complete.
-- **Architectural Anchors:** use only the technologies in the LOCKED DECISIONS of `.agent/PLAN.md`. Never introduce new technology without explicit permission.
+- **Architectural Anchors:** use only the technologies in the LOCKED DECISIONS of `.agents/PLAN.md`. Never introduce new technology without explicit permission.
 - **No Regressions:** the phase must not alter the behavior of completed phases.
 - **Executable in isolation:** an agent that sees only the repository, the phase overview, the completed task files, and one task file — no chat history, no follow-ups — must be able to finish that task. No hidden assumptions.
 
@@ -153,7 +153,7 @@ Derive from the chat context (see "Scoping from chat context" above):
 - Use `uv` for all package management.
 - **Mandatory Dependencies:** `python-dotenv` (production); `debugpy`, `ruff`, `pyright`, `pytest`, `pytest-cov` (dev).
 - **Web Projects:** add `fastapi`, `alembic`, `pydantic`; prefer `httpx`.
-- **Scaffold Files:** a comprehensive `.gitignore` (must include `.agent/phase-sessions/` and `.agent/pipeline.log` — but **never** `.agent/` itself: the planning tree is tracked and committed), a multi-stage `Containerfile` (assuming `podman`/`docker`), and a `README.md` with `uv` and configuration instructions.
+- **Scaffold Files:** a comprehensive `.gitignore` (must include `.agents/phase-sessions/` and `.agents/pipeline.log` — but **never** `.agents/` itself: the planning tree is tracked and committed), a multi-stage `Containerfile` (assuming `podman`/`docker`), and a `README.md` with `uv` and configuration instructions.
 
 ### Phase 3: Strategic Architectural Design
 
@@ -174,12 +174,12 @@ phases may use. The design must cover:
 
 Use file tools to create (not just describe):
 
-- **`.agent/PLAN.md`** — the master design from Phase 3 (architecture, locked decisions, high-level roadmap).
-- **`AGENTS.md`** — initialized with: always read `.agent/PLAN.md` first; follow the phased protocol in `.agent/phases/`; never modify `.agent/PLAN.md` or anything in `.agent/phases/complete/`; ask the user before editing files in `.agent/phases/todo/`; strictly adhere to the **LOCKED DECISIONS**.
-- **`.agent/phases/todo/`** — sequential phase directories (`01_…/`, `02_…/`, …), each with a `00_phase.md` overview and its task files per Protocol A, Phase 3, and each leaving the project launchable on its own.
-- **`.agent/phases/complete/`** — create the directory, leave it empty.
+- **`.agents/PLAN.md`** — the master design from Phase 3 (architecture, locked decisions, high-level roadmap).
+- **`AGENTS.md`** — initialized with: always read `.agents/PLAN.md` first; follow the phased protocol in `.agents/phases/`; never modify `.agents/PLAN.md` or anything in `.agents/phases/complete/`; ask the user before editing files in `.agents/phases/todo/`; strictly adhere to the **LOCKED DECISIONS**.
+- **`.agents/phases/todo/`** — sequential phase directories (`01_…/`, `02_…/`, …), each with a `00_phase.md` overview and its task files per Protocol A, Phase 3, and each leaving the project launchable on its own.
+- **`.agents/phases/complete/`** — create the directory, leave it empty.
 
-Do **not** create `.agent/validate.sh` — the `phased-execution` skill
+Do **not** create `.agents/validate.sh` — the `phased-execution` skill
 installs it from its template on first run and it must be adapted to the
 project's real checks.
 
@@ -189,7 +189,7 @@ execution with `phased-execution` (`auto-phase.sh`).
 ## Strict Operational Rules
 
 - **Work requests become phase directories.** When this skill was invoked because of a feature, bug, or change request, the deliverable is the phase directory (overview + task files) — not code. Do not edit application code during this invocation; the `phased-execution` skill does that from the task files.
-- **Never** modify `.agent/PLAN.md`, `AGENTS.md`, or any file in `.agent/phases/complete/`.
-- **Never** modify existing phase directories or their files in `.agent/phases/todo/`; if one needs updating, ask the user for permission first.
+- **Never** modify `.agents/PLAN.md`, `AGENTS.md`, or any file in `.agents/phases/complete/`.
+- **Never** modify existing phase directories or their files in `.agents/phases/todo/`; if one needs updating, ask the user for permission first.
 - Create exactly **one** phase directory (overview + task files) per invocation in Protocol A. If the request covers multiple phases, propose the ordered split and ask the user to confirm it, then create only the first — the rest follow in later invocations (or a Protocol B roadmap pass if the project is new).
 - Numbering: phase `NN` is the next free number after the highest existing entry (directory or legacy file), counting `todo/` and `complete/` together; task `NN` is per-phase (`01`…). Never reuse or collide a number.