yadflow 1.4.0 → 2.0.0

package/skills/{sdlc-checks → yad-checks}/references/check-gates.md

@@ -8,10 +8,10 @@ repo uses. Each reads conventions established by earlier steps — it invents no
 
 | Gate | Reads | Source step |
 |------|-------|-------------|
-| spec-link | the `Task: <story>-<task>` commit trailer; `specs/<story>/link.md` | `sdlc-implement` (trailer), `sdlc-spec` (link.md) |
-| contract-check | changed files under `specs/<story>/contracts/`; the `Contract-Change: yes` trailer; `link.md`'s pinned `contract-lock`; the product repo's `contract-lock.json` | `sdlc-author-architecture` (lock), `sdlc-spec` (slice + link), `sdlc-implement` (trailer) |
+| spec-link | the `Task: <story>-<task>` commit trailer; `specs/<story>/link.md` | `yad-implement` (trailer), `yad-spec` (link.md) |
+| contract-check | changed files under `specs/<story>/contracts/`; the `Contract-Change: yes` trailer; `link.md`'s pinned `contract-lock`; the product repo's `contract-lock.json` | `yad-architecture` (lock), `yad-spec` (slice + link), `yad-implement` (trailer) |
 | build/test/lint | the repo's `npm run lint` / `npm run build` / `npm test` | the repo |
-| verified-commits | each commit's platform signature-verification status; the author email vs `.sdlc/verified-authors` | hub roster `email` fields (`sdlc check --fix` generates the allowlist) |
+| verified-commits | each commit's platform signature-verification status; the author email vs `.sdlc/verified-authors` | hub roster `email` fields (`yad check --fix` generates the allowlist) |
 
 ## 1. spec-link (`templates/checks/spec-link.sh`)
 
@@ -34,9 +34,9 @@ repo uses. Each reads conventions established by earlier steps — it invents no
   - Best-effort fidelity: when the product repo is reachable (via `link.md`'s `product-repo` path),
     require `link.md`'s pinned `contract-lock` hash to match the product repo's current
     `contract-lock.json`. A claimed change that still pins the **old** lock **FAILS** — re-run
-    `sdlc-spec` so the slice matches the re-locked contract.
+    `yad-spec` so the slice matches the re-locked contract.
 - This enforces the Phase 2 rule: the shared surface is owned upstream and is never widened from inside
-  a code repo. The hash recipe is in `../sdlc-author-architecture/references/contract-format.md`.
+  a code repo. The hash recipe is in `../yad-architecture/references/contract-format.md`.
 
 ## 3. build/test/lint (`templates/checks/build-test-lint.sh`)
 
@@ -68,7 +68,7 @@ repo. For each commit in `<base>..HEAD`, two independent checks:
   "Verified" badge: signed with a GPG/SSH key registered to the account owning the author email).
   Read via `gh api repos/{owner}/{repo}/commits/<sha>` (GitHub) or the commits/signature API (GitLab).
 - **Known author** — the commit's **author email** must appear in `.sdlc/verified-authors`, generated
-  by `sdlc check --fix` from the hub roster's `email`/`emails` fields plus hub.json's
+  by `yad check --fix` from the hub roster's `email`/`emails` fields plus hub.json's
   `verified_authors` list (edit hub.json, never the generated file). Only the author is checked:
   platform-generated merge/squash commits set the platform as committer, and their integrity is
   covered by the signature check.
@@ -80,7 +80,7 @@ closed** with guidance. GitLab CI needs a `GITLAB_TOKEN`/`SDLC_API_TOKEN` variab
 `CI_JOB_TOKEN` cannot read the signature API.
 
 Note the deliberate split with the gate-sync bot: this gate runs on **PRs/MRs only**, so the
-`sdlc-gate-sync` ledger commits (pushed directly to the default branch, unsigned, bot-authored) are
+`yad-gate-sync` ledger commits (pushed directly to the default branch, unsigned, bot-authored) are
 not subject to it. Do **not** replace it with a platform-level "reject unsigned pushes" rule on the
 default branch — that would break the event-driven gate sync (and GitLab push rules are Premium-only).
 
@@ -88,10 +88,10 @@ default branch — that would break the event-driven gate sync (and GitLab push
 
 The gates run identically under either CI; the config just invokes the scripts with the PR/MR base.
 
-- **GitHub Actions** — `templates/github/sdlc-checks.yml` → `.github/workflows/sdlc-checks.yml`. The
+- **GitHub Actions** — `templates/github/yad-checks.yml` → `.github/workflows/yad-checks.yml`. The
   jobs run on `pull_request` with `fetch-depth: 0`, passing `origin/${{ github.base_ref }}` as base
   (verified-commits also gets a read-only `GH_TOKEN` for the Verified-badge lookup).
-- **GitLab CI** — `templates/gitlab/sdlc-checks.gitlab-ci.yml` → `.gitlab/ci/sdlc-checks.yml`, pulled in
+- **GitLab CI** — `templates/gitlab/yad-checks.gitlab-ci.yml` → `.gitlab/ci/yad-checks.yml`, pulled in
   by the root `.gitlab-ci.yml`'s `include:`. The jobs run on `merge_request_event` with `GIT_DEPTH: 0`,
   passing `origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME`.
 
@@ -102,20 +102,20 @@ editing a foreign CI file. The principle is "own a separate file; touch the fore
 one-line include".
 
 **GitHub.** Every workflow file runs independently, so the gates simply live in their own
-`sdlc-checks.yml`, identified by the first-line marker `# sdlc-managed: sdlc-checks`.
+`yad-checks.yml`, identified by the first-line marker `# yad-managed: yad-checks`.
 - No file at our path → copy the template verbatim.
 - Our marked file already there → refresh it (no-op if identical).
-- A **foreign** workflow occupies the name → install as `sdlc-checks.gen.yml` instead and make the
+- A **foreign** workflow occupies the name → install as `yad-checks.gen.yml` instead and make the
   display `name:` unique. We never merge jobs into, or edit, a foreign workflow.
 
 **GitLab.** Only one root `.gitlab-ci.yml` may exist, so the gates live in an **includable** fragment
-`.gitlab/ci/sdlc-checks.yml` (marker `# sdlc-managed-include: sdlc-checks`). Its jobs declare `needs: []`
+`.gitlab/ci/yad-checks.yml` (marker `# yad-managed-include: yad-checks`). Its jobs declare `needs: []`
 and **no `stage:`**, so they run in the default stage and a foreign root's `stages:` list can neither
-break nor reorder them; job names are `sdlc-`prefixed to avoid collisions.
+break nor reorder them; job names are `yad-`prefixed to avoid collisions.
 - No root `.gitlab-ci.yml` → write a minimal root (`gitlab-ci.include-root.yml`) that only `include:`s
   the fragment.
 - Root exists → read its top-level `include:`; add the key if absent, append
-  `- local: '.gitlab/ci/sdlc-checks.yml'` if missing, no-op if already present. **Nothing else** in the
+  `- local: '.gitlab/ci/yad-checks.yml'` if missing, no-op if already present. **Nothing else** in the
   root is touched.
 - Root YAML cannot be parsed safely → **STOP** and print the include snippet for the human to paste.
 
@@ -127,24 +127,24 @@ that already had its own pipeline keeps it and still gains the gates.
 ## Wiring the hub (`repo: hub`)
 
 The product hub is itself a repo on a platform (recorded in `.sdlc/hub.json` by
-`sdlc-connect-repos action: detect-hub`). `wire repo: hub` targets `{project-root}` and uses the same
+`yad-connect-repos action: detect-hub`). `wire repo: hub` targets `{project-root}` and uses the same
 merge-not-clobber logic, with a **hub-flavored gate set** appropriate to a "thinking" repo (it has no
 `specs/` or `package.json` build):
 - **owner-set** — every `epic.md` (and forward artifact) under `epics/EP-*/` carries an `owner`.
 - **contract-locked** — where an epic has a `contract.md`, its surface hash matches
   `.sdlc/contract-lock.json` (reuse the recipe in
-  `../sdlc-author-architecture/references/contract-format.md`).
+  `../yad-architecture/references/contract-format.md`).
 - **approvals-present** — an epic at `ready-for-build` has the approvals its gate rule requires recorded
-  in `.sdlc/approvals.json` (the same predicate `sdlc-review-gate` enforces).
+  in `.sdlc/approvals.json` (the same predicate `yad-review-gate` enforces).
 
 These are advisory checks on the hub's own PRs (the front-half review PRs the bridge opens); they keep
 the hub's artifacts internally consistent. The hub never runs the code-repo `spec-link`/`build-test-lint`
 gates. Author the hub gate scripts under the hub's `checks/` following the same CI-agnostic-bash pattern.
 
-The hub **does** run the verified-commits gate — `sdlc check --fix` installs `checks/verified-commits.sh`
-plus a standalone workflow (`templates/github/sdlc-verified-commits.yml` →
-`.github/workflows/sdlc-verified-commits.yml`, or the GitLab fragment
-`templates/gitlab/sdlc-verified-commits.gitlab-ci.yml` → `.gitlab/ci/sdlc-verified-commits.yml` +
+The hub **does** run the verified-commits gate — `yad check --fix` installs `checks/verified-commits.sh`
+plus a standalone workflow (`templates/github/yad-verified-commits.yml` →
+`.github/workflows/yad-verified-commits.yml`, or the GitLab fragment
+`templates/gitlab/yad-verified-commits.gitlab-ci.yml` → `.gitlab/ci/yad-verified-commits.yml` +
 its one include line) whenever `.sdlc/hub.json` has a platform with the bridge enabled. So the
 front-half review PRs are held to the same rule as code-repo PRs: signed, known authors only.
 

package/skills/{sdlc-checks → yad-checks}/templates/checks/contract-check.sh

@@ -33,7 +33,7 @@ cc="$(git log "$RANGE" --format='%(trailers:key=Contract-Change,valueonly)' | se
 if ! printf '%s\n' "$cc" | grep -qx 'yes'; then
   echo "FAIL [contract-check]: contract surface changed without a 'Contract-Change: yes' trailer."
   echo "  -> Route back to the architecture gate: update + re-lock contract.md in the product repo,"
-  echo "     re-run sdlc-spec, then implement with Contract-Change: yes. The surface is never widened"
+  echo "     re-run yad-spec, then implement with Contract-Change: yes. The surface is never widened"
   echo "     from inside a code repo."
   exit 1
 fi
@@ -51,7 +51,7 @@ if [ -f "$link" ]; then
     current="$(sed -nE 's/.*"hash":[[:space:]]*"sha256:([0-9a-f]+)".*/\1/p' "$lock" | head -1)"
     if [ -n "$current" ] && [ "$current" != "$pinned" ]; then
       echo "FAIL [contract-check]: Contract-Change claimed, but ${link} still pins ${pinned:0:12}…"
-      echo "  while the product lock is ${current:0:12}… — re-run sdlc-spec so the slice matches the re-locked contract."
+      echo "  while the product lock is ${current:0:12}… — re-run yad-spec so the slice matches the re-locked contract."
       exit 1
     fi
     echo "note [contract-check]: link.md hash matches the product lock (${current:0:12}…)."

package/skills/{sdlc-checks → yad-checks}/templates/checks/verified-commits.sh

@@ -3,7 +3,7 @@
 # Every commit in the range under review must (1) carry a signature the PLATFORM marks as verified
 # (the GitHub/GitLab "Verified" badge — proves the commit was signed by a key registered to the
 # account that owns the author email) and (2) be AUTHORED by a known identity: the author email must
-# appear in the .sdlc/verified-authors allowlist (generated by `sdlc check --fix` from the hub
+# appear in the .sdlc/verified-authors allowlist (generated by `yad check --fix` from the hub
 # roster's `email` fields + hub.json `verified_authors`). Unsigned commits and commits from unknown
 # authors do not reach merge — on the product hub and on every connected repo alike.
 #
@@ -41,7 +41,7 @@ authors_on=0
 if [ -f "$ALLOWLIST" ]; then
   authors_on=1
 else
-  echo "WARN [verified-commits]: ${ALLOWLIST} not found — author allowlist NOT enforced. Add 'email' to the hub roster (or hub.json 'verified_authors'), then run \`sdlc check --fix\`."
+  echo "WARN [verified-commits]: ${ALLOWLIST} not found — author allowlist NOT enforced. Add 'email' to the hub roster (or hub.json 'verified_authors'), then run \`yad check --fix\`."
 fi
 
 # ---- platform for the signature check (override with SDLC_PLATFORM=github|gitlab|none) -----------

package/skills/{sdlc-checks/templates/github/sdlc-checks.yml → yad-checks/templates/github/yad-checks.yml}

@@ -1,9 +1,9 @@
-# sdlc-managed: sdlc-checks
+# yad-managed: yad-checks
 # SDLC check gates (Phase 3 build plan §C). The three gates run on every PR and must pass before
 # merge. They are CI-agnostic bash in checks/ — this workflow just invokes them with the PR base.
-# This workflow file is OWNED by sdlc-checks (the marker on line 1 identifies it). It runs
+# This workflow file is OWNED by yad-checks (the marker on line 1 identifies it). It runs
 # independently of any other workflow in .github/workflows/, so wiring never edits a foreign workflow.
-name: sdlc-checks
+name: yad-checks
 on:
   pull_request:
     branches: ["**"]

package/skills/{sdlc-checks/templates/github/sdlc-verified-commits.yml → yad-checks/templates/github/yad-verified-commits.yml}

@@ -1,9 +1,9 @@
-# sdlc-managed: sdlc-checks
+# yad-managed: yad-checks
 # verified-commits gate for the PRODUCT HUB: every PR (including the front-half review/EP-* PRs)
 # must contain only commits whose signature the platform marks Verified AND whose author email is a
-# known identity (.sdlc/verified-authors — generated by `sdlc check --fix` from the hub roster).
-# Standalone workflow so it never collides with the hub-flavored sdlc-checks workflow.
-name: sdlc-verified-commits
+# known identity (.sdlc/verified-authors — generated by `yad check --fix` from the hub roster).
+# Standalone workflow so it never collides with the hub-flavored yad-checks workflow.
+name: yad-verified-commits
 on:
   pull_request:
     branches: ["**"]

package/skills/{sdlc-checks → yad-checks}/templates/gitlab/gitlab-ci.include-root.yml

@@ -1,7 +1,7 @@
 # SDLC check gates — minimal root pipeline.
-# Written by `sdlc-checks wire` ONLY when the repo has no existing root `.gitlab-ci.yml`.
+# Written by `yad-checks wire` ONLY when the repo has no existing root `.gitlab-ci.yml`.
 # The gates themselves live in the included fragment so the same single source is reused whether
 # or not a root pipeline already exists. If a root later grows real jobs, they coexist with the
-# included sdlc-* jobs (which carry `needs: []` and no `stage:`).
+# included yad-* jobs (which carry `needs: []` and no `stage:`).
 include:
-  - local: '.gitlab/ci/sdlc-checks.yml'
+  - local: '.gitlab/ci/yad-checks.yml'

package/skills/{sdlc-checks/templates/gitlab/sdlc-checks.gitlab-ci.yml → yad-checks/templates/gitlab/yad-checks.gitlab-ci.yml}

@@ -1,13 +1,13 @@
-# sdlc-managed-include: sdlc-checks
+# yad-managed-include: yad-checks
 # SDLC check gates (Phase 3 build plan §C), as an INCLUDABLE fragment.
 # This file is pulled into a repo's existing .gitlab-ci.yml via:
 #   include:
-#     - local: '.gitlab/ci/sdlc-checks.yml'
+#     - local: '.gitlab/ci/yad-checks.yml'
 # so wiring NEVER edits the foreign root pipeline beyond adding that one include line.
 #
 # Merge-safety: these jobs do NOT declare a `stage:` and use `needs: []`, so they run in the
 # pipeline's default stage regardless of any `stages:` order the foreign root defines — a foreign
-# `stages:` list can neither break them nor reorder them. Job names are sdlc-prefixed to avoid
+# `stages:` list can neither break them nor reorder them. Job names are yad-prefixed to avoid
 # colliding with the host project's own job names.
 default:
   image: node:20
@@ -19,19 +19,19 @@ default:
 variables:
   GIT_DEPTH: "0"   # full history so the gates can diff against the target branch
 
-sdlc-spec-link:
+yad-spec-link:
   extends: .sdlc_mr_only
   needs: []
   script:
     - bash checks/spec-link.sh "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME"
 
-sdlc-contract-check:
+yad-contract-check:
   extends: .sdlc_mr_only
   needs: []
   script:
     - bash checks/contract-check.sh "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME"
 
-sdlc-build-test-lint:
+yad-build-test-lint:
   extends: .sdlc_mr_only
   needs: []
   script:
@@ -40,7 +40,7 @@ sdlc-build-test-lint:
 # No unverified commits from unverified users: platform-Verified signature + allowlisted author.
 # Needs a CI/CD variable GITLAB_TOKEN (or SDLC_API_TOKEN) with read_api scope — CI_JOB_TOKEN cannot
 # read the commit-signature API. Without it the job FAILS closed with guidance.
-sdlc-verified-commits:
+yad-verified-commits:
   extends: .sdlc_mr_only
   needs: []
   script:

package/skills/{sdlc-checks/templates/gitlab/sdlc-verified-commits.gitlab-ci.yml → yad-checks/templates/gitlab/yad-verified-commits.gitlab-ci.yml}

@@ -1,16 +1,16 @@
-# sdlc-managed-include: sdlc-checks
+# yad-managed-include: yad-checks
 # verified-commits gate for the PRODUCT HUB, as an INCLUDABLE fragment. Pulled into the hub's root
 # .gitlab-ci.yml via:
 #   include:
-#     - local: '.gitlab/ci/sdlc-verified-commits.yml'
+#     - local: '.gitlab/ci/yad-verified-commits.yml'
 # Every MR (including the front-half review/EP-* MRs) must contain only commits whose signature the
 # platform marks Verified AND whose author email is a known identity (.sdlc/verified-authors).
 #
 # Needs a CI/CD variable GITLAB_TOKEN (or SDLC_API_TOKEN) with read_api scope — CI_JOB_TOKEN cannot
 # read the commit-signature API. The hub's SDLC_GATE_TOKEN (from the gate-sync wiring) also works:
 # set GITLAB_TOKEN: $SDLC_GATE_TOKEN in the job if you prefer one token.
-# Job name is sdlc-hub-prefixed so it can coexist with the code-repo fragment in one pipeline.
-sdlc-hub-verified-commits:
+# Job name is yad-hub-prefixed so it can coexist with the code-repo fragment in one pipeline.
+yad-hub-verified-commits:
   needs: []
   image: node:20
   variables:

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

@@ -1,11 +1,11 @@
 ---
-name: sdlc-connect-repos
+name: yad-connect-repos
 description: 'Connects code repos to the product hub so the front/"brain" phases are code-aware. Registers N code repos (GitHub or GitLab, local-user auth, no stored tokens) into the project-wide .sdlc/repos.json, then caches an AI-readable picture of each — a compressed Repomix pack and a lightweight code-map (existing endpoints/events/data-models/modules), secret-scanned. Run at one-time setup or any time a new repo is added. Reusable, idempotent, refreshable; staleness is tracked by HEAD sha. Use when the user says "connect a repo", "connect the code repos", "refresh the code context", or "list connected repos".'
 ---
 
 # SDLC — Connect Code Repos (make the brain code-aware)
 
-**Goal:** Give the front/"brain" phases (`sdlc-author-epic` → `-architecture` → `-ui` → `-stories`)
+**Goal:** Give the front/"brain" phases (`yad-epic` → `-architecture` → `-ui` → `-stories`)
 full context about what **already exists** in the code, so the AI does not author a contract, UI, or
 stories that contradict or duplicate what is built. This skill **connects** code repos to the product
 hub and caches an AI-readable picture of each. It is the product → code half of the 2-way link (the
@@ -20,7 +20,7 @@ epic's approvals. It only writes the project-wide registry and the per-repo cont
 - The **product repo is the front-phase toolchain hub** (`config.yaml` `code_context`): Repomix (and
   Impeccable, later) are installed/run **here** and target the connected code repos **by path**. The
   code repos themselves need no install for this. (The build-half CI gates are the exception — they
-  live inside each code repo; see `sdlc-checks`.)
+  live inside each code repo; see `yad-checks`.)
 - **Repomix is a true CLI subprocess** (Phase 0 / RESEARCH-NOTES §3): `npx repomix@latest [flags]` —
   NOT a slash-command. It secret-scans by default (Secretlint).
 - Registry: `{project-root}/.sdlc/repos.json` (project-wide, shared across all epics — NOT per-epic).
@@ -114,7 +114,7 @@ the front phases will now load this repo's code-map. Nothing auto-advances; this
 ## Hub detection + reviewer roster (the front-half review bridge)
 
 The hub is itself a git repo on a platform. These actions record that so the front-half review/comment/
-approval cycle can run through a real PR/MR on the hub (`sdlc-review-gate` + `sdlc-hub-bridge`). They
+approval cycle can run through a real PR/MR on the hub (`yad-review-gate` + `yad-hub-bridge`). They
 write only `{project-root}/.sdlc/hub.json` (`config.yaml` `hub.config`) — never an epic's state/approvals.
 
 - **`detect-hub`** — detect the hub's own platform and upsert `.sdlc/hub.json`. Run
@@ -137,7 +137,7 @@ re-run Repomix **live**, scoped to that area:
 npx repomix@latest --compress --include "<area globs>" --style markdown -o -
 ```
 Same CLI, invoked ad hoc — no registry write. A **stale repo** (HEAD ≠ `syncedHead`) is different: the
-phase **flags it and stops**, pointing the human at `sdlc repo refresh <repo>` (or `sdlc check --fix`) —
+phase **flags it and stops**, pointing the human at `yad repo refresh <repo>` (or `yad check --fix`) —
 it does not silently re-pack. Refreshing the cache is a human decision. Documented in
 `references/code-context.md`.
 
@@ -155,5 +155,5 @@ it does not silently re-pack. Refreshing the cache is a human decision. Document
 - Hub config + reviewer roster (the review bridge): `references/hub-config.md`.
 - Repomix command, secret-scan, degrade path, the code-map prompt, and live on-demand:
   `references/code-context.md`.
-- The repomix discipline this reuses (one-feature-at-a-time variant): `../sdlc-backfill/references/backfill.md`.
-- Repos convention + per-repo review routing: `../sdlc-author-stories/references/story-schema.md`.
+- The repomix discipline this reuses (one-feature-at-a-time variant): `../yad-backfill/references/backfill.md`.
+- Repos convention + per-repo review routing: `../yad-stories/references/story-schema.md`.

package/skills/{sdlc-connect-repos → yad-connect-repos}/references/code-context.md

@@ -1,7 +1,7 @@
 # Code context — Repomix pack, the code-map prompt, and live on-demand
 
-How `sdlc-connect-repos` turns a connected code repo into an AI-readable picture the front/"brain"
-phases can read. Three layers, same Repomix machinery as `sdlc-backfill` (this is the repo-wide
+How `yad-connect-repos` turns a connected code repo into an AI-readable picture the front/"brain"
+phases can read. Three layers, same Repomix machinery as `yad-backfill` (this is the repo-wide
 variant; backfill is the one-feature-at-a-time variant).
 
 ## Layer 1 — the cached pack (full context)
@@ -78,15 +78,15 @@ npx repomix@latest --compress --include "<area globs>" --style markdown -o -
 
 This is for a one-off look at a specific area. **Staleness is a human decision, not an automatic
 side-effect:** when a repo is stale (HEAD ≠ `syncedHead`), the phase **flags it and stops** —
-"`<repo>` is stale; run `sdlc repo refresh <repo>` to re-pack the cache + `syncedHead`" — rather than
+"`<repo>` is stale; run `yad repo refresh <repo>` to re-pack the cache + `syncedHead`" — rather than
 silently re-packing the whole repo. A phase never refreshes the registry on its own; the human runs
-`sdlc repo refresh` (or `sdlc check --fix`).
+`yad repo refresh` (or `yad check --fix`).
 
 ## Why this stays DRY with backfill
 
-`sdlc-backfill` already documents the exact Repomix command, the Secretlint discipline, the
+`yad-backfill` already documents the exact Repomix command, the Secretlint discipline, the
 `repomix: unavailable` degrade, and the "describe what exists, do not invent" prompt
-(`../sdlc-backfill/references/backfill.md`). This skill reuses all of it; the only differences are
+(`../yad-backfill/references/backfill.md`). This skill reuses all of it; the only differences are
 **scope** (repo-wide index vs one feature) and **output** (a lightweight code-map for the brain vs a
 human-approved feature spec). Backfill produces a *verified* spec that gates changes; connect produces a
 *context* artifact that informs design — they are complementary.

package/skills/{sdlc-connect-repos → yad-connect-repos}/references/hub-config.md

@@ -9,7 +9,7 @@ login to an SDLC name + role. It is a single object for the hub itself — the s
 
 `{project-root}/.sdlc/hub.json`
 
-(`config.yaml` `hub.config`.) Created/updated by `sdlc-connect-repos action: detect-hub`.
+(`config.yaml` `hub.config`.) Created/updated by `yad-connect-repos action: detect-hub`.
 
 ## Schema
 
@@ -60,7 +60,7 @@ as the registry). `detect-hub` upserts `hub.json` in place — it is idempotent
 ## Bridge enable / degradation
 
 - `bridge_enabled: true` **and** a non-null `platform` **and** `gh`/`glab` authenticated → the front-half
-  review opens a PR/MR on the hub and `sdlc-review-gate action: sync` pulls platform state into the ledger.
+  review opens a PR/MR on the hub and `yad-review-gate action: sync` pulls platform state into the ledger.
 - `bridge_enabled: false`, `platform: null`, or no/unauthenticated CLI → the gate falls back to the
   existing **file-only** flow with no error. The file ledger is the source of truth in both modes.
 - The master switch `config.yaml` `hub.bridge: false` disables the bridge globally regardless of `hub.json`.

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

@@ -1,5 +1,5 @@
 ---
-name: sdlc-author-epic
+name: yad-epic
 description: 'Front state for the epic in the gated SDLC. Shape a feature idea with the analyst (or read analysis.md when the optional analysis step already ran), then write the epic with the pm, into epic.md. The entry point when analysis is skipped: assigns the EP-<slug> ID and seeds .sdlc/ state. Never auto-advances — hands off to the team review gate. Use when the user says "start a new feature/epic" or "author an epic".'
 ---
 
@@ -8,9 +8,9 @@ description: 'Front state for the epic in the gated SDLC. Shape a feature idea w
 **Goal:** Produce a human-authored, AI-assisted `epic.md` for a new feature, and — when the epic is the
 entry point — assign its stable `EP-<slug>` ID and initialise the per-epic state machine in `.sdlc/`.
 This is a **front state**: human-authored with AI assist and **never auto-advances**. When the epic is
-drafted, control passes to `sdlc-review-gate`.
+drafted, control passes to `yad-review-gate`.
 
-**Two entry modes** (the optional `sdlc-author-analysis` step decides which):
+**Two entry modes** (the optional `yad-analysis` step decides which):
 - **Analysis ran** — `.sdlc/state.json` already exists with `currentStep == "epic"`. The epic **reads
   `analysis.md`** as its shaped input and does not re-seed state.
 - **Analysis skipped** (the default) — no `state.json` yet. The epic is the entry point: it shapes the
@@ -40,7 +40,7 @@ exists for the idea.
 
 Either mode runs Step 3b (branch), Step 4 (write the epic), and Step 6 (stop at the gate).
 
-If `state.json` exists but `currentStep != "epic"`, stop and point the user at `sdlc-status` / the gate.
+If `state.json` exists but `currentStep != "epic"`, stop and point the user at `yad-status` / the gate.
 
 ### Step 2 — Shape the idea (assist: analyst) — or read the analysis
 - **Analysis skipped:** ask the user for a one-line feature idea if not provided, then adopt the
@@ -59,14 +59,14 @@ and let it inform which `repos` the epic should touch.
 - **Greenfield-safe:** if `repos.json` is absent or empty, note "no repos connected" and proceed — no
   behaviour change for a project with no code yet.
 - **Staleness:** if a repo's current HEAD (`git -C <path> rev-parse HEAD`) ≠ its registry `syncedHead`,
-  warn and suggest `sdlc repo refresh <repo>` (a human decision — flag and stop, never auto-refresh);
+  warn and suggest `yad repo refresh <repo>` (a human decision — flag and stop, never auto-refresh);
   stamp `code-context: stale` in the frontmatter.
 - **Traceability:** record which maps you loaded in the epic frontmatter `code-context:` field.
-- For depth on a specific area not in the map, do a live on-demand read (see `sdlc-connect-repos`
+- For depth on a specific area not in the map, do a live on-demand read (see `yad-connect-repos`
   `references/code-context.md`) — do not block on it.
 
 ### Step 3 — Generate the Epic ID (engine-assigned, never by hand) — analysis-skipped only
-*(Skip when analysis ran — the ID was already assigned by `sdlc-author-analysis`.)*
+*(Skip when analysis ran — the ID was already assigned by `yad-analysis`.)*
 Derive `EP-<slug>` where `slug` is **2–4 lowercase words joined by hyphens**, drawn from the idea
 (e.g. `EP-istifta-inquiries`). Lowercase except the fixed `EP` prefix. **The ID is assigned once and
 never renamed** — renaming breaks every downstream link (build plan §6b).
@@ -105,7 +105,7 @@ Fill the body with the user; leave `owner` / `technical_product_owner` for the u
 `repos` to the repos this epic will touch.
 
 ### Step 5 — Seed the state machine — analysis-skipped only
-*(Skip when analysis ran — `sdlc-author-analysis` already seeded the 10-step chain. Go to Step 5b.)*
+*(Skip when analysis ran — `yad-analysis` already seeded the 10-step chain. Go to Step 5b.)*
 Create `{project-root}/epics/EP-<slug>/.sdlc/state.json` describing the full **8-step** front-state
 sequence (no analysis), all steps defaulting to `automation: human_approve`, with the four authoring
 steps **locked**. Use this exact shape (see `references/state-schema.md`):
@@ -134,21 +134,21 @@ Notes:
 - Also create an empty approvals ledger `{project-root}/epics/EP-<slug>/.sdlc/approvals.json`
   and an empty comments ledger `{project-root}/epics/EP-<slug>/.sdlc/comments.json`, each containing
   `[]`, and the `reviews/` directory. (`comments.json` is the machine-readable counterpart to the
-  `reviews/*--comments.md` markdown — `sdlc-review-gate` appends to it on every `comment`.)
+  `reviews/*--comments.md` markdown — `yad-review-gate` appends to it on every `comment`.)
 
 ### Step 5b — Advance the authoring step — analysis-ran only
-*(Only when analysis ran — `state.json` already exists from `sdlc-author-analysis`.)*
+*(Only when analysis ran — `state.json` already exists from `yad-analysis`.)*
 In `state.json`: set `epic.status: "done"`, set `epic-review.status: "in_review"`, and set
 `currentStep: "epic-review"`. Write `state.json`. Do **not** re-seed and do **not** touch
 `approvals.json` — only real reviewers approve, through the gate.
 
 ### Step 6 — Stop at the gate (do NOT advance)
 Report: epic ID, the path to `epic.md`, and that the next action is **review** via
-`sdlc-review-gate`. **Never mark the epic-review step approved here** — only real reviewers do that
+`yad-review-gate`. **Never mark the epic-review step approved here** — only real reviewers do that
 through the gate. Front states do not auto-advance. When the hub has a platform, the gate opens a review
-PR on the hub (via `sdlc-hub-bridge`) and `sdlc-review-gate action: sync` pulls platform approvals/
+PR on the hub (via `yad-hub-bridge`) and `yad-review-gate action: sync` pulls platform approvals/
 comments into the ledger; otherwise the review is recorded file-only.
 
 ## Reference
 - State schema and field meanings: `references/state-schema.md`.
-- Connecting code repos + the code-context the brain reads: `../sdlc-connect-repos/SKILL.md`.
+- Connecting code repos + the code-context the brain reads: `../yad-connect-repos/SKILL.md`.

package/skills/{sdlc-author-epic → yad-epic}/references/state-schema.md

@@ -22,15 +22,15 @@ Each `steps[]` entry:
 ### Two valid chain shapes (analysis is optional)
 
 The `analysis` step (and its `analysis-review` gate) is **optional** — it exists only when the team
-ran `sdlc-author-analysis` before the epic. The entry-point skill (whichever runs first) is the one
+ran `yad-analysis` before the epic. The entry-point skill (whichever runs first) is the one
 that assigns `EP-<slug>` and seeds `state.json` + the empty ledgers; the other skill detects an
 existing `state.json` and does **not** re-seed.
 
-- **With analysis** (10 steps — `sdlc-author-analysis` seeded the chain):
+- **With analysis** (10 steps — `yad-analysis` seeded the chain):
   `analysis → analysis-review → epic → epic-review → architecture → architecture-review → ui-design →
   ui-design-review → stories → stories-review`. Seeded `currentStep` is `analysis-review`; `epic`
   starts `blocked`.
-- **Without analysis** (8 steps — `sdlc-author-epic` is the entry point, the default):
+- **Without analysis** (8 steps — `yad-epic` is the entry point, the default):
   `epic → epic-review → … → stories-review`. Seeded `currentStep` is `epic-review`.
 
 After `stories-review` passes, `currentStep` becomes the `ready-for-build` sentinel either way.
@@ -41,7 +41,7 @@ After `stories-review` passes, `currentStep` becomes the `ready-for-build` senti
 Each front **authoring** step opens its own git branch at the start of the step, named
 `<step>/EP-<slug>` where `<step>` ∈ `analysis | epic | architecture | ui-design | stories`
 (`config.yaml` `defaults.front_authoring_branch`). This is **distinct** from the review branch
-`review/EP-<slug>/<artifact-base>` that `sdlc-hub-bridge` opens later for the review PR/MR.
+`review/EP-<slug>/<artifact-base>` that `yad-hub-bridge` opens later for the review PR/MR.
 
 The shared procedure (run once the `EP-<slug>` is known):
 1. **Git-safe / greenfield-safe:** if `{project-root}` is not a git work tree
@@ -66,12 +66,12 @@ Append-only ledger (an array). Each entry:
 { "artifact": "epic.md", "step": "epic-review", "approver": "<name>", "role": "owner|reviewer|domain-owner", "domain": "<repo-or-area, optional>", "status": "approved", "date": "<YYYY-MM-DD>", "source": "<bridge, optional>" }
 ```
 
-`source: "bridge"` marks an approval synced from a hub review PR/MR by `sdlc-review-gate action: sync`
-(via `sdlc-hub-bridge`). Manual approvals omit `source` and are never altered by `sync`.
+`source: "bridge"` marks an approval synced from a hub review PR/MR by `yad-review-gate action: sync`
+(via `yad-hub-bridge`). Manual approvals omit `source` and are never altered by `sync`.
 
 ## `comments.json`
 Append-only ledger (an array), the machine-readable counterpart to the `reviews/*--comments.md` markdown
-("who reviewed/commented", as `approvals.json` is "who approved"). Written by `sdlc-review-gate`'s
+("who reviewed/commented", as `approvals.json` is "who approved"). Written by `yad-review-gate`'s
 `comment` action; feeds the `approved.md` participation roster, not the gate predicate. Each entry:
 
 ```json
@@ -102,7 +102,7 @@ and `<artifact-base>` is the artifact without extension (e.g. `epic`, `architect
 # Phase 4 build-half state (the back half made dial-bearing)
 
 Phase 3 recorded build progress only *after the fact* in `build-log.json`. Phase 4 needs the back
-steps to carry their own `automation` dial so the orchestrator (`sdlc-run`) can read it and decide
+steps to carry their own `automation` dial so the orchestrator (`yad-run`) can read it and decide
 whether to advance on its own. Two new files under `.sdlc/` do this.
 
 ## `build-state/<story-id>.json`
@@ -134,7 +134,7 @@ Each `steps[]` entry:
 | `id` | `spec`, `tasks`, `implement`, `checks`, `engineer-review` | Back-half step identity (the `back_steps` from `config.yaml` + the human merge gate). |
 | `automation` | `human_approve` \| `machine_advance` | Dial 2. Defaults to `human_approve`; flipped to `machine_advance` only after the trust threshold is met (and never for `locked` steps). |
 | `locked` | `true` \| `false` | `engineer-review` is `true` — it never auto-advances (build plan §E). |
-| `status` | `blocked` \| `in_progress` \| `in_review` \| `done` | Lifecycle. `sdlc-run` advances `done` steps and `blocked`s on a halt. |
+| `status` | `blocked` \| `in_progress` \| `in_review` \| `done` | Lifecycle. `yad-run` advances `done` steps and `blocked`s on a halt. |
 
 `currentStep` is the `id` the orchestrator is waiting on / about to run for that repo. The file is
 created when a story enters the build half; all dials start `human_approve` (the `config.yaml`
@@ -170,9 +170,9 @@ base** that decides when a step is safe to automate (build plan Step A). One ent
 
 | Step | Signals | Finalized at (the human gate) |
 |------|---------|-------------------------------|
-| `spec` | `human_edited_spec` | the human who accepts `specs/<story>/` (`sdlc-spec` Step 8) |
-| `tasks` | `task_rescoped` | first consume by `sdlc-implement` (Step 8) |
-| `implement` | `human_edited_diff`, `scope_overrun`, `contract_touch` | engineer review at `sdlc-ship` |
+| `spec` | `human_edited_spec` | the human who accepts `specs/<story>/` (`yad-spec` Step 8) |
+| `tasks` | `task_rescoped` | first consume by `yad-implement` (Step 8) |
+| `implement` | `human_edited_diff`, `scope_overrun`, `contract_touch` | engineer review at `yad-ship` |
 | `checks` | `checks` (`pass`\|`fail`) | the gate run itself (objective) |
 
 **Deriving the provisional verdict** (build plan Step A; extended for `spec`/`tasks` in Phase 4b — the
@@ -184,4 +184,4 @@ same three-way shape, anchored to each step's human gate, never self-graded):
 **Trust threshold** (from `config.yaml` `automation.trust_threshold`): a step is a candidate for
 `machine_advance` only when its slice of `trust-log.json` (same `step`, this story's repo or the
 project) has `>= min_runs` entries AND the fraction with `verdict == "approved-unchanged"` is
-`>= min_approved_unchanged`. The dial-setter in `sdlc-run` enforces this; `sdlc-status` surfaces it.
+`>= min_approved_unchanged`. The dial-setter in `yad-run` enforces this; `yad-status` surfaces it.