ai-delivery-workflow 0.2.2

package/skills/ai-delivery-orchestrate/assets/project-template/.workflow/tools/viewer/start.cmd

@@ -0,0 +1,4 @@
+@echo off
+setlocal
+node "%~dp0server.mjs" %*
+endlocal

package/skills/ai-delivery-orchestrate/assets/project-template/.workflow/tools/viewer/start.ps1

@@ -0,0 +1,2 @@
+$ErrorActionPreference = "Stop"
+node (Join-Path $PSScriptRoot "server.mjs") @args

package/skills/ai-delivery-orchestrate/assets/project-template/.workflow/tools/viewer/start.sh

@@ -0,0 +1,4 @@
+#!/usr/bin/env sh
+set -eu
+SCRIPT_DIR=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)
+exec node "$SCRIPT_DIR/server.mjs" "$@"

package/skills/ai-delivery-orchestrate/assets/project-template/AGENTS.md

@@ -0,0 +1,44 @@
+# AI 研发交付说明
+
+## 双仓工作区强制规则
+
+- `.workflow/config/workspace.yaml` 所在目录是工作流 Git 仓库；只允许从其中 `code_repository.path` 解析唯一代码 Git 仓库。
+- 工作流仓库跟踪 `.workflow/`、项目级 Skills、共享任务分片、checkpoint、审批和 Manifest，并精确忽略代码子目录。代码仓库独立跟踪源码、自动化测试、代码分支和代码 Tag。
+- 所有 `line/*`、`version/*`、`work/*`、`release/*`、`release-fix/*`、`hotfix/*`、代码 `main` 和 `version-ready/*` 操作只能在代码仓库执行。`workflow-ready/*` 只能在工作流仓库创建。
+- 本机 runtime 不存在且下一动作属于 `agent` 时，由 `recover` 从 `.workflow/control/tasks/` 和最新共享 checkpoint 恢复；`user/external` 等待态保持只读，收到输入后由 `activate` 原子恢复并转交。若本机与共享 revision 或语义 checksum 冲突则停止。只有显式 `task-state.mjs publish --task-id <id> --push` 才允许推送共享状态。
+- 代码引用必须包含 `repo_id`、`code_commit`、可选 `code_tag`、`source_path` 和 SHA-256。版本发布身份必须同时核验代码 Tag、工作流 Tag 和 Manifest checksum。
+- 根 `.gitattributes` 必须保持安装器写入的工作流 `eol=lf` 规则，避免跨平台 checkout 改变受控物料字节和 checksum；该规则不得扩展到嵌套代码仓。
+
+开始工作前：
+
+1. 只使用安装在 `.agents/skills/` 下的项目级 Skill，不得在全局安装或更新本工作流。
+1.1 用户说“开始”“继续”“下一步”“现在做到哪了”、直接描述需求或明确提出发布，都属于有效自然语言入口。AI 必须自主规划并调用所需 Skill 和项目内 CLI，不得要求用户输入 Skill 名称或执行工作流命令；只向用户询问业务事实、物料确认、人工 Gate 或外部副作用授权。
+2. 首次进入项目或重启会话时，先使用 `$ai-delivery-bootstrap`，并在项目根运行 `node .workflow/tools/bootstrap/bootstrap.mjs inspect` 只读识别状态。空项目进入需求发现，存量代码项目生成草稿上下文，中断任务进入 checkpoint 恢复，不一致状态停止并报告。
+2.1 已完成 `init` 且没有正式交付物和 task shard 时，先运行项目内 `bootstrap` 入口生成上下文，再以 `INIT-0001` 建立 `TASK-INIT-0001-00`（Bootstrap）和依赖它的 `TASK-INIT-0001-01`（产品发现）。首次业务问题之前必须已有合法任务身份；不得从聊天记忆临时编造下一任务。
+3. 修改代码或交付物前，先读取 Bootstrap 返回的 `runtime.next_action_owner`。仅当责任方为 `agent` 时，运行 `$ai-delivery-checkpoint-task recover --iteration-id <iteration-id>`，只继续返回的 `recommended_task_id`，并通过 `task-state.mjs activate` 激活任务。责任方为 `user` 时，只原样询问记录的单个业务问题，禁止 recover、activate、checkpoint、正式状态、物料或 Git 写入；责任方为 `external` 时，只报告等待条件。收到所需输入后，必须通过 `activate` 同时提供 `--next-action-owner agent` 和新的幂等 `--next-action`，由 CLI 在需要时从共享 shard 原子恢复本机 runtime 并转交责任方。
+4. 任务、checkpoint、恢复状态、活动任务标记和版本归档只能由 `.agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs` 修改。
+5. 正式流程、物料和 Gate 状态只能由 `node .workflow/tools/state/state.mjs ...` 修改。禁止直接编辑 `.workflow/delivery/workflow-state.yaml`、`.workflow/delivery/artifact-registry.yaml` 和 `.workflow/delivery/state-events.jsonl`。
+5.1 研发 scope 使用 `iteration-started`，发布 scope 仅在用户明确发布后使用 `release-started`；两者可并行且不得互相重置。节点必须满足流程图前置条件、成功证据和当前尝试的强制 Gate。
+6. 状态脚本失败时必须停止并修复输入、revision 冲突或脚本问题，不得手工修改受控文件绕过失败。
+7. 每次状态变更前运行 `inspect` 获取当前 revision；每次节点交接、版本收尾、生产审批、部署和发布归档前运行 `verify`。
+8. 读取 `.workflow/standards/index.yaml`，只加载适用于当前任务且状态为 `approved` 的规范。
+9. 应用 `STD-DOC-LANG-001`：面向人阅读的交付文档默认使用简体中文；技术标识、Schema、命令、路径、协议值和引用原文保持不变。
+10. 应用 `STD-ARTIFACT-PATH-001`：研发流程文档写入 `.workflow/`；计划版本产物写入 `.workflow/iterations/<version-id>/<node-id>/`；独立发布产物写入 `.workflow/releases/<release-id>/<release-node>/`；不得忽略整个 `.workflow/`。
+11. 应用 `STD-TEST-LOCATION-001`：应用测试使用代码仓库既有框架和原生测试位置，不写入 `.workflow/`；临时测试输出按代码仓库规则忽略，不得登记为正式交付物。
+12. 每个交付物记录实际应用的规范 ID 和版本。已登记物料发生变更时创建新 ID，并使用 `--supersedes` 关联旧版本，不得覆盖旧版本。
+13. 一个任务组开始前，将全部已知任务按 `sequence` 和 `depends_on` 登记为 `queued`。每个任务用 `next_action_owner: agent | user | external` 明确下一动作责任方；重复 evidence 必须保持唯一。激活推荐任务后，在有意义的里程碑写入 checkpoint，并在交还控制权前结束当前任务状态。
+13.1 `task-state.mjs` 会从权威 `.workflow/config/workspace.yaml` 解析嵌套代码仓并写入 `code_branch`、`code_commit`；不得从安装清单副本推断代码路径，也不得把工作流分支或工作流提交作为代码身份。`blockers` 只保存当前未解决阻塞，解除阻塞后必须通过脚本切换状态并清空当前列表。
+14. Hook 日志只用于脱敏审计和心跳，不得作为任务完成、Gate 批准或正式交付物的替代品，也不得修改正式或 runtime 状态。
+15. 研发流程在 `12-version-closeout` 结束。登记 `release-ready` 收尾物料、完成节点并验证不可变身份后，必须通过正式状态 CLI 的 `version-closed` 事件更新累计研发版本，再归档任务上下文；不得直接编辑状态文件，也不得因为版本完成而自动发布。
+16. 后续计划版本必须从最新 `line/<product-id>` 开始；`main` 始终表示当前生产验证成功历史。
+17. 只有用户明确提出发布并选择截止版本时，才使用 `$ai-delivery-orchestrate-release`。系统必须计算从当前生产版本到目标版本的连续闭包。
+18. 同版本重新发布必须创建新 release ID，并重新执行环境快照、验证和生产审批。R09 只向 R10 交付已验证生产身份；R10 登记 `released` 归档物料并完成节点后，必须通过 `release-archived` 事件更新生产版本和 release ID。历史版本恢复通过旧镜像 digest，不创建 rollback 分支。
+19. 不得绕过流程 Gate、修改已批准基线、推断缺失批准，或在恢复后自动重放生产动作。
+20. 版本任务归档的权威位置是 `.workflow/control/archives/versions/<version-id>/`。归档完成后不得把对应任务或 checkpoint 留在活动集合，普通恢复不得加载归档详情。
+21. 需要人工浏览工作流和物料时，在项目根目录运行 `.\.workflow\tools\viewer\start.cmd`（Windows）或 `sh ./.workflow/tools/viewer/start.sh`（macOS/Linux）。查看器是可删除、可由 `init` 重装的只读工具，其缺失不影响工作流运行。
+## 项目级工作流自进化
+
+- 用户明确提出工作流意见或建议时，使用 `$ai-delivery-evolve-workflow` 记录脱敏反馈并返回反馈 ID；普通讨论和 AI 推测不得冒充用户反馈。
+- `.workflow/evolution/`、`.workflow/extensions/` 的治理状态只能由 `node .workflow/tools/evolution/evolve.mjs ...` 修改。不得直接编辑索引或以放入文件代替注册、校验、批准和启用。
+- 自进化只在任务完成、版本收尾或显式 review 安全点评估，并从下一任务或下一版本生效。它不得修改受管 Skill、正式状态 CLI、Hook、人工 Gate 或已批准项目规范。
+- 风险优先级为核心安全与 Gate、已批准规范、人工批准扩展、自动 trial 扩展。中高风险、Node 脚本和 `block` 必须绑定扩展版本 checksum 的明确人工批准。

package/skills/ai-delivery-orchestrate/references/formal-state-contract.md

@@ -0,0 +1,64 @@
+# Formal State Contract
+
+## Authority
+
+Portable active task and checkpoint authority is sharded by task under `.workflow/control/tasks/` and `.workflow/control/checkpoints/`. Closed versions move to `.workflow/control/archives/versions/<version-id>/`; normal recovery scans only active collections and explicit audit reads the archive. Local `.workflow/delivery/runtime/` contains only non-portable execution state and optional detailed archive copies.
+
+Use `.workflow/tools/state/state.mjs` as the only writer for:
+
+- `.workflow/delivery/workflow-state.yaml`;
+- `.workflow/delivery/artifact-registry.yaml`;
+- `.workflow/delivery/state-events.jsonl`.
+
+Use `.agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs` as the only writer for runtime task snapshots, checkpoints, recovery state, and version archives. Hooks may append their own redacted lifecycle records but may not infer task, artifact, Gate, node, candidate, release, or deployment completion.
+
+Do not edit controlled files directly, including after a command error. Inspect, repair the cause, and rerun with the newly observed revision.
+
+## Commands
+
+Run from the project root:
+
+```text
+node .workflow/tools/state/state.mjs inspect
+node .workflow/tools/state/state.mjs verify
+node .workflow/tools/state/state.mjs rebuild
+node .workflow/tools/state/state.mjs artifact register --expected-revision <revision> --id <artifact-id> --artifact-type <type> --path <.workflow/path> --node <node-id> --status <status> --version <version> --producer-skill <skill>
+node .workflow/tools/state/state.mjs artifact register --expected-revision <revision> --id <new-id> --path <.workflow/path> --node <node-id> --status <status> --supersedes <old-id>
+node .workflow/tools/state/state.mjs artifact status --expected-revision <revision> --id <artifact-id> --status <status> --evidence <reference>
+node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event node-started --iteration-id <iteration-id> --node <node-id>
+node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event release-started --iteration-id <release-id>
+node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event node-completed --iteration-id <iteration-id> --node <node-id> --evidence <artifact-id>
+node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event version-closed --iteration-id <version-id> --artifact-id <closeout-artifact-id>
+node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event release-archived --iteration-id <release-id> --artifact-id <archive-artifact-id> --production-version-id <version-id>
+node .workflow/tools/state/state.mjs gate request --expected-revision <revision> --gate-id <gate-id> --iteration-id <iteration-id> --node <node-id> --evidence <artifact-id>
+node .workflow/tools/state/state.mjs gate decide --expected-revision <revision> --gate-id <gate-id> --decision <decision> --actor <actor-id> --rationale <text> --evidence <artifact-id>
+```
+
+Repeat `--evidence` for multiple evidence IDs. Use `iteration-started` only for development and `release-started` only after explicit user release intent. Other events are `node-started`, `node-completed`, `node-blocked`, `node-unblocked`, `candidate-selected`, `release-selected`, `version-closed`, and `release-archived`.
+
+`workflow-state.yaml` schema 2 owns independent `development_state` and `release_state` objects. Each has its own scope ID, revision, node collections, Gate collections, node attempts, and selected identities. The top-level revision remains the serialized audit-stream revision. A release may advance while later cumulative development is active; neither scope resets the other.
+
+`version-closed` requires completed `12-version-closeout` and a registered `release-ready` artifact from that node; it is the only writer of `latest_line_version_id`. `release-archived` requires completed `R10-release-archive`, a registered `released` artifact from that node, and `--production-version-id`; it is the only writer of `production_version_id` and `production_release_id`. These identities live in the audited `workflow-state.yaml`; descriptive or legacy compatibility fields in `project.yaml` are not authoritative.
+
+New development work uses nodes `00-bootstrap` through `12-version-closeout`; independent release work uses `R00-release-request` through `R10-release-archive`. Legacy nodes `12-release-preparation` through `16-version-archive` are accepted only when registering or reading historical artifacts; transition and Gate commands reject them as read-only. Use artifact statuses `release-ready` for a closed unpublished version and `included-in-release` when a specific release has consumed that immutable version manifest.
+
+## Mutation Order
+
+1. Recover and activate the runtime task.
+2. Write and validate the artifact in `.workflow/`.
+3. Inspect formal state and capture both revisions.
+4. Register the artifact or change its status.
+5. Request and decide every required Gate with explicit actor, rationale, and registered evidence.
+6. Transition the node only after graph prerequisites are satisfied by current-scope completion or successful registered baseline evidence, completion evidence has an allowed success status, mandatory Gates for the current node attempt pass, and no Gate remains pending.
+7. Run `verify`.
+8. Checkpoint or finish the runtime task with the resulting IDs and revisions.
+
+Every mutation uses optimistic concurrency through `--expected-revision`. A revision conflict means another writer won; inspect and reconcile before choosing a new command.
+
+## Integrity
+
+The CLI uses one shared formal-state lock, atomic replacement, SHA-256 artifact checksums, and append-style JSONL audit events. The shared lock serializes both revision streams so concurrent workflow and registry commands cannot overwrite each other's audit append. `verify` checks schemas, revisions, both scope identities, node-state exclusivity, artifact identity and path uniqueness, `.workflow/` path containment, artifact checksums, audit revision continuity, and the last audit checksum for each formal stream.
+
+Formal approval is never inferred. A Gate decision requires an explicit actor, rationale, and registered evidence. A Hook event, chat message, file timestamp, UI state, or successful command alone is not approval.
+
+Version completion never implies release intent. Registering a `release-ready` artifact or completing `12-version-closeout` must not create an R-node transition. `R00-release-request` requires successful evidence registered on R00 with `artifact_type: release-request`. Mandatory Gate IDs are `GATE-A`, `GATE-B`, `UX-LF`, `UX-VS`, `UX-UI`, and `PRODUCTION-APPROVAL`. Only a genuinely non-visual experience scope may use `not-required` for a UX Gate; the decision must retain its experience evidence and add successful `02-product-definition` evidence whose artifact type contains `terminal` (the canonical type is `product-terminal-scope`). Gate A, Gate B, and production approval require `approved`.

package/skills/ai-delivery-orchestrate/references/workflow-model.md

@@ -0,0 +1,29 @@
+# Workflow Model
+
+## Installation And State
+
+Install all delivery Skills under `.agents/skills/`, keep Hook configuration in `.codex/config.toml`, and write durable workflow documents under `.workflow/`. Formal state is mutated only by `.workflow/tools/state/state.mjs`; runtime tasks are mutated only by `task-state.mjs`.
+
+Formal state schema 2 separates `development_state` from `release_state`. The two scopes own independent IDs, revisions, nodes, Gates, and selections while sharing only the serialized audit revision and cumulative/production identities. Start them with `iteration-started` and `release-started` respectively. Release activity never prevents the next cumulative development version from starting.
+
+## Development State Machine
+
+`00-bootstrap -> 01-product-discovery -> 02-product-definition -> 03-architecture-initial -> 04-experience-design(UX-LF -> UX-VS -> UX-UI) -> 02-product-definition(prototype-reconciliation) -> 05-architecture-reconcile -> 07-iteration-planning -> 08-test-design -> 09-development -> 10-change-review -> 11-candidate-verification -> 12-version-closeout -> release-ready`
+
+Start `06-platform-preparation` after initial architecture and join it before candidate verification. Closeout creates an immutable version-ready Tag, advances `line/<product-id>`, archives closed version tasks, and stops. It never changes `main` or starts a release.
+
+The state CLI enforces graph prerequisites. A later iteration may satisfy an unaffected prerequisite with a registered successful baseline artifact instead of replaying the node. Reopening a completed node requires an explicit reason and creates a new node attempt, so prior Gate decisions cannot silently approve revised output.
+
+## Independent Release State Machine
+
+`R00-release-request -> R01-version-selection -> R02-release-eligibility -> R03-material-aggregation -> R04-release-candidate -> R05-release-verification -> R06-release-preparation -> R07-production-approval -> R08-production-deployment -> R09-production-verification -> R10-release-archive`
+
+Only explicit user release intent may create R00. The user selects a cumulative target version. The system computes the continuous range after current production through that target and blocks gaps, stale candidates, backward targets, or divergence on any adjacent code or workflow commit edge. Same-version redeploy is permitted with a new release ID and fresh snapshots, verification, and approval.
+
+## Gates And Transition Rules
+
+Retain discovery Gate A, product Gate B, major architecture decisions, prototype tool selection, mandatory human `UX-LF`/`UX-VS`/`UX-UI`, standard governance, and exact-package production approval. Product reconciliation after all prototype candidates must be `valid/aligned`; intermediate handoffs use downstream contract validation.
+
+Advance only from immutable referenced inputs. Mark dependents stale after upstream change. Preserve failed candidates, releases, Tags, and deployment records. Treat image rollback as deployment state, never Git state. On restart reconcile workspace, Git, artifacts, and external systems; never automatically replay production actions.
+
+Legacy nodes `12-release-preparation` through `16-version-archive` remain readable only for historical audit compatibility and are not used for new work.

package/skills/ai-delivery-orchestrate-release/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: ai-delivery-orchestrate-release
+description: Orchestrate a production release independently from iteration delivery by recording an explicit user request, selecting a release-ready cumulative target version, routing release eligibility, material assembly, verification, preparation, human approval, deployment, production verification, and archive. Use only when the user explicitly asks to publish, release, deploy completed versions, or resume an existing R00-R10 release.
+---
+
+# Orchestrate Independent Release
+
+Coordinate `R00` through `R10`. Never infer release intent from completed versions or start production work from normal iteration orchestration.
+
+## Start From Explicit Intent
+
+1. Inspect formal state and list eligible cumulative target versions with production and development-line context.
+2. Require the user-selected target version. Record `release_id`, actor, rationale, target environment, current production version, and target version in `.workflow/releases/<release-id>/R00-release-request/`; register it on R00 with successful status and `artifact_type: release-request` before starting the node.
+3. Run the formal `release-started` transition for that release ID. It initializes only `release_state` and must leave an active or completed `development_state` unchanged.
+4. Permit `same-version-redeploy` when target equals production, but create a new release ID and require fresh environment capture, verification, and production approval.
+5. Reject a target older than production. Route historical restoration to immutable-image rollback rather than release or Git history changes.
+
+## Route Release Nodes
+
+1. `R01-version-selection`: invoke `$ai-delivery-assemble-release` to calculate and freeze the version selection.
+2. `R02-release-eligibility`: require continuous lineage, immutable tags, eligible artifacts, every adjacent code and workflow ancestry edge, available images, compatible migrations/configuration, and no stale candidate.
+3. `R03-material-aggregation`: aggregate checksummed requirements, architecture, prototypes, code, images, configuration, migrations, tests, risks, operations, and rollback materials.
+4. `R04-release-candidate`: create `release/<release-id>-<slug>` from the exact target `version-ready` tag and freeze a release candidate.
+5. `R05-release-verification`: invoke `$ai-delivery-verify-candidate` with `scope: release`.
+6. `R06-release-preparation`: invoke `$ai-delivery-prepare-release` for the selected version closure.
+7. `R07-production-approval`: request mandatory Gate `PRODUCTION-APPROVAL`, bound to the exact package checksum and target environment. It cannot be waived with `not-required`.
+8. `R08-production-deployment`: invoke `$ai-delivery-deploy-production` only after approval.
+9. `R09-production-verification`: invoke `$ai-delivery-verify-production` and decide `released` or rollback/recovery.
+10. `R10-release-archive`: register the final archive artifact as `released`, complete R10 with that artifact as evidence, tag the released commit, then run `state.mjs transition --expected-revision <revision> --event release-archived --iteration-id <release-id> --artifact-id <archive-artifact-id> --production-version-id <version-id>`. Verify the formal state before compacting release task context. Never edit production identity fields directly.
+
+Run formal `verify` at every handoff. Preserve failed releases and evidence. Stop instead of replaying a production action after recovery.
+
+Read [release-workflow-contract.md](references/release-workflow-contract.md) and use the request and selection assets.

package/skills/ai-delivery-orchestrate-release/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Orchestrate Release"
+  short_description: "Publish selected cumulative versions on demand"
+  default_prompt: "Use $ai-delivery-orchestrate-release to start or resume an explicit production release."

package/skills/ai-delivery-orchestrate-release/assets/release-request.yaml

@@ -0,0 +1,9 @@
+schema_version: 1
+release_id: "REL-0001"
+product_id: "PRODUCT-001"
+requested_by: "human:<id>"
+rationale: "<release reason>"
+target_environment: "production"
+current_production_version: "VER-0002"
+target_version: "VER-0005"
+requested_at: "<RFC3339>"

package/skills/ai-delivery-orchestrate-release/assets/version-selection.yaml

@@ -0,0 +1,16 @@
+schema_version: 1
+release_id: "REL-0001"
+mode: "incremental"
+current_production_version: "VER-0002"
+target_version: "VER-0005"
+newly_included_versions:
+  - "VER-0003"
+  - "VER-0004"
+  - "VER-0005"
+dependency_closure:
+  - "VER-0001"
+  - "VER-0002"
+  - "VER-0003"
+  - "VER-0004"
+  - "VER-0005"
+selection_frozen_at: "<RFC3339>"

package/skills/ai-delivery-orchestrate-release/references/release-workflow-contract.md

@@ -0,0 +1,11 @@
+# Independent Release Workflow Contract
+
+The development state machine ends at `12-version-closeout`. Only an explicit user request creates `R00-release-request`.
+
+Each release owns `.workflow/releases/<release-id>/R00-release-request/` through `R10-release-archive/`. Every node consumes registered immutable inputs and registers versioned outputs. Release IDs are unique even when the target commit and image digest were previously deployed.
+
+For an incremental release, `newly_included_versions` is the ordered open interval after current production through the selected target. `dependency_closure` is the complete cumulative lineage from the first version through the target. For a same-version redeploy, the newly included range is empty while the target version remains the immutable provenance source.
+
+Only `R07-production-approval` is the production human Gate. Any package, environment, configuration, migration, image, or target change invalidates it. Rollback restores the previous compatible image digest and never creates or moves a Git branch.
+
+`R09-production-verification` supplies the verified deployed version and immutable evidence but does not update the authoritative production identity. After a `released` archive artifact is registered and `R10-release-archive` is completed, run the formal `release-archived` transition. This event is the only writer of `workflow-state.yaml.production_version_id` and `production_release_id`, including same-version redeploys with a new release ID.

package/skills/ai-delivery-plan-iteration/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: ai-delivery-plan-iteration
+description: Plan an agile AI delivery iteration by prioritizing business outcomes and sequencing independently verifiable vertical slices. Use after architecture reconciliation, when starting or replanning an iteration, after test or production feedback, or when scope, dependencies, risks, or release priorities change.
+---
+
+# Plan Iteration
+
+Plan business capability increments. Do not pre-split work into fixed frontend, backend, database, or human-role silos.
+
+## Artifact Location
+
+Write every workflow document produced by this skill under project `.workflow/`, defaulting version-scoped planning outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Do not relocate source code, automated test source, repository configuration, or non-document build artifacts.
+
+## Task State
+
+1. Invoke `$ai-delivery-checkpoint-task` before preflight to recover or initialize the task snapshot.
+2. Checkpoint after every meaningful artifact, gate, validation, merge, deployment action, or other external milestone, and before compaction or interruption.
+3. Before returning, finish the snapshot as `completed`, `blocked`, `failed`, or `interrupted`, with actual outputs, evidence, blockers, and one idempotent next action. A Hook event alone never proves completion.
+
+## Preflight
+
+Read approved product, final architecture, and experience baselines; exact `ui-handoff.yaml`; aligned `product-prototype-reconciliation.yaml`; experience/requirement change sets; interaction, visual, component, and page-component contracts; the confirmed prototype set and accepted architecture receipts; current backlog; production state; applicable standards; and unresolved risks. Require `development_readiness: ready-for-development` and reject stale changes, missing receipts, non-passing decisions, or identity/checksum mismatches. Distinguish product priority from technical execution order.
+
+## Workflow
+
+1. Build or update the product backlog from stable feature, story, and acceptance IDs.
+2. Rank items by business value, urgency, user impact, risk reduction, and learning value.
+3. Map feature dependencies and architecture constraints.
+4. Slice work vertically so each slice produces independently testable user or operational value.
+5. Define MVP or planned-version scope, cumulative version order, allowed concurrency, and risk probes. Do not assume any completed version will be published immediately.
+6. Prefer high-value, high-risk, and early-feedback slices while respecting prerequisites.
+7. Define entry criteria, completion criteria, and measurable iteration outcomes.
+8. Attach the exact prototype-set identity/checksum, relevant member identity/revision/checksum, management/review/impact checksums, and stable page/canvas/file/element IDs to every UI-bearing slice in `slice-prototype-traceability.csv`.
+9. Map every actionable `added`, `modified`, `retired`, or `superseded` row to a selected slice in `slice-experience-change-traceability.csv`. Preserve its phase status and implementation/test impact; do not schedule `proposed`, `blocked`, or `stale` changes.
+10. Record deviations when technical sequence delays a higher business priority; request human approval only if release scope or an approved product decision changes.
+11. Replan after verified feedback rather than preserving stale dates or task lists.
+
+## Outputs
+
+- `backlog.csv` with business priority and rationale;
+- `vertical-slices.csv`;
+- `slice-dependencies.csv`;
+- cumulative planned-version roadmap and explicit dependency order;
+- risk probes and assumptions;
+- definition of ready and definition of done;
+- product-to-iteration traceability;
+- `slice-prototype-traceability.csv` for UI-bearing work;
+- `slice-experience-change-traceability.csv` showing which added/modified/retired experience changes enter each slice;
+- replanning rules and current plan baseline.
+
+Do not output component-level technical tasks. The development orchestrator derives those just in time from a selected slice and the latest architecture.
+
+Read [planning-contract.md](references/planning-contract.md) and use `assets/planning-template/` for a new iteration.
+
+## Handoff
+
+Send the next selected vertical slice and its approved sources to `$ai-delivery-design-tests`.

package/skills/ai-delivery-plan-iteration/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Plan Iteration"
+  short_description: "Prioritize and sequence vertical slices for an agile iteration"
+  default_prompt: "Use $ai-delivery-plan-iteration to plan the next agile delivery iteration."

package/skills/ai-delivery-plan-iteration/assets/planning-template/backlog.csv

@@ -0,0 +1 @@
+backlog_id,source_type,source_id,title,business_priority,value,urgency,risk_reduction,learning_value,release_scope,status,rationale

package/skills/ai-delivery-plan-iteration/assets/planning-template/slice-dependencies.csv

@@ -0,0 +1 @@
+predecessor_slice_id,successor_slice_id,dependency_type,rationale

package/skills/ai-delivery-plan-iteration/assets/planning-template/slice-experience-change-traceability.csv

@@ -0,0 +1 @@
+slice_id,experience_change_id,change_type,phase_status,implementation_impact,test_impact

package/skills/ai-delivery-plan-iteration/assets/planning-template/slice-prototype-traceability.csv

@@ -0,0 +1 @@
+slice_id,prototype_artifact_id,prototype_version,source_revision,prototype_file_id,canvas_id,page_id,prototype_element_id

package/skills/ai-delivery-plan-iteration/assets/planning-template/slice-sources.csv

@@ -0,0 +1 @@
+slice_id,source_type,source_id

package/skills/ai-delivery-plan-iteration/assets/planning-template/vertical-slices.csv

@@ -0,0 +1 @@
+slice_id,iteration_id,title,user_or_operational_outcome,entry_criteria,done_criteria,risk,sequence,status

package/skills/ai-delivery-plan-iteration/references/planning-contract.md

@@ -0,0 +1,40 @@
+# Planning Contract
+
+## Backlog
+
+`backlog.csv`:
+
+`backlog_id,source_type,source_id,title,business_priority,value,urgency,risk_reduction,learning_value,release_scope,status,rationale`
+
+## Vertical Slices
+
+`vertical-slices.csv`:
+
+`slice_id,iteration_id,title,user_or_operational_outcome,entry_criteria,done_criteria,risk,sequence,status`
+
+`slice-sources.csv`:
+
+`slice_id,source_type,source_id`
+
+`slice-dependencies.csv`:
+
+`predecessor_slice_id,successor_slice_id,dependency_type,rationale`
+
+Use dependency types `blocks`, `enables`, and `validates`.
+
+`slice-prototype-traceability.csv`:
+
+`slice_id,prototype_artifact_id,prototype_version,source_revision,prototype_file_id,canvas_id,page_id,prototype_element_id`
+
+`slice-experience-change-traceability.csv`:
+
+`slice_id,experience_change_id,change_type,phase_status,implementation_impact,test_impact`
+
+## Rules
+
+- Preserve business priority from product sources.
+- Use technical constraints to choose sequence, not to silently redefine priority.
+- Prefer thin end-to-end behavior over horizontal frontend/backend layers.
+- Pin the ready UI handoff, aligned product reconciliation, experience-change set, confirmed prototype-set ID/version/checksum and every relevant member `prototype_artifact_id`, version, `source_revision`, `review_bundle_checksum`, tool-selection checksum, page/canvas/file catalog checksums, review/adjustment checksums, and impact-assessment checksum in the iteration plan. Map UI-bearing slices to individual experience-change and page/canvas/file/element rows without delimiter-packed CSV fields. Schedule only `ready-for-development` changes.
+- Describe affected component scope only at planning time; defer technical tasks and roles to development.
+- Replan from verified evidence and record scope-impact decisions.

package/skills/ai-delivery-prepare-platform/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: ai-delivery-prepare-platform
+description: Prepare the delivery and operations platform required to build, test, observe, release, and roll back an application. Use after initial architecture, when environments or CI/CD are missing, when infrastructure or configuration changes, or when candidate verification requires a reproducible test environment.
+---
+
+# Prepare Delivery Platform
+
+Run as a parallel stream after initial architecture and join application development before independent candidate verification.
+
+## Artifact Location
+
+Write every platform plan, configuration inventory, environment ledger, readiness report, and workflow document under project `.workflow/`, defaulting version-scoped outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Infrastructure source and executable configuration remain in architecture-defined repository locations and are referenced by path, version, and checksum.
+
+## Task State
+
+1. Invoke `$ai-delivery-checkpoint-task` before preflight to recover or initialize the task snapshot.
+2. Checkpoint after every meaningful artifact, gate, validation, merge, deployment action, or other external milestone, and before compaction or interruption.
+3. Before returning, finish the snapshot as `completed`, `blocked`, `failed`, or `interrupted`, with actual outputs, evidence, blockers, and one idempotent next action. A Hook event alone never proves completion.
+
+## Preflight
+
+Read initial and final architecture as available, deployment topology, stack manifest, quality targets, security standards, current environment baselines, and iteration scope. Treat cloud, paid-service, privacy, and hard-to-reverse infrastructure changes as major architecture decisions.
+
+## Workflow
+
+1. Determine actual platform capabilities required by architecture and the current iteration; do not create irrelevant infrastructure.
+2. Implement reproducible build and artifact management, CI/CD, environment definitions, configuration and secret references, infrastructure as code, migrations, health checks, observability, backups, and rollback automation.
+3. Build test and staging environments from versioned definitions.
+4. Validate migration ordering, backward compatibility, old-image rollback compatibility, configuration safety, and environment parity.
+5. Exercise deployment and rollback outside production.
+6. Record environment-specific differences without using Git branches to represent environments.
+
+## Outputs
+
+- build and CI/CD definitions;
+- immutable artifact and registry conventions;
+- IaC and environment baselines;
+- configuration key and secret-reference catalogs without secret values;
+- migration and rollback procedures;
+- logs, metrics, traces, dashboards, alerts, health checks, and SLO support;
+- backup and recovery evidence;
+- reproducible test-environment evidence;
+- platform change and risk records.
+
+Read [platform-contract.md](references/platform-contract.md) and use `assets/platform-template/` for operational catalogs.
+
+## Handoff
+
+Candidate verification may start only when the application candidate and reproducible test environment are both available. Production deployment later consumes the frozen platform items in the approved release package.

package/skills/ai-delivery-prepare-platform/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Prepare Delivery Platform"
+  short_description: "Prepare CI/CD, environments, infrastructure, and observability"
+  default_prompt: "Use $ai-delivery-prepare-platform to prepare delivery and operations capabilities."

package/skills/ai-delivery-prepare-platform/assets/platform-template/environment-ledger.csv

@@ -0,0 +1 @@
+environment_id,release_or_candidate_id,commit_sha,artifact_set_ref,configuration_baseline,migration_set_ref,iac_ref,deployed_at,verification_status

package/skills/ai-delivery-prepare-platform/references/platform-contract.md

@@ -0,0 +1,18 @@
+# Platform Contract
+
+## Required Capabilities
+
+Create only capabilities required by architecture and iteration scope. Consider build, registry, CI/CD, environments, IaC, configuration, secret references, database migrations, health checks, logs, metrics, traces, dashboards, alerts, backups, recovery, and rollback.
+
+## Environment Ledger
+
+Record environment ID, deployed version, commit, artifact-set reference, configuration baseline hash, migration-set reference, IaC state or plan, deployment timestamp, and verification state. Store artifact and migration membership in separate association files. Never use a branch name as environment identity.
+
+## Safety Rules
+
+- Never store secret values in delivery artifacts.
+- Promote the same immutable artifact between environments.
+- Exercise deployment and rollback before production.
+- Prove old-image compatibility with post-release data, configuration, and infrastructure.
+- Prefer backward-compatible expand/contract schema changes.
+- Record production differences from test and staging environments.

package/skills/ai-delivery-prepare-release/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: ai-delivery-prepare-release
+description: Prepare an independently verified multi-version or same-version release candidate for production by freezing its complete delivery inventory and proving rollback compatibility. Use only at R06 after explicit release orchestration and R05 release verification pass; do not use for normal iteration completion.
+---
+
+# Prepare Release
+
+Create an auditable release package. Do not deploy production.
+
+## Artifact Location
+
+Write release manifests, change inventories, rollback documents, and workflow records to `.workflow/releases/<release-id>/R06-release-preparation/`. Images, binaries, and other non-document release artifacts remain in their artifact stores and are referenced by immutable digest.
+
+## Task State
+
+1. Invoke `$ai-delivery-checkpoint-task` before preflight to recover or initialize the task snapshot.
+2. Checkpoint after every meaningful artifact, gate, validation, merge, deployment action, or other external milestone, and before compaction or interruption.
+3. Before returning, finish the snapshot as `completed`, `blocked`, `failed`, or `interrupted`, with actual outputs, evidence, blockers, and one idempotent next action. A Hook event alone never proves completion.
+
+## Preflight
+
+Read the explicit release request, frozen version selection, passing release candidate, prior production release, all included version manifests, changed baselines, verification evidence, platform artifacts, Git state, and environment baselines. Acquire the serialized release transition through `$ai-delivery-manage-git`.
+
+## Freeze The Candidate
+
+1. Confirm the release branch was created from the selected target's exact immutable `version-ready` tag and that the target descends from production.
+2. Re-run impacted and final release gates after any release-fix candidate.
+3. Freeze the exact release ID, target version, version closure, commit, Tag, application artifact digests, configuration baseline, migrations, IaC plan, and standards baseline.
+4. Never merge additional code after final regression. Any material change creates a new candidate and repeats affected verification.
+
+## Build The Release Package
+
+Generate `release-manifest.yaml` and a unified `delivery-items.csv`. Dynamically add detailed inventories only for actual change types, including container images, configuration, database migrations, infrastructure, feature flags, scheduled jobs, static assets, certificates, observability, and SBOMs.
+
+Include requirements, product, experience, architecture, source, dependency, security, environment, data, test, defect, operations, compatibility, risk, deployment, verification, and rollback changes. Never include secret values.
+
+Require every delivery item to reference an order, verification step, and rollback or recovery action. Identify images by digest, not mutable tag. Identify IaC plans and configuration baselines by immutable hash.
+
+## Prove Rollback Readiness
+
+Verify that the last-known-good image remains available and compatible with the new database, configuration, and infrastructure state. Prefer expand/contract migrations. Block automatic image rollback when compatibility is not proven and require an approved recovery or forward-fix plan.
+
+Read [release-contract.md](references/release-contract.md) and use `assets/release-template/` for inventories.
+
+## Handoff
+
+Return exactly one immutable prepared release package to `$ai-delivery-orchestrate-release`. Human production approval occurs independently at `R07-production-approval`.

package/skills/ai-delivery-prepare-release/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Prepare Release"
+  short_description: "Freeze an immutable version and complete delivery inventory"
+  default_prompt: "Use $ai-delivery-prepare-release to prepare the current iteration for production release."

package/skills/ai-delivery-prepare-release/assets/release-template/delivery-items.csv

@@ -0,0 +1 @@
+item_id,item_type,name,change_type,target,version_ref,artifact_ref,deploy_order,verification_ref,rollback_ref

package/skills/ai-delivery-prepare-release/assets/release-template/release-manifest.yaml

@@ -0,0 +1,18 @@
+release_id: RELEASE-0001
+iteration_id: ITER-0001
+version: 0.1.0
+target_environment: production
+commit_sha: ""
+tag: ""
+package_hash: ""
+artifact_digests: []
+configuration_baseline: ""
+migration_set: []
+iac_plan_hash: ""
+standards_baseline_ref: ""
+verification_ref: ""
+previous_stable_release_id: ""
+approval:
+  status: pending
+  approved_by: null
+  approved_at: null

package/skills/ai-delivery-prepare-release/references/release-contract.md

@@ -0,0 +1,21 @@
+# Release Contract
+
+## Release Manifest
+
+Record release ID, mode, selected target and continuous version closure, target environment, commit, immutable version and release Tags, package hash, application artifact digests, configuration baseline, migration set, IaC plan hash, standards baseline, R05 verification result, previous stable release, known risks, and inventory references. Production approval is a separate R07 artifact and is not created here.
+
+## Unified Delivery Index
+
+`delivery-items.csv`:
+
+`item_id,item_type,name,change_type,target,version_ref,artifact_ref,deploy_order,verification_ref,rollback_ref`
+
+Use `add`, `update`, `remove`, and `unchanged-required` change types. Generate detailed CSV files only for actual item types.
+
+## Required Change Coverage
+
+Consider product, terminology, terminal, feature, experience, architecture, API, data, code, dependencies, container images, configuration, secrets references, migrations, infrastructure, flags, jobs, assets, certificates, observability, tests, defects, compatibility, operations, and accepted risk.
+
+## Image Rollback Gate
+
+Record previous image digest, registry availability, schema compatibility, configuration compatibility, infrastructure compatibility, rollback action, verification action, and any manual recovery requirement. Block automatic rollback when compatibility is unproven.

package/skills/ai-delivery-review-change/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: ai-delivery-review-change
+description: Independently review a technical work-package change against approved product behavior, architecture, repository standards, security constraints, and test quality. Use before merging a work branch, after a review fix, or when a candidate failure suggests a code-level compliance defect.
+---
+
+# Review Change
+
+Review independently from the implementation context. Do not edit product code or approve a change with unresolved blocking findings.
+
+## Artifact Location
+
+Write every review report, findings table, decision, and evidence reference produced by this skill under project `.workflow/`, defaulting version-scoped outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Do not write review documents beside application source.
+
+## Task State
+
+1. Invoke `$ai-delivery-checkpoint-task` before preflight to recover or initialize the task snapshot.
+2. Checkpoint after every meaningful artifact, gate, validation, merge, deployment action, or other external milestone, and before compaction or interruption.
+3. Before returning, finish the snapshot as `completed`, `blocked`, `failed`, or `interrupted`, with actual outputs, evidence, blockers, and one idempotent next action. A Hook event alone never proves completion.
+
+## Preflight
+
+Read the work package, diff, approved source artifacts, standards versions, architecture constraints, TDD evidence, test results, allowed modification scope, exact UI handoff/product-reconciliation checksums, task-to-experience-change actions, and page/canvas/file/element mappings for UI-bearing work. Re-run relevant checks when evidence is absent or stale.
+
+## Review Axes
+
+1. **Specification:** verify the requested behavior and acceptance criteria without adding unrequested capability.
+2. **Architecture:** verify boundaries, contracts, stack, data, security, configuration, migration, and observability rules.
+3. **Standards:** apply all pinned standards and repository instructions.
+4. **Correctness:** inspect error paths, state transitions, concurrency, compatibility, resource handling, and rollback impact.
+5. **Tests:** verify behavior through confirmed seams, independent expected values, useful failure sensitivity, and adequate regression coverage.
+6. **Scope:** flag unrelated files, hidden generated changes, dependency drift, and ownership violations.
+7. **Experience conformance:** for UI-bearing changes, verify each `ready-for-development` experience change was implemented with its declared create/update/remove/migrate/no-code action, exact member revision, interaction/component-state obligations, and stable page/canvas/file/element mappings; reject stale, untracked, or visually inferred work.
+
+## Output
+
+Report findings first, ordered by severity, with tight file and line references. For each finding include evidence, violated source ID, impact, and required correction. Then report open questions, check results, residual risk, and one decision: `pass`, `fail`, or `blocked`.
+
+Do not use `pass` when required checks did not run. Do not repair findings yourself; return them to the work-package executor.
+
+Read [review-contract.md](references/review-contract.md).

package/skills/ai-delivery-review-change/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Review Change"
+  short_description: "Independently review a code change against standards and specs"
+  default_prompt: "Use $ai-delivery-review-change to independently review the current code change."