ultra-builder-pro-cli 0.9.0 → 0.11.0

package/skills/ultra-init/SKILL.md

@@ -1,150 +1,70 @@
 ---
 name: ultra-init
-description: "Initialize Ultra Builder Pro project: detect context, confirm with user, scaffold .ultra/ via task.init_project, set up git."
-runtime: all
-mcp_tools_required:
-  - task.init_project
-cli_fallback: "task init-project"
+description: Initialize an Ultra Builder Pro project with authoritative state, baseline specification files, and optional Git setup. Use when a repository has not yet been initialized for the Ultra workflow.
 ---
 
-# ultra-init — Phase 3.1
+# Initialize an Ultra project
 
-把当前工作目录（或 `--target-dir`）初始化为一个 Ultra Builder Pro 项目：拉起
-`.ultra/` 骨架、初始化权威 `state.db`、建立持续变更目录、写入 `tasks.json`
-初始元数据，并按需配置 git。
+Create the project-local Ultra runtime without inventing product requirements or
+business tasks.
 
-真实的目录搭建 + 模板拷贝 + tasks.json 注入统一由 **MCP tool `task.init_project`** 完成；
-MCP 不可达时回退 `ultra-tools task init-project`。
+## Inputs
 
-## 设计要点（对比 pre-Phase-3 行为）
+Use the current working directory unless the user names another target. Inspect
+existing project manifests to infer:
 
-- **无 Claude 独占依赖**：`task.init_project` + `ultra-tools init-project` 两条路径
-  都不调 Claude 原生工具，Claude Code、OpenCode、Codex 三个 runtime 都能走通。
-- **模板内置**：`.ultra/` 骨架来自仓内 `templates/.ultra/`；不再依赖 `~/.claude/.ultra-template/`。
-- **幂等**：二次 init 默认拒绝，`--overwrite` 才会备份旧 `.ultra/` 为
-  `.ultra.backup.<ts>` 后重建。
+- project name;
+- project type;
+- primary technologies;
+- whether Git and `.ultra/` already exist.
+
+Ask only about unresolved ambiguity, optional Git initialization, or permission to
+replace an existing `.ultra/` directory. Never infer permission to overwrite it.
 
 ## Workflow
 
-### Step 0: 状态检测（skill 调用方做）
-
-在调 `task.init_project` 之前，调用方（Claude / CLI / SDK）需要先判断：
-
-- `target_dir/.ultra/` 是否已存在 → 决定是否需要 `overwrite=true`
-- `target_dir/.git/` 是否已存在 → 影响 Step 3 的分支
-- 读 `package.json` / `Cargo.toml` / `pyproject.toml` / `go.mod` 推断项目类型和栈
-- 如果调用方是 Claude，可在此用 `TaskCreate` 跟踪 Step 0–4 的 session 内进度
-  （这是 runtime 的 session-local 跟踪，不走 MCP）
-
-### Step 1: 补全参数
-
-入参不足时补：
-
-| 字段 | 缺省 |
-|------|------|
-| `project_name` | 当前目录名（`path.basename(target_dir)`） |
-| `project_type` | Step 0 识别结果；多技术栈 → `fullstack` |
-| `stack` | Step 0 识别到的依赖（逗号分隔多值，如 `react,express,postgres`） |
-| `git_init` | `.git/` 不存在 → 询问用户 |
-
-### Step 1.5: 交互确认（仅当检测到模糊或重入）
-
-触发条件：
-- `target_dir/.ultra/` 已存在（重入）
-- 识别到多项目类型（Web + API）
-- 显式 `--interactive` 标志
-
-交互渠道：
-- **Claude runtime**：调 `AskUserQuestion`（原生）
-- **其他 runtime**：使用 Host 原生提问界面；若当前表面不支持交互，
-  要求用户通过显式命令行参数选择
-
-确认 4 个问题：
-1. 项目类型（可多选，`detected` 标签打在识别项）
-2. 技术栈（可多选）
-3. 已有 `.git/` → 保留 / 重置备份 / 不用 git
-4. 已有 `.ultra/` → 覆盖（备份） / 保留 / 取消
-
-### Step 2: 调 `task.init_project` 拉起骨架
-
-**MCP 主路径**：
-```jsonc
-// call: task.init_project
-{
-  "target_dir": "/abs/path/to/project",
-  "project_name": "my-app",
-  "project_type": "fullstack",
-  "stack": "react,express,postgres",
-  "overwrite": false
-}
-// response
-{
-  "created_path": "/abs/path/to/project/.ultra",
-  "status": "created",
-  "copied_files": [
-    "specs/discovery.md", "specs/product.md", "specs/architecture.md",
-    "tasks/tasks.json", "tasks/contexts/TEMPLATE.md",
-    "changes/active/.gitkeep", "changes/archive/.gitkeep",
-    "docs/research/README.md",
-    "test-report.json", "delivery-report.json"
-  ],
-  "state_db_path": "/abs/path/to/project/.ultra/state.db"
-}
-```
-
-**CLI 回退路径**（`UBP_MCP=off` 或 MCP 调用返回网络错）：
-```bash
-ultra-tools task init-project \
-  --target-dir "$TARGET" \
-  --project-name "$NAME" \
-  --project-type "$TYPE" \
-  --stack "$STACK" \
-  $([ "$OVERWRITE" = "1" ] && echo --overwrite)
-```
-CLI 最后一行是 `{ "ok": true, "data": { ... } }`（见 spec/cli-protocol.md §2）。
-
-**错误处理**：
-- `ULTRA_DIR_EXISTS` → Step 1.5 重新询问是否 overwrite
-- `TEMPLATE_MISSING` → 致命；提示检查 `templates/.ultra/` 是否被 gitignore 吞了
-- `TARGET_NOT_DIR` / `VALIDATION_ERROR` → 返回调用方，修参数
-- `IO_ERROR` → retriable=true；最多重试 2 次
-
-### Step 3: Git 集成
-
-根据 Step 1.5 结果：
-
-- **初始化新仓**：`git init` + 写 `.gitignore`（排除 `.ultra/backups/`、`node_modules/`、
-  敏感文件等项目通用规则）+ 写基础 `README.md`（若不存在）。
-- **保留现有 `.git/`**：仅追加 `.gitignore` 里的 `.ultra/backups/` 一行（若缺失）。
-- **不用 git**：跳过。
-
-提示建议第一个 commit：`git add . && git commit -m "feat: initialize Ultra Builder Pro"`，
-但不代为执行（commit 是用户决策）。
-
-### Step 4: 成功总结 + 下一步
-
-用中文输出：
-- ✅ `.ultra/` 骨架（specs / tasks / changes / docs / reports）
-- ✅ `.ultra/state.db` 已初始化为当前 schema，后续不再依赖第一次写操作懒创建
-- ✅ tasks.json 注入元数据（name / type / stack / created / updated）
-- ✅ git 状态（按选择）
-- ⚠️ **下一步**：跑 `/ultra-research` 做 17 步 discovery 填 spec；不要跳过直接 `/ultra-plan`
-
-## 调用方式（按 runtime）
-
-| Runtime | 调用形态 |
-|---------|----------|
-| Claude  | `/ultra-init [name] [type] [stack] [git]` — 命令薄壳拉起此 skill |
-| OpenCode | `/ultra-init …` 同上（agent frontmatter 小写化） |
-| Codex   | `codex exec "run /ultra-init …"`（Phase 4.4 adapter 接） |
-
-## 输出锚点
-
-- `target_dir/.ultra/tasks/tasks.json` — project.name / project.type / project.stack 已注入
-- `target_dir/.ultra/specs/{discovery,product,architecture}.md` — 带 `[NEEDS CLARIFICATION]` 标记
-- 若 `overwrite=true`：`target_dir/.ultra.backup.<ts>/` 保存旧骨架
-
-## 不做的事
-
-- **不**创建业务 task（业务 task 由 `/ultra-plan` 在 spec 填完后批量创建）
-- **不**调 web：离线可执行
+1. Resolve the absolute target directory and verify that it exists.
+2. Derive the project metadata from repository evidence. Treat user-provided values
+   as authoritative when they conflict with inference.
+3. If `.ultra/` exists, stop and ask whether to keep it, cancel, or recreate it with
+   `overwrite: true`. Explain that recreation first preserves a timestamped backup.
+4. Call `task.init_project` with the smallest complete input:
+
+   ```json
+   {
+     "target_dir": "/absolute/project/path",
+     "project_name": "example",
+     "project_type": "fullstack",
+     "stack": "react,node,postgres",
+     "overwrite": false
+   }
+   ```
+
+5. Verify the returned `.ultra` path, `state_db_path`, status, and copied-file list.
+   Confirm that the returned state database and baseline specification files exist.
+6. If the user requested Git setup, initialize Git only when needed and add narrowly
+   scoped ignore rules. Do not stage or commit without explicit authorization.
+
+If the MCP server cannot start, use the installed
+`ultra-tools task init-project` command only when it is available. The CLI and MCP
+must use the same initializer. Do not simulate initialization by creating projection
+files manually.
+
+## Failure handling
+
+- `ULTRA_DIR_EXISTS`: return to the overwrite decision; do not retry automatically.
+- `TEMPLATE_MISSING`: stop and report an installation/package integrity failure.
+- `TARGET_NOT_DIR` or `VALIDATION_ERROR`: correct the input and retry once.
+- `IO_ERROR`: report the affected path and preserve any backup or partial evidence.
+
+## Authority and output
+
+`.ultra/state.db` is the durable Ultra authority. Generated JSON and Markdown are
+projections or workflow artifacts and must not be edited to create state.
+
+Report the initialized path, state database path, backup path when present, Git
+action, and one next action. Route incomplete product intent to `ultra-research`;
+route an already validated baseline to `ultra-plan`.
+
+Do not create business tasks, browse the web, or rewrite an existing README as part
+of initialization.

package/skills/ultra-plan/SKILL.md

@@ -1,329 +1,69 @@
 ---
 name: ultra-plan
-description: "Generate task breakdown from complete specs OR from a raw PRD (Phase 8A). Scope-mode-aware; writes state.db via task.create or task.parse_prd; projector generates tasks.json + contexts/*.md."
-runtime: all
-mcp_tools_required:
-  - task.create
-  - task.parse_prd
-  - task.dependency_topo
-  - plan.export
-  - plan.get
+description: Convert a validated baseline, active delta, or approved PRD into dependency-valid vertical slices with bounded context and exact verification. Use when requirements are ready to become authoritative Ultra tasks.
 ---
 
-# ultra-plan — Phase 3.3
+# Plan fresh-context execution
 
-Transform validated `.ultra/specs/` into an executable task plan. **state.db is
-the authority** (D32): every new task is created via MCP `task.create`; the
-projector regenerates `.ultra/tasks/tasks.json` and context-md frontmatter
-automatically. Context-md bodies are written by this skill (not projector).
+Produce a task graph whose slices can be completed independently and verified through
+live product seams. `.ultra/state.db` remains authoritative; task JSON and context
+Markdown are generated projections.
 
-## Authority failure boundary
+## Entry gate
 
-Before planning, call a state-backed MCP tool. If the MCP server is missing,
-unreachable, or returns any authority error, stop before creating tasks. In
-particular, `LEGACY_STATE_MIGRATION_REQUIRED` means the project still has a
-non-empty v4.4 projection; tell the user to run:
+Start with a state-backed MCP read. If state or schema health blocks access, stop and
+route to `ultra-doctor`. Never read or write `.ultra/tasks/tasks.json` as a fallback.
 
-```bash
-ultra-tools migrate --from=4.4 --to=4.5 --source-dir <project-root>
-```
+Choose one input:
 
-Never read or write `.ultra/tasks/tasks.json` as a fallback. It is a generated
-projection, not an alternate task store. There is no task-mutation CLI fallback.
+- validated baseline specifications;
+- one active change packet;
+- a raw PRD through the approval-gated mode below.
 
-## Prerequisites
+Ask only for product, scope, cost, or risk decisions that cannot be derived from
+current evidence. A material unresolved assumption blocks persistence.
 
-- `/ultra-research` completed — specs must be 100% (no `[NEEDS CLARIFICATION]`)
-- `.ultra/specs/product.md` + `.ultra/specs/architecture.md` exist
-- `.ultra/specs/research-distillate.md` preferred when present (token-efficient)
+## Planning rules
 
-## Workflow
+1. Trace acceptance through an entry point, domain behavior, side effects, and a
+   user-observable or public seam.
+2. Prefer a walking skeleton or `tracer_bullet` before horizontal layers.
+3. Give each task one outcome, bounded ownership, explicit dependencies, required
+   references, and one deterministic verification command.
+4. Use the context budget returned by the current Ultra contract. Widen it only when
+   an approved slice cannot be split without losing correctness.
+5. Add integration checkpoints at actual boundaries, not after arbitrary task counts.
+6. Put validation, errors, recovery, documentation, and migrations in the task that
+   owns the behavior.
+7. Reject scaffolding with no reachable consumer.
 
-### Workflow activation
+Every persisted task must include its slice kind, public seam, verification command,
+acceptance evidence, ownership, dependencies, documentation impact, and linked change
+id when applicable.
 
-At entry, write `.ultra/workflow-state.json` with
-`{"command":"ultra-plan","task_id":"plan","step":"0","status":"active","ts":"<ISO8601>"}`.
-This activates the workflow-only hooks. Mark it terminal only after the MCP
-task writes and verification complete.
+## Baseline or change mode
 
-### Input Mode Selection (BEFORE Step 0)
+1. Read the smallest authoritative references that define acceptance.
+2. Build the task DAG in memory and check dependency and ownership conflicts.
+3. Present the proposed outcome, execution order, risk concentration, and first live
+   seam. Obtain approval if scope, cost, or delivery semantics change materially.
+4. Persist approved tasks with `task.create`.
+5. For change-linked tasks, compile `change.context` with the planning role and gate.
+   Resolve every readiness blocker before calling a task executable.
+6. Call `task.dependency_topo`; cycles and missing dependencies block completion.
+7. Call `plan.export`, then verify the persisted result with `plan.get`.
+8. Call `change.breadcrumb` when a change is active and return one next action.
 
-Two entry points lead into the planner:
+## PRD mode
 
-| Mode | When | Path |
-|------|------|------|
-| **Spec Mode** (default) | `.ultra/specs/` exists and `/ultra-research` is complete | Steps 0–7 below |
-| **PRD Direct** (Phase 8A) | User hands you a raw PRD (path or inline text) and wants to skip the spec layer | see **PRD Direct Workflow** below |
+1. Call `task.parse_prd` with `dry_run: true`.
+2. Show the proposed slices, topology, conflict surface, and cost estimate.
+3. Require explicit approval; rejection performs no state write.
+4. On approval, repeat with `dry_run: false`, export the plan, and verify that the
+   dry-run and persisted task identities agree.
 
----
-
-### PRD Direct Workflow (Phase 8A — human-gated artifact)
-
-For a one-shot PRD → task graph pipeline with approval gate:
-
-1. **Dry-run parse** (no state.db writes):
-   ```jsonc
-   // MCP
-   { "tool": "task.parse_prd", "args": { "prd_path": "<path>", "dry_run": true, "tag": "<branch>" } }
-   ```
-   Returns `{ tasks: [...], topo: [[...],[...]] }` without touching state.db.
-
-2. **Build execution plan** (in-memory via the server's `plan-builder`):
-   The server composes `computeWaves` + `files_modified` overlap + `pricing.computeCost`
-   into a plan with `waves`, `ownership_forecast`, `conflict_surface`, and
-   estimated cost / duration.
-
-3. **Human gate** — ask through the current Host's native user-interaction
-   surface with the plan summary and estimated cost:
-   - `approve` → re-run `task.parse_prd` **with `dry_run: false`** to commit
-     tasks, then `plan.export { out_path: ".ultra/execution-plan.json" }`
-     to land the artifact and emit the `plan_approved` event.
-   - `reject` → **do not** call the non-dry-run path. No state.db rows, no
-     artifact. Prompt user for PRD revision and loop.
-
-4. **Post-approval** — the artifact at `.ultra/execution-plan.json` is the
-   source of truth for Phase 8B orchestration (wave-by-wave dispatch).
-   Use `plan.get { section: "topo" | "conflicts" | "all" }` to inspect
-   without re-reading the file.
-
-**AC guarantees**:
-- `reject` path performs zero state.db writes (dry_run=true on parse).
-- `approve` path emits exactly one `plan_approved` event, tied to the
-  persisted artifact path.
-- Task IDs returned by the dry-run and the final persisted tasks are
-  identical (parser is deterministic given the same LLM output).
-
----
-
-### Step 0 — Scope Mode Selection
-
-Ask the user which posture this plan takes. **Commit once selected — do not
-drift silently.**
-
-| Mode | Posture | Use when |
-|------|---------|----------|
-| **EXPAND** | "What would make this 10x better for 2x effort?" — surface stretch opportunities | Greenfield, user wants to think bigger |
-| **SELECTIVE** (default) | Baseline scope held; optional expansions surfaced individually | Most common; feature work on existing product |
-| **HOLD** | Scope locked; make it bulletproof; catch every failure mode | Requirements clear, need execution depth |
-| **REDUCE** | Find the minimum viable version; cut ruthlessly | MVP, time pressure, PoC |
-
-Use the current Host's native picker. If that Host has no structured picker,
-present the choices directly and require an explicit answer.
-
-**Dual-scale effort** on every EXPAND/SELECTIVE expansion decision:
-`Complete: ~X LOC, AI ~Y min | Shortcut: ~X LOC, saves Y min but ___`
-
-### Step 1 — Specification Completeness Validation (BLOCK gate)
-
-Read specs and check field-by-field. **Fail loud** — don't generate a plan
-against broken specs.
-
-**discovery.md** (if present):
-- §0 Problem Validation has demand signal + confidence %
-- §2 Market Assessment has TAM/SAM/SOM with numbers + sources
-- §3 Competitive Landscape has ≥2 competitors compared
-- §4 Product Strategy has ≥3 trade-offs
-
-**product.md**:
-- §2 Personas: ≥2 with goals + pain points
-- §3 Scenarios: ≥3 with current + desired flow
-- §4 User Stories: acceptance criteria in Given/When/Then
-- §5 Feature Scope: Features Out section with rationale
-- §6 Success Metrics: North Star has numeric target
-
-**architecture.md**:
-- §1 Quality Goals: ≥3 measurable scenarios
-- §4 Solution Strategy: tech stack with URL-cited rationale
-- §5 Building Blocks: modules map to features
-- §6 Runtime Scenarios: ≥1 with data flow
-
-**Fail if**: `[NEEDS CLARIFICATION]` markers present / file missing / checklist fails.
-On fail → instruct user to run `/ultra-research` targeting the gap.
-
-### Step 2 — Requirements + Codebase Analysis
-
-**Requirements extraction** (prefer distillate):
-- Functional requirements (product.md §4)
-- Technical constraints (architecture.md §2)
-- Quality requirements (architecture.md §10)
-- Success metrics (product.md §6)
-
-**Codebase analysis** (for AI-executable context):
-- Directory structure (src/ tests/ config/)
-- Existing patterns worth referencing
-- Tech stack detection (framework versions, test runners)
-- Naming conventions
-
-### Step 3 — Task Generation
-
-#### tasks.json schema (v4.5 projection, source in state.db)
-
-Fields per task: `id`, `title` (action verb + target), `type`
-(architecture/feature/bugfix), `priority` (P0-P3), `complexity` (1-10),
-`status` (pending initially), `deps` (task IDs), `estimated_days`,
-`context_file`, `trace_to` (spec section anchor).
-
-#### Integration tasks — MANDATORY inserts
-
-1. **Walking Skeleton — always Task #1, P0, type=architecture**
-   - Title: "Walking skeleton: {primary use case} end-to-end"
-   - Must touch every layer: entry → use case → domain → persistence
-   - Acceptance: one real request returns real data through all layers
-
-2. **Contract Definition** (when specs show component boundaries)
-   - Title: "Define contract: {component A} ↔ {component B}"
-   - Must PRECEDE implementation tasks on both sides
-   - Acceptance: shared interface/schema + contract test
-
-3. **Integration Checkpoint** — every 3-4 feature tasks
-   - Title: "Integration checkpoint: verify {feature group} connectivity"
-   - Acceptance: components from recent tasks communicate end-to-end
-
-#### Task granularity
-
-- Ideal complexity: 3-5 (one-session completable)
-- Too large (>6) → split
-- Too small (<3) → merge
-- Context budget: target 40% per task; max 8 files touched; complexity ≥7 must split
-
-### Step 4 — Dependency Analysis
-
-- Build dependency graph from each task's `deps` list
-- Detect cycles (DFS with visited + recursion stack) — cycles are **fatal**
-- Topological order → surface parallel opportunities
-- Vertical slicing check: flag any task touching only one layer → split or merge
-- Walking skeleton blocks all feature tasks
-- Contract tasks precede their consumer implementations
-
-### Step 5 — Persist via MCP `task.create`
-
-For **each** task in the planned list (topological order):
-
-```jsonc
-// MCP call per task
-{
-  "id": "1",                          // optional; server mints uuid if omitted
-  "title": "Walking skeleton: …",
-  "type": "architecture",
-  "priority": "P0",
-  "complexity": 4,
-  "estimated_days": 2,
-  "deps": [],
-  "tag": "<git branch>",              // optional
-  "trace_to": ".ultra/specs/product.md#US-01"
-}
-```
-
-After each `task.create`, the server auto-runs the projector — `tasks.json`
-and `contexts/task-{id}.md` (frontmatter only) appear.
-
-Create one task per `task.create` call so every write is schema-validated and
-projected through the same live MCP contract.
-
-### Step 5.5 — Context-md body (skill responsibility)
-
-Projector writes the frontmatter; this skill writes the body. For each task,
-write `.ultra/tasks/contexts/task-{id}.md` body (projector preserves it):
-
-```markdown
-## Context
-**What**: …
-**Why**: … (Persona/Scenario link)
-**Constraints**: - …
-
-## Implementation
-**Target Files**: - path/to/file.ts (create|modify: desc)
-**Pattern**: …
-**Tech Notes**: …
-
-## Acceptance
-**Tests**: - [ ] `test cmd`
-**Verification**: ```bash …```
-
-## Trace
-**Source**: `.ultra/specs/product.md#US-01`
-
-## Change Log
-| Date | Change | Specs Updated | Reason |
-|------|--------|---------------|--------|
-
-## Completion
-> _Filled when task completed by /ultra-dev_
-```
-
-### Step 6 — Plan Verification (BLOCKING)
-
-Run programmatic checks **before** presenting to user:
-
-| Check | Severity | Action on fail |
-|-------|----------|----------------|
-| Every user story (US-XX) mapped to ≥1 task via `trace_to` | CRITICAL | create missing task or flag |
-| Dependency graph acyclic | CRITICAL | report cycle chain, block |
-| `trace_to` points at real spec anchor | WARN | suggest correction |
-| Tasks with complexity ≥7 | WARN | suggest split |
-| Tasks touching >8 files | WARN | suggest split |
-| Total tasks >20 | WARN | suggest phased delivery |
-| Per-task complexity × 5% context > 40% | WARN | split recommended |
-
-All CRITICAL pass → present to user (Step 7). Any CRITICAL fail → auto-fix or surface.
-
-### Step 7 — Report + Next Steps
-
-Summary output:
-- Total tasks, priority distribution (P0/P1/P2), complexity histogram
-- Dependency edge count, parallel-track count
-- Estimated total effort (sum of `estimated_days`)
-- Requirement coverage % (stories mapped / stories total)
-- First task details (Walking Skeleton)
-- Suggest `/ultra-dev`
-
-### Continuation block (MANDATORY)
-
-```markdown
----
-## ▶ Next Up
-**Start Development** — TDD workflow on Task #1: {Walking Skeleton title}
-
-`/clear` then `/ultra-dev`
-
----
-**Also available**: `/ultra-status`
----
-```
-
-## Quality Standards
-
-- 100% requirement coverage (every user story mapped)
-- Clear acceptance criteria per task
-- No circular dependencies
-- Realistic complexity (justifiable in review)
-- Action-verb titles
-- Walking Skeleton is Task #1
-- Every feature task is a vertical slice (≥2 layers)
-- Integration checkpoint every 3-4 feature tasks
-- Contract tasks precede cross-boundary implementations
-
-## Integration Points
-
-| | |
-|---|---|
-| **Prerequisite** | `/ultra-research` — specs 100% complete |
-| **Input** | `.ultra/specs/research-distillate.md` (primary), `product.md`, `architecture.md`, `discovery.md` |
-| **Writes** | state.db via `task.create`; context-md bodies |
-| **Output (projected)** | `.ultra/tasks/tasks.json`, `.ultra/tasks/contexts/task-*.md` |
-| **Next** | `/ultra-dev` |
-
-## MCP failure matrix
-
-| Purpose | MCP tool | Failure behavior |
-|---------|----------|------------------|
-| Scope mode prompt | none | current Host's native user-interaction surface |
-| Create task | `task.create` | stop; surface the MCP error; never write a projection |
-
-## What this skill DOES NOT do
+## Completion gate
 
-- Does NOT write state.db directly — all task writes go through `task.create`
-- Does NOT regenerate `tasks.json` — projector owns that
-- Does NOT read `tasks.json` when MCP state is empty or unavailable
-- Does NOT start implementation — that's `/ultra-dev`
-- Does NOT re-run research — if specs are incomplete, redirects to `/ultra-research`
+Planning is complete only when the DAG is valid, each task reaches a public seam, each
+verification command is executable, every change-linked context is ready, and no
+required documentation or decision remains unknown.