[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71J2M557GQEATE7FK0QEXZF":3,"skill-same:01M71J2M557GQEATE7FK0QEXZF":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":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":6,"updatedAt":58,"install":59,"resources":71},"01M71J2M557GQEATE7FK0QEXZF","map-codebase",null,"Derives the tech-stack doc from scratch by scanning the codebase — analyzes stack, architecture, and gray areas (error handling, API shapes) and persists findings into specs\u002Ftech-architecture\u002Ftech-stack.md. Run when the tech doc doesn't exist yet; use survey-context to consume it once it does.","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.gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Fmap-codebase\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"map","codebase","map codebase","From Scratch","use","true","scratch","tech","context","sonnet","doc","run","scanning","stack","api","architecture","when","tech doc","survey","error","2026-11-10 10:12:30",false,"---\nname: map-codebase\nmodel: sonnet\ndescription: \"Derives the tech-stack doc from scratch by scanning the codebase — analyzes stack, architecture, and gray areas (error handling, API shapes) and persists findings into specs\u002Ftech-architecture\u002Ftech-stack.md. Run when the tech doc doesn't exist yet; use survey-context to consume it once it does.\"\ndisable-model-invocation: true\n---\n\n# Map Codebase\n\nPerform a deep architectural and structural analysis of the codebase. Unlike `survey-context` which identifies \"where we are\", `map-codebase` identifies \"what we are dealing with\" and \"how things are done\".\n\n> **Use this vs survey-context:** `map-codebase` BUILDS the tech-stack doc by scanning the codebase from scratch. `survey-context` READS existing specs\u002Ftech-architecture docs without re-deriving them. Run `map-codebase` when `specs\u002Ftech-architecture\u002Ftech-stack.md` doesn't exist yet; run `survey-context` when it does.\n\n> **HARD GATE** — Cold analysis only. Do NOT assume architectural patterns without reading the code. If the codebase structure surprises you, call out the delta.\n\n## Process\n\n### 1. Identify Core Stack & Dependencies\n- Scan `package.json`, `Cargo.toml`, `requirements.txt`, etc.\n- Identify primary framework, runtime, and critical libraries (ORM, Auth, State, UI).\n- Note version constraints and any deprecated or unusual dependencies.\n\n### 2. Map High-Level Architecture\n- Identify the entry points (CLI, Web, API).\n- Map the primary data flow (e.g., Controller → Service → Repository).\n- Identify where business logic lives vs. where I\u002FO lives.\n- Look for established patterns (e.g., hexagonal, layered, feature-folders).\n\n### 3. Analyze \"Gray Areas\" (The \"How\")\nSearch for patterns and anti-patterns in these categories:\n- **Error Handling:** Are exceptions caught early or bubbled? Is there a global error handler? Are error messages structured?\n- **API Shapes:** Is it REST, GraphQL, or RPC? What is the casing (camelCase, snake_case)? How are responses structured?\n- **Type Safety:** Is it strictly typed? Are there many `any` or `unsafe` blocks? Are interfaces used for DIP?\n- **Observability:** Is there structured logging? Are there health checks? Where do logs go?\n- **Testing:** What is the test coverage strategy? Are mocks used? Where do tests live?\n\n### 4. Identify Planning \"Signals\"\nLook for signals that will influence upcoming plans:\n- **Consistency Gaps:** \"Half the project uses async\u002Fawait, the other half uses Promises.\"\n- **Debt Hotspots:** \"The `AuthManager` is 1500 lines and handles both JWT and session logic.\"\n- **Integration Points:** \"We need to talk to the Stripe API, but there's no wrapper yet.\"\n- **Conventions:** \"The team always uses functional components over classes.\"\n\n### 5. Persist to specs\u002Ftech-architecture\u002Ftech-stack.md\nCompile all findings into `specs\u002Ftech-architecture\u002Ftech-stack.md`. This file serves as the project's \"Long-Term Memory\".\n\n```markdown\n# Project Context\n\n## Stack\n- [Framework\u002FLanguage]\n- [Key Libraries]\n\n## Architecture\n- [Pattern Description]\n- [Data Flow]\n\n## Conventions (Observed)\n- [Error Handling Pattern]\n- [API Design]\n- [Type System]\n\n## Signals \u002F Active Considerations\n- [Gap 1]\n- [Hotspot 2]\n```\n\n## When to Use\n- When first joining a project.\n- Before a major refactor or architectural change.\n- When `survey-context` reveals a lack of domain knowledge.\n- To refresh `specs\u002Ftech-architecture\u002Ftech-stack.md` after significant changes.\n","# Map Codebase\n\nPerform a deep architectural and structural analysis of the codebase. Unlike `survey-context` which identifies \"where we are\", `map-codebase` identifies \"what we are dealing with\" and \"how things are done\".\n\n> **Use this vs survey-context:** `map-codebase` BUILDS the tech-stack doc by scanning the codebase from scratch. `survey-context` READS existing specs\u002Ftech-architecture docs without re-deriving them. Run `map-codebase` when `specs\u002Ftech-architecture\u002Ftech-stack.md` doesn't exist yet; run `survey-context` when it does.\n\n> **HARD GATE** — Cold analysis only. Do NOT assume architectural patterns without reading the code. If the codebase structure surprises you, call out the delta.\n\n## Process\n\n### 1. Identify Core Stack & Dependencies\n- Scan `package.json`, `Cargo.toml`, `requirements.txt`, etc.\n- Identify primary framework, runtime, and critical libraries (ORM, Auth, State, UI).\n- Note version constraints and any deprecated or unusual dependencies.\n\n### 2. Map High-Level Architecture\n- Identify the entry points (CLI, Web, API).\n- Map the primary data flow (e.g., Controller → Service → Repository).\n- Identify where business logic lives vs. where I\u002FO lives.\n- Look for established patterns (e.g., hexagonal, layered, feature-folders).\n\n### 3. Analyze \"Gray Areas\" (The \"How\")\nSearch for patterns and anti-patterns in these categories:\n- **Error Handling:** Are exceptions caught early or bubbled? Is there a global error handler? Are error messages structured?\n- **API Shapes:** Is it REST, GraphQL, or RPC? What is the casing (camelCase, snake_case)? How are responses structured?\n- **Type Safety:** Is it strictly typed? Are there many `any` or `unsafe` blocks? Are interfaces used for DIP?\n- **Observability:** Is there structured logging? Are there health checks? Where do logs go?\n- **Testing:** What is the test coverage strategy? Are mocks used? Where do tests live?\n\n### 4. Identify Planning \"Signals\"\nLook for signals that will influence upcoming plans:\n- **Consistency Gaps:** \"Half the project uses async\u002Fawait, the other half uses Promises.\"\n- **Debt Hotspots:** \"The `AuthManager` is 1500 lines and handles both JWT and session logic.\"\n- **Integration Points:** \"We need to talk to the Stripe API, but there's no wrapper yet.\"\n- **Conventions:** \"The team always uses functional components over classes.\"\n\n### 5. Persist to specs\u002Ftech-architecture\u002Ftech-stack.md\nCompile all findings into `specs\u002Ftech-architecture\u002Ftech-stack.md`. This file serves as the project's \"Long-Term Memory\".\n\n```markdown\n# Project Context\n\n## Stack\n- [Framework\u002FLanguage]\n- [Key Libraries]\n\n## Architecture\n- [Pattern Description]\n- [Data Flow]\n\n## Conventions (Observed)\n- [Error Handling Pattern]\n- [API Design]\n- [Type System]\n\n## Signals \u002F Active Considerations\n- [Gap 1]\n- [Hotspot 2]\n```\n\n## When to Use\n- When first joining a project.\n- Before a major refactor or architectural change.\n- When `survey-context` reveals a lack of domain knowledge.\n- To refresh `specs\u002Ftech-architecture\u002Ftech-stack.md` after significant changes.\n",{"name":5,"model":33,"description":7,"disable-model-invocation":49},true,"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Fmap-codebase",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":60,"prompt":70,"zipAvailable":49},[61,64,67],{"tool":62,"command":63},"npx","npx skills add danielvm-git\u002Fbigpowers --skill map-codebase",{"tool":65,"command":66},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill map-codebase",{"tool":68,"command":69},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill map-codebase","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.gemini\u002Fextensions\u002Fbigpowers\u002Fskills\u002Fmap-codebase\u002FSKILL.md",[],[73,93,100,127,150,171],{"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":84,"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":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[85,86,87,88,89,90,35,91,92],"fixture","open","verify","skill verify fail open fixture","skill verify","path","for","never",{"skillNo":94,"name":95,"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":96,"categories":97,"keywords":98,"publishedAt":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[99,90],"negative path",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":109,"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",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000002","文档处理",[110,111,112,113,114,115,116,117,118,119,28,40,120,121,33,122,123,124,125,126],"write","write document","document","documents","actionable","technical","methodology","high","bmad","standard","minimal","bold","integrity","organize","sync","directory","guides",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"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",[],[134,135,136,119,137,28,138,139,140,141,33,142,143,144,145,146,147,40,148,149],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"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",[],[157,158,159,160,161,162,163,164,165,166,167,119,168,91,134,33,169,170],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"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",[177,180,181],{"categoryNo":178,"categoryName":179,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":182,"categoryName":183,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[185,186,187,188,189,190,191,192,193,33,194,195,196,197,198,38,39,148,199,200],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","project status","http api"]