[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JM3J66KG54CWHM0AMPPV0":3,"skill-same:01M71JM3J66KG54CWHM0AMPPV0":72},{"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":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71JM3J66KG54CWHM0AMPPV0","survey-context",null,"Per-task context bootstrap — reads existing specs\u002F and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first.","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",292,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsurvey-context\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"survey context","context","survey","scratch","lifecycle","for","tech","do","suggest","doc","start","at","break","next","haiku","stack","phase","architecture","when","map","2026-11-10 10:12:30",false,"---\nname: survey-context\nmodel: haiku\ndescription: \"Per-task context bootstrap — reads existing specs\u002F and tech-architecture docs to map the current lifecycle phase and suggest the next skill. Use at the start of any task, when returning after a break, or when unsure what to do next. For deriving a tech-stack doc from scratch, use map-codebase first.\"\n---\n\n\u003C!-- story: e82s02 -->\n\n# Survey Context\n\nRead the project's current state and give a phase map + next-skill recommendation. This is the \"where am I?\" skill — run it at the start of every task.\n\n> **Use this vs map-codebase:** `survey-context` consumes existing specs and docs (fast; does not re-derive). `map-codebase` builds the tech-stack doc from scratch by scanning the codebase. Run `map-codebase` when `specs\u002Ftech-architecture\u002Ftech-stack.md` doesn't exist yet; run `survey-context` when it does.\n\n> **HARD GATE** — Read specs\u002F files before suggesting next steps. If state.yaml is stale or contradicts the codebase, request clarification rather than assuming intent.\n\nOrchestrate-project 6 phases: Phase 1 Discover - Phase 2 Elaborate - Phase 3 Plan - Phase 4 Build - Phase 5 Verify - Phase 6 Release\n\n## Process\n\n> **Timing:** `bash scripts\u002Fbp-timing.sh start survey-context` at invocation; `bash scripts\u002Fbp-timing.sh end survey-context` before handoff.\n\n### 1. Read CONVENTIONS.md\n\nIf `CONVENTIONS.md` exists at the project root, read it first. It contains the rules all agents must follow in this project.\n\n### 2. Read specs\u002F (YAML-first)\n\nScan the `specs\u002F` directory if it exists:\n\n```\nspecs\u002F\n├── state.yaml                  → session: active_flow, epic, git, handoff\n├── release-plan.yaml           → target version, WSJF epic index\n├── execution-status.yaml       → flat story\u002Fepic status\n├── planning-status.yaml        → discover-phase checklist (optional)\n├── requirements\u002F\n│   ├── VISION_LATEST.yaml\n│   ├── SCOPE_LATEST.yaml\n│   └── GLOSSARY_LATEST.yaml\n├── plans\u002F                      → TECH_STACK, TEST_PLAN, etc.\n├── epics\u002F                      → eNN shards (flat yaml or eNN\u002Fstories\u002F)\n└── bugs\u002F                       → BUG-*.md + registry.yaml\n```\n\nFor each YAML file found, note: exists? keys populated? `handoff.next_skill`?\n\nLegacy markdown (`specs\u002Farchive\u002FSTATE.md`, `RELEASE-PLAN.md`) is **not** SoT if YAML exists.\n\n→ verify: `bash scripts\u002Fvalidate-specs-yaml.sh`\n\n### 3. Read CLAUDE.md\n\nIf `CLAUDE.md` exists at the project root, read it for project context (stack, commands, architecture, conventions).\n\n### 4. Check VCS state\n\nRead `state.yaml` `vcs.kind` (or resolve `auto`). Use native identity:\n\n```bash\n# Git\ngit status --short; git log --oneline -5; git branch --show-current\n# Jujutsu\njj status; jj log -r 'mine() & ::@' -n 5\n```\n\nFor Jujutsu, compare stable change IDs and bookmarks with the `vcs` block; never interpret colocated Git's detached HEAD as branch state.\n\n### 5. Map the lifecycle phase\n\nBased on what you've found, identify which PMBOK phase this project is currently in:\n\n| Phase | Signals |\n|-------|---------|\n| **Discover** | No `requirements\u002FSCOPE_LATEST.yaml` yet, or only rough notes |\n| **Design** | SCOPE exists but no `release-plan.yaml` |\n| **Plan** | `release-plan.yaml` exists; on `main`\u002F`master` branch |\n| **Initiate** | On a feature branch; no code changes yet |\n| **Execute** | `state.yaml` `active_flow: build_epic`; epic capsule in progress |\n| **Verify** | Implementation done; run `verify-work` or `run-evals` |\n| **Bug** | `state.yaml` `active_flow: fix_bug` or open `specs\u002Fbugs\u002FBUG-*.md` |\n| **Review** | All code written; no PR yet |\n| **Integrate** | PR open; tests passing |\n| **Sustain** | Ongoing; no active task |\n\nPrefer `specs\u002Fstate.yaml` `active_flow` and `handoff.next_skill` when present.\n\n### 6. Suggest next skill\n\nBased on the phase and state, recommend the most useful next step:\n\n- **If in Plan\u002FBug phase and on `main`**: Suggest `kickoff-branch` next.\n- **If in Initiate phase**: Suggest `develop-tdd` or `execute-plan` or `ship-epic`.\n- **If in Execute phase**: Suggest `ship-epic` (resume) or `develop-tdd` for `active_story_id`.\n- **If in Verify phase**: Suggest `verify-work` (UAT) or `run-evals`.\n\nExample:\n```\nPhase: Execute\nActive branch: feat\u002Fe02-verify (state.yaml matches)\nrelease-plan.yaml: v3.0.0, 10 epics\nactive_epic_id: e02\n\nSuggested next: ship-epic (resume e02s01 at develop-tdd)\n```\n\nBe specific — name the exact skill and why. If multiple options exist, list them in priority order.\n\n### 7. Surface blockers\n\nIf something looks wrong:\n- Broken tests in the baseline\n- Open `specs\u002Fbugs\u002FBUG-*.md` with no active fix branch\n- Epic shards missing `verify:` on tasks\n- `validate-specs-yaml.sh` fails\n- Git hash in `state.yaml` stale vs `git rev-parse`\n\nReport blockers first, before recommendations.\n\n### 8. Record story start timestamp\n\nAt story start, write `metrics.story_start` with the current ISO 8601 timestamp to `specs\u002Fstate.yaml` as an **informational progress marker only** — not a measurement input. Cycle-time metrics are now derived from git commit history via `scripts\u002Frecord-cycle-time.sh` (see `skills\u002Frelease-branch\u002FREFERENCE.md` §Cycle-time recording).\n\n## Utility outputs\n\n### list-epics (absorbed)\n\nLoop through all `specs\u002Fepics\u002F*\u002Fepic.yaml` files and print a summary of story counts per epic. Useful for understanding overall project scope and epic distribution.\n\n### check-gates (absorbed)\n\nPrint `active_flow`, validate YAML, then show `git status` or `jj status` according to `vcs.kind`. Use before handoffs or context transitions.\n\n## Handoff\n\nGate: READY -> next: plan-work\nWrites: state.yaml handoff.next_skill = plan-work\n\n\n\u003C!-- story: e03s03 -->\n","\u003C!-- story: e82s02 -->\n\n# Survey Context\n\nRead the project's current state and give a phase map + next-skill recommendation. This is the \"where am I?\" skill — run it at the start of every task.\n\n> **Use this vs map-codebase:** `survey-context` consumes existing specs and docs (fast; does not re-derive). `map-codebase` builds the tech-stack doc from scratch by scanning the codebase. Run `map-codebase` when `specs\u002Ftech-architecture\u002Ftech-stack.md` doesn't exist yet; run `survey-context` when it does.\n\n> **HARD GATE** — Read specs\u002F files before suggesting next steps. If state.yaml is stale or contradicts the codebase, request clarification rather than assuming intent.\n\nOrchestrate-project 6 phases: Phase 1 Discover - Phase 2 Elaborate - Phase 3 Plan - Phase 4 Build - Phase 5 Verify - Phase 6 Release\n\n## Process\n\n> **Timing:** `bash scripts\u002Fbp-timing.sh start survey-context` at invocation; `bash scripts\u002Fbp-timing.sh end survey-context` before handoff.\n\n### 1. Read CONVENTIONS.md\n\nIf `CONVENTIONS.md` exists at the project root, read it first. It contains the rules all agents must follow in this project.\n\n### 2. Read specs\u002F (YAML-first)\n\nScan the `specs\u002F` directory if it exists:\n\n```\nspecs\u002F\n├── state.yaml                  → session: active_flow, epic, git, handoff\n├── release-plan.yaml           → target version, WSJF epic index\n├── execution-status.yaml       → flat story\u002Fepic status\n├── planning-status.yaml        → discover-phase checklist (optional)\n├── requirements\u002F\n│   ├── VISION_LATEST.yaml\n│   ├── SCOPE_LATEST.yaml\n│   └── GLOSSARY_LATEST.yaml\n├── plans\u002F                      → TECH_STACK, TEST_PLAN, etc.\n├── epics\u002F                      → eNN shards (flat yaml or eNN\u002Fstories\u002F)\n└── bugs\u002F                       → BUG-*.md + registry.yaml\n```\n\nFor each YAML file found, note: exists? keys populated? `handoff.next_skill`?\n\nLegacy markdown (`specs\u002Farchive\u002FSTATE.md`, `RELEASE-PLAN.md`) is **not** SoT if YAML exists.\n\n→ verify: `bash scripts\u002Fvalidate-specs-yaml.sh`\n\n### 3. Read CLAUDE.md\n\nIf `CLAUDE.md` exists at the project root, read it for project context (stack, commands, architecture, conventions).\n\n### 4. Check VCS state\n\nRead `state.yaml` `vcs.kind` (or resolve `auto`). Use native identity:\n\n```bash\n# Git\ngit status --short; git log --oneline -5; git branch --show-current\n# Jujutsu\njj status; jj log -r 'mine() & ::@' -n 5\n```\n\nFor Jujutsu, compare stable change IDs and bookmarks with the `vcs` block; never interpret colocated Git's detached HEAD as branch state.\n\n### 5. Map the lifecycle phase\n\nBased on what you've found, identify which PMBOK phase this project is currently in:\n\n| Phase | Signals |\n|-------|---------|\n| **Discover** | No `requirements\u002FSCOPE_LATEST.yaml` yet, or only rough notes |\n| **Design** | SCOPE exists but no `release-plan.yaml` |\n| **Plan** | `release-plan.yaml` exists; on `main`\u002F`master` branch |\n| **Initiate** | On a feature branch; no code changes yet |\n| **Execute** | `state.yaml` `active_flow: build_epic`; epic capsule in progress |\n| **Verify** | Implementation done; run `verify-work` or `run-evals` |\n| **Bug** | `state.yaml` `active_flow: fix_bug` or open `specs\u002Fbugs\u002FBUG-*.md` |\n| **Review** | All code written; no PR yet |\n| **Integrate** | PR open; tests passing |\n| **Sustain** | Ongoing; no active task |\n\nPrefer `specs\u002Fstate.yaml` `active_flow` and `handoff.next_skill` when present.\n\n### 6. Suggest next skill\n\nBased on the phase and state, recommend the most useful next step:\n\n- **If in Plan\u002FBug phase and on `main`**: Suggest `kickoff-branch` next.\n- **If in Initiate phase**: Suggest `develop-tdd` or `execute-plan` or `ship-epic`.\n- **If in Execute phase**: Suggest `ship-epic` (resume) or `develop-tdd` for `active_story_id`.\n- **If in Verify phase**: Suggest `verify-work` (UAT) or `run-evals`.\n\nExample:\n```\nPhase: Execute\nActive branch: feat\u002Fe02-verify (state.yaml matches)\nrelease-plan.yaml: v3.0.0, 10 epics\nactive_epic_id: e02\n\nSuggested next: ship-epic (resume e02s01 at develop-tdd)\n```\n\nBe specific — name the exact skill and why. If multiple options exist, list them in priority order.\n\n### 7. Surface blockers\n\nIf something looks wrong:\n- Broken tests in the baseline\n- Open `specs\u002Fbugs\u002FBUG-*.md` with no active fix branch\n- Epic shards missing `verify:` on tasks\n- `validate-specs-yaml.sh` fails\n- Git hash in `state.yaml` stale vs `git rev-parse`\n\nReport blockers first, before recommendations.\n\n### 8. Record story start timestamp\n\nAt story start, write `metrics.story_start` with the current ISO 8601 timestamp to `specs\u002Fstate.yaml` as an **informational progress marker only** — not a measurement input. Cycle-time metrics are now derived from git commit history via `scripts\u002Frecord-cycle-time.sh` (see `skills\u002Frelease-branch\u002FREFERENCE.md` §Cycle-time recording).\n\n## Utility outputs\n\n### list-epics (absorbed)\n\nLoop through all `specs\u002Fepics\u002F*\u002Fepic.yaml` files and print a summary of story counts per epic. Useful for understanding overall project scope and epic distribution.\n\n### check-gates (absorbed)\n\nPrint `active_flow`, validate YAML, then show `git status` or `jj status` according to `vcs.kind`. Use before handoffs or context transitions.\n\n## Handoff\n\nGate: READY -> next: plan-work\nWrites: state.yaml handoff.next_skill = plan-work\n\n\n\u003C!-- story: e03s03 -->\n",{"name":5,"model":38,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".pi\u002Fskills\u002Fsurvey-context",23,"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":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add danielvm-git\u002Fbigpowers --skill survey-context",{"tool":64,"command":65},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill survey-context",{"tool":67,"command":68},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill survey-context","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.pi\u002Fskills\u002Fsurvey-context\u002FSKILL.md",true,[],[73,89,96,125,146,167],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":80,"publishedAt":44},"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",[79],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[81,82,83,84,85,86,87,29,88],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","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":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[95,86],"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":44},"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":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",[106,107,108,109,110,111,112,113,114,115,116,42,117,118,119,120,121,122,123,124],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","use","minimal","bold","sonnet","integrity","organize","sync","directory","guides",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":44},"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",[],[132,133,134,115,135,116,136,137,138,139,119,140,35,141,142,143,40,42,144,145],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","structured logging","production-readiness","idempotent","project","scripts",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":44},"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",[],[153,154,155,156,157,158,159,160,161,162,163,115,164,29,132,119,165,166],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":184,"publishedAt":44},"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",[173,176,181],{"categoryNo":174,"categoryName":175,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":177,"categoryName":178,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":182,"categoryName":183,"taxonomyType":179,"taxonomyTypeDesc":180},"01JBSEEDCAT000000000000033","数据分析师",[185,186,187,188,189,190,191,192,193,119,34,194,195,196,197,198,41,144,199,200],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","release","opencode","plan","browser","api","project status","http api"]