ai-driven-dev · alexsoyes · Jul 25, 2026 · Jul 25, 2026 · Jul 25, 2026 · Jul 25, 2026
@@ -17,7 +17,7 @@
     {
       "name": "aidd-dev",
       "source": "./plugins/aidd-dev",
-      "description": "Code transformation: Dev SDLC orchestrator (code-shipping pipeline), plan, assert, audit, review, test, refactor, debug, for-sure. Hosts engineering agents.",
+      "description": "Code transformation: plan, implement, assert, audit, review, test, refactor, debug, for-sure. Hosts engineering agents.",
       "strict": true,
       "recommended": true
     },
@@ -38,9 +38,9 @@
     {
       "name": "aidd-orchestrator",
       "source": "./plugins/aidd-orchestrator",
-      "description": "Async development orchestration: turn ready issues into pull requests, then iterate on review feedback until a human takes over.",
+      "description": "Orchestration: synchronous SDLC code-shipping pipeline and async issue-to-PR automation.",
       "strict": true,
-      "recommended": false
+      "recommended": true
     },
     {
       "name": "aidd-refine",

@@ -1,22 +1,6 @@
+# THIS IS AUTOGENERATED. DO NOT EDIT MANUALLY
 version = 1
 name = "framework"
 
 [setup]
-script = """
-# Guardrail: never move a named branch during setup.
-if [ "$(git rev-parse --abbrev-ref HEAD)" != "HEAD" ]; then
-  echo "Refusing to move a named branch during setup."
-  exit 1
-fi
-
-# Guardrail: only refresh the setup base from a clean worktree.
-if [ -n "$(git status --porcelain)" ]; then
-  echo "Refusing to update setup base: worktree is not clean."
-  git status --short
-  exit 1
-fi
-
-git fetch --prune origin main
-git switch --detach origin/main
-make setup
-"""
+script = ""
@@ -27,8 +27,8 @@ _(Already tested on `Legacy` codebases)_
 The **AI-Driven Dev Framework** installs a working SDLC (Software Development Life Cycle) into your AI coding tool — **skills, agents, commands, rules** — that turns a rough idea into a reviewed, shipped pull request:
 
 ```text
-/aidd-dev:00-sdlc "add rate limiting to the /login endpoint"
-→ spec → plan → implement → review → ship (commit + PR opened)
+/aidd-orchestrator:01-sdlc "add rate limiting to the /login endpoint"
+→ frame when needed → plan → implement → validate → review → challenge → ship
 ```
 
 Why not just write your own commands? → [FAQ](docs/FAQ.md#-why-aidd-instead-of-your-own-skills).
@@ -182,7 +182,7 @@ Three ways in — pick one:
 | --- | --- | --- |
 | 🧭 **Guided onboarding** | `/aidd-context:00-onboard` | First time, or unsure what to run — it inspects the project and routes you. |
 | 🧠 **Project memory** | `/aidd-context:02-project-memory` | Build the project memory bank by hand. |
-| ⚙️ **Feature flow** | `/aidd-dev:00-sdlc` | Ship a feature end to end (plan → implement → review → PR). |
+| ⚙️ **Feature flow** | `/aidd-orchestrator:01-sdlc` | Autonomously ship a feature end to end (frame → deliver → check → PR). |
 
 The full loop, and how onboarding sets it up:
 
@@ -228,9 +228,9 @@ Project init, memory bank, context-artifact generation, diagrams, learning, expl
 
 ### ⚙️ [aidd-dev](plugins/aidd-dev/README.md)
 
-`11 skills` · stable
+`10 skills` · stable
 
-SDLC loop: plan, implement, assert, audit, review, test, refactor, debug.
+Code transformation: plan, implement, assert, audit, review, test, refactor, debug.
 
 </td>
 <td width="33%" valign="top">
@@ -266,9 +266,9 @@ Brainstorm, challenge, condense, shadow-areas, fact-check.
 
 ### 🎼 [aidd-orchestrator](plugins/aidd-orchestrator/README.md)
 
-`1 skill` · stable
+`2 skills` · stable
 
-Async dev: label an issue → get a PR.
+Synchronous feature flow and async issue-to-PR automation.
 
 </td>
 </tr>

@@ -39,10 +39,10 @@ Skills are grouped into plugins by domain. Install only the plugins you need.
 | ----------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------- |
 | aidd-context      | Bootstrap, project init, generation of context artifacts (skills, agents, rules, commands, hooks, plugins, marketplaces), mermaid diagrams, learn, discovery | `02-project-memory`, `03-context-generate`, `09-mermaid`      |
 | aidd-refine       | Meta-cognition: brainstorm, challenge prior work, condensed communication mode     | `01-brainstorm`, `02-challenge`, `03-condense`              |
-| aidd-pm           | Product management: ticket info, user stories, Product Briefs, PRD, spec, spikes     | `01-ticket-info`, `02-user-stories`, `03-prd`, `04-spec`, `05-spike`, `06-product-brief` |
-| aidd-dev          | Code transformation: Dev SDLC orchestrator, plan, implement, assert, audit, review, test, refactor, debug, for-sure | `00-sdlc`, `01-plan`, `02-implement`, `05-review`, `06-test` |
+| aidd-pm           | Product management: ticket info, user stories, Product Briefs, PRD, spec, spikes   | `01-ticket-info`, `02-user-stories`, `03-prd`, `04-spec`, `05-spike`, `06-product-brief` |
+| aidd-dev          | Code transformation: plan, implement, assert, audit, review, test, refactor, debug, for-sure | `01-plan`, `02-implement`, `05-review`, `06-test` |
 | aidd-vcs          | VCS workflows: commit, pull/merge request, release tag, issue creation             | `01-commit`, `02-pull-request`, `04-issue-create`           |
-| aidd-orchestrator | Async orchestration of the SDLC on labeled issues (optional, extra)                | `00-async-dev` (router with setup / run / review sub-flows) |
+| aidd-orchestrator | Synchronous SDLC orchestration and optional async issue-to-PR automation | `00-async-dev`, `01-sdlc` |
 
 > See the [CATALOG](../docs/CATALOG.md) for the exhaustive list of skills and actions.
 
@@ -102,7 +102,8 @@ AIDD is delivered as a plugin marketplace. Pick what you need; do not install ev
 | ------------ | ------------------------------------------------------------------------------------------------------------------- |
 | aidd-context | 00-onboard, 01-bootstrap, 02-project-memory, 03-context-generate, 09-mermaid, 10-learn, 11-explore                    |
 | aidd-refine  | 01-brainstorm, 02-challenge, 03-condense, 04-shadow-areas, 05-fact-check                                            |
-| aidd-dev     | 00-sdlc, 01-plan, 02-implement, 03-assert, 04-audit, 05-review, 06-test, 07-refactor, 08-debug, 09-for-sure         |
+| aidd-dev     | 01-plan, 02-implement, 03-assert, 04-audit, 05-review, 06-test, 07-refactor, 08-debug, 09-for-sure, 10-todo       |
+| aidd-orchestrator | 00-async-dev, 01-sdlc                                                                                         |
 | aidd-vcs     | 01-commit, 02-pull-request, 03-release-tag, 04-issue-create                                                         |
 | aidd-pm      | 01-ticket-info, 02-user-stories, 03-prd, 04-spec, 05-spike, 06-product-brief                                      |
 
@@ -123,15 +124,13 @@ A typical change cycles through skills from several plugins. The order below is
 9. **Ship**: `aidd-vcs:01-commit`, `aidd-vcs:02-pull-request`, then `aidd-vcs:03-release-tag` when the work is in production. File issues with `aidd-vcs:04-issue-create`.
 10. **Refactor and maintain**: `aidd-dev:07-refactor` for performance or security, `aidd-dev:04-audit` for technical-debt sweeps, `aidd-dev:08-debug` to reproduce and fix bugs.
 
-When you want the whole synchronous pipeline run in one go (spec, plan, implementation, finalize), invoke `aidd-dev:00-sdlc`.
+When you want the whole synchronous pipeline run autonomously in one go (frame when needed, plan, implementation, validation, independent review, outcome challenge, finalize), invoke `aidd-orchestrator:01-sdlc`.
 
 ---
 
 ## Optional: Async Automation
 
-Beyond the synchronous path above, `aidd-orchestrator` runs the SDLC asynchronously on labeled issues (webhook or cron). This is extra: most projects do not need it. Use only when you want the AI to pick up `to-implement` issues without a human pressing a key.
-
-Inside the synchronous path, `aidd-dev:00-sdlc` is the Dev SDLC orchestrator that drives spec, plan, implementation, finalize in one go when you want the whole pipeline at once.
+Beyond the synchronous path above, `aidd-orchestrator:00-async-dev` runs the SDLC asynchronously on labeled issues (webhook or cron). This capability is optional. Use it only when you want the AI to pick up `to-implement` issues without a human pressing a key.
 
 ---
 

@@ -18,6 +18,7 @@ flowchart TD
 
     AiddContext --> CtxSkills["skills/ (onboard, bootstrap, project-memory, context-generate, mermaid, learn, discovery)"]
     AiddContext --> CtxHooks["hooks/update_memory.js"]
-    AiddDev --> DevSkills["skills/ (00-sdlc, 01-plan, 02-implement, 03-assert, 04-audit, 05-review, 06-test, 07-refactor, 08-debug, 09-for-sure)"]
-    AiddDev --> DevAgents["agents/ (planner, implementer, reviewer)"]
+    AiddDev --> DevSkills["skills/ (01-plan, 02-implement, 03-assert, 04-audit, 05-review, 06-test, 07-refactor, 08-debug, 09-for-sure, 10-todo)"]
+    AiddDev --> DevAgents["agents/ (executor, checker)"]
+    AiddOrchestrator --> OrchestratorSkills["skills/ (00-async-dev, 01-sdlc)"]
 ```
@@ -0,0 +1,62 @@
+# Review: SDLC orchestration migration
+
+- **Verdict**: approve
+- **Diff**: `origin/next...working-tree`
+- **Axes run**: code, functional, relevancy
+- **Date**: 2026_07_25
+- **Findings**: 0 critical, 0 warning, 0 minor
+
+## Phases
+
+### Phase 1 — Move orchestration
+
+- [x] Register `01-sdlc` in `aidd-orchestrator` — `plugins/aidd-orchestrator/.claude-plugin/plugin.json:10`
+- [x] Remove the former SDLC skill and its action tree from `aidd-dev` — `git diff --name-status origin/next`
+- [x] Attach the orchestrator skill branch to the declared plugin node in the codebase map — `aidd_docs/memory/codebase-map.md:23`
+
+### Phase 2 — Frame the contract
+
+- [x] Enter Frame with `$source` only and resolve a referenced ticket as part of that source — `plugins/aidd-orchestrator/skills/01-sdlc/references/01-frame.md:5`
+- [x] Send a planning-ready source directly to Deliver without mandatory framing work — `plugins/aidd-orchestrator/skills/01-sdlc/references/01-frame.md:36`
+- [x] Call canonical brainstorm and spec providers only for the missing behavior they own — `plugins/aidd-orchestrator/skills/01-sdlc/references/01-frame.md:37`
+
+### Phase 3 — Deliver the candidate
+
+- [x] Produce a proportional plan autonomously and delegate it to one `@aidd-dev:executor` — `plugins/aidd-dev/skills/01-plan/actions/04-plan.md:19`
+- [x] Let the executor own validation repair loops and invoke `/aidd-dev:08-debug` when the cause is unclear — `plugins/aidd-dev/agents/executor.md:16`
+- [x] Include architecture conformance through `/aidd-dev:03-assert` when architecture is documented — `plugins/aidd-orchestrator/skills/01-sdlc/references/02-deliver.md:5`
+- [x] Run the required E2E journey last and return a failure to the executor — `plugins/aidd-orchestrator/skills/01-sdlc/references/02-deliver.md:44`
+- [x] Commit and push validated work through `/aidd-vcs:01-commit` before Check — `plugins/aidd-orchestrator/skills/01-sdlc/references/02-deliver.md:7`
+
+### Phase 4 — Check independently
+
+- [x] Give one fresh checker the contract, plan, committed candidate, and validation reports — `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md:44`
+- [x] Run `/aidd-dev:05-review`, then `/aidd-refine:02-challenge` in the same independent context — `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md:48`
+- [x] Keep pride, confidence, and end-to-end satisfaction gates inside the challenge skill — `plugins/aidd-refine/skills/02-challenge/actions/01-challenge.md:18`
+- [x] Use product and contract findings as the next Frame source — `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md:54`
+- [x] Parallelize independent implementation findings through Todo and keep dependent repairs together — `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md:55`
+- [x] Re-enter Check after every repaired candidate and open the draft PR only without actionable findings — `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md:7`
+- [x] Declare every checker capability with its canonical slash address — `plugins/aidd-dev/agents/checker.md:44`
+
+### Phase 5 — Keep the protocol autonomous and readable
+
+- [x] Make autonomy the default and define the narrow conditions that still require user authority — `plugins/aidd-orchestrator/skills/01-sdlc/SKILL.md:10`
+- [x] Keep the top-level router to Frame, Deliver, and Check without representing the already-invoked SDLC as a node — `plugins/aidd-orchestrator/skills/01-sdlc/SKILL.md:36`
+- [x] State the expected behavior before each routing diagram — `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md:3`
+- [x] Keep all four diagrams top-down, grouped by stage, and visually distinguish skills, agents, artifacts, and zones — `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md:13`
+- [x] Keep orchestration protocols in references rather than restoring an executable action tree — `docs/ARCHITECTURE.md:144`
+- [x] Document orchestrator-authorized bounded Todo fan-out without permitting agent delegation chains — `docs/ARCHITECTURE.md:155`
+- [x] Resolve every canonical provider and agent address used by the SDLC protocol — `plugins/aidd-orchestrator/skills/01-sdlc/references/03-check.md:65`
+
+## Findings
+
+None.
+
+## Verification
+
+| Metric        | Value |
+| ------------- | ----- |
+| Verified      | 100% (24/24) |
+| Files checked | All 35 changed files in `origin/next...working-tree`; four SDLC Mermaid diagrams rendered; five flat distributions built |
+| Unchecked     | none |
+| Unplanned     | none |
@@ -118,15 +118,15 @@ Three rules follow:
 
 ## 🔀 Skills are routers
 
-A skill's `SKILL.md` is a manifest plus an actions table. Claude Code loads the SKILL.md when the skill is invoked; the body decides which action(s) to run.
+A skill's `SKILL.md` is a manifest plus a router. Claude Code loads the SKILL.md when the skill is invoked; the body decides which local action or orchestration protocol to run.
 
 ```mermaid
 ---
 title: skill router pattern
 ---
 flowchart LR
-  User["User: 'Use skill aidd-X:NN-name'"]
-  Skill["SKILL.md (router)"]
+  User["User: '/skill-name'"]
+  Skill["/skill-name"]
   Action1["actions/01-step.md"]
   Action2["actions/02-step.md"]
   ActionN["actions/NN-step.md"]
@@ -141,7 +141,7 @@ flowchart LR
   ActionN --> Out
 ```
 
-Each action is a self-contained markdown file with inputs, outputs, depends-on, process steps, and a test checklist. Actions can call other skills via the `Skill` tool, so a skill discovers a capability it needs at runtime (by matching skill descriptions, never by hardcoded plugin name) and delegates to it.
+Recipe skills route to self-contained actions with inputs, outputs, process steps, and tests. An orchestrator with no domain logic may instead route through numbered reference protocols that define handoffs and delegate the work to capabilities discovered at runtime.
 
 ## 🤖 Skills and agents
 
@@ -152,16 +152,16 @@ Choose by context, not complexity: keep the work visible to the caller → skill
 
 Composition rules:
 
-- **Spawning is an orchestration decision, never a skill's.** A recipe skill never spawns an agent; it runs in the caller's context. Only a high-level orchestrator skill (for example the SDLC) spawns agents, and it decides per step whether to isolate the work in an agent or run the recipe inline.
-- An orchestrator spawns each step as a leaf agent that runs a recipe, or runs the recipe itself when the step needs no isolation. The SDLC owns planning (runs `01-plan` in its own context) and spawns two workers: `executor` (runs `02-implement`) and `checker` (runs `05-review`). The agent is the isolation; the recipe inside it never spawns again.
-- An agent invokes only the recipe skills it declares under `# Skills you may invoke`, never an orchestrator skill, and never reads a skill's files. It names a same-plugin skill by its `plugin:folder` address (deterministic); it names a cross-plugin skill by capability, per cross-plugin orthogonality.
+- **Spawning is authorized by the high-level orchestrator, never invented by a recipe skill.** A recipe skill normally runs in the caller's context. A bounded fan-out capability may mechanically spawn leaf agents only when the orchestrator explicitly delegates that responsibility and retains routing ownership.
+- An orchestrator spawns each isolated step as a leaf agent that runs a recipe, or runs the recipe itself when isolation is unnecessary. The SDLC owns planning, delegates delivery to `executor`, and delegates independent judgments to a fresh `checker`. For independent repair findings, it may explicitly delegate bounded fan-out to `10-todo`; Todo's leaf executors return their results to the SDLC. A recipe invoked inside an agent never spawns again.
+- An agent invokes only the recipe skills it declares under `# Skills you may invoke`, never an orchestrator skill, and never reads a skill's files. It names every skill by its canonical `/plugin:folder` address so its permissions are explicit and auditable.
 - An agent never delegates flow work to another agent and never invokes an orchestrator skill. It may spawn a read-only recon helper (for example `Explore`) that mutates nothing and spawns nothing. So the write path stays two layers deep and delegation can never cycle.
 
 ## 🔗 Cross-plugin orthogonality
 
-Plugins never reference each other by name — **orchestrators included**. When skill A needs a capability skill B owns, it discovers a candidate at runtime through description matching, never a hardcoded `aidd-<plugin>:…` address. This keeps the marketplace forkable, the plugins swappable, and the docs maintainable.
+Recipe skills never hardcode a sibling provider. They discover cross-plugin capabilities at runtime through description matching. Agent permission lists and orchestration references are responsibility maps, so they name the current provider with its canonical `/plugin:folder` or `@plugin:agent` address. The orchestrator must verify that provider is installed before calling it.
 
-The rule is social (PR template checklist), not yet mechanically enforced — a lefthook grep for cross-plugin literals would catch violations (an orchestrator hardcoding a sibling skill name still slips through today).
+This distinction keeps recipe plugins swappable while making orchestration handoffs explicit and auditable.
 
 ## 🔎 See also