yadflow 1.0.1 → 2.0.0

package/skills/{sdlc-pr-template → yad-pr-template}/templates/hub/github/pull_request_template.md

@@ -1,7 +1,7 @@
 <!-- SDLC HUB PR template — front-half artifact review (epic / architecture+contract / ui-design / stories). -->
-<!-- This PR is a REVIEW VEHICLE on the product hub, not a code merge. The file gate (sdlc-review-gate)
+<!-- This PR is a REVIEW VEHICLE on the product hub, not a code merge. The file gate (yad-review-gate)
      advances the step; do NOT rely on merging this PR to advance. Reviewers approve/comment here, then a
-     `sdlc-review-gate action: sync` pulls that into the file ledger. -->
+     `yad-review-gate action: sync` pulls that into the file ledger. -->
 
 ## Artifact under review
 - Epic: `EP-<slug>`
@@ -17,7 +17,7 @@
 - **Risk tags:** <none | contract | auth | payments>  <!-- contract/auth/payments => escalates to domain owners -->
 - **Contract surface:** <n/a | locked @ sha256:…>  <!-- architecture only; a re-lock invalidates prior approvals -->
 
-## Required approvals (sdlc-review-gate rule)
+## Required approvals (yad-review-gate rule)
 - Base: **owner + 1 reviewer**.
 - Escalated (risk tag set, or a stories PR): **plus one domain-owner per touched repo** — see the
   requested reviewers / `domain:<repo>` labels on this PR. Run `bash checks/hub-route.sh <this-description>`
@@ -27,7 +27,7 @@
 - **Approve** this PR to record an `owner` / `reviewer` / `domain-owner` approval in the file ledger
   (your platform login maps to your SDLC name + role via `.sdlc/hub.json`'s roster).
 - **Comment / request changes** to record review comments (synced into `reviews/<artifact>--<date>--comments.md`).
-- **Do NOT merge to advance** — `sdlc-review-gate action: sync` + `action: advance` move the step.
+- **Do NOT merge to advance** — `yad-review-gate action: sync` + `action: advance` move the step.
 
 ## Checklist
 - [ ] `owner` set in the artifact frontmatter (inherited from `epic.md`)

package/skills/{sdlc-pr-template → yad-pr-template}/templates/hub/gitlab/merge_request_templates/Default.md

@@ -1,7 +1,7 @@
 <!-- SDLC HUB MR template — front-half artifact review (epic / architecture+contract / ui-design / stories). -->
-<!-- This MR is a REVIEW VEHICLE on the product hub, not a code merge. The file gate (sdlc-review-gate)
+<!-- This MR is a REVIEW VEHICLE on the product hub, not a code merge. The file gate (yad-review-gate)
      advances the step; do NOT rely on merging this MR to advance. Reviewers approve/comment here, then a
-     `sdlc-review-gate action: sync` pulls that into the file ledger. -->
+     `yad-review-gate action: sync` pulls that into the file ledger. -->
 
 ## Artifact under review
 - Epic: `EP-<slug>`
@@ -17,7 +17,7 @@
 - **Risk tags:** <none | contract | auth | payments>  <!-- contract/auth/payments => escalates to domain owners -->
 - **Contract surface:** <n/a | locked @ sha256:…>  <!-- architecture only; a re-lock invalidates prior approvals -->
 
-## Required approvals (sdlc-review-gate rule)
+## Required approvals (yad-review-gate rule)
 - Base: **owner + 1 reviewer**.
 - Escalated (risk tag set, or a stories MR): **plus one domain-owner per touched repo** — see the
   reviewers / `domain:<repo>` labels on this MR. Run `bash checks/hub-route.sh <this-description>` to list them.
@@ -26,7 +26,7 @@
 - **Approve** this MR to record an `owner` / `reviewer` / `domain-owner` approval in the file ledger
   (your platform login maps to your SDLC name + role via `.sdlc/hub.json`'s roster).
 - **Comment** to record review comments (synced into `reviews/<artifact>--<date>--comments.md`).
-- **Do NOT merge to advance** — `sdlc-review-gate action: sync` + `action: advance` move the step.
+- **Do NOT merge to advance** — `yad-review-gate action: sync` + `action: advance` move the step.
 
 ## Checklist
 - [ ] `owner` set in the artifact frontmatter (inherited from `epic.md`)

package/skills/{sdlc-review-comments → yad-review-comments}/SKILL.md

@@ -1,13 +1,13 @@
 ---
-name: sdlc-review-comments
-description: 'Installs platform-matched PR/MR review-comment scaffolds into a repo so reviewers leave structured, attributable feedback that maps cleanly into the SDLC file ledger. Works for code repos and the product hub. GitHub has no repo-level multi-comment template, so the scaffold is a committed REVIEW_COMMENTS.md reviewers copy from (saved as Saved Replies on GitHub / comment templates on GitLab). Each canned comment carries an attributable `**<name> (<role>)**` header that matches the `## <name> (<role>)` headings sdlc-review-gate writes. Use when the user says "add the comment templates" or "set up review comments" for a repo.'
+name: yad-review-comments
+description: 'Installs platform-matched PR/MR review-comment scaffolds into a repo so reviewers leave structured, attributable feedback that maps cleanly into the SDLC file ledger. Works for code repos and the product hub. GitHub has no repo-level multi-comment template, so the scaffold is a committed REVIEW_COMMENTS.md reviewers copy from (saved as Saved Replies on GitHub / comment templates on GitLab). Each canned comment carries an attributable `**<name> (<role>)**` header that matches the `## <name> (<role>)` headings yad-review-gate writes. Use when the user says "add the comment templates" or "set up review comments" for a repo.'
 ---
 
 # SDLC — Review Comment Templates
 
 **Goal:** Give reviewers a consistent, **attributable** set of canned PR/MR comments so review feedback
 reads the same across repos and **maps cleanly into the file ledger** the gate keeps. The headers match
-the `## <name> (<role>)` shape `sdlc-review-gate` writes into `reviews/<artifact>--<date>--comments.md`
+the `## <name> (<role>)` shape `yad-review-gate` writes into `reviews/<artifact>--<date>--comments.md`
 and the per-commenter record in `comments.json`, so a synced or copy-pasted comment lands without
 reformatting.
 
@@ -55,9 +55,9 @@ Report what was committed. The scaffold is an aid to human review; it approves n
 - **Drop only the matching scaffold** for the detected platform.
 - **Attributable headers** — every canned comment keeps the `**<name> (<role>)**` form so the gate's
   ledger and the PR thread agree.
-- **Nothing auto-advances.** Comments feed the human review and (via the bridge) `sdlc-review-gate`.
+- **Nothing auto-advances.** Comments feed the human review and (via the bridge) `yad-review-gate`.
 
 ## Reference
 - Comment conventions + the full scaffold contents: `references/comment-conventions.md`.
-- The ledger headings these match: `../sdlc-review-gate/SKILL.md` (comment action) and `references/gating.md`.
-- The review bridge that syncs platform comments into the ledger: `../sdlc-hub-bridge/SKILL.md`.
+- The ledger headings these match: `../yad-review-gate/SKILL.md` (comment action) and `references/gating.md`.
+- The review bridge that syncs platform comments into the ledger: `../yad-hub-bridge/SKILL.md`.

package/skills/{sdlc-review-comments → yad-review-comments}/references/comment-conventions.md

@@ -8,14 +8,14 @@ attributable header:
 **<name> (<role>)**
 ```
 
-`<role>` is one of `owner | reviewer | domain-owner` — the same roles `sdlc-review-gate` records. This
+`<role>` is one of `owner | reviewer | domain-owner` — the same roles `yad-review-gate` records. This
 header matches the `## <name> (<role>)` headings the gate writes into
 `reviews/<artifact>--<date>--comments.md`, so a comment copied from the PR thread (or synced by
-`sdlc-hub-bridge`) needs no reformatting to land in the ledger.
+`yad-hub-bridge`) needs no reformatting to land in the ledger.
 
 ## Blocking comments (a gate or rule says stop)
 
-These map to the code-repo check gates (`sdlc-checks`) and the file-boundary / contract rules:
+These map to the code-repo check gates (`yad-checks`) and the file-boundary / contract rules:
 
 - **spec-link** — "This commit has no `Task: <story>-<task>` trailer; the spec-link gate will fail. Add
   the trailer (and ensure `specs/<story>/link.md` exists)."
@@ -24,12 +24,12 @@ These map to the code-repo check gates (`sdlc-checks`) and the file-boundary / c
 - **build-test-lint** — "Lint/build/test is red (or the test doesn't exercise the new behavior). The
   build-test-lint gate must pass with a test that actually exercises the acceptance criterion."
 - **file-boundary** — "This diff touches files the task's `Files:` list didn't declare. Re-scope the
-  task (re-run `sdlc-spec`) rather than widening the diff silently."
+  task (re-run `yad-spec`) rather than widening the diff silently."
 
 ## Escalation / routing comment
 
 - **routing** — "Risk is `high` / a contract|auth|payments surface is touched — this needs a
-  domain-owner approval per touched repo (the same escalation `sdlc-review-gate` applies). Run
+  domain-owner approval per touched repo (the same escalation `yad-review-gate` applies). Run
   `bash checks/risk-route.sh <body>` (code repo) or `bash checks/hub-route.sh <body>` (hub)."
 
 ## Non-blocking comments
@@ -41,7 +41,7 @@ These map to the code-repo check gates (`sdlc-checks`) and the file-boundary / c
 ## Approval note
 
 - **approve** — "Approving as `<role>`. Recorded in `approvals.json` (code-repo ship: `build-log.json`).
-  On the hub, your approval here is pulled in by `sdlc-review-gate action: sync`."
+  On the hub, your approval here is pulled in by `yad-review-gate action: sync`."
 
 ## Hub front-artifact review
 

package/skills/{sdlc-review-comments → yad-review-comments}/templates/github/REVIEW_COMMENTS.md

@@ -20,13 +20,13 @@ SDLC review ledger (`reviews/<artifact>--<date>--comments.md`) so feedback stays
 
 **<name> (<role>)**
 - file-boundary: this touches files the task's `Files:` list didn't declare. Re-scope the task (re-run
-  `sdlc-spec`) instead of widening the diff.
+  `yad-spec`) instead of widening the diff.
 
 ## Routing / escalation
 
 **<name> (<role>)**
 - routing: risk is `high` / a contract|auth|payments surface is touched — needs a domain-owner approval
-  per touched repo (same escalation as `sdlc-review-gate`). Run `bash checks/risk-route.sh <body>`.
+  per touched repo (same escalation as `yad-review-gate`). Run `bash checks/risk-route.sh <body>`.
 
 ## Non-blocking
 

package/skills/{sdlc-review-comments → yad-review-comments}/templates/gitlab/REVIEW_COMMENTS.md

@@ -20,13 +20,13 @@ SDLC review ledger (`reviews/<artifact>--<date>--comments.md`) so feedback stays
 
 **<name> (<role>)**
 - file-boundary: this touches files the task's `Files:` list didn't declare. Re-scope the task (re-run
-  `sdlc-spec`) instead of widening the diff.
+  `yad-spec`) instead of widening the diff.
 
 ## Routing / escalation
 
 **<name> (<role>)**
 - routing: risk is `high` / a contract|auth|payments surface is touched — needs a domain-owner approval
-  per touched repo (same escalation as `sdlc-review-gate`). Run `bash checks/risk-route.sh <body>`.
+  per touched repo (same escalation as `yad-review-gate`). Run `bash checks/risk-route.sh <body>`.
 
 ## Non-blocking
 

package/skills/{sdlc-review-gate → yad-review-gate}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: sdlc-review-gate
+name: yad-review-gate
 description: 'The reusable team review + approve gate for the SDLC. Shares an authored artifact for review, records reviewer comments and approvals as files, enforces the owner + 1 reviewer rule (escalating to domain owners on contract/auth/payments), and advances the epic state ONLY when approval is recorded. Use when the user says "review the analysis/epic/architecture/UI/stories", "comment", "approve", or "advance the gate".'
 ---
 
@@ -13,7 +13,7 @@ escalation applies only where `risk_tags` or per-repo routing call for it.
 
 This gate is **swappable and file-driven**: it talks only through files. A front step advances only on a
 human act — recording an approval and `advance`, or (with the bridge) **merging the approved,
-fully-resolved review PR/MR**. It works the same whether a human or the `sdlc gate` CLI triggers it — the
+fully-resolved review PR/MR**. It works the same whether a human or the `yad gate` CLI triggers it — the
 trigger is a parameter, not a hardcoded human.
 
 ## Conventions
@@ -29,7 +29,7 @@ trigger is a parameter, not a hardcoded human.
 - `action`: one of `open` | `comment` | `approve` | `sync` | `advance` (default: `open`).
 - For `comment` / `approve`: the reviewer name and role (`owner` | `reviewer` | `domain-owner`),
   and for domain owners the `domain` (repo/area). Ask if not provided.
-- `sync` needs no reviewer input — it reads the platform PR/MR review state (via `sdlc-hub-bridge`).
+- `sync` needs no reviewer input — it reads the platform PR/MR review state (via `yad-hub-bridge`).
 
 ## On Activation
 
@@ -60,7 +60,7 @@ the rule above, and tell reviewers how to comment/approve. Set the step `status`
 
 If `.sdlc/hub.json` has a non-null `platform`, `bridge_enabled: true`, `config.yaml` `hub.bridge: true`,
 and `gh`/`glab` is authenticated, **also open a review PR/MR on the hub** by invoking
-`sdlc-hub-bridge action: open` (epic + artifact). Record the PR in `epics/<epic>/.sdlc/hub-prs.json`
+`yad-hub-bridge action: open` (epic + artifact). Record the PR in `epics/<epic>/.sdlc/hub-prs.json`
 (`{step, artifact, platform, number, url, branch, lastSyncedAt}`) and report the URL + required
 reviewers. Otherwise (no platform / disabled / no CLI) proceed **file-only** exactly as before — no
 error. Opening the PR records no approvals and never advances.
@@ -119,7 +119,7 @@ a separate, explicit check.
 
 **`sync`** — (the platform bridge input path) Pull the hub review PR/MR's review state into the ledger,
 then re-evaluate the rule (Step 3). Read the PR for this step from `.sdlc/hub-prs.json` and use
-`sdlc-hub-bridge`'s read recipes (`../sdlc-hub-bridge/references/bridge.md`) to fetch reviews + comments
+`yad-hub-bridge`'s read recipes (`../yad-hub-bridge/references/bridge.md`) to fetch reviews + comments
 via the local user's `gh`/`glab`. For each:
 - map the platform `login` → SDLC `name` + `role` via `.sdlc/hub.json`'s roster (a roster `name` equal
   to a repo's `domain_owner` in `repos.json` becomes that repo's `domain-owner` for a touched domain;
@@ -131,7 +131,7 @@ via the local user's `gh`/`glab`. For each:
 key comments on the platform comment id (re-running `sync` does not duplicate). **Manual approvals (no
 `source` tag) are never touched.** For the architecture+contract step, discard bridge approvals dated
 before a new contract lock (re-lock invalidates platform approvals too). Then refresh the `approved.md`
-roster, set `hub-prs.json` `lastSyncedAt`, and **re-evaluate Step 3**. Under the PR-driven CLI (`sdlc
+roster, set `hub-prs.json` `lastSyncedAt`, and **re-evaluate Step 3**. Under the PR-driven CLI (`yad
 gate sync`), `sync` advances the step when Step 3 passes on a **merged**, fully-resolved, approved PR
 (the merge is the human act); otherwise it records state and holds the step `in_review`.
 
@@ -145,7 +145,7 @@ The step may advance **iff ALL hold**:
 2. The artifact has not changed since the latest approval round (no newer authored edit than the
    newest `approved` record). If it changed, approvals are stale → return to `comment`. For the
    **architecture+contract** review, also recompute the contract-surface hash (see
-   `../sdlc-author-architecture/references/contract-format.md`): if it no longer matches
+   `../yad-architecture/references/contract-format.md`): if it no longer matches
    `.sdlc/contract-lock.json`, the surface changed → approvals stale → return to `comment` and re-lock.
 
 If the predicate **fails**: report exactly which approvals are still missing and STOP. Do not modify
@@ -161,9 +161,9 @@ If the predicate **passes**:
 - Write `state.json`. Report the advance and what the next authored artifact is (or that the epic is
   now `ready-for-build`).
 
-### PR-driven automation (the `sdlc gate` CLI)
+### PR-driven automation (the `yad gate` CLI)
 When the hub has a platform, the mechanical `open`/`sync`/`advance` is performed deterministically by the
-**`sdlc gate` CLI** (`sdlc gate open|sync|comments|status`), which writes the same `.sdlc/` + `reviews/`
+**`yad gate` CLI** (`yad gate open|sync|comments|status`), which writes the same `.sdlc/` + `reviews/`
 records this skill describes. The skill's job is then the human half: presenting the artifact, helping the
 owner address comments, and narrating the gate. The CLI is the single implementation of the gh/glab
 mechanics — do not hand-run gh/glab recipes when it is installed.
@@ -172,11 +172,11 @@ Under that CLI the gate **advances on merge**: a review PR/MR whose reviewer rul
 comment threads are **all resolved**, and which has been **merged** auto-marks the step `done` and
 unblocks the next step. (Until those three hold, the step stays `in_review`.)
 
-`sync` can also be **event-driven**: when the hub is wired with the gate-sync CI (`sdlc-hub-bridge`
+`sync` can also be **event-driven**: when the hub is wired with the gate-sync CI (`yad-hub-bridge`
 `wire` action), every approval / change request / dismissal / merge on the review PR/MR triggers
-`sdlc gate ci` on the hub, which runs the same sync and commits the ledger updates directly to the
+`yad gate ci` on the hub, which runs the same sync and commits the ledger updates directly to the
 hub's default branch (pull to see them locally). The predicate, the human merge, and manual
-`sdlc gate sync` are all unchanged — CI never approves and never merges.
+`yad gate sync` are all unchanged — CI never approves and never merges.
 
 ### Hard rules (build plan §1, §5)
 - **The merge click is the human approval act.** A front step advances only when a human merges the
@@ -193,4 +193,4 @@ hub's default branch (pull to see them locally). The predicate, the human merge,
 
 ## Reference
 - Gating details and worked example: `references/gating.md`.
-- The platform PR/MR bridge (`open`/`sync` mechanics, read recipes, roster): `../sdlc-hub-bridge/SKILL.md`.
+- The platform PR/MR bridge (`open`/`sync` mechanics, read recipes, roster): `../yad-hub-bridge/SKILL.md`.

package/skills/{sdlc-review-gate → yad-review-gate}/references/gating.md

@@ -33,7 +33,7 @@ content. This prevents "approve, then quietly change it" (build plan §5 spirit)
 For the architecture+contract review there is a second, content-based staleness check: recompute the
 SHA-256 of the contract-surface block and compare it to `.sdlc/contract-lock.json`. A mismatch means
 the locked surface changed even if the file's mtime looks fine — approvals are stale, re-lock and
-re-approve. (Hash recipe: `sdlc-author-architecture/references/contract-format.md`.)
+re-approve. (Hash recipe: `yad-architecture/references/contract-format.md`.)
 
 ## Worked example — epic gate
 
@@ -58,7 +58,7 @@ attributable, and it is the same shape a future service or the platform bridge c
 ## Platform-backed input (the bridge)
 When the hub has a platform (`.sdlc/hub.json`) and the bridge is enabled, reviewers can approve/comment
 on a real PR/MR instead of (or as well as) the skill recording it directly. `action: sync`
-(`sdlc-hub-bridge`) reads that platform state with the reviewer's own `gh`/`glab` and writes the **same**
+(`yad-hub-bridge`) reads that platform state with the reviewer's own `gh`/`glab` and writes the **same**
 `approvals.json` / `comments.json` / `reviews/*.md` records the manual path writes — bridge approvals
 tagged `"source": "bridge"`. **The predicate above is unchanged**: it counts owner/reviewer/domain-owner
 approvals regardless of how they were recorded.
@@ -69,7 +69,7 @@ approvals regardless of how they were recorded.
   comment id) and never touches **manual** approvals.
 - The architecture+contract staleness rule applies to bridge approvals too: a re-lock discards bridge
   approvals dated before the new lock.
-- No platform / no CLI → the gate runs file-only with no error. Detail: `../sdlc-hub-bridge/references/bridge.md`.
+- No platform / no CLI → the gate runs file-only with no error. Detail: `../yad-hub-bridge/references/bridge.md`.
 
 ## Why this shape
 - Owner + 1 reviewer keeps review load low on a small team (design priority 2) while still requiring

package/skills/{sdlc-run → yad-run}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: sdlc-run
+name: yad-run
 description: 'Phase 4 (automation) — the orchestrator that makes the second dial real. Drives a story''s back-half loop (spec → tasks → implement → checks) in one code repo, reading each step''s automation dial from build-state: on machine_advance it advances on its own, on human_approve it stops for a human. Records every run in the trust log (the evidence base for earning automation). Realizes Step B: when checks is earned, a clean gate pass auto-advances to engineer-review; any failure, scope overrun, or contract-surface touch HALTS and pulls in a human. Also sets a step''s dial (gated by trust evidence) and flips the system-wide kill switch. Never advances a front state or the engineer review. Use when the user says "run the build half", "advance story <id>", "set the checks dial", or "kill switch".'
 ---
 
@@ -32,9 +32,9 @@ signal to seed them from, so they are earned only on real runs.
   `trust_threshold`, `locked_steps`, `kill_switch`).
 - Per-story build-half state: `epics/<epic>/.sdlc/build-state/<story-id>.json` (per repo).
 - Trust ledger: `epics/<epic>/.sdlc/trust-log.json` (append-only). Schemas:
-  `../sdlc-author-epic/references/state-schema.md`.
-- The orchestrator **calls the existing step skills unchanged** — `sdlc-spec` (A), `sdlc-implement`
-  (B), `sdlc-checks` (C). It owns only the *advance decision*, never what a step does.
+  `../yad-epic/references/state-schema.md`.
+- The orchestrator **calls the existing step skills unchanged** — `yad-spec` (A), `yad-implement`
+  (B), `yad-checks` (C). It owns only the *advance decision*, never what a step does.
 
 ## Inputs
 
@@ -54,8 +54,8 @@ Read `config.yaml` `automation`, the story's `build-state/<story>.json` (create
 ### `action: run` — drive the loop
 Walk the steps for `repo` starting at `from`/`currentStep`. For each step:
 
-1. **Run the step's skill** — `spec`→`sdlc-spec`, `tasks`→ the tasks leg of `sdlc-spec`,
-   `implement`→`sdlc-implement`, `checks`→`sdlc-checks (action: run)`. Capture its result.
+1. **Run the step's skill** — `spec`→`yad-spec`, `tasks`→ the tasks leg of `yad-spec`,
+   `implement`→`yad-implement`, `checks`→`yad-checks (action: run)`. Capture its result.
 2. **Derive trust signals & append a trust-log entry** (`ranBy: machine` if this advance was
    automated, else `human`) — see `references/run-loop.md` for the derivation. Do this for *every*
    step run, pass or fail; the log is the evidence base.
@@ -63,14 +63,14 @@ Walk the steps for `repo` starting at `from`/`currentStep`. For each step:
    to `human_approve`** if `automation.kill_switch` is true OR the step is `locked` OR the step id is
    in `automation.locked_steps`. (So a kill switch or a lock always wins.)
 4. **Decide:**
-   - **HALT** if the step failed — any check FAIL, a scope overrun (`sdlc-implement` stopped on the
+   - **HALT** if the step failed — any check FAIL, a scope overrun (`yad-implement` stopped on the
      file-boundary rule), a contract-surface touch, or any ambiguity. Set the step `status: blocked`,
      write the `rejected` trust entry, **stop the loop**, and report what a human must resolve.
    - else if effective dial is **`machine_advance`** → set the step `done`, advance `currentStep` to
      the next step, and **continue the loop** (this is the Step B auto-advance for `checks`).
    - else (**`human_approve`**) → set the step `done`/`in_review`, **stop** and report
      "waiting for a human at `<next-step>`".
-5. **Always stop at `engineer-review`** (it is `locked`): hand off to `sdlc-ship` for the human merge
+5. **Always stop at `engineer-review`** (it is `locked`): hand off to `yad-ship` for the human merge
    gate, which finalizes the trust verdict (confirm/override the provisional one).
 
 ### `action: set-dial` — earn (or revert) a step's automation
@@ -87,7 +87,7 @@ Flip `step`'s `automation` to `to` in build-state. Enforce, in order:
 ### `action: kill` / `action: unkill` — the kill switch
 Set `automation.kill_switch` to `true` (`kill`) or `false` (`unkill`) in `config.yaml`. While true,
 **every** step's effective dial is `human_approve` system-wide — no per-step edits, instantly
-reversible (build plan §Safety). Report the new state and that `sdlc-status` will show it.
+reversible (build plan §Safety). Report the new state and that `yad-status` will show it.
 
 ## Hard rules (phase-4-build-plan.md)
 
@@ -104,6 +104,6 @@ reversible (build plan §Safety). Report the new state and that `sdlc-status` wi
 
 ## Reference
 - The loop, the trust-verdict derivation, and the threshold predicate: `references/run-loop.md`.
-- State/trust schemas: `../sdlc-author-epic/references/state-schema.md`.
-- The steps it drives: `../sdlc-spec/`, `../sdlc-implement/`, `../sdlc-checks/`; the human gate it
-  hands off to: `../sdlc-ship/`.
+- State/trust schemas: `../yad-epic/references/state-schema.md`.
+- The steps it drives: `../yad-spec/`, `../yad-implement/`, `../yad-checks/`; the human gate it
+  hands off to: `../yad-ship/`.

package/skills/{sdlc-run → yad-run}/references/run-loop.md

@@ -1,4 +1,4 @@
-# `sdlc-run` — the loop, the trust verdict, the threshold
+# `yad-run` — the loop, the trust verdict, the threshold
 
 This is the detail behind `SKILL.md`. It restates the orchestration so the skill is self-contained,
 and pins down the two judgments the skill makes: **what trust verdict to record** and **when a step
@@ -12,9 +12,9 @@ From `config.yaml` `automation.back_steps` plus the human merge gate:
 spec → tasks → implement → checks → engineer-review(locked)
 ```
 
-`spec` and `tasks` are the two legs of `sdlc-spec` (the heavy ceremony, then the atomic `tasks.md`).
-`implement` is one atomic task via `sdlc-implement`. `checks` is `sdlc-checks (action: run)`.
-`engineer-review` is the human gate at `sdlc-ship` — always a stop, never automated.
+`spec` and `tasks` are the two legs of `yad-spec` (the heavy ceremony, then the atomic `tasks.md`).
+`implement` is one atomic task via `yad-implement`. `checks` is `yad-checks (action: run)`.
+`engineer-review` is the human gate at `yad-ship` — always a stop, never automated.
 
 ## The loop (pseudocode)
 
@@ -24,7 +24,7 @@ bs    = build-state/<story>.json.repos[<repo>]        # create from defaults if
 step  = from or bs.currentStep
 
 while step is a back step (not engineer-review):
-    result = run_step_skill(step)                     # sdlc-spec | sdlc-implement | sdlc-checks
+    result = run_step_skill(step)                     # yad-spec | yad-implement | yad-checks
 
     signals = derive_signals(step, result)            # see "Deriving signals"
     verdict = derive_verdict(signals)                 # rejected | approved-with-edits | approved-unchanged
@@ -40,7 +40,7 @@ while step is a back step (not engineer-review):
     else:  # human_approve
         bs.step.status = "done"; persist; STOP and report "waiting for human at <next>"
 
-# reached engineer-review: always stop, hand to sdlc-ship (human gate, finalizes the verdict)
+# reached engineer-review: always stop, hand to yad-ship (human gate, finalizes the verdict)
 ```
 
 `ranBy` is `machine` when the *previous* step's effective dial caused this step to run without a human
@@ -62,17 +62,17 @@ per-step dial says. `engineer-review` and the four front states are covered by `
 ## Deriving signals & the provisional verdict
 
 `signals` are the raw facts of the run; the **provisional `verdict`** is derived from them. The human
-gate for each step (the engineer review at `sdlc-ship` for `implement`; spec acceptance for `spec`;
+gate for each step (the engineer review at `yad-ship` for `implement`; spec acceptance for `spec`;
 first-consume for `tasks`; the gate itself for `checks`) later confirms or overrides the verdict and
 finalizes the entry — a human always has the last word on the trust signal.
 
 `signals` (only the relevant ones are set per step — see the table in
-`../sdlc-author-epic/references/state-schema.md`):
+`../yad-epic/references/state-schema.md`):
 - `checks` — `pass` | `fail` | `n/a` (only the `checks` step runs the three gates).
 - `human_edited_diff` — `true` if a human changed the produced **diff** before merge (`implement`).
 - `human_edited_spec` — `true` if a human edited the generated **spec/plan/tasks** before accepting (`spec`).
 - `task_rescoped` — `true` if a task's declared `Files:`/scope was edited before implementing (`tasks`).
-- `scope_overrun` — `true` if `sdlc-implement` stopped on the file-boundary rule (diff outside the
+- `scope_overrun` — `true` if `yad-implement` stopped on the file-boundary rule (diff outside the
   task's declared files).
 - `contract_touch` — `true` if the diff touched the locked contract surface without an upstream
   re-lock (routes back to the architecture gate).
@@ -114,7 +114,7 @@ Reverting (`to: human_approve`) is never gated — automation must be reversible
 
 ## What stays human, always
 
-- `engineer-review` — the merge gate. `sdlc-run` always stops here and hands to `sdlc-ship`.
+- `engineer-review` — the merge gate. `yad-run` always stops here and hands to `yad-ship`.
 - The four front states (`epic`, `architecture`, `ui-design`, `stories`) — not in `back_steps`, in
   `locked_steps`; the dial-setter refuses them.
 - Any contract-surface change — halts the loop and routes back to the architecture gate, regardless of

package/skills/{sdlc-ship → yad-ship}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: sdlc-ship
+name: yad-ship
 description: 'Build-half Step E of the gated SDLC — AI review, engineer review, then ship. Wire an advisory AI first-pass (CodeRabbit) on the PR/MR; record the human engineer review with the same human_approve discipline as the front gates (owner + 1 reviewer, escalating to domain owners on high risk / contract / auth / payments — the Step D routing); and on merge, record the ship in the epic build-log and update the story state so the epic → story → task → PR chain is traceable. Never auto-advances — the human owns the merge. Use when the user says "ship this task", "record the engineer review", or "wire the AI review".'
 ---
 
@@ -17,9 +17,9 @@ then **ship** — merge, record the ship, and update the story state. This is th
   truth: it holds the story and the build ledger).
 - Code repos are separate git repos under `{project-root}/demo-repos/<repo>/`.
 - The build ledger is `{project-root}/epics/<epic>/.sdlc/build-log.json` (append-only).
-- The engineer-review rule reuses `sdlc-review-gate`: base = at least one `owner` AND one distinct
+- The engineer-review rule reuses `yad-review-gate`: base = at least one `owner` AND one distinct
   `reviewer`; **escalated** (the PR's Impact & Risk is `high`, or it touches contract/auth/payments) =
-  base PLUS one `domain-owner` per touched domain — the same routing `sdlc-pr-template`'s
+  base PLUS one `domain-owner` per touched domain — the same routing `yad-pr-template`'s
   `risk-route.sh` prints.
 - AI review wiring: `templates/.coderabbit.yaml` → `<repo>/.coderabbit.yaml`.
 
@@ -42,7 +42,7 @@ ran; surface its findings to the engineer. Do **not** treat AI approval as a gat
 ### Step 2 — `approve` (the engineer review — the human gate)
 A human engineer reads the diff **against the spec** (`specs/<story>/`) and the acceptance criteria,
 and records an approval. Determine the rule from the PR's Impact & Risk block (run
-`../sdlc-pr-template/templates/checks/risk-route.sh` on the PR body): base, or escalated to a
+`../yad-pr-template/templates/checks/risk-route.sh` on the PR body): base, or escalated to a
 domain-owner per touched domain. Record each approval; re-evaluate whether the rule is satisfied.
 Recording an approval does **not** ship — shipping is a separate, explicit step. Front-half discipline:
 the gate talks only through files; refuse to treat AI review as a human approval.
@@ -62,7 +62,7 @@ engineer-review rule is satisfied (Step 2). Then:
   the story frontmatter `status: shipped`; otherwise `status: in-build`. The chain
   **epic → story → task → PR → mergeCommit** is now traceable end to end.
 - **Finalize the trust verdict (Phase 4).** If this story has a `build-state/<story>.json` (it ran
-  through `sdlc-run`), the engineer **confirms or overrides** the provisional trust verdict that the
+  through `yad-run`), the engineer **confirms or overrides** the provisional trust verdict that the
   orchestrator derived for this run, and the final verdict is written to
   `epics/<epic>/.sdlc/trust-log.json`. The human has the last word on the trust signal: a diff merged
   as authored is `approved-unchanged`; one the engineer edited before merge is `approved-with-edits`;
@@ -76,11 +76,11 @@ stays as it was (`ready-for-build`). The build half is recorded in `build-log.js
 ## Hard rules (build plan §E, Cross-cutting)
 
 - **AI review is advisory, never the authority.** Only a human engineer approval counts toward the gate.
-- **High risk routes to domain owners** — the same escalation as `sdlc-review-gate` / `risk-route.sh`.
+- **High risk routes to domain owners** — the same escalation as `yad-review-gate` / `risk-route.sh`.
 - **Ship only after gates + engineer review.** No gate skipped; the human owns the merge.
 - **Nothing auto-advances.** Step E records human decisions in files; it never machine-advances.
 
 ## Reference
 - The build ledger + story-state rules: `references/ship-and-record.md`.
-- The escalation reused: `../sdlc-review-gate/SKILL.md`; the routing helper: `../sdlc-pr-template/`.
-- The gates that must pass first: `../sdlc-checks/references/check-gates.md`.
+- The escalation reused: `../yad-review-gate/SKILL.md`; the routing helper: `../yad-pr-template/`.
+- The gates that must pass first: `../yad-checks/references/check-gates.md`.

package/skills/{sdlc-ship → yad-ship}/references/ship-and-record.md

@@ -1,6 +1,6 @@
 # Ship — the build ledger and the story state
 
-Step E (`sdlc-ship`) closes the build half: AI review (advisory) → engineer review (the human gate) →
+Step E (`yad-ship`) closes the build half: AI review (advisory) → engineer review (the human gate) →
 ship. Shipping records the merge and updates the story state so the whole chain is traceable.
 
 ## Two sets of eyes
@@ -10,7 +10,7 @@ ship. Shipping records the merge and updates the story state so the whole chain
    gate. Where CodeRabbit can't run (no remote), an equivalent AI first-pass is run by hand and its
    notes captured.
 2. **Engineer review (the authority).** A human reads the diff against the spec and the acceptance
-   criteria and records an approval. The rule is `sdlc-review-gate`'s:
+   criteria and records an approval. The rule is `yad-review-gate`'s:
    - **base:** at least one `owner` AND one distinct `reviewer`.
    - **escalated:** when the PR's Impact & Risk is `high`, or it touches contract/auth/payments — base
      PLUS one `domain-owner` per touched domain (exactly what `risk-route.sh` prints).
@@ -64,4 +64,4 @@ trailer → story → epic).
 2. The **AI review** has run (advisory; findings surfaced to the engineer).
 3. The **engineer review** rule is satisfied (base or escalated per the Impact & Risk block).
 
-Only then does the human merge and `sdlc-ship` record it. Nothing auto-advances.
+Only then does the human merge and `yad-ship` record it. Nothing auto-advances.

package/skills/{sdlc-ship → yad-ship}/templates/.coderabbit.yaml

@@ -1,6 +1,6 @@
 # CodeRabbit — AI first-pass review (Phase 3 build plan §E).
 # Advisory only: a second set of eyes that COMMENTS on every PR. It never approves or merges — the
-# human engineer review (sdlc-review-gate discipline) owns that decision. See skills/sdlc-ship.
+# human engineer review (yad-review-gate discipline) owns that decision. See skills/yad-ship.
 language: en
 reviews:
   request_changes_workflow: false   # never block the merge — the engineer review is the gate

package/skills/{sdlc-spec → yad-spec}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: sdlc-spec
+name: yad-spec
 description: 'Build-half Step A of the gated SDLC. For one ready-for-build story and one of its repos, run the heavy Spec Kit ceremony ONCE (specify → clarify → plan → analyze → checklist → tasks) inside that code repo, writing specs/<story-id>/ in Spec Kit''s own layout. Drives /speckit.* as harness slash-commands when installed; authors the same files by hand and records speckit: not-installed when absent. References the locked contract — never re-invents the surface. Writes link.md back to the story. Never auto-advances. Use when the user says "spec story <id> in <repo>" or after a story is ready-for-build.'
 ---
 
@@ -7,16 +7,16 @@ description: 'Build-half Step A of the gated SDLC. For one ready-for-build story
 
 **Goal:** Turn ONE `ready-for-build` story into a per-repo Spec Kit spec/plan/tasks inside that
 story's code repo. The heavy spec ceremony runs **once per story per repo**; the light
-tasks → implement loop is **Step B** (`sdlc-implement`). This step **never re-locks the contract** —
+tasks → implement loop is **Step B** (`yad-implement`). This step **never re-locks the contract** —
 the cross-repo surface is owned upstream by the architecture gate (build plan §A, Cross-cutting
 "Heavy spec once per story, light loop per task"). It does not advance the front-half state machine;
-when driven by the orchestrator (`sdlc-run`, Phase 4) it records a `spec`/`tasks` trust signal
+when driven by the orchestrator (`yad-run`, Phase 4) it records a `spec`/`tasks` trust signal
 (Step 8) — but it never auto-advances a contract change or a front state.
 
 Spec Kit is driven as **harness slash-commands** (`/speckit.*`), not a subprocess CLI (Phase 0
 Deviation 3). When Spec Kit is not installed, the same files are hand-authored in Spec Kit's exact
 layout and the spec is marked `speckit: not-installed` — the workflow does not block on the tool. This
-is the same graceful-degradation pattern `sdlc-author-ui` uses for Impeccable.
+is the same graceful-degradation pattern `yad-ui` uses for Impeccable.
 
 ## Conventions
 
@@ -45,7 +45,7 @@ is the same graceful-degradation pattern `sdlc-author-ui` uses for Impeccable.
 Read `{project-root}/epics/<epic>/.sdlc/state.json`. Proceed only when
 `currentStep == "ready-for-build"` (the whole front half is `done`). Read the story file
 `epics/<epic>/stories/<story>.md`; confirm `repo` is in its `repos`. If the epic is not ready, STOP
-and point the user at `sdlc-status`. **Do not mutate front-half state** — `ready-for-build` semantics
+and point the user at `yad-status`. **Do not mutate front-half state** — `ready-for-build` semantics
 stay intact.
 
 ### Step 2 — Resolve the target code repo
@@ -87,21 +87,21 @@ spec folder is the authoritative record that this story's spec exists.
 
 ### Step 7 — Stop (front-half state untouched)
 Report: the spec folder path, the files written, whether Spec Kit was used, the task count from
-`tasks.md`, and that the next action is **Step B — `sdlc-implement`**. Do **not** edit the epic's
+`tasks.md`, and that the next action is **Step B — `yad-implement`**. Do **not** edit the epic's
 `state.json`, `approvals.json`, or `contract-lock.json`. Step A is a generation step, not a front gate.
 
 ### Step 8 — Record the `spec` trust signal (Phase 4b)
-When this step runs under the orchestrator (`sdlc-run`), the generated spec is a back-half run that the
+When this step runs under the orchestrator (`yad-run`), the generated spec is a back-half run that the
 trust log measures (it is the evidence that could later earn the `spec` step a `machine_advance`). The
 verdict is **anchored to the human who accepts the spec**, never self-graded:
 - the human approves the generated `specs/<story>/` untouched → `approved-unchanged`;
 - the human edits the spec/plan/tasks before accepting → `approved-with-edits` (signal
   `human_edited_spec: true`);
 - the spec is rejected or the ceremony re-run → `rejected`.
-`sdlc-run` records a provisional entry when the spec is generated; this acceptance finalizes it (same
-pattern as the engineer review finalizing `implement` at `sdlc-ship`). Append the finalized entry to
+`yad-run` records a provisional entry when the spec is generated; this acceptance finalizes it (same
+pattern as the engineer review finalizing `implement` at `yad-ship`). Append the finalized entry to
 `epics/<epic>/.sdlc/trust-log.json` (schema:
-`../sdlc-author-epic/references/state-schema.md`). **Run standalone, no trust entry is written** — the
+`../yad-epic/references/state-schema.md`). **Run standalone, no trust entry is written** — the
 log measures orchestrated runs. `spec` stays `human_approve` until its slice clears the threshold;
 this step only *gathers* the evidence, it does not flip the dial.
 
@@ -115,5 +115,5 @@ this step only *gathers* the evidence, it does not flip the dial.
 
 ## Reference
 - Command list, output map, degradation rules, link.md template: `references/spec-handoff.md`.
-- Contract surface format + hash recipe: `../sdlc-author-architecture/references/contract-format.md`.
+- Contract surface format + hash recipe: `../yad-architecture/references/contract-format.md`.
 - Spec Kit facts and the slash-command-vs-CLI deviation: `RESEARCH-NOTES.md` §2 + Phase 3 decisions + Deviation 3.

package/skills/{sdlc-spec → yad-spec}/references/spec-handoff.md

@@ -1,9 +1,9 @@
 # Spec Kit handoff — command list, output map, and degradation rules
 
-Step A (`sdlc-spec`) runs the **heavy Spec Kit ceremony once per story per repo** and writes the
+Step A (`yad-spec`) runs the **heavy Spec Kit ceremony once per story per repo** and writes the
 result into the story's code repo. This reference pins the exact commands, the files they produce, and
 how to hand-author the same files faithfully when Spec Kit is not installed — so Step B
-(`sdlc-implement`, not built yet) can read them unchanged.
+(`yad-implement`, not built yet) can read them unchanged.
 
 ## The ceremony (run once, in order)