[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HQEZ0PV13MXHAS91ZBPCGT":3,"skill-same:01M6HQEZ0PV13MXHAS91ZBPCGT":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M6HQEZ0PV13MXHAS91ZBPCGT","plan-proposal",null,"Develop-side planning orchestrator for an OpenSpec change: artifact creation → doubt-driven-review → scenario-design → fold of automated scenarios into tasks.md, then STOPS at the git-worktree boundary. Main interactive session only; never a subagent. Triggers: \"plan this change\", \"draft the proposal and plan\", \"scaffold + review + fold\", \"prep a change for building\".","BlackBeltTechnology\u002Fpi-agent-dashboard","BlackBeltTechnology","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F8101592?v=4","01M6HQDX7QAJA0QP4NYRYBMJ8A","BlackBelt Technology","01M6HQDXCC7719N9YDMQVH9JS6",348,"MIT","https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard\u002Fblob\u002Fdevelop\u002F.pi\u002Fskills\u002Fplan-proposal\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"plan","plan proposal","proposal","git-worktree","scenario","git","at","orchestrator","worktree","artifact","change","review","subagent","tasks","main","only","design","project","creation","never","2026-11-10 10:12:30",false,"---\nname: plan-proposal\ndescription: 'Develop-side planning orchestrator for an OpenSpec change: artifact creation → doubt-driven-review → scenario-design → fold of automated scenarios into tasks.md, then STOPS at the git-worktree boundary. Main interactive session only; never a subagent. Triggers: \"plan this change\", \"draft the proposal and plan\", \"scaffold + review + fold\", \"prep a change for building\".'\nmetadata:\n  version: \"1.0\"\n  scope: project\n---\n\n# plan-proposal\n\nOrchestrates the **planning phase** of an OpenSpec change on `develop`. Composes\nexisting skills — it does **not** reimplement them. Twin of `ship-it`, which owns\nthe implementation phase inside the worktree. The two split at the **git-worktree\nboundary**, which is also the **interactive\u002Fheadless line**.\n\n```mermaid\nflowchart LR\n  subgraph Planning [\"PLANNING — develop, human present\"]\n    A[\"new\u002Fff\u002Fcontinue\"] --> B[\"doubt-review\"]\n    B --> C[\"scenario-design + category-fold + manifest\"]\n    C --> D[\"plan-proposal (this skill)\"]\n  end\n  D -->|\"boundary: commit + spawn worktree\"| E[\"ship-it\"]\n  subgraph Implementation [\"IMPLEMENTATION — worktree\"]\n    E\n  end\n```\n\n## Hard constraint — main session only (never a subagent)\n\n`plan-proposal` MUST run in the main interactive session. It invokes\n`doubt-driven-review` (which spawns a fresh-context reviewer, and a second\ncross-model reviewer — automatically when a `@propose-review-N` role resolves,\noffered interactively only when none does; nested subagent spawn is blocked) and\n`scenario-design` (whose proposal\u002Fdesign-stage HARD gate calls `ask_user`). Both\nneed a live main session.\n\n**Guard:** if you detect you are running inside a subagent context (nested\nreviewer spawn would be blocked, or `ask_user` is unavailable), **STOP** and\nsurface: *\"plan-proposal must run in the main session — doubt-review and the\nscenario-design gate cannot run nested. Re-invoke from the main session on\n`develop`.\"* Do not degrade the doubt-review to a self-questioning fallback.\n\n## Preconditions\n\n- On the `develop` branch (planning happens on develop; the worktree is spawned\n  from the planning commit).\n- `openspec` CLI available; resolve the change name from `--change \u003Cname>`, the\n  conversation, or `openspec list --json` (ask if ambiguous).\n- Announce: *\"Planning change: `\u003Cchange>` (override with `\u002Fplan-proposal \u003Cother>`).\"*\n\n## Procedure\n\n### 1. Ensure planning artifacts exist\n\nBring the change to a drafted state using the existing generated skills — do not\nhand-roll the directory:\n\n- No change dir yet → `openspec-new-change` (or `-ff` for the fast path).\n- Partial artifacts → `openspec-continue-change`.\n\nState in the drafting request: **\"plan-proposal is driving this change\"**. The\n`openspec\u002Fconfig.yaml` `rules.tasks` rule sees it and skips its \"Run\nplan-proposal now?\" confirm (no re-entry). `rules.proposal` may still offer\npending mockups while `proposal.md` is written — that is expected; Step 1b only\nre-offers rows not declined.\n\nArtifacts live at `openspec\u002Fchanges\u002F\u003Cchange>\u002F`: `proposal.md`, `design.md` (when\nthe change warrants one), `specs\u002F**\u002Fspec.md`, `tasks.md`.\n\n**Cite code claims in `design.md`.** Instruct the author to cite the path (and\n`:line` when the statement is line-specific) for every statement in `design.md`\nabout existing code behaviour — e.g. `packages\u002Fserver\u002Fsrc\u002Fpi-core-checker.ts:42`.\nNot gated: a citation makes a wrong-file or \"does not exist\" claim cheap to spot\nbefore review.\n\n### 1b. Adopt pending mockups (idempotent backstop)\n\nBackstop for direct entry, `-continue` on an existing proposal, re-runs, and\n`SHIP_IT_BLOCKED` hand-backs. Runs after the artifacts exist, **before**\ndoubt-review, so reviewers and `scenario-design` see the mockup at its final path.\n\n1. Collect every root `mockups\u002FAGENTS.md` row whose Purpose cell ends with\n   `Pending change: \u003Cintent>`, minus rows that also carry `See change:` (owned\n   by a change — never offered), minus rows already declined in this session\n   (including a decline in the `rules.proposal` multiselect during Step 1).\n2. None left → ask nothing, change nothing, go to Step 2.\n3. Otherwise ONE `ask_user` multiselect offering every remaining row; the user\n   matches, you do not judge similarity. Unchosen rows count as declined.\n   **Live-component mocks** (entry dir with `mock.tsx`) follow their\n   `decision.json`: run `node packages\u002Fmockup-loop\u002Fsrc\u002Fmock-site\u002Fcli.mjs adoptable`\n   and offer its `options` in order with their labels (entry, intent, status) —\n   accepted first `(accepted)`, open \u002F malformed `(open)` — and never offer its\n   `skipped` (rejected) entries; report them, and every `warnings` line\n   (malformed decision files). With only rejected live mocks\n   pending, ask nothing and move nothing.\n4. Adopt each chosen entry with the mechanics of the `explore-mockup-adoption`\n   requirement (canonical, same as `rules.proposal`): File cell must resolve to\n   an entry directly under `mockups\u002F` (else skip + report); `mkdir -p\n   \u003CchangeDir>\u002Fmockups`; refuse if `\u003CchangeDir>\u002Fmockups\u002F\u003Centry>` already exists;\n   `git mv` (tracked) \u002F `mv` (untracked), never copy — a live mock dir moves\n   as ONE unit via `node packages\u002Fmockup-loop\u002Fsrc\u002Fmock-site\u002Fcli.mjs move mockups\u002F\u003Centry> \u003CchangeDir>`,\n   untracked `decision.json` included, and a source dir left behind is a failed move; only after a successful\n   move — recompute outward relative links, remove the row, add\n   `Mockup: mockups\u002F\u003Centry> (in this change)` under What Changes in\n   `proposal.md`. A failed move keeps its row.\n\nAn edited `proposal.md` is \"modified in this session\" → Step 2 reviews it.\n\n### 2. Doubt-review proposal.md + design.md (trigger: drafted or modified)\n\nWhenever `proposal.md` or `design.md` is created or changed in this session,\ninvoke `doubt-driven-review` on the changed artifact:\n\n- Pass **ARTIFACT + CONTRACT only** — never the CLAIM, never your reasoning.\n  - ARTIFACT = the proposal\u002Fdesign prose (decompose if large per doubt-review).\n  - CONTRACT = the requirements\u002Fconstraints the artifact must satisfy (the specs\n    deltas, the non-goals, the invariants it asserts).\n- **Run the spec-collateral scan before each doubt-review cycle** (the artifact\n  changes between cycles): `node scripts\u002Fspec-collateral.mjs --change \u003Cchange>`.\n  Append its output to the CONTRACT under the heading **\"Candidate conflicting\n  requirements (advisory scan) — check each\"**. The candidates are facts about\n  the corpus, not the CLAIM. If the scan cannot run or exits non-zero, report\n  the failure and proceed with the cycle without candidates — the scan never\n  blocks planning.\n- **Reviewer prompt hygiene** — the reviewer verifies claims against the\n  repository, writes `unverified` for any claim it cannot check instead of\n  asserting it, and reports every listed candidate the artifact contradicts.\n  A contradicted candidate is resolved by a MODIFIED\u002FREMOVED delta or an\n  artifact correction; \"unaffected\" is reserved for a verified false positive.\n- **Cross-model review** — runs automatically when a `@propose-review-N` role\n  resolves; surface the interactive cross-model offer only when none does.\n- **Reconcile every finding** against the artifact text using doubt-review's\n  precedence (contract-misread → actionable → trade-off → noise). When a finding\n  is valid + actionable, **PAUSE**: the artifact is corrected before proceeding.\n\nDo not fold scenarios until the doubt cycle reaches a stop condition (trivial\nfindings, 3 cycles, or explicit \"ship it\").\n\n### 3. scenario-design → category-routed fold into tasks.md (MANDATORY — never skip)\n\n**`scenario-design` is a required step, not an option.** A change never reaches\nthe worktree boundary without a `test-plan.md` manifest and its automated rows\nfolded into `tasks.md`. Do **not** hand-author test tasks, infer scenarios from\nthe proposal, or skip straight to the commit — always drive the tasks from the\n`scenario-design` output. Smoke-test-only `tasks.md` is a planning failure.\n\nRun `scenario-design` for the change (proposal\u002Fdesign stage → HARD gate; it may\n`ask_user` and STOP on a spec gap — that is expected, answer and continue). It\nwrites `openspec\u002Fchanges\u002F\u003Cchange>\u002Ftest-plan.md` — the **manifest**, carrying a\n`level` + `disposition` (`automated` | `manual-only`) per scenario row. If\n`test-plan.md` does not exist after this step, `scenario-design` did not run —\nre-invoke it before folding.\n\nThen **fold** each row into `tasks.md`:\n\n- **`automated` rows** → one vanilla `- [ ]` task each, routed to its category:\n\n  | manifest `level` | home | check-first (reuse infra) |\n  |---|---|---|\n  | L1 | `packages\u002F*\u002F**\u002F__tests__\u002F*.test.ts` (vitest) | sibling `*.test.ts` |\n  | L2 | `qa\u002Ftests\u002F*.sh` \\| `*.ps1` | existing qa test for that OS |\n  | L3 | `tests\u002Fe2e\u002F*.spec.ts` (docker harness) | existing spec for that surface |\n  | electron | `ci-electron.yml` \u002F `_electron-build.yml` | existing electron job |\n  | ci | `ci.yml` \u002F workflow-level | existing workflow assertion |\n\n  Before tasking new infra, scan for an existing test of that type to extend.\n  Each folded test task MUST carry:\n  1. a **harness-exemplar pointer** — the nearest existing spec\u002Ftest of that\n     category to copy harness glue from (e.g. `see tests\u002Fe2e\u002Freconnect.spec.ts`).\n     Bare \"author X.spec.ts\" tasks are forbidden — `ship-it` resolves the\n     exemplar path into the task context it hands `apply`.\n  2. the scenario **Triple** (`input · trigger · observable`) as plain text.\n  3. a manifest reference as ordinary prose — either `(test-plan #\u003Cid>)` or an\n     inline `(test-plan: automated)` — so `ship-it`\u002F`ship-change` can map it back.\n\n- **`manual-only` rows** → a plain manual task tagged `(test-plan: manual-only)`;\n  **no test is folded**. `ship-change` defers these post-merge (its manifest-aware\n  defer rule).\n\n**Post-fold re-scan (before Step 4):** folded tasks can introduce identifiers\nthe doubt cycles never saw, so run `node scripts\u002Fspec-collateral.mjs --change\n\u003Cchange>` once more after the fold and report every candidate not seen in the\ndoubt-review cycles. A real conflict among them returns planning to Step 2; a\ncontradicted candidate is resolved by a delta or an artifact correction —\n\"unaffected\" only for a verified false positive.\n\n**Fold-completeness gate (before Step 4):** every `automated` row in\n`test-plan.md` MUST map to exactly one folded test task in `tasks.md`, and every\n`manual-only` row MUST map to one tagged manual task. Verify the count matches\nthe manifest — if any scenario row has no corresponding task, the fold is\nincomplete; finish it before committing. Do not proceed to the boundary with an\nunfolded manifest.\n\n**Parser-safety (load-bearing):** `tasks.md` MUST stay vanilla checkbox format.\nNo custom token, no bracketed tag, no non-standard syntax on a task line — only\n`- [ ] \u003Ctext>` where the manifest reference is ordinary prose. `openspec status\n--json` and the generated `apply` skill parse this file; a stray token could\nbreak them. Verify `openspec status --change \u003Cchange> --json` reports the same\ntask counts after folding as the plain checkboxes imply.\n\n### 4. Commit planning artifacts + stop at the worktree boundary\n\n**Precondition:** `test-plan.md` exists and the fold-completeness gate passed.\nNever commit without the manifest — a missing `test-plan.md` means Step 3 was\nskipped; go back and run `scenario-design`.\n\nCommit `proposal.md`, `design.md`, `specs\u002F**`, `tasks.md`, and `test-plan.md` to\n`develop` — plus `dependencies.yaml` when the change has one (the worktree and\n`ship-it`'s dependency gate read it), plus the change's `mockups\u002F**` whenever it exists (adopted or\nwritten there directly), and, when mockups were adopted, the adoption's\nroot-side edits (`mockups\u002FAGENTS.md`, the renamed-away sources), so the\nworktree `ship-it` builds in carries the mockup. The worktree is spawned from that commit via the existing worktree\nflow (dashboard \"start work\" \u002F `git worktree add`).\n\nThen **STOP**. `plan-proposal` does not enter the implementation phase. Report:\n\n> *Planning complete for `\u003Cchange>`. Artifacts committed to `develop`; worktree\n> ready. Automated scenarios folded to tasks (manifest dispositions in\n> `test-plan.md`). **Next: run `ship-it` inside the worktree to build + ship.**\n> If a design issue surfaces during build, `ship-it` writes `SHIP_IT_BLOCKED.md`\n> and hands back here.*\n\n## Situation brief for `ask_user`\n\nEvery `ask_user` call this skill makes MUST carry a self-contained situation\nbrief in its `message` — at least 240 characters (the dashboard's\n`questions.minBriefChars` default; shorter and the server generates a brief with\nthe `@fast` model instead). The answer may be given from the global question\nstack by someone who has not seen this chat. State, in 2–4 lines:\n\n1. **Task** — what change\u002Fstep is in progress.\n2. **Why asking** — what was found or blocked that needs a human.\n3. **Per-option outcome** — what each option leads to (skip for free-text inputs).\n\nA bare question (\"Resume or hand back?\") is never enough. See change:\n`add-pending-question-stack`.\n\n## Guardrails\n\n- **Main session only** — refuse and surface if nested (see Hard constraint).\n- **Adopt pending mockups only via `ask_user`** (Step 1b) — never move a mockup\n  unasked, never re-offer a row declined this session, never copy.\n- **Never pass the CLAIM to the reviewer**; ARTIFACT + CONTRACT only.\n- **Never fold before reconciling** actionable doubt-review findings.\n- **`tasks.md` stays vanilla** — the manifest (`test-plan.md`), not a task tag,\n  is the automated-vs-manual source of truth.\n- **`scenario-design` is mandatory** — no `test-plan.md`, no commit. Never\n  hand-author test tasks or skip scenario design; the manifest is the sole\n  source of the folded test tasks.\n- **Fold every manifest row** — the boundary is blocked until every `automated`\n  and `manual-only` row maps to a task.\n- **Never author test\u002Fapp code here** — folding writes *tasks*; `ship-it` authors\n  the tests. This skill plans; it does not implement.\n- **Stop at the boundary** — do not continue into implementation.\n\n## Composed skills\n\n`openspec-new-change` \u002F `-ff` \u002F `-continue` · `doubt-driven-review` ·\n`scenario-design` (+ its `test-plan.md` manifest) · handoff to `ship-it`.\n","# plan-proposal\n\nOrchestrates the **planning phase** of an OpenSpec change on `develop`. Composes\nexisting skills — it does **not** reimplement them. Twin of `ship-it`, which owns\nthe implementation phase inside the worktree. The two split at the **git-worktree\nboundary**, which is also the **interactive\u002Fheadless line**.\n\n```mermaid\nflowchart LR\n  subgraph Planning [\"PLANNING — develop, human present\"]\n    A[\"new\u002Fff\u002Fcontinue\"] --> B[\"doubt-review\"]\n    B --> C[\"scenario-design + category-fold + manifest\"]\n    C --> D[\"plan-proposal (this skill)\"]\n  end\n  D -->|\"boundary: commit + spawn worktree\"| E[\"ship-it\"]\n  subgraph Implementation [\"IMPLEMENTATION — worktree\"]\n    E\n  end\n```\n\n## Hard constraint — main session only (never a subagent)\n\n`plan-proposal` MUST run in the main interactive session. It invokes\n`doubt-driven-review` (which spawns a fresh-context reviewer, and a second\ncross-model reviewer — automatically when a `@propose-review-N` role resolves,\noffered interactively only when none does; nested subagent spawn is blocked) and\n`scenario-design` (whose proposal\u002Fdesign-stage HARD gate calls `ask_user`). Both\nneed a live main session.\n\n**Guard:** if you detect you are running inside a subagent context (nested\nreviewer spawn would be blocked, or `ask_user` is unavailable), **STOP** and\nsurface: *\"plan-proposal must run in the main session — doubt-review and the\nscenario-design gate cannot run nested. Re-invoke from the main session on\n`develop`.\"* Do not degrade the doubt-review to a self-questioning fallback.\n\n## Preconditions\n\n- On the `develop` branch (planning happens on develop; the worktree is spawned\n  from the planning commit).\n- `openspec` CLI available; resolve the change name from `--change \u003Cname>`, the\n  conversation, or `openspec list --json` (ask if ambiguous).\n- Announce: *\"Planning change: `\u003Cchange>` (override with `\u002Fplan-proposal \u003Cother>`).\"*\n\n## Procedure\n\n### 1. Ensure planning artifacts exist\n\nBring the change to a drafted state using the existing generated skills — do not\nhand-roll the directory:\n\n- No change dir yet → `openspec-new-change` (or `-ff` for the fast path).\n- Partial artifacts → `openspec-continue-change`.\n\nState in the drafting request: **\"plan-proposal is driving this change\"**. The\n`openspec\u002Fconfig.yaml` `rules.tasks` rule sees it and skips its \"Run\nplan-proposal now?\" confirm (no re-entry). `rules.proposal` may still offer\npending mockups while `proposal.md` is written — that is expected; Step 1b only\nre-offers rows not declined.\n\nArtifacts live at `openspec\u002Fchanges\u002F\u003Cchange>\u002F`: `proposal.md`, `design.md` (when\nthe change warrants one), `specs\u002F**\u002Fspec.md`, `tasks.md`.\n\n**Cite code claims in `design.md`.** Instruct the author to cite the path (and\n`:line` when the statement is line-specific) for every statement in `design.md`\nabout existing code behaviour — e.g. `packages\u002Fserver\u002Fsrc\u002Fpi-core-checker.ts:42`.\nNot gated: a citation makes a wrong-file or \"does not exist\" claim cheap to spot\nbefore review.\n\n### 1b. Adopt pending mockups (idempotent backstop)\n\nBackstop for direct entry, `-continue` on an existing proposal, re-runs, and\n`SHIP_IT_BLOCKED` hand-backs. Runs after the artifacts exist, **before**\ndoubt-review, so reviewers and `scenario-design` see the mockup at its final path.\n\n1. Collect every root `mockups\u002FAGENTS.md` row whose Purpose cell ends with\n   `Pending change: \u003Cintent>`, minus rows that also carry `See change:` (owned\n   by a change — never offered), minus rows already declined in this session\n   (including a decline in the `rules.proposal` multiselect during Step 1).\n2. None left → ask nothing, change nothing, go to Step 2.\n3. Otherwise ONE `ask_user` multiselect offering every remaining row; the user\n   matches, you do not judge similarity. Unchosen rows count as declined.\n   **Live-component mocks** (entry dir with `mock.tsx`) follow their\n   `decision.json`: run `node packages\u002Fmockup-loop\u002Fsrc\u002Fmock-site\u002Fcli.mjs adoptable`\n   and offer its `options` in order with their labels (entry, intent, status) —\n   accepted first `(accepted)`, open \u002F malformed `(open)` — and never offer its\n   `skipped` (rejected) entries; report them, and every `warnings` line\n   (malformed decision files). With only rejected live mocks\n   pending, ask nothing and move nothing.\n4. Adopt each chosen entry with the mechanics of the `explore-mockup-adoption`\n   requirement (canonical, same as `rules.proposal`): File cell must resolve to\n   an entry directly under `mockups\u002F` (else skip + report); `mkdir -p\n   \u003CchangeDir>\u002Fmockups`; refuse if `\u003CchangeDir>\u002Fmockups\u002F\u003Centry>` already exists;\n   `git mv` (tracked) \u002F `mv` (untracked), never copy — a live mock dir moves\n   as ONE unit via `node packages\u002Fmockup-loop\u002Fsrc\u002Fmock-site\u002Fcli.mjs move mockups\u002F\u003Centry> \u003CchangeDir>`,\n   untracked `decision.json` included, and a source dir left behind is a failed move; only after a successful\n   move — recompute outward relative links, remove the row, add\n   `Mockup: mockups\u002F\u003Centry> (in this change)` under What Changes in\n   `proposal.md`. A failed move keeps its row.\n\nAn edited `proposal.md` is \"modified in this session\" → Step 2 reviews it.\n\n### 2. Doubt-review proposal.md + design.md (trigger: drafted or modified)\n\nWhenever `proposal.md` or `design.md` is created or changed in this session,\ninvoke `doubt-driven-review` on the changed artifact:\n\n- Pass **ARTIFACT + CONTRACT only** — never the CLAIM, never your reasoning.\n  - ARTIFACT = the proposal\u002Fdesign prose (decompose if large per doubt-review).\n  - CONTRACT = the requirements\u002Fconstraints the artifact must satisfy (the specs\n    deltas, the non-goals, the invariants it asserts).\n- **Run the spec-collateral scan before each doubt-review cycle** (the artifact\n  changes between cycles): `node scripts\u002Fspec-collateral.mjs --change \u003Cchange>`.\n  Append its output to the CONTRACT under the heading **\"Candidate conflicting\n  requirements (advisory scan) — check each\"**. The candidates are facts about\n  the corpus, not the CLAIM. If the scan cannot run or exits non-zero, report\n  the failure and proceed with the cycle without candidates — the scan never\n  blocks planning.\n- **Reviewer prompt hygiene** — the reviewer verifies claims against the\n  repository, writes `unverified` for any claim it cannot check instead of\n  asserting it, and reports every listed candidate the artifact contradicts.\n  A contradicted candidate is resolved by a MODIFIED\u002FREMOVED delta or an\n  artifact correction; \"unaffected\" is reserved for a verified false positive.\n- **Cross-model review** — runs automatically when a `@propose-review-N` role\n  resolves; surface the interactive cross-model offer only when none does.\n- **Reconcile every finding** against the artifact text using doubt-review's\n  precedence (contract-misread → actionable → trade-off → noise). When a finding\n  is valid + actionable, **PAUSE**: the artifact is corrected before proceeding.\n\nDo not fold scenarios until the doubt cycle reaches a stop condition (trivial\nfindings, 3 cycles, or explicit \"ship it\").\n\n### 3. scenario-design → category-routed fold into tasks.md (MANDATORY — never skip)\n\n**`scenario-design` is a required step, not an option.** A change never reaches\nthe worktree boundary without a `test-plan.md` manifest and its automated rows\nfolded into `tasks.md`. Do **not** hand-author test tasks, infer scenarios from\nthe proposal, or skip straight to the commit — always drive the tasks from the\n`scenario-design` output. Smoke-test-only `tasks.md` is a planning failure.\n\nRun `scenario-design` for the change (proposal\u002Fdesign stage → HARD gate; it may\n`ask_user` and STOP on a spec gap — that is expected, answer and continue). It\nwrites `openspec\u002Fchanges\u002F\u003Cchange>\u002Ftest-plan.md` — the **manifest**, carrying a\n`level` + `disposition` (`automated` | `manual-only`) per scenario row. If\n`test-plan.md` does not exist after this step, `scenario-design` did not run —\nre-invoke it before folding.\n\nThen **fold** each row into `tasks.md`:\n\n- **`automated` rows** → one vanilla `- [ ]` task each, routed to its category:\n\n  | manifest `level` | home | check-first (reuse infra) |\n  |---|---|---|\n  | L1 | `packages\u002F*\u002F**\u002F__tests__\u002F*.test.ts` (vitest) | sibling `*.test.ts` |\n  | L2 | `qa\u002Ftests\u002F*.sh` \\| `*.ps1` | existing qa test for that OS |\n  | L3 | `tests\u002Fe2e\u002F*.spec.ts` (docker harness) | existing spec for that surface |\n  | electron | `ci-electron.yml` \u002F `_electron-build.yml` | existing electron job |\n  | ci | `ci.yml` \u002F workflow-level | existing workflow assertion |\n\n  Before tasking new infra, scan for an existing test of that type to extend.\n  Each folded test task MUST carry:\n  1. a **harness-exemplar pointer** — the nearest existing spec\u002Ftest of that\n     category to copy harness glue from (e.g. `see tests\u002Fe2e\u002Freconnect.spec.ts`).\n     Bare \"author X.spec.ts\" tasks are forbidden — `ship-it` resolves the\n     exemplar path into the task context it hands `apply`.\n  2. the scenario **Triple** (`input · trigger · observable`) as plain text.\n  3. a manifest reference as ordinary prose — either `(test-plan #\u003Cid>)` or an\n     inline `(test-plan: automated)` — so `ship-it`\u002F`ship-change` can map it back.\n\n- **`manual-only` rows** → a plain manual task tagged `(test-plan: manual-only)`;\n  **no test is folded**. `ship-change` defers these post-merge (its manifest-aware\n  defer rule).\n\n**Post-fold re-scan (before Step 4):** folded tasks can introduce identifiers\nthe doubt cycles never saw, so run `node scripts\u002Fspec-collateral.mjs --change\n\u003Cchange>` once more after the fold and report every candidate not seen in the\ndoubt-review cycles. A real conflict among them returns planning to Step 2; a\ncontradicted candidate is resolved by a delta or an artifact correction —\n\"unaffected\" only for a verified false positive.\n\n**Fold-completeness gate (before Step 4):** every `automated` row in\n`test-plan.md` MUST map to exactly one folded test task in `tasks.md`, and every\n`manual-only` row MUST map to one tagged manual task. Verify the count matches\nthe manifest — if any scenario row has no corresponding task, the fold is\nincomplete; finish it before committing. Do not proceed to the boundary with an\nunfolded manifest.\n\n**Parser-safety (load-bearing):** `tasks.md` MUST stay vanilla checkbox format.\nNo custom token, no bracketed tag, no non-standard syntax on a task line — only\n`- [ ] \u003Ctext>` where the manifest reference is ordinary prose. `openspec status\n--json` and the generated `apply` skill parse this file; a stray token could\nbreak them. Verify `openspec status --change \u003Cchange> --json` reports the same\ntask counts after folding as the plain checkboxes imply.\n\n### 4. Commit planning artifacts + stop at the worktree boundary\n\n**Precondition:** `test-plan.md` exists and the fold-completeness gate passed.\nNever commit without the manifest — a missing `test-plan.md` means Step 3 was\nskipped; go back and run `scenario-design`.\n\nCommit `proposal.md`, `design.md`, `specs\u002F**`, `tasks.md`, and `test-plan.md` to\n`develop` — plus `dependencies.yaml` when the change has one (the worktree and\n`ship-it`'s dependency gate read it), plus the change's `mockups\u002F**` whenever it exists (adopted or\nwritten there directly), and, when mockups were adopted, the adoption's\nroot-side edits (`mockups\u002FAGENTS.md`, the renamed-away sources), so the\nworktree `ship-it` builds in carries the mockup. The worktree is spawned from that commit via the existing worktree\nflow (dashboard \"start work\" \u002F `git worktree add`).\n\nThen **STOP**. `plan-proposal` does not enter the implementation phase. Report:\n\n> *Planning complete for `\u003Cchange>`. Artifacts committed to `develop`; worktree\n> ready. Automated scenarios folded to tasks (manifest dispositions in\n> `test-plan.md`). **Next: run `ship-it` inside the worktree to build + ship.**\n> If a design issue surfaces during build, `ship-it` writes `SHIP_IT_BLOCKED.md`\n> and hands back here.*\n\n## Situation brief for `ask_user`\n\nEvery `ask_user` call this skill makes MUST carry a self-contained situation\nbrief in its `message` — at least 240 characters (the dashboard's\n`questions.minBriefChars` default; shorter and the server generates a brief with\nthe `@fast` model instead). The answer may be given from the global question\nstack by someone who has not seen this chat. State, in 2–4 lines:\n\n1. **Task** — what change\u002Fstep is in progress.\n2. **Why asking** — what was found or blocked that needs a human.\n3. **Per-option outcome** — what each option leads to (skip for free-text inputs).\n\nA bare question (\"Resume or hand back?\") is never enough. See change:\n`add-pending-question-stack`.\n\n## Guardrails\n\n- **Main session only** — refuse and surface if nested (see Hard constraint).\n- **Adopt pending mockups only via `ask_user`** (Step 1b) — never move a mockup\n  unasked, never re-offer a row declined this session, never copy.\n- **Never pass the CLAIM to the reviewer**; ARTIFACT + CONTRACT only.\n- **Never fold before reconciling** actionable doubt-review findings.\n- **`tasks.md` stays vanilla** — the manifest (`test-plan.md`), not a task tag,\n  is the automated-vs-manual source of truth.\n- **`scenario-design` is mandatory** — no `test-plan.md`, no commit. Never\n  hand-author test tasks or skip scenario design; the manifest is the sole\n  source of the folded test tasks.\n- **Fold every manifest row** — the boundary is blocked until every `automated`\n  and `manual-only` row maps to a task.\n- **Never author test\u002Fapp code here** — folding writes *tasks*; `ship-it` authors\n  the tests. This skill plans; it does not implement.\n- **Stop at the boundary** — do not continue into implementation.\n\n## Composed skills\n\n`openspec-new-change` \u002F `-ff` \u002F `-continue` · `doubt-driven-review` ·\n`scenario-design` (+ its `test-plan.md` manifest) · handoff to `ship-it`.\n",{"name":5,"metadata":49,"description":7},{"scope":41,"version":50},"1.0","develop","98ae265a36b140597cf0f6428bef208bad34b140",".pi\u002Fskills\u002Fplan-proposal",56,"https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard","https:\u002F\u002Fpi-dashboard.dev\u002F","https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology","https:\u002F\u002Fwww.blackbelt.hu","2026-11-12 23:37:37",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add BlackBeltTechnology\u002Fpi-agent-dashboard --skill plan-proposal",{"tool":66,"command":67},"bunx","bunx skills add BlackBeltTechnology\u002Fpi-agent-dashboard --skill plan-proposal",{"tool":69,"command":70},"pnpm","pnpm dlx skills add BlackBeltTechnology\u002Fpi-agent-dashboard --skill plan-proposal","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard\u002Fblob\u002Fdevelop\u002F.pi\u002Fskills\u002Fplan-proposal\u002FSKILL.md",true,[],[75,106,137,159,183,206],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":84,"publishedAt":44},"01M6HQYQ5B82AM5T9Y299S9CFY","youtube-srt","Download YouTube subtitles (SRT + timestamped TXT) for a channel, playlist or video via yt-dlp, no media download; optionally mine them into a categorized catalog (e.g. AI models by function, open weights, local runnability, hardware tier). Use on \"download the srt of this video\", \"transcripts of channel X for the last N months\", \"catalog the models AI Search talked about\", \"update docs\u002Fmodels\".","https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard\u002Fblob\u002Fdevelop\u002Fpackages\u002Fvideo-transcription\u002F.pi\u002Fskills\u002Fyoutube-srt\u002FSKILL.md",[81],{"categoryNo":82,"categoryName":83,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105],"youtube","srt","youtube srt","update","search","subtitles","dlp","Video","Media","open","catalog","use","update docs","yt-dlp","local","mine","via","ai models","last","for","media download",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":116,"publishedAt":44},"01M6HQYJBKSXR55T5RSYNJQG4D","video-transcription","Transcribe video and audio files to SRT subtitles with speaker diarization using the Soniox (default) or AssemblyAI API. Use when the user wants to transcribe meetings, videos, or audio files. Supports MKV, MP4, MOV, M4A, MP3. Triggers on \"\u002Ftranscribe\", \"transcribe my meetings\", \"transcribe videos in ~\u002FMovies\", or any request to convert audio\u002Fvideo to text.","https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard\u002Fblob\u002Fdevelop\u002Fpackages\u002Fvideo-transcription\u002F.pi\u002Fskills\u002Fvideo-transcription\u002FSKILL.md",[112,115],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":82,"categoryName":83,"taxonomyType":21,"taxonomyTypeDesc":22},[92,117,118,119,90,120,121,122,123,124,125,96,126,127,128,129,130,131,132,86,133,134,135,136],"transcription","video transcription","transcribe","api","Audio","convert","mp4","text","meetings","files","default","mp3","triggers","with","videos","assemblyai","my","srt subtitles","request","when",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":44},"01M6HQYECMVDC5TDHHW22VC5RX","speaker-id","Name anonymous diarized SRT speakers from a persistent local voiceprint library and repair speaker drift; local, CPU-only, no API key. Triggers \"who is speaker 2\", \"put names on the transcript\", \"label the meeting SRT\", \"the diarization split one person into three\", \"enroll my voice\". Backed by the pi-voiceid CLI.","https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard\u002Fblob\u002Fdevelop\u002Fpackages\u002Fvideo-transcription\u002F.pi\u002Fskills\u002Fspeaker-id\u002FSKILL.md",[],[144,145,146,147,120,148,149,39,150,151,152,99,129,153,154,155,156,86,157,158],"id","speaker id","cli","transcript","voice","pi","three","drift","repair","name","CPU","meeting","anonymous","split","person",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":168,"publishedAt":44},"01M6HQYAZWDXE9QJEG592E5PXK","veo-showreel-production-kit","Turn a video timeline + voiceover into a reproducible, sliceable Veo 3.1 prompt package with a consistency anchor and AI storyboard sketches.","https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard\u002Fblob\u002Fdevelop\u002Fpackages\u002Fvideo-production\u002F.pi\u002Fskills\u002Fveo-showreel-production-kit\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[169,170,171,172,173,174,175,92,176,177,178,179,130,180,181,182],"Production","veo","kit","veo showreel production kit","package","Reproducible","timeline","prompt","voiceover","storyboard","anchor","consistency","veo 3","2026",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":191,"publishedAt":44},"01M6HQY6TJ0X1ADDKYPMVJY6NV","veo-generator","Render a scripted video project into mp4 clips with the Google Veo 3.1 API. Reads a project's shot package (shots\u002F*.md), one clip per camera cut, reusing each shot's prompt and sketch — world anchor only with `--with-reference`, seed unless `--no-seed`. Use on \"render the Veo video for \u003Cproject>\", \"generate the videos from the shot scripts\", \"make the clips with Veo\".","https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard\u002Fblob\u002Fdevelop\u002Fpackages\u002Fvideo-production\u002F.pi\u002Fskills\u002Fveo-generator\u002FSKILL.md",[189,190],{"categoryNo":82,"categoryName":83,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},[170,192,193,194,195,173,120,92,123,176,96,196,39,197,198,199,200,41,179,201,202,203,204,130,205,104,181],"generator","veo generator","google","generate","clip","sketch","camera","world","seed","cut","scripts","make","render","google veo",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":212,"publishedAt":44},"01M6HQY1K2NZJ3B2YHSJJPPVAF","hyperframes-showreel","Turn real screen and site footage into a rhythmic showreel rendered with HyperFrames: sampling, edit script, redacted clips, a generated composition, Veo only as additive FX, music edit + camera punches, delivery render and export QA. Use on \"make a showreel from these recordings\", \"build the HyperFrames video\", \"assemble the footage edit\", \"render and QA the showreel\".","https:\u002F\u002Fgithub.com\u002FBlackBeltTechnology\u002Fpi-agent-dashboard\u002Fblob\u002Fdevelop\u002Fpackages\u002Fvideo-production\u002F.pi\u002Fskills\u002Fhyperframes-showreel\u002FSKILL.md",[],[213,214,215,92,216,217,218,96,219,220,221,39,222,223,224,225,226,204,130,227],"hyperframes","hyperframes showreel","qa","Composition","edit","generated","assemble","export","sampling","build","delivery","as","fx","screen","script"]