[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HTSFHV2NVKSPNW6QCM6PR":3,"skill-same:01M71HTSFHV2NVKSPNW6QCM6PR":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":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M71HTSFHV2NVKSPNW6QCM6PR","inspect-quality",null,"Interactive QA session where user reports bugs or issues conversationally, and the agent logs them to specs\u002Fbugs\u002Fregistry.yaml with a structured audit schema. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, or mentions \"QA session\".","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.copilot\u002Fskills\u002Finspect-quality\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"quality","inspect quality","inspect","use","schema","session","for","bugs","domain","do","context","sonnet","registry","domain language","audit","reports","logs","when","qa","issues","2026-11-10 10:12:30",false,"---\nname: inspect-quality\nmodel: sonnet\ndescription: \"Interactive QA session where user reports bugs or issues conversationally, and the agent logs them to specs\u002Fbugs\u002Fregistry.yaml with a structured audit schema. Explores the codebase in the background for context and domain language. Use when user wants to report bugs, do QA, or mentions \\\"QA session\\\".\"\n---\n\n# Inspect Quality\n> **HARD GATE** — **HARD GATE** — Quality metrics (coverage, lint, cyclomatic complexity, security scans) must be monitored. If a metric degrades, surface it as a blocker. Do NOT accept regressions.\n\n\nRun an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and log each issue to `specs\u002Fbugs\u002Fregistry.yaml` with a structured, durable format.\n\n## For each issue the user raises\n\n### 1. Listen and lightly clarify\n\nLet the user describe the problem in their own words. Ask **at most 2–3 short clarifying questions** focused on:\n\n- What they expected vs what actually happened\n- Steps to reproduce (if not obvious)\n- Whether it's consistent or intermittent\n\nDo NOT over-interview. If the description is clear enough to log, move on.\n\n### 2. Explore the codebase in the background\n\nKick off an Agent (subagent_type=Explore) to understand the relevant area. The goal is NOT to find a fix — it's to:\n\n- Learn the domain language used in that area (check `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md` if present)\n- Understand what the feature is supposed to do\n- Identify the user-facing behavior boundary\n\n### 3. Assess scope: single issue or breakdown?\n\nBreak down when:\n\n- The fix spans multiple independent areas\n- There are clearly separable concerns that could be worked on in parallel\n- The user describes something with multiple distinct failure modes\n\nKeep as a single issue when:\n\n- It's one behavior that's wrong in one place\n- The symptoms are all caused by the same root behavior\n\n### 4. Log to specs\u002Fbugs\u002Fregistry.yaml\n\nAppend the issue to `specs\u002Fbugs\u002Fregistry.yaml`. Create the `specs\u002Fbugs\u002F` directory if it doesn't exist.\n\n#### registry.yaml format\n\nThe file maintains a Markdown table with the following columns (derived from structured audit practice):\n\n| Field | Description |\n|-------|-------------|\n| `bug_id` | `BUG-YYYY-MM-DDTHHMMSS` |\n| `date` | `YYYY-MM-DD` |\n| `severity` | `critical` \u002F `high` \u002F `medium` \u002F `low` |\n| `priority` | `p0` \u002F `p1` \u002F `p2` \u002F `p3` |\n| `scope` | kebab-case area (e.g. `auth`, `checkout`) |\n| `what_happened` | actual behavior (user-facing terms) |\n| `what_expected` | expected behavior |\n| `steps_to_reproduce` | numbered steps |\n| `root_cause` | one-line hypothesis |\n| `files_changed` | filled in after fix |\n| `approach` | filled in after fix |\n| `risk_level` | `low` \u002F `medium` \u002F `high` |\n| `new_tests` | count (filled in after fix) |\n| `type_check` | `pass` \u002F `fail` (filled in after fix) |\n| `lint` | `pass` \u002F `fail` (filled in after fix) |\n| `commit_type` | `fix` \u002F `fix!` \u002F `feat` (filled in after fix) |\n| `release_type` | `patch` \u002F `minor` \u002F `major` (filled in after fix) |\n| `commit_message` | Conventional Commits message (filled in after fix) |\n| `follow_ups` | semicolon-separated follow-up items |\n| `file` | path to detailed `specs\u002Fbugs\u002FBUG-*.md` (filled in by investigate-bug) |\n| `status` | `open` \u002F `in-progress` \u002F `fixed` \u002F `wont-fix` |\n\nWhen a bug is fixed (via `validate-fix`), update the relevant row with the resolution fields.\n\n#### Issue body (for context below the table)\n\nFor each bug, also append a detail section:\n\n```markdown\n### BUG-YYYY-MM-DDTHHMMSS: [short title]\n\n**What happened:** [actual behavior, plain language]\n**What I expected:** [expected behavior]\n**Steps to reproduce:**\n1. [Step 1]\n2. [Step 2]\n\n**Additional context:** [domain-language observations, no file paths]\n```\n\n#### Rules for all entries\n\n- **bug_id** uses full timestamp: `BUG-YYYY-MM-DDTHHMMSS` — matches the individual bug file name in `specs\u002Fbugs\u002F`\n- **No file paths or line numbers** — these go stale\n- **Use the project's domain language** (check `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md` if it exists)\n- **Describe behaviors, not code** — \"the sync service fails to apply the patch\" not \"applyPatch() throws\"\n- **Reproduction steps are mandatory** — if you can't determine them, ask the user\n\n### 5. Continue the session\n\nAfter logging, ask: \"Next issue, or are we done?\" Keep going until the user says done. Each issue is independent — don't batch them.\n","# Inspect Quality\n> **HARD GATE** — **HARD GATE** — Quality metrics (coverage, lint, cyclomatic complexity, security scans) must be monitored. If a metric degrades, surface it as a blocker. Do NOT accept regressions.\n\n\nRun an interactive QA session. The user describes problems they're encountering. You clarify, explore the codebase for context, and log each issue to `specs\u002Fbugs\u002Fregistry.yaml` with a structured, durable format.\n\n## For each issue the user raises\n\n### 1. Listen and lightly clarify\n\nLet the user describe the problem in their own words. Ask **at most 2–3 short clarifying questions** focused on:\n\n- What they expected vs what actually happened\n- Steps to reproduce (if not obvious)\n- Whether it's consistent or intermittent\n\nDo NOT over-interview. If the description is clear enough to log, move on.\n\n### 2. Explore the codebase in the background\n\nKick off an Agent (subagent_type=Explore) to understand the relevant area. The goal is NOT to find a fix — it's to:\n\n- Learn the domain language used in that area (check `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md` if present)\n- Understand what the feature is supposed to do\n- Identify the user-facing behavior boundary\n\n### 3. Assess scope: single issue or breakdown?\n\nBreak down when:\n\n- The fix spans multiple independent areas\n- There are clearly separable concerns that could be worked on in parallel\n- The user describes something with multiple distinct failure modes\n\nKeep as a single issue when:\n\n- It's one behavior that's wrong in one place\n- The symptoms are all caused by the same root behavior\n\n### 4. Log to specs\u002Fbugs\u002Fregistry.yaml\n\nAppend the issue to `specs\u002Fbugs\u002Fregistry.yaml`. Create the `specs\u002Fbugs\u002F` directory if it doesn't exist.\n\n#### registry.yaml format\n\nThe file maintains a Markdown table with the following columns (derived from structured audit practice):\n\n| Field | Description |\n|-------|-------------|\n| `bug_id` | `BUG-YYYY-MM-DDTHHMMSS` |\n| `date` | `YYYY-MM-DD` |\n| `severity` | `critical` \u002F `high` \u002F `medium` \u002F `low` |\n| `priority` | `p0` \u002F `p1` \u002F `p2` \u002F `p3` |\n| `scope` | kebab-case area (e.g. `auth`, `checkout`) |\n| `what_happened` | actual behavior (user-facing terms) |\n| `what_expected` | expected behavior |\n| `steps_to_reproduce` | numbered steps |\n| `root_cause` | one-line hypothesis |\n| `files_changed` | filled in after fix |\n| `approach` | filled in after fix |\n| `risk_level` | `low` \u002F `medium` \u002F `high` |\n| `new_tests` | count (filled in after fix) |\n| `type_check` | `pass` \u002F `fail` (filled in after fix) |\n| `lint` | `pass` \u002F `fail` (filled in after fix) |\n| `commit_type` | `fix` \u002F `fix!` \u002F `feat` (filled in after fix) |\n| `release_type` | `patch` \u002F `minor` \u002F `major` (filled in after fix) |\n| `commit_message` | Conventional Commits message (filled in after fix) |\n| `follow_ups` | semicolon-separated follow-up items |\n| `file` | path to detailed `specs\u002Fbugs\u002FBUG-*.md` (filled in by investigate-bug) |\n| `status` | `open` \u002F `in-progress` \u002F `fixed` \u002F `wont-fix` |\n\nWhen a bug is fixed (via `validate-fix`), update the relevant row with the resolution fields.\n\n#### Issue body (for context below the table)\n\nFor each bug, also append a detail section:\n\n```markdown\n### BUG-YYYY-MM-DDTHHMMSS: [short title]\n\n**What happened:** [actual behavior, plain language]\n**What I expected:** [expected behavior]\n**Steps to reproduce:**\n1. [Step 1]\n2. [Step 2]\n\n**Additional context:** [domain-language observations, no file paths]\n```\n\n#### Rules for all entries\n\n- **bug_id** uses full timestamp: `BUG-YYYY-MM-DDTHHMMSS` — matches the individual bug file name in `specs\u002Fbugs\u002F`\n- **No file paths or line numbers** — these go stale\n- **Use the project's domain language** (check `specs\u002FUBIQUITOUS_LANGUAGE_LATEST.md` if it exists)\n- **Describe behaviors, not code** — \"the sync service fails to apply the patch\" not \"applyPatch() throws\"\n- **Reproduction steps are mandatory** — if you can't determine them, ask the user\n\n### 5. Continue the session\n\nAfter logging, ask: \"Next issue, or are we done?\" Keep going until the user says done. Each issue is independent — don't batch them.\n",{"name":5,"model":30,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".copilot\u002Fskills\u002Finspect-quality",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":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add danielvm-git\u002Fbigpowers --skill inspect-quality",{"tool":59,"command":60},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill inspect-quality",{"tool":62,"command":63},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill inspect-quality","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.copilot\u002Fskills\u002Finspect-quality\u002FSKILL.md",true,[],[68,88,95,122,145,166],{"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,25,87],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","never",{"skillNo":89,"name":90,"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":91,"categories":92,"keywords":93,"publishedAt":39},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[94,85],"negative path",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":104,"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",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000002","文档处理",[105,106,107,108,109,110,111,112,113,114,22,36,115,116,30,117,118,119,120,121],"write","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,22,133,134,135,136,30,137,138,139,140,141,142,36,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,162,114,163,25,129,30,164,165],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":183,"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",[172,175,180],{"categoryNo":173,"categoryName":174,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":176,"categoryName":177,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":181,"categoryName":182,"taxonomyType":178,"taxonomyTypeDesc":179},"01JBSEEDCAT000000000000033","数据分析师",[184,185,186,187,188,189,190,191,192,30,193,194,195,196,197,198,199,143,200,201],"dashboard","visual","visual dashboard","status","artifacts","http","plans","planning","panel","start","release","opencode","plan","browser","api","architecture","project status","http api"]