[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71KB8TM089JJD5AY5KAFSDM":3,"skill-same:01M71KB8TM089JJD5AY5KAFSDM":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},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability",null,"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.","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\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"observability","wire observability","readiness","standard","use","development","as","logging","add","sonnet","instrumentation","commands","scripts","at","structured logging","production-readiness","idempotent","phase","when","project","2026-11-10 10:12:30",false,"---\nname: wire-observability\nmodel: sonnet\neffort: standard\ndescription: 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.\n---\n\n# Wire Observability\n> **HARD GATE** — **HARD GATE** — Observability is not optional. Before shipping, verify: structured logging is in place, key metrics are instrumented, error cases emit signals. 'We'll add metrics later' becomes 'never.'\n\n\nAdd structured logging, observability commands, and idempotent setup scripts. Can be invoked at any phase — recommended at the end of the first working slice, before the first deploy.\n\n## What this sets up\n\n1. **Structured JSON logging** — machine-readable logs for debugging and observability\n2. **Observability commands** — how to check the system's health documented in CLAUDE.md\n3. **Idempotent setup scripts** — scripts that can be run repeatedly without side effects\n\n## Process\n\n### 1. Assess current state\n\nCheck what's already in place:\n- Is there a logging library? (pino, winston, structlog, zap, slog, etc.)\n- Is logging JSON or plain text?\n- Is there a health check endpoint or command?\n- Are there setup scripts? Are they idempotent?\n\n### 2. Add structured JSON logging\n\n**For user-facing CLI output:** plain text is fine.\n**For everything else:** structured JSON.\n\nStructured log entry format:\n```json\n{\n  \"level\": \"info\",\n  \"timestamp\": \"2025-01-15T10:23:45.123Z\",\n  \"message\": \"User created\",\n  \"userId\": \"usr_abc123\",\n  \"requestId\": \"req_xyz789\"\n}\n```\n\nGuidelines:\n- Include `level`, `timestamp`, `message` in every entry\n- Add context fields relevant to the operation (userId, requestId, traceId)\n- Log at boundaries: HTTP requests in\u002Fout, DB queries, external API calls, background job start\u002Fend\n- Log errors with stack traces: `logger.error({ err, context }, \"Operation failed\")`\n- **Never log secrets, passwords, tokens, or PII**\n\n### 3. Document observability commands in CLAUDE.md\n\nAdd an \"Observability\" section to the project's CLAUDE.md:\n\n```markdown\n## Observability\n\n| What | Command |\n|------|---------|\n| View logs | `\u003Clog tail command>` |\n| Health check | `\u003Chealth check command>` |\n| Check DB connection | `\u003Cdb ping command>` |\n| View metrics | `\u003Cmetrics command>` |\n```\n\n### 4. Write idempotent setup scripts\n\nAn idempotent script can be run multiple times and always produces the same result (no errors on re-run).\n\nPattern: check if the thing already exists before creating it.\n\n```bash\n#!\u002Fusr\u002Fbin\u002Fenv bash\nset -euo pipefail\n\n# Idempotent: only create if not exists\nif ! psql -c \"SELECT 1 FROM pg_database WHERE datname = 'myapp'\" | grep -q 1; then\n  createdb myapp\n  echo \"Database created\"\nelse\n  echo \"Database already exists, skipping\"\nfi\n```\n\nPlace setup scripts in `scripts\u002Fsetup.sh` (or language-appropriate equivalent). Document the command in CLAUDE.md under Commands.\n\n### 5. Verify\n\n- [ ] Run the app and confirm JSON logs appear in the correct format\n- [ ] Run `scripts\u002Fsetup.sh` twice — second run should produce no errors\n- [ ] Health check command returns success\n- [ ] No sensitive data in log output\n\n## BCP Plus Integration\n\nThis skill maps to **BCP Plus dimension 11 (Quality Attributes)** — specifically performance, reliability, and availability instrumentation. Structured logging, health checks, and idempotent setup scripts are observable manifestations of quality-attribute requirements. The NFR Gate rule applies: standard-expectation items (e.g., \"the app should log errors\") score 0 with a one-line rationale; only above-standard quality requirements (e.g., p99 latency tracking, SLO-based alerting) contribute to the dimension 11 count. See `docs\u002Freferences\u002Fbcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.\n\n","# Wire Observability\n> **HARD GATE** — **HARD GATE** — Observability is not optional. Before shipping, verify: structured logging is in place, key metrics are instrumented, error cases emit signals. 'We'll add metrics later' becomes 'never.'\n\n\nAdd structured logging, observability commands, and idempotent setup scripts. Can be invoked at any phase — recommended at the end of the first working slice, before the first deploy.\n\n## What this sets up\n\n1. **Structured JSON logging** — machine-readable logs for debugging and observability\n2. **Observability commands** — how to check the system's health documented in CLAUDE.md\n3. **Idempotent setup scripts** — scripts that can be run repeatedly without side effects\n\n## Process\n\n### 1. Assess current state\n\nCheck what's already in place:\n- Is there a logging library? (pino, winston, structlog, zap, slog, etc.)\n- Is logging JSON or plain text?\n- Is there a health check endpoint or command?\n- Are there setup scripts? Are they idempotent?\n\n### 2. Add structured JSON logging\n\n**For user-facing CLI output:** plain text is fine.\n**For everything else:** structured JSON.\n\nStructured log entry format:\n```json\n{\n  \"level\": \"info\",\n  \"timestamp\": \"2025-01-15T10:23:45.123Z\",\n  \"message\": \"User created\",\n  \"userId\": \"usr_abc123\",\n  \"requestId\": \"req_xyz789\"\n}\n```\n\nGuidelines:\n- Include `level`, `timestamp`, `message` in every entry\n- Add context fields relevant to the operation (userId, requestId, traceId)\n- Log at boundaries: HTTP requests in\u002Fout, DB queries, external API calls, background job start\u002Fend\n- Log errors with stack traces: `logger.error({ err, context }, \"Operation failed\")`\n- **Never log secrets, passwords, tokens, or PII**\n\n### 3. Document observability commands in CLAUDE.md\n\nAdd an \"Observability\" section to the project's CLAUDE.md:\n\n```markdown\n## Observability\n\n| What | Command |\n|------|---------|\n| View logs | `\u003Clog tail command>` |\n| Health check | `\u003Chealth check command>` |\n| Check DB connection | `\u003Cdb ping command>` |\n| View metrics | `\u003Cmetrics command>` |\n```\n\n### 4. Write idempotent setup scripts\n\nAn idempotent script can be run multiple times and always produces the same result (no errors on re-run).\n\nPattern: check if the thing already exists before creating it.\n\n```bash\n#!\u002Fusr\u002Fbin\u002Fenv bash\nset -euo pipefail\n\n# Idempotent: only create if not exists\nif ! psql -c \"SELECT 1 FROM pg_database WHERE datname = 'myapp'\" | grep -q 1; then\n  createdb myapp\n  echo \"Database created\"\nelse\n  echo \"Database already exists, skipping\"\nfi\n```\n\nPlace setup scripts in `scripts\u002Fsetup.sh` (or language-appropriate equivalent). Document the command in CLAUDE.md under Commands.\n\n### 5. Verify\n\n- [ ] Run the app and confirm JSON logs appear in the correct format\n- [ ] Run `scripts\u002Fsetup.sh` twice — second run should produce no errors\n- [ ] Health check command returns success\n- [ ] No sensitive data in log output\n\n## BCP Plus Integration\n\nThis skill maps to **BCP Plus dimension 11 (Quality Attributes)** — specifically performance, reliability, and availability instrumentation. Structured logging, health checks, and idempotent setup scripts are observable manifestations of quality-attribute requirements. The NFR Gate rule applies: standard-expectation items (e.g., \"the app should log errors\") score 0 with a one-line rationale; only above-standard quality requirements (e.g., p99 latency tracking, SLO-based alerting) contribute to the dimension 11 count. See `docs\u002Freferences\u002Fbcp-plus.md` for the full 13-dimension framework and NFR Gate pattern.\n\n",{"name":5,"model":28,"effort":22,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa","skills\u002Fwire-observability",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":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add danielvm-git\u002Fbigpowers --skill wire-observability",{"tool":59,"command":60},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill wire-observability",{"tool":62,"command":63},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill wire-observability","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",true,[],[68,89,96,122,143,179],{"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","文档处理",[106,107,108,37,109,110,111,112,113,114,22,23,115,116,117,28,118,119,120,121],"write","write document","document","actionable","documents","technical","methodology","high","bmad","guides","minimal","bold","integrity","organize","sync","directory",{"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},"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",[],[129,130,19,131,132,133,134,135,22,136,87,137,138,139,140,141,142,28],"ci","wire ci","setup","templates","validation","REST","with","ci pipeline setup","git","workflows","forge","remote","local","pipeline",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":160,"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",[149,152,157],{"categoryNo":150,"categoryName":151,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":158,"categoryName":159,"taxonomyType":155,"taxonomyTypeDesc":156},"01JBSEEDCAT000000000000033","数据分析师",[161,162,163,38,164,165,166,167,168,169,170,171,28,172,173,174,175,176,177,178],"visual","visual dashboard","dashboard","project status","http api","architecture","planning","artifacts","http","plans","panel","start","status","release","opencode","plan","browser","api",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":186,"publishedAt":39},"01M71KB0SHK1RE5RW5N7847EB9","verify-work","Multi-phase UAT gate — cold-start smoke, build, typecheck, lint, tests, step-by-step manual verification, gaps-closure loop. Use after execute-plan or develop-tdd, before audit-code.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fverify-work\u002FSKILL.md",[185],{"categoryNo":153,"categoryName":154,"taxonomyType":155,"taxonomyTypeDesc":156},[187,82,188,189,23,190,191,192,193,172,194,195,176,196,36,197,198,199,200,201],"work","verify work","typecheck","tests","manual","smoke","uat","audit","haiku","verification","code","loop","closure","cold-start","cold"]