@tacuchi/agent-workflow-cli 20.22.0 → 20.24.0

package/skills/w/modules/SPLIT-GATE.md

@@ -0,0 +1,42 @@
+# SPLIT-GATE — one deliverable, or several siblings
+
+Loaded when the prompt may hold more than one independent outcome (signal `split`).
+
+## Split gate (multi-spec)
+
+Right after the reconnaissance and **before writing anything**, assess whether the prompt bundles
+**several independent outcomes**. The unit is the **functional outcome**, not the technical
+boundary: distinct repos, a frontend/backend pair, several microservices, a migration plus the
+code it enables — all **secondary evidence**, never on their own a reason to divide.
+
+**Divide only when each part is a result that can be refined, accepted and planned on its own** —
+its own purpose, its own acceptance criteria, worth delivering even if the other part is dropped.
+The gate fires **only on clear signals** (>=2 of: independent deliverables/goals · explicit
+enumeration of distinct features · different requested moments or order · users or value that do
+not depend on each other). Borderline, or evidence too thin to tell → **one spec, no question**:
+the hypothesis goes to `## Assumptions` and the doubt to `## Open questions`.
+
+It applies only to a **raw user prompt** (direct invocation, or the `plan-new` mode-3 handoff); it
+**never fires** on the reuse entries — the quick escalation and the `persist` adoption arrive
+already scoped to one objective.
+
+- **The offer** — the command's **only** interaction: **one** structured-choice (<=2 content
+  questions + the `flow` control; `Cerrar` = abort, nothing is written yet). The question body
+  shows the proposed cut in the **user's language**: per part, a name + slug, a 1-line scope and
+  the suggested order. Labels: `Dividir en varias specs` (recommended when the signals hold) |
+  `Una sola spec`. A free-form answer adjusts the cut (merge/rename/drop parts); if one part
+  remains, proceed as a single spec.
+- **The second content question** is allowed **only** for a functional ambiguity with two
+  incompatible readings that would change the number of specs (or leave the requested outcome
+  unidentifiable). Anything smaller — confirming an observable technology, closing an
+  implementation detail, raising confidence from medium to high — is **not** asked: it goes to
+  `## Assumptions` or `## Open questions`.
+- **On acceptance** — still single-pass: the cut comes from the prompt plus the reconnaissance
+  already done, never from a second look. Per part, mint with `aw next-number docs/specs`
+  **immediately before each write**, then write that draft. Numbers come out consecutive, so every
+  sibling path is known after the first mint.
+- **Sibling contract**: each `## Origin` records the shared prompt + `split (part i/N)` + the
+  **siblings by path** + the suggested order; each `## Scope` Out points to the sibling that owns
+  the excluded part. Cross-reference by path, never by bare number.
+- **Report**: list the N files and suggest the next step per spec (`/w:spec-refine` on the first —
+  each sibling refines and plans at its own moment).

package/skills/w/modules/WORKSPACE-SCAFFOLD.md

@@ -0,0 +1,28 @@
+# WORKSPACE-SCAFFOLD — what init versions, ignores and prunes
+
+Loaded when the folder already has a workspace, or the user asks what `workspace-init` writes,
+ignores or removes on a re-run (signal `scaffold`).
+
+## Versioning policy (CLI-owned `.gitignore`)
+
+Init writes and owns the full set.
+
+- **Ignored** — `.workflow/sessions/` (machine-local live log), `.workflow/.lock`,
+  `.workflow/processes.json`, `.workflow/launch/`, `docs/logs/` and, when there are external
+  sources, `.claude/settings.local.json*` / `.codex/config.toml*` (the patterns cover the
+  `.bak.<epoch>` backups).
+- **Versioned** — `.workflow/skills.toml`, `docs/**` (the deliverables) and
+  `.workflow/HISTORY.md`, the durable record: `aw session-close` upserts each closed session's
+  row there.
+
+## Re-run: reconcile + prune
+
+A re-run adds no duplicate entries and overwrites no manual configuration. It prunes the legacy
+upfront scaffold:
+
+- `.gitkeep`-only taxonomy folders and stray `.gitkeep` files;
+- an empty `docs/logs/`;
+- a released `.workflow/.lock` leftover.
+
+The `.gitignore` is completed to the current set — entries merge under the existing header, never
+duplicated.

package/skills/w/roles/git/ROLE.md

@@ -97,14 +97,13 @@ Outside an active session: relax to "1 line + no co-author"; the `session<NNN>`
 
 Autonomous `git merge` is forbidden (above), **but** resolving an **in-progress** merge (MERGE_HEAD), or one invoked by the user via `/w:fix-git`, **is** sanctioned work. **Workspace-agnostic**: it operates on any repo (no `.workflow/`, flows or sessions required).
 
-1. **Detect + identify** with `aw merge-state [<path>|--source <alias>|--all]` (read-only): `is_merging`, `current_branch` (**destination / ours**), `merge_origin` (**origin / theirs**), `conflicted_files`. If `merge_origin` comes empty, check `.git/MERGE_MSG` or `git log --oneline -1 MERGE_HEAD`.
-2. **Analyze each conflict's intent** **before** resolving — never pick a side blindly:
-   - The three versions: `git show :1:<file>` (base) · `:2:<file>` (ours/destination) · `:3:<file>` (theirs/origin).
-   - Each side's why: `git log --merge -p -- <file>`; the hunk's history on each branch.
-   - The code around the marker (coherence with the rest of the file).
-3. **Resolve** by editing the file (remove `<<<<<<<` / `=======` / `>>>>>>>`): pick **ours**, **theirs**, **combine** both intents, or **rewrite** to satisfy both. `git add <file>` what is resolved.
-4. **Ask** (*structured-choice*) when the intent is **ambiguous** or both sides are **incoherent** with each other (not combinable without losing something): one content question per doubtful file/hunk (≤3 + `flow` control), options "Ours (`<destination>`)" / "Theirs (`<origin>`)" / "Combine" / "Edit manually". **Never invent** a resolution under real doubt.
-5. **Proposed commit**: completing the merge is a `git commit` (the merge commit) → **propose-then-execute** like any commit (canonical format above; outside a session → 1 line without the `session<NNN>` tag; never `--no-verify`/`--amend`/`push`). The `git-commit-advisor` hook gates it.
+**The mechanics live in the CLI** (`aw fix-git prepare | apply | commit`); what follows is the reasoning it expects from you. Never edit a conflicted file, `git add` or `git commit` by hand here — see [`../../commands/fix-git.md`](../../commands/fix-git.md) for the exact invocations.
+
+1. **Detect + identify**: `aw fix-git prepare` (read-only) returns the merge direction (**theirs → ours**), the conflicted paths and, per path, its three index stages with their blob hashes. `aw merge-state` remains the lighter inspector when you only need the state.
+2. **Analyze each conflict's intent** **before** resolving — never pick a side blindly. The request already carries the three versions: `base` (common ancestor), `ours` (destination) and `theirs` (origin). Add `git log --merge -p -- <file>` when the *why* of a hunk is not evident, and read the surrounding code for coherence.
+3. **Resolve** by composing the complete resolved file: pick **ours**, **theirs**, **combine** both intents, or **rewrite** to satisfy both — with no `<<<<<<<` / `=======` / `>>>>>>>` left. The CLI writes and stages it; a leftover marker is rejected, and so is a path that is no longer in conflict.
+4. **Ask** (*structured-choice*) when the intent is **ambiguous** or both sides are **incoherent** with each other (not combinable without losing something): answer `state: "ambiguous"` so nothing is written, then ask one content question per doubtful file/hunk (≤3 + `flow` control), options "Ours (`<destination>`)" / "Theirs (`<origin>`)" / "Combine" / "Edit manually". **Never invent** a resolution under real doubt. A **binary** conflict is never resolved automatically: propose `git checkout --ours|--theirs`.
+5. **Proposed commit**: completing the merge is a `git commit` (the merge commit) → **propose-then-execute** like any commit (canonical format above; outside a session → 1 line without the `session<NNN>` tag; never `--no-verify`/`--amend`/`push`). It is a **separate, confirmed** invocation — `aw fix-git commit --message "<msg>" --confirm` — which refuses while any file stays unmerged. The `git-commit-advisor` hook gates it.
 6. **Escape hatch**: if the merge must not complete, `git merge --abort` **after user confirmation** (*structured-choice*) — leaves the repo as before the merge.
 
 > **Resume via git**: the merge state in `.git` (MERGE_HEAD + index) **is** the checkpoint; re-running `/w:fix-git` resumes from the remaining conflicts. No session, no artifact.

package/skills/w/roles/ui-spec/ROLE.md

@@ -28,7 +28,7 @@ Given a UI requirement, author a **structured Markdown description** of the scre
 Two levels, same capability:
 
 - **`spec-refine-loop`** (see `../../loops/spec-refine-loop/LOOP.md`) — resolving the **UI unspecified** gap (when the requirement involves UI): authors the spec's `## UI spec` section (the UI's *what*, coarse-grain screens).
-- **`plan-new-loop` · `plan-refine-loop`** (see `../../loops/plan-new-loop/LOOP.md` § *Delta 4*) — resolving the **UI without design SPEC** gap (when the **plan includes UI**): authors per-screen **design SPECs** (`NNN-SPEC-<SLUG>.md`) as **PLAN session artifacts** (see `../../artifacts/artifacts-design/SPEC.md`); they derive from `## UI spec` when it exists.
+- **`plan-new-loop` · `plan-refine-loop`** (see `../../modules/PLAN-DESIGN-SPECS.md`, the plan loops' `ui` module) — resolving the **UI without design SPEC** gap (when the **plan includes UI**): authors per-screen **design SPECs** (`NNN-SPEC-<SLUG>.md`) as **PLAN session artifacts** (see `../../artifacts/artifacts-design/SPEC.md`); they derive from `## UI spec` when it exists.
 
 In both, the composing loop contributes: