[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71J3ECNXPHPRBA6T5X7MA2F":3,"skill-same:01M71J3ECNXPHPRBA6T5X7MA2F":67},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":6,"updatedAt":53,"install":54,"resources":66},"01M71J3ECNXPHPRBA6T5X7MA2F","plan-release",null,"RELEASE-INDEX BUILDER — Sequence elaborated epics into specs\u002Frelease-plan.yaml with WSJF ordering and BCP baselines. NOT a planning-spine substitute: it does not scope work (scope-work) or write story tasks (plan-work). Use after elaborate-spec when the user wants a versioned release index of epics.","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",289,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Fplan-release\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"release","plan release","plan","scope work","spec","WSJF","with","use","true","planning","sonnet","sequence","write","spine","work","tasks","when","scope","bcp","builder","2026-11-10 10:12:30",false,"---\nname: plan-release\nmodel: sonnet\ndescription: \"RELEASE-INDEX BUILDER — Sequence elaborated epics into specs\u002Frelease-plan.yaml with WSJF ordering and BCP baselines. NOT a planning-spine substitute: it does not scope work (scope-work) or write story tasks (plan-work). Use after elaborate-spec when the user wants a versioned release index of epics.\"\ndisable-model-invocation: true\n---\n\n# Plan Release\n\n> **HARD GATE** — Do NOT run this skill unless `elaborate-spec` has produced a clear spec or the user has already defined the feature in detail. If the problem is still fuzzy, run `elaborate-spec` first.\n> **HARD GATE** — `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` (or legacy `specs\u002Fproduct\u002FSCOPE_LATEST.yaml`) must exist. If missing, run `scope-work` first.\n\nSynthesize the conversation context into `specs\u002Frelease-plan.yaml` (index) and shard detail under `specs\u002Fepics\u002F`. No new interview — only clarify if something is genuinely ambiguous.\n\n## Outputs\n\n| File | Content |\n|------|---------|\n| `specs\u002Frelease-plan.yaml` | `release.version`, semver bump hint, WSJF-ordered epic list with `id`, `capsule_dir`, `wsjf`, `bcps` — **no story status** |\n| `specs\u002Fepics\u002FeNN-\u003Cslug>\u002Fepic.yaml` | Epic manifest: `id`, `title`, `wsjf`, `total_bcps`, `status`, `stories[]` list |\n| `specs\u002Fepics\u002FeNN-\u003Cslug>\u002FeNNsYY-\u003Cslug>.md` | Story spec in [countable-story-format.md](..\u002F..\u002Fdocs\u002Fcountable-story-format.md) with 20 sections and Gherkin acceptance criteria |\n| `specs\u002Fepics\u002FeNN-\u003Cslug>\u002FeNNsYY-tasks.yaml` | Decoupled task checklist with `verify:` commands per task |\n| `specs\u002Fexecution-status.yaml` | Flat key-value store for story status (`eNNsYY: todo`) |\n\n## Epic Capsule Structure\n\nAll epics use capsule directories (no flat\u002Ffolder distinction):\n\n```\nspecs\u002Fepics\u002Fe01-auth-system\u002F\n├── epic.yaml              # Epic manifest\n├── adr\u002F                   # Epic-local ADRs (created lazily)\n├── e01s01-login.md        # Story spec (countable-story-format)\n├── e01s01-tasks.yaml      # Decoupled task checklist\n├── e01s02-jwt.md          # Story spec\n└── e01s02-tasks.yaml      # Decoupled task checklist\n```\n\n**Rationale:** Capsule dirs achieve change isolation (C9), enable archive pruning (C2\u002FC6), and enforce SRP by decoupling spec `.md` from execution `-tasks.yaml` (C1).\n\n## Process\n### 1. Draft epics and stories\n\nFrom the conversation context, define:\n- **Epics** — `e01`, `e02`, … (stable IDs; WSJF order in `release-plan.yaml` only)\n- **Stories** — `e01s01`, `e01s02`, … with Gherkin acceptance criteria\n\nWSJF-sort epics: score = (Business Value + Time Criticality + Risk Reduction) \u002F Job Size. Highest score first.\n\n> **Security risk boost:** If an epic's `specs\u002Fsecurity\u002Fepics\u002F\u003Cid>\u002FTHREAT_MODEL.md` identifies HIGH or CRITICAL risk, add +2 to the WSJF numerator (BV + TC + RR + 2) to reflect the urgency of addressing security concerns before they ship. Document the boost in the epic's note field in release-plan.yaml.\n### 2. Write acceptance criteria (Gherkin)\n\nFor each story, write at least one happy-path and one edge-case scenario (countable format §17 if maturity ≥ 3).\n### 3. Write tasks with verify commands\n\nEvery task must have a `verify:` command. No verify command = not a task.\n### 4. Save specs\u002Frelease-plan.yaml\n\n> **Do NOT hand-track the real version.** semantic-release decides it at merge. `version` here is a\n> non-authoritative mirror\u002Flabel only — read the real number with `gh release view`. Set `bump_hint`\n> (the expectation), not a number you intend to enforce.\n\n```yaml\nrelease:\n  version: \"2.29.0\"         # mirror of next expected tag, NOT authoritative — gh release view wins\n  codename: \"Feature Name\"\n  status: planning          # planning | in_progress | released\n  semantic_release: true\n  bump_hint: minor          # patch | minor | major — CI decides at merge\nepics:\n  - id: e01\n    title: Auth System\n    wsjf: 4.5\n    capsule_dir: epics\u002Fe01-auth-system\n  - id: e02\n    title: User Profile\n    wsjf: 3.8\n    capsule_dir: epics\u002Fe02-user-profile\n```\n### 5. Save epic manifest (`epic.yaml`)\n\nEach epic capsule directory contains an `epic.yaml` manifest:\n\n```yaml\nid: e01\ntitle: Auth System\nwsjf: 4.5\ntotal_bcps: 8\nstatus: in_progress\nstories:\n  - id: e01s01\n    title: Login\n    bcps: 3\n    status: todo\n    spec: e01s01-login.md\n    tasks: e01s01-tasks.yaml\n  - id: e01s02\n    title: JWT Token Management\n    bcps: 5\n    status: todo\n    spec: e01s02-jwt.md\n    tasks: e01s02-tasks.yaml\n```\n### 6. Save story specs (countable-story-format .md)\n\nEach story becomes a standalone `.md` file following [countable-story-format.md](..\u002F..\u002Fdocs\u002Fcountable-story-format.md). Minimum: maturity 3 (Countable) with all 20 sections present. Acceptance criteria in §17 use Gherkin scenarios.\n### 7. Save decoupled task files (`-tasks.yaml`)\n\nEach story has a decoupled `-tasks.yaml` with implementation steps:\n\n```yaml\nstory_id: e01s01\ntitle: Login\nstatus: todo\nbcps: 3\ntasks:\n  - id: 1\n    description: \"Add login form component tests\"\n    verify: \"npm test -- login-form.test.tsx\"\n    status: todo\n  - id: 2\n    description: \"Implement login form with validation\"\n    verify: \"npm test -- login-form.test.tsx\"\n    status: todo\n```\n\n> **HARD GATE** — Every task MUST have a runnable `verify:` command. No `verify:` = not a task.\n\n→ verify: `bash scripts\u002Fvalidate-specs-yaml.sh`\n### 7b. Generate bug registry summary\n\nRead `specs\u002Fbugs\u002Fregistry.yaml` and add a `bugs:` section to `release-plan.yaml` with totals by status (`fixed`, `deferred`, `wontfix`, `open`): `bugs: { total: N, fixed: N, deferred: N, wontfix: N, registry: specs\u002Fbugs\u002Fregistry.yaml }`.\n\n### 8. Sync execution status\n\n```bash\nbash scripts\u002Fsync-status-from-epics.sh\n```\n### 9. Snapshot on planning close (optional)\n\nCopy to `specs\u002Fproduct\u002Fsnapshots\u002Frelease-\u003Cversion>\u002F` when the user approves the plan.\n### 10. Suggest next steps\n\n- Run `assess-impact` before `plan-work` for any story touching existing modules.\n- Run `plan-work` per story for detailed steps inside the epic shard.\n- Run `change-request` if a new requirement arrives mid-flight.\n","# Plan Release\n\n> **HARD GATE** — Do NOT run this skill unless `elaborate-spec` has produced a clear spec or the user has already defined the feature in detail. If the problem is still fuzzy, run `elaborate-spec` first.\n> **HARD GATE** — `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` (or legacy `specs\u002Fproduct\u002FSCOPE_LATEST.yaml`) must exist. If missing, run `scope-work` first.\n\nSynthesize the conversation context into `specs\u002Frelease-plan.yaml` (index) and shard detail under `specs\u002Fepics\u002F`. No new interview — only clarify if something is genuinely ambiguous.\n\n## Outputs\n\n| File | Content |\n|------|---------|\n| `specs\u002Frelease-plan.yaml` | `release.version`, semver bump hint, WSJF-ordered epic list with `id`, `capsule_dir`, `wsjf`, `bcps` — **no story status** |\n| `specs\u002Fepics\u002FeNN-\u003Cslug>\u002Fepic.yaml` | Epic manifest: `id`, `title`, `wsjf`, `total_bcps`, `status`, `stories[]` list |\n| `specs\u002Fepics\u002FeNN-\u003Cslug>\u002FeNNsYY-\u003Cslug>.md` | Story spec in [countable-story-format.md](..\u002F..\u002Fdocs\u002Fcountable-story-format.md) with 20 sections and Gherkin acceptance criteria |\n| `specs\u002Fepics\u002FeNN-\u003Cslug>\u002FeNNsYY-tasks.yaml` | Decoupled task checklist with `verify:` commands per task |\n| `specs\u002Fexecution-status.yaml` | Flat key-value store for story status (`eNNsYY: todo`) |\n\n## Epic Capsule Structure\n\nAll epics use capsule directories (no flat\u002Ffolder distinction):\n\n```\nspecs\u002Fepics\u002Fe01-auth-system\u002F\n├── epic.yaml              # Epic manifest\n├── adr\u002F                   # Epic-local ADRs (created lazily)\n├── e01s01-login.md        # Story spec (countable-story-format)\n├── e01s01-tasks.yaml      # Decoupled task checklist\n├── e01s02-jwt.md          # Story spec\n└── e01s02-tasks.yaml      # Decoupled task checklist\n```\n\n**Rationale:** Capsule dirs achieve change isolation (C9), enable archive pruning (C2\u002FC6), and enforce SRP by decoupling spec `.md` from execution `-tasks.yaml` (C1).\n\n## Process\n### 1. Draft epics and stories\n\nFrom the conversation context, define:\n- **Epics** — `e01`, `e02`, … (stable IDs; WSJF order in `release-plan.yaml` only)\n- **Stories** — `e01s01`, `e01s02`, … with Gherkin acceptance criteria\n\nWSJF-sort epics: score = (Business Value + Time Criticality + Risk Reduction) \u002F Job Size. Highest score first.\n\n> **Security risk boost:** If an epic's `specs\u002Fsecurity\u002Fepics\u002F\u003Cid>\u002FTHREAT_MODEL.md` identifies HIGH or CRITICAL risk, add +2 to the WSJF numerator (BV + TC + RR + 2) to reflect the urgency of addressing security concerns before they ship. Document the boost in the epic's note field in release-plan.yaml.\n### 2. Write acceptance criteria (Gherkin)\n\nFor each story, write at least one happy-path and one edge-case scenario (countable format §17 if maturity ≥ 3).\n### 3. Write tasks with verify commands\n\nEvery task must have a `verify:` command. No verify command = not a task.\n### 4. Save specs\u002Frelease-plan.yaml\n\n> **Do NOT hand-track the real version.** semantic-release decides it at merge. `version` here is a\n> non-authoritative mirror\u002Flabel only — read the real number with `gh release view`. Set `bump_hint`\n> (the expectation), not a number you intend to enforce.\n\n```yaml\nrelease:\n  version: \"2.29.0\"         # mirror of next expected tag, NOT authoritative — gh release view wins\n  codename: \"Feature Name\"\n  status: planning          # planning | in_progress | released\n  semantic_release: true\n  bump_hint: minor          # patch | minor | major — CI decides at merge\nepics:\n  - id: e01\n    title: Auth System\n    wsjf: 4.5\n    capsule_dir: epics\u002Fe01-auth-system\n  - id: e02\n    title: User Profile\n    wsjf: 3.8\n    capsule_dir: epics\u002Fe02-user-profile\n```\n### 5. Save epic manifest (`epic.yaml`)\n\nEach epic capsule directory contains an `epic.yaml` manifest:\n\n```yaml\nid: e01\ntitle: Auth System\nwsjf: 4.5\ntotal_bcps: 8\nstatus: in_progress\nstories:\n  - id: e01s01\n    title: Login\n    bcps: 3\n    status: todo\n    spec: e01s01-login.md\n    tasks: e01s01-tasks.yaml\n  - id: e01s02\n    title: JWT Token Management\n    bcps: 5\n    status: todo\n    spec: e01s02-jwt.md\n    tasks: e01s02-tasks.yaml\n```\n### 6. Save story specs (countable-story-format .md)\n\nEach story becomes a standalone `.md` file following [countable-story-format.md](..\u002F..\u002Fdocs\u002Fcountable-story-format.md). Minimum: maturity 3 (Countable) with all 20 sections present. Acceptance criteria in §17 use Gherkin scenarios.\n### 7. Save decoupled task files (`-tasks.yaml`)\n\nEach story has a decoupled `-tasks.yaml` with implementation steps:\n\n```yaml\nstory_id: e01s01\ntitle: Login\nstatus: todo\nbcps: 3\ntasks:\n  - id: 1\n    description: \"Add login form component tests\"\n    verify: \"npm test -- login-form.test.tsx\"\n    status: todo\n  - id: 2\n    description: \"Implement login form with validation\"\n    verify: \"npm test -- login-form.test.tsx\"\n    status: todo\n```\n\n> **HARD GATE** — Every task MUST have a runnable `verify:` command. No `verify:` = not a task.\n\n→ verify: `bash scripts\u002Fvalidate-specs-yaml.sh`\n### 7b. Generate bug registry summary\n\nRead `specs\u002Fbugs\u002Fregistry.yaml` and add a `bugs:` section to `release-plan.yaml` with totals by status (`fixed`, `deferred`, `wontfix`, `open`): `bugs: { total: N, fixed: N, deferred: N, wontfix: N, registry: specs\u002Fbugs\u002Fregistry.yaml }`.\n\n### 8. Sync execution status\n\n```bash\nbash scripts\u002Fsync-status-from-epics.sh\n```\n### 9. Snapshot on planning close (optional)\n\nCopy to `specs\u002Fproduct\u002Fsnapshots\u002Frelease-\u003Cversion>\u002F` when the user approves the plan.\n### 10. Suggest next steps\n\n- Run `assess-impact` before `plan-work` for any story touching existing modules.\n- Run `plan-work` per story for detailed steps inside the epic shard.\n- Run `change-request` if a new requirement arrives mid-flight.\n",{"name":5,"model":29,"description":7,"disable-model-invocation":44},true,"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Fplan-release",24,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":44},[56,59,62],{"tool":57,"command":58},"npx","npx skills add danielvm-git\u002Fbigpowers --skill plan-release",{"tool":60,"command":61},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill plan-release",{"tool":63,"command":64},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill plan-release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Fplan-release\u002FSKILL.md",[],[68,89,96,122,145,165],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":79,"publishedAt":39},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[74],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[80,81,82,83,84,85,86,87,88],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":90,"name":91,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":39},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[95,85],"negative path",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":105,"publishedAt":39},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[102],{"categoryNo":103,"categoryName":104,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000002","文档处理",[31,106,107,108,109,110,111,112,113,114,26,35,115,116,29,117,118,119,120,121],"write document","document","documents","actionable","technical","methodology","high","bmad","standard","minimal","bold","integrity","organize","sync","directory","guides",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":39},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[129,130,131,114,132,26,133,134,135,136,29,137,138,139,140,141,142,35,143,144],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":39},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[152,153,154,155,156,157,158,159,160,161,25,114,162,87,129,29,163,164],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","ci pipeline setup","git","workflows",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":182,"publishedAt":39},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[171,174,179],{"categoryNo":172,"categoryName":173,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":175,"categoryName":176,"taxonomyType":177,"taxonomyTypeDesc":178},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":180,"categoryName":181,"taxonomyType":177,"taxonomyTypeDesc":178},"01JBSEEDCAT000000000000033","数据分析师",[183,184,185,186,187,188,189,28,190,29,191,19,192,21,193,194,195,143,196,197],"dashboard","visual","visual dashboard","status","artifacts","http","plans","panel","start","opencode","browser","api","architecture","project status","http api"]