[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7EPDP746K92EN6X2SBPRVB7":3,"skill-same:01M7EPDP746K92EN6X2SBPRVB7":51},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":29,"commitSha":30,"skillDirectory":31,"forksCount":32,"repositoryHtmlUrl":33,"repositoryHomepageUrl":6,"ownerHtmlUrl":34,"ownerBlogUrl":6,"ownerDescription":35,"updatedAt":36,"install":37,"resources":50},"01M7EPDP746K92EN6X2SBPRVB7","panel",null,"Multi-provider deliberation panel for COMPLEX, multi-view questions — architecture, strategy, market research, and codebase sweeps. Runs a 4-stage deliberation across the provider fleet (diverge → contrarian red-team → adversarial verify → cited synthesis), the same multi-perspective rigour the plan-gate already applies to plan reviews, generalised to arbitrary questions. Use when one model's answer isn't enough and you want convergence THROUGH disagreement + verification, not a single opinion.","lza6\u002FArmor-piercing-system-prompts","lza6","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F128880206?v=4","01M7EB3K7WPX5T28EJ2NVHE6EG","Chinese-tingfeng","01M7EB3K97E1KQ16QWKJMFNGX8",11,"MIT","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F04-安全渗透\u002Fpanel\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: panel\ndescription: Multi-provider deliberation panel for COMPLEX, multi-view questions — architecture, strategy, market research, and codebase sweeps. Runs a 4-stage deliberation across the provider fleet (diverge → contrarian red-team → adversarial verify → cited synthesis), the same multi-perspective rigour the plan-gate already applies to plan reviews, generalised to arbitrary questions. Use when one model's answer isn't enough and you want convergence THROUGH disagreement + verification, not a single opinion.\nallowed-tools: [Read, Grep, Glob, Bash]\n---\n\n# \u002Fpanel — multi-provider deliberation\n\nFor hard questions where you want several strong models to genuinely deliberate, not just answer in parallel. Each stage builds on the last, so the panel converges *through* disagreement and verification instead of averaging opinions.\n\n## When to use\n\n- **architecture** — a feature\u002Fsystem design where the tradeoffs are non-obvious.\n- **strategy** — a business\u002Fproduct call that rests on assumptions worth stress-testing.\n- **research** — market\u002Fcompetitive questions where claims need refuting.\n- **sweep** — a codebase audit (security \u002F correctness \u002F dead-code \u002F refactor).\n\nReach for it when a single model's answer would be a guess, and you'd otherwise open five terminals yourself.\n\n## How it works (4 stages)\n\n1. **Diverge** — every fleet provider (codex \u002F kimi \u002F claude \u002F glm-5.2 \u002F deepseek-harness) analyses the SAME question through a DIFFERENT mode-specific lens.\n2. **Contrarian** — one designated seat red-teams the emerging consensus: what did everyone miss, which \"this is fine\" is wrong.\n3. **Verify** — the top claims are adversarially checked (against the CODE for sweeps — real `file:line`; against SOURCES for research — try to refute).\n4. **Synthesis** — one cited report: consensus + surviving dissent + verified\u002Frefuted claims, ranked and deduped.\n\n## How seat coverage is counted (OI-1519)\n\n\"N of M lenses present\" is reconciled against the t0 receipt ledger\n(`t0_receipts.ndjson`), never taken from the `exit_code` a seat writes about ITSELF in\nits own report frontmatter. After each stage completes, every seat's dispatch-id is\nlooked up in the ledger via `receipt_provenance.find_receipts_by_dispatch` and lands in\none of THREE outcomes:\n\n- **present** — the ledger holds a decisive SUCCESS record for the seat's dispatch-id\n  (`status` in the ADR-035 success set `done`\u002F`success`\u002F`complete`\u002F`completed`, or\n  `verdict.decision=accept`).\n- **failed** — the ledger holds a decisive FAILURE record (`status` in the ADR-035\n  hard-failure set `failed`\u002F`failure`\u002F`error`\u002F`blocked`\u002F`timeout`\u002F`contract_invalid`,\n  or `verdict.decision=reject`; multiple receipts for one dispatch-id reconcile\n  failure-beats-success — a success record never launders a recorded failure). A\n  dispatcher that RAISED before the seat completed is failed on direct local evidence.\n- **unmeasured** — the ledger has NO decisive record for the dispatch-id (no receipt\n  at all, or only indecisive ones). This is a third BRANCH, not a third value: the\n  seat counts as NEITHER present NOR failed and is named in the report\n  (`**Unmeasured seats:**`, `[SEAT UNMEASURED — no decisive ledger record]`).\n  Reading \"unmeasured\" as \"probably fine\" repeats exactly the bug OI-1519 repaired —\n  a measurement gap is not a lens.\n\nWhere the ledger and the seat's own frontmatter DISAGREE, the ledger WINS the count and\nthe divergence itself is reported (`## Ledger reconciliation — divergences` in the\nreport, `result.ledger_divergences`) — a silent correction would produce a panel that\ncannot be weighed. When no ledger exists or can be read at all (fresh checkout) the\ntally falls back to the pre-OI-1519 frontmatter measurement, flagged loudly via\n`ledger_available=False` in the report — never silently.\n\nThis holds for the diverge fan-out AND for the sequential stages (contrarian, verify,\nsynthesis), which accept a seat via `_first_ok` under the same measurement: a\nledger-failed seat is skipped; an unmeasured seat is kept only as a last-resort\nfallback so a measurement gap cannot collapse a stage to `[empty]` when real content\nexists.\n\nMeasured case (2026-08-29, the dispatch that opened OI-1519): seat\n`panel-sweep-diverge-0-a6421f` (codex) wrote `exit_code: 0` in its own report\nfrontmatter while the receipt ledger records `status=timeout`,\n`verdict.decision=reject` after the 600s deadline. Pre-fix it counted PRESENT (4\u002F5\nlenses reported; really 3 + a timeout). Post-fix it counts FAILED, and the divergence\nis printed in the report.\n\n## Run it\n\n```bash\npython3 scripts\u002Fpanel.py \u003Cmode> \"\u003Cquestion>\" [--context-file FILE] [--timeout 900] [--out FILE]\n```\n\nExamples:\n\n```bash\n# architecture decision, grounded on a design doc\npython3 scripts\u002Fpanel.py architecture \"Should the judge run per-receipt or batched?\" --context-file docs\u002Fadr-028.md\n\n# code sweep grounded on a diff or file list\ngit diff origin\u002Fmain > \u002Ftmp\u002Fd.diff\npython3 scripts\u002Fpanel.py sweep \"Review this change for security + correctness\" --context-file \u002Ftmp\u002Fd.diff\n\n# market research\npython3 scripts\u002Fpanel.py research \"Is there an underserved MKB market for local-LLM invoice processing?\"\n```\n\nThe cited report lands in `unified_reports\u002Fpanel-\u003Cmode>-\u003Cid>.md` and prints to stdout.\n\n## Notes\n\n- Governed lane: each panelist dispatches through the review lane and emits a receipt. Respects the provider constraints (kimi-via-cli-only, glm via OpenRouter\u002Fharness, deepseek-harness with its own key + hardening, no-anthropic-sdk) — the dispatcher routes each provider correctly.\n- A dead\u002Fabsent provider (e.g. deepseek without its key) degrades the panel gracefully; it never blocks the run.\n- The panel is the fabric's general multi-view tool. It complements the **plan-gate panel** (which is scoped to plan reviews) and the **t0-orchestrator** skill (which owns orchestration decisions). Implementation: `scripts\u002Flib\u002Fdeliberation_panel.py`.\n","# \u002Fpanel — multi-provider deliberation\n\nFor hard questions where you want several strong models to genuinely deliberate, not just answer in parallel. Each stage builds on the last, so the panel converges *through* disagreement and verification instead of averaging opinions.\n\n## When to use\n\n- **architecture** — a feature\u002Fsystem design where the tradeoffs are non-obvious.\n- **strategy** — a business\u002Fproduct call that rests on assumptions worth stress-testing.\n- **research** — market\u002Fcompetitive questions where claims need refuting.\n- **sweep** — a codebase audit (security \u002F correctness \u002F dead-code \u002F refactor).\n\nReach for it when a single model's answer would be a guess, and you'd otherwise open five terminals yourself.\n\n## How it works (4 stages)\n\n1. **Diverge** — every fleet provider (codex \u002F kimi \u002F claude \u002F glm-5.2 \u002F deepseek-harness) analyses the SAME question through a DIFFERENT mode-specific lens.\n2. **Contrarian** — one designated seat red-teams the emerging consensus: what did everyone miss, which \"this is fine\" is wrong.\n3. **Verify** — the top claims are adversarially checked (against the CODE for sweeps — real `file:line`; against SOURCES for research — try to refute).\n4. **Synthesis** — one cited report: consensus + surviving dissent + verified\u002Frefuted claims, ranked and deduped.\n\n## How seat coverage is counted (OI-1519)\n\n\"N of M lenses present\" is reconciled against the t0 receipt ledger\n(`t0_receipts.ndjson`), never taken from the `exit_code` a seat writes about ITSELF in\nits own report frontmatter. After each stage completes, every seat's dispatch-id is\nlooked up in the ledger via `receipt_provenance.find_receipts_by_dispatch` and lands in\none of THREE outcomes:\n\n- **present** — the ledger holds a decisive SUCCESS record for the seat's dispatch-id\n  (`status` in the ADR-035 success set `done`\u002F`success`\u002F`complete`\u002F`completed`, or\n  `verdict.decision=accept`).\n- **failed** — the ledger holds a decisive FAILURE record (`status` in the ADR-035\n  hard-failure set `failed`\u002F`failure`\u002F`error`\u002F`blocked`\u002F`timeout`\u002F`contract_invalid`,\n  or `verdict.decision=reject`; multiple receipts for one dispatch-id reconcile\n  failure-beats-success — a success record never launders a recorded failure). A\n  dispatcher that RAISED before the seat completed is failed on direct local evidence.\n- **unmeasured** — the ledger has NO decisive record for the dispatch-id (no receipt\n  at all, or only indecisive ones). This is a third BRANCH, not a third value: the\n  seat counts as NEITHER present NOR failed and is named in the report\n  (`**Unmeasured seats:**`, `[SEAT UNMEASURED — no decisive ledger record]`).\n  Reading \"unmeasured\" as \"probably fine\" repeats exactly the bug OI-1519 repaired —\n  a measurement gap is not a lens.\n\nWhere the ledger and the seat's own frontmatter DISAGREE, the ledger WINS the count and\nthe divergence itself is reported (`## Ledger reconciliation — divergences` in the\nreport, `result.ledger_divergences`) — a silent correction would produce a panel that\ncannot be weighed. When no ledger exists or can be read at all (fresh checkout) the\ntally falls back to the pre-OI-1519 frontmatter measurement, flagged loudly via\n`ledger_available=False` in the report — never silently.\n\nThis holds for the diverge fan-out AND for the sequential stages (contrarian, verify,\nsynthesis), which accept a seat via `_first_ok` under the same measurement: a\nledger-failed seat is skipped; an unmeasured seat is kept only as a last-resort\nfallback so a measurement gap cannot collapse a stage to `[empty]` when real content\nexists.\n\nMeasured case (2026-08-29, the dispatch that opened OI-1519): seat\n`panel-sweep-diverge-0-a6421f` (codex) wrote `exit_code: 0` in its own report\nfrontmatter while the receipt ledger records `status=timeout`,\n`verdict.decision=reject` after the 600s deadline. Pre-fix it counted PRESENT (4\u002F5\nlenses reported; really 3 + a timeout). Post-fix it counts FAILED, and the divergence\nis printed in the report.\n\n## Run it\n\n```bash\npython3 scripts\u002Fpanel.py \u003Cmode> \"\u003Cquestion>\" [--context-file FILE] [--timeout 900] [--out FILE]\n```\n\nExamples:\n\n```bash\n# architecture decision, grounded on a design doc\npython3 scripts\u002Fpanel.py architecture \"Should the judge run per-receipt or batched?\" --context-file docs\u002Fadr-028.md\n\n# code sweep grounded on a diff or file list\ngit diff origin\u002Fmain > \u002Ftmp\u002Fd.diff\npython3 scripts\u002Fpanel.py sweep \"Review this change for security + correctness\" --context-file \u002Ftmp\u002Fd.diff\n\n# market research\npython3 scripts\u002Fpanel.py research \"Is there an underserved MKB market for local-LLM invoice processing?\"\n```\n\nThe cited report lands in `unified_reports\u002Fpanel-\u003Cmode>-\u003Cid>.md` and prints to stdout.\n\n## Notes\n\n- Governed lane: each panelist dispatches through the review lane and emits a receipt. Respects the provider constraints (kimi-via-cli-only, glm via OpenRouter\u002Fharness, deepseek-harness with its own key + hardening, no-anthropic-sdk) — the dispatcher routes each provider correctly.\n- A dead\u002Fabsent provider (e.g. deepseek without its key) degrades the panel gracefully; it never blocks the run.\n- The panel is the fabric's general multi-view tool. It complements the **plan-gate panel** (which is scoped to plan reviews) and the **t0-orchestrator** skill (which owns orchestration decisions). Implementation: `scripts\u002Flib\u002Fdeliberation_panel.py`.\n",{"name":5,"description":7,"allowed-tools":24},[25,26,27,28],"Read","Grep","Glob","Bash","main","d69096e239f2a89aabc2cd078c47664a9d3b1e11","04-安全渗透\u002Fpanel",3,"https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts","https:\u002F\u002Fgithub.com\u002Flza6","个人vx：Tf00798\r\n个人✈：@TFGY999","2026-10-08 14:29:22",{"source":8,"skillName":5,"commands":38,"prompt":48,"zipAvailable":49},[39,42,45],{"tool":40,"command":41},"npx","npx skills add lza6\u002FArmor-piercing-system-prompts --skill panel",{"tool":43,"command":44},"bunx","bunx skills add lza6\u002FArmor-piercing-system-prompts --skill panel",{"tool":46,"command":47},"pnpm","pnpm dlx skills add lza6\u002FArmor-piercing-system-prompts --skill panel","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F04-安全渗透\u002Fpanel\u002FSKILL.md",true,[],[52,59,66,73,81,88],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":19},"01M7EXRM12046G0GM1WGMMFXCN","ci-cd-and-automation","Automates CI\u002FCD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fci-cd-and-automation\u002FSKILL.md",[],[],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":19},"01M7EXRFYYSJ3Y15AGPDDEWWQD","chrome-devtools","Uses Chrome DevTools via MCP for efficient debugging, troubleshooting and browser automation. Use when debugging web pages, automating browser interactions, analyzing performance, or inspecting network requests. This skill does not apply to `--slim` mode (MCP configuration).","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchrome-devtools\u002FSKILL.md",[],[],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M7EXR6EYPE4X5X1BTAE6QJRV","chrome-cdp","Drive a real Chrome via the Chrome DevTools Protocol (CDP). Ensures a\ndebuggable Chrome is running (launching it if needed) so the agent can\nnavigate, read page content, inspect the DOM, run JavaScript, and take\nscreenshots — without the user typing any launch command. Includes a\nfirst-class \"review a live running app\" flow: point Chrome at the app under\ndevelopment and inspect\u002Fscreenshot the REAL page (what a static-artifact tool\ncannot do). Backed by Glimpse and the chrome-devtools MCP server. Use when\nasked to \"use chrome\", \"open chrome\", \"drive my browser\", \"read the page in\nchrome\", \"review the running app\", \"screenshot the app\", or \"\u002Fchrome-cdp\".","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchrome-cdp\u002FSKILL.md",[],[],{"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":77,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7EXR1Y7E79KQKG4J798XGH6","check-identity-pack","Run an AFP 100-point or AUSTRAC safe-harbour identity check over a set of documents, and report exactly what's missing. Use when the user asks to check identity documents, verify someone's ID for onboarding, or assess whether a document pack satisfies Australian identity requirements.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fcheck-identity-pack\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7EXQXW7C7PGREJW9ZZTZ16H","changelog","Auto-generates a changelog from git commits, sprint data, and design documents. Produces both internal and player-facing versions.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchangelog\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"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":19},"01M7EXQMH2ZME3ANN8Q8MEWPFB","cellxgene-census","Query the CZ CELLxGENE Census programmatically for versioned public single-cell and spatial transcriptomics data. Use when you need population-scale cell metadata, gene expression slices, Census summary counts, source H5AD URIs\u002Fdownloads, embeddings, spatial Census data, or reference atlas comparisons across organisms, tissues, diseases, assays, and cell types. For analyzing your own local single-cell data use scanpy, anndata, or scvi-tools.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fcellxgene-census\u002FSKILL.md",[],[]]