[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69B0GE4RMZEH86M4MZFSRGD":3,"skill-same:01M69B0GE4RMZEH86M4MZFSRGD":95},{"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":24,"linkOnly":25,"markdownContent":26,"markdownBody":27,"frontMatter":28,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":62},"01M69B0GE4RMZEH86M4MZFSRGD","councilify",null,"Build a NEW complete \"council\" for a domain — a panel of orthogonal review lenses that fan out cold, debate to consensus, and return a synthesized verdict with recorded dissent, exactly like \u002Fcouncil and \u002Fdesign-council. Identifies the distinct lenses a domain needs (one load-bearing question each, mined from real archetypes — not invented), reuses existing lenses, and builds only the genuinely-missing ones (persona SKILLs via personafy, or agents when the role is an active builder). Use when creating a council, standing up a review panel for a domain (product, security, performance, data), or when someone says \"councilify\", \"make a council\", \"build a \u003Cdomain> council\".","microsoft\u002Famplifier-bundle-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AZYFW50CECTV9VW6B34SE",12,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fcouncilify\u002FSKILL.md",[],[5,19,20,21,22,23],"design","review","security","performance","council","2026-11-10 10:12:30",false,"---\nname: councilify\ndisable-model-invocation: true\ndescription: >-\n  Build a NEW complete \"council\" for a domain — a panel of orthogonal review lenses that\n  fan out cold, debate to consensus, and return a synthesized verdict with recorded\n  dissent, exactly like \u002Fcouncil and \u002Fdesign-council. Identifies the distinct lenses a\n  domain needs (one load-bearing question each, mined from real archetypes — not\n  invented), reuses existing lenses, and builds only the genuinely-missing ones (persona\n  SKILLs via personafy, or agents when the role is an active builder). Use when creating a\n  council, standing up a review panel for a domain (product, security, performance, data),\n  or when someone says \"councilify\", \"make a council\", \"build a \u003Cdomain> council\".\nuser-invocable: true\nmodel_role: reasoning\nallowed-tools:\n  - read_file\n  - write_file\n  - edit_file\n  - glob\n  - grep\n  - bash\n  - delegate\nvisibility:\n  summary: >-\n    Build a new domain council — orthogonal review lenses that fan out cold, debate to\n    consensus, and return a verdict with dissent.\n---\n\n# Councilify\n\nProduce a NEW, invocable **council** for a domain: a `context: fork` concierge\norchestrator over a bench of **orthogonal lenses**, following the proven\n`\u002Fcouncil` → `\u002Fdesign-council` pattern. Reuse before you build; build lenses only\nwhere a real, distinct load-bearing question is missing.\n\n**Success artifact:** a council bundle that, in a FRESH session, convenes on a\nrealistic target — prints a roster manifest, loads every rostered lens (cold,\nindependent), returns `{PASS|CONCERN|FAIL|N\u002FA}` verdicts, and surfaces standing\ndissent — with every NEW lens grounded in real evidence and proven to steer.\n\n## Inputs\n\n- `$ARGUMENTS`: the domain to build a council for (e.g. \"product development\",\n  \"security review\", \"performance\"). Optionally: pointers to evidence\u002Farchetypes,\n  a target-class hint, and a preferred bundle home.\n\n## Core Principles\n\n- **Reuse beats build.** A lens that already owns an axis is composed in by\n  reference across bundle boundaries (the ROB-from-made-support precedent), never\n  copied. Building a lens whose question equals an existing lens's is the failure\n  this skill exists to prevent.\n- **One question per lens, from evidence.** Every lens owns exactly ONE\n  load-bearing question, mined from a real person\u002Farchetype per `personafy` —\n  never invented from vibes. If a candidate's question collapses into an existing\n  lens's, it is not a lens. Cut it.\n- **No anthropomorphizing beyond a distinct voice.** A lens is a review\n  *perspective* with a recognizable voice and discipline, not a fictional\n  character with a backstory. Voice serves steering; lore does not.\n- **Councils are complementary, not duplicative.** A new council must review a\n  distinct target class at a distinct stage. Sharing a lens across councils is\n  fine; two councils doing the same job is not.\n\n## Steps\n\n### 1. Study the pattern\n\nRead the reference implementations in full: `council\u002FSKILL.md`,\n`council-here\u002FSKILL.md`, and `design-council\u002FSKILL.md` + two of its lens skills\n(e.g. `originality-critic`, `purpose-keeper`). Extract: the phase-by-phase\norchestration (roster → optional neutral digest → cold fan-out →\ndebate-to-consensus → synthesize), the trust guardrails (roster manifest first,\nattributed quotes, never downgrade a FAIL, keep FAIL≠N\u002FA), UNAVAILABLE vs\nERRORED handling, and the **council-native lens template** (Load-Bearing\nQuestion \u002F Grounding \u002F Tone \u002F Core Behaviors \u002F Verdict Protocol \u002F Tension With).\nNote the phase-numbering difference between the two: `council` has 5 phases\n(Guard Check, Roster, repo-digest, fan-out, debate, synthesize) because it\nsupports a repo-crawl pre-digest; `design-council` has 4 phases (no pre-digest —\ntargets always pass directly) because every target is a single self-contained\ndesign artifact.\n\n**Success criteria:** You can restate the orchestrator's phases and the lens\ntemplate from memory, and name why `council-here` is inline while `council`\nforks.\n\n### 2. Derive the domain's ideal roster — BLIND to the existing inventory first\n\nName the domain's **target class** (what artifact does this council review?) and\n**stage** (when in the lifecycle?). Then derive, independently of what already\nexists, the distinct perspectives that domain genuinely demands — mining real\ndomain-leadership archetypes for each. For each candidate: one load-bearing\nquestion, the archetype\u002Fframework it's grounded in, and a one-line voice.\n\n**Do this before looking at the installed skill inventory.** Naming what already\nexists first biases the derivation toward \"what we have\" instead of \"what the\ndomain actually needs\" — the two can look similar, but a roster built the second\nway is more likely to contain the ideal makeup rather than a locally-convenient\none.\n\n- **Execution:** Delegate parallel `model_role=\"research\"` agents to gather\n  archetype evidence per candidate lens; each writes findings to disk, returns a\n  thin summary. Explicitly instruct each research agent NOT to consult or let\n  its own visible skill list bias which perspectives it proposes — derive from\n  the domain's real leadership archetypes and literature, not from what\n  happens to already be installed.\n\n**Honest limitation, stated plainly (verified directly, not assumed):** on this\nplatform, a `delegate`-spawned sub-session — even with `context_depth=\"none\"` —\nstill receives an unconditional `hooks-skills-visibility` system-reminder\nlisting dozens of installed skill names, regardless of what it was told or\nasked to do. This was confirmed by direct test: a cold, context-free sub-agent\nreported seeing the full skill list before any instruction reached it. **True\ntechnical isolation from the inventory is not currently achievable via\n`delegate` alone on this platform.** Treat the \"don't consult the inventory\"\ninstruction above as a *policy constraint you are asking the model to honor*,\nnot an architectural guarantee — and say so if you rely on it. If a stronger\nguarantee is ever needed, that requires a different mechanism than same-platform\n`delegate` (e.g., an external process with no skill-visibility hook at all);\ndon't claim isolation you haven't verified holds.\n\n**Success criteria:** A candidate list where each entry has ONE question grounded\nin a named archetype, not a vibe — derived from the domain's real needs first.\n\n### 3. Reconcile against the installed inventory — route every candidate\n\nOnly now enumerate the FULL installed inventory: `load_skill(list=true)` for all\nlens skills, and identify every existing panel — `council` (6: intent-keeper,\ncranky-old-sam, crusty-old-engineer, restless-old-brian, user-advocate,\ntester-breaker), `design-council` (7 design lenses), `adversarial-review` (6:\nSRE, security, staff engineer, finance, operator, developer advocate —\nproduction\u002Foperational risk of a system design; note it also ships a\nrecipe-callable `systems-design-critic` agent form of the same bench, a third\ncomposition pattern worth considering in Step 6's optional extension), plus any\nothers surfaced by the inventory scan.\n\nBuild a **coverage matrix**: the Step 2 candidate list × existing lenses. Route\neach candidate to exactly one of:\n- **REUSE** — an existing lens already owns this exact question → compose by\n  reference; record its home bundle + graceful-degradation note.\n- **BUILD-skill** — a real, distinct review question with no owner → Step 5.\n- **BUILD-agent** — not a review lens at all but an *active builder\u002Fspecialist*\n  → Step 4.\n\n**Don't let reconciliation silently re-inflate what Step 2 derived as ideal.**\nIf an existing lens is a near-but-imperfect match for a Step 2 candidate,\ncheck whether it's a genuine REUSE or whether accepting it is convenience\nposing as fit — a real mismatch is still a BUILD, even if something adjacent\nalready exists.\n\nThen apply the **needs-its-own-council test** (all three required): distinct\ntarget class; ≥4–5 net-new orthogonal lenses; folding them into an existing bench\nwould make it incoherent or oversized (>~8). If it fails, STOP and recommend\n`personafy`-ing the 1–2 new lenses into the existing council instead.\n\n**Don't fix the headcount before this step produces it.** Naming a target\nnumber (\"we want N lenses\") before deriving the roster is the same bias this\nstep exists to prevent, aimed at a different constraint — the count is an\noutput of Steps 2–3, not an input to them. If real evidence (multiple\nindependent derivations, actual usage history, a genuine overlap check) later\nargues for a different count than what a single pass produced, that's a reason\nto re-derive, not to trim or pad toward a number decided in advance.\n\n#### Bench-size guidance (a strong default, not a gate)\n\nGrounded in the real benches confirmed in this ecosystem, not invented round\nnumbers: `council` runs exactly 6 (intent-keeper, cranky-old-sam,\ncrusty-old-engineer, restless-old-brian, user-advocate, tester-breaker) —\nconfirmed directly from its own `SKILL.md`. `adversarial-review` runs exactly\n6 (SRE, security, staff engineer, finance, operator, developer advocate) —\nconfirmed via its own declared skill description, surfaced live in-session (its\nsource file was not available to inspect directly, so this is a\nmetadata-level confirmation, not a file-level one — say so if you're ever in\nthe same position). `design-council` runs exactly 7 — confirmed directly from\nits own `SKILL.md`. A `product-council` instance in this ecosystem grew from 7\nto 8 after a genuinely orthogonal 8th lens passed the collapse-test gate\nagainst its single closest neighbor — confirmed directly from its own\n`SKILL.md` and bundle.md, which both flag 8 explicitly as \"the edge, not the\ncomfortable middle\" of the range below.\n\nFrom these four real data points — **6, 6, 7, 8** — treat as a strong default:\n\n- **Hard floor ~4.** Below four lenses, you don't have enough irreducible\n  perspectives to justify calling the thing a \"council\" rather than just\n  adding a couple of extra reviewers to whatever bench already exists — the\n  orchestration overhead (roster manifest, cold fan-out, debate-to-consensus\n  machinery) stops paying for itself. No confirmed bench in this ecosystem\n  runs below 6; treat 4 as the line below which you should stop and ask\n  whether this needs the council mechanism at all, not just a smaller one.\n- **Typical\u002Fcomfortable range 5–7.** Brackets all three of the smaller\n  confirmed working benches (6, 6, 7) — the load a synthesizer can hold in\n  its head, attribute every claim to, and quote verbatim from, per lens,\n  without the Phase-5\u002FPhase-4 synthesis guardrails becoming unwieldy.\n- **Soft ceiling ~8.** `design-council`'s 7 is the largest *comfortable*\n  confirmed precedent; the one 8-lens bench on record explicitly flags\n  itself as sitting at the edge of the range, not inside it. Above 8, the\n  cost of full cold fan-out (every lens spawned in an isolated sub-session)\n  and the cognitive load on the human reading the synthesis both start to\n  degrade faster than the added orthogonality is worth — that's the signal\n  to fold an overlapping lens into a sibling, or split into two councils\n  with genuinely distinct target classes, rather than keep growing one\n  bench.\n\n**This is guidance for your judgment in this step, not a hard-coded gate.**\nTrust the model with the *why*, not a rigid headcount: if a candidate lens\ngenuinely passes the orthogonality\u002Fcollapse-test gate — a real, distinct,\nevidence-grounded load-bearing question with no existing owner — that is\nstronger evidence than a round number, and the bench should grow to fit the\nevidence, exactly as `product-council` did going from 7 to 8. The moment a\n9th genuinely-orthogonal candidate shows up for any bench, treat that as the\ntrigger to seriously reconsider whether it's still one council — not a\nreason to silently wave the 9th one in past the ceiling above.\n\n- **Human checkpoint:** confirm the roster (reused + new), and the\n  own-council-vs-add-lenses decision, before any building.\n\n**Success criteria:** Every candidate routed; the own-council decision is\nexplicit and defensible against all existing panels.\n**Rule:** ground the decision in the actual inventory, not assumption.\n\n### 4. Skill-lens vs agent decision (only for BUILD-agent candidates)\n\nConsult the skills-vs-agents framework (`load_skill(\"skills-assist\")`). Default:\na **review lens → persona SKILL**. Choose an **agent** only when the member must\nwield its own tools, produce artifacts, or run isolated multi-turn builds — i.e.\nit *builds*, it doesn't *judge*. If the domain's members are mostly builders, say\nso plainly: you are producing an **agent-specialist panel** (fan-out delegate to\nbuilder agents, synthesize artifacts), which is a different orchestration than a\ncritique council — do not force it into the council template.\n\n**Success criteria:** Each new member is typed skill-lens or agent with a one-line\njustification.\n\n### 5. Build the missing lenses\n\nFor each BUILD-skill lens, run `personafy` end-to-end (study family → define the\nload-bearing question + contrast table → mine voice\u002Fdiscipline from real evidence\n→ draft to the **council-native lens template** → prove it steers → reduce).\nWrite each to `\u003Ccouncil-bundle>\u002Fskills\u002F\u003Clens>\u002FSKILL.md`.\n\n- **Execution:** Delegate one `personafy` run per lens (parallel where the lenses\n  are independent); `model_role=\"reasoning\"`.\n\n**Success criteria:** Each new lens has a verbatim-grounded profile, an explicit\nVerdict Protocol returning `{lens,verdict,findings[],evidence[]}`, and a\nTension-With section naming its seams against the rest of the bench.\n**Rule:** if two new lenses' contrast tables don't cleanly separate, one of them\nisn't a lens — merge or cut.\n**Artifacts:** the new SKILL.md paths.\n\n### 6. Assemble the orchestrator\n\nInstantiate `templates\u002Fcouncil-orchestrator.SKILL.md.tmpl` →\n`\u003Ccouncil-bundle>\u002Fskills\u002F\u003Cdomain>-council\u002FSKILL.md`, and the inline counterpart →\n`\u003Cdomain>-council-here\u002FSKILL.md`. Fill: the bench (mandatory vs conditional\nsplit), where each lens lives (in-bundle vs reused-cross-bundle + its\nUNAVAILABLE reason string), the target class, and whether a neutral pre-digest\nphase applies (repo targets → yes, like `council`; single-artifact targets → no,\nlike `design-council` — delete the phase and renumber down if not needed).\nPreserve every trust guardrail verbatim.\n\nOptional extension: if a recipe-driven consumer is identified (per the\n`adversarial-review` \u002F `systems-design-critic` precedent from Step 3), also\nexpose a thin `delegate`-able agent wrapper over the same bench for\nrecipe-context callers. Only add this if a real recipe consumer exists — do not\nbuild it speculatively.\n\n**Success criteria:** Orchestrator + here-counterpart exist, bench hard-coded,\ngraceful-degradation covers every reused (cross-bundle) lens.\n**Rule:** keep `\u003Cdomain>-council`\u002F`\u003Cdomain>-council-here` in sync — same roster,\nsame guardrails, only the target differs.\n\n### 7. Scaffold the bundle and choose its home\n\nAlways emit the flat-layout supporting root `bundle.md` as the namespace\nmanifest for `amplifier-bundle-\u003Cdomain>-council`, and emit the primary reusable\npayload at `behaviors\u002F\u003Cdomain>-council-behavior.yaml`. The registry discovers\nthe root manifest to resolve its `@\u003Cdomain>-council:skills` and\n`@\u003Cdomain>-council:context\u002F...` references when the behavior is installed\ndirectly. This namespace-only registration does not compose or select the root,\nso it does not make this root-first. Generic self-contained behaviors outside\nthis flat layout may remain rootless.\n\nThe behavior filename corresponds to the supporting root's extensionless\n`\u003Cdomain>-council:behaviors\u002F\u003Cdomain>-council-behavior` include; the resolver\nappends `.yaml`. It owns required portable dependencies:\nthe full skills behavior supplies the tool, instructions, and visibility;\nreused cross-bundle lenses are behavior includes; and its own\n`tool-skills.config.skills` points at `@\u003Cbundle>:skills`. Keep its source and\nthe thin awareness `context.include`. Do not use complete roots as proxy\ndependencies.\n\nThe always-emitted supporting root is also an optional runnable entry. It\ncomposes Anchors\n(`git+https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-foundation@main#subdirectory=bundles\u002Fanchors\u002Fbundle.md`)\nand the council's own behavior only. Its name remains the namespace anchor;\nthe behavior has the distinct `-behavior` name. Its body contains only\n`@anchors:context\u002Fsystem.md` unless a distinct root-only instruction is\nevidenced. Keep awareness in the behavior's `context.include`, not in the\nroot body.\n\nWrite the human overview, lens descriptions, grounding, and division of labor\nto the generated `README.md`; do not put them in the supporting root body.\nArchetype-named council → public; real-person-named lenses → keep those lenses\nin a private\u002Fteam bundle and compose by reference.\n\n- **Human checkpoint:** confirm the bundle name and home (public vs private).\n\n**Success criteria:** `bundle.md` is always emitted as the flat-layout\nnamespace anchor; `behaviors\u002F\u003Cdomain>-council-behavior.yaml` is the primary\ndirect-install artifact; the primary behavior composes all portable\ndependencies; the supporting root composes only Anchors and that behavior;\nawareness pointer is a thin \"this council exists, invoke \u002F\u003Cdomain>-council\" —\nNOT the lens content; and README carries the human overview.\n\n### 8. Prove the council convenes (end-to-end)\n\nIn a FRESH session, run `\u002F\u003Cdomain>-council \u003Crealistic target>`. Confirm: roster\nmanifest prints first, every rostered lens LOADS (reused cross-bundle lenses\nincluded, or degrades to UNAVAILABLE with reason), verdicts return, at least one\ngenuine tension is surfaced as dissent rather than averaged away.\n\n**Every lens description this council emits must pass the validators\nunmodified.** Run, from the target repo:\n\n    amplifier tool invoke recipes operation=execute \\\n      recipe_path=foundation:recipes\u002Fvalidate-bundle-repo.yaml \\\n      context='{\"repo_path\": \".\"}'\n\nand read the Skill Description Validation section: zero `skill_description_excessive`,\nzero `example_block_present`. A council of N lenses multiplies any description\ndefect by N, and every one of those descriptions is paid on every request of\nevery session that can see the skills.\n\n**Success criteria:** A transcript of a real convened run — roster + attributed\nverdicts + preserved dissent — and a clean Skill Description Validation section\nfor every lens the council added.\n**Rule:** proof is a convened run. \"The files exist\" is NOT proof (the ROB gate).\n\n### 9. Reduce and publish\n\nTrim any restated procedure; keep guardrails and verbatim lens quotes. Run the git\nlifecycle.\n\n- **Execution:** Delegate branch\u002Fcommit\u002FPR\u002Fmerge to `anchors:git-ops`.\n- **Human checkpoint:** confirm before opening\u002Fmerging the PR.\n\n**Success criteria:** PR merged; then, in a clean session after `amplifier\nupdate`, `\u002F\u003Cdomain>-council` resolves from the bundle cache — \"merged\" ≠ \"loads\nfor a user.\"\n","# Councilify\n\nProduce a NEW, invocable **council** for a domain: a `context: fork` concierge\norchestrator over a bench of **orthogonal lenses**, following the proven\n`\u002Fcouncil` → `\u002Fdesign-council` pattern. Reuse before you build; build lenses only\nwhere a real, distinct load-bearing question is missing.\n\n**Success artifact:** a council bundle that, in a FRESH session, convenes on a\nrealistic target — prints a roster manifest, loads every rostered lens (cold,\nindependent), returns `{PASS|CONCERN|FAIL|N\u002FA}` verdicts, and surfaces standing\ndissent — with every NEW lens grounded in real evidence and proven to steer.\n\n## Inputs\n\n- `$ARGUMENTS`: the domain to build a council for (e.g. \"product development\",\n  \"security review\", \"performance\"). Optionally: pointers to evidence\u002Farchetypes,\n  a target-class hint, and a preferred bundle home.\n\n## Core Principles\n\n- **Reuse beats build.** A lens that already owns an axis is composed in by\n  reference across bundle boundaries (the ROB-from-made-support precedent), never\n  copied. Building a lens whose question equals an existing lens's is the failure\n  this skill exists to prevent.\n- **One question per lens, from evidence.** Every lens owns exactly ONE\n  load-bearing question, mined from a real person\u002Farchetype per `personafy` —\n  never invented from vibes. If a candidate's question collapses into an existing\n  lens's, it is not a lens. Cut it.\n- **No anthropomorphizing beyond a distinct voice.** A lens is a review\n  *perspective* with a recognizable voice and discipline, not a fictional\n  character with a backstory. Voice serves steering; lore does not.\n- **Councils are complementary, not duplicative.** A new council must review a\n  distinct target class at a distinct stage. Sharing a lens across councils is\n  fine; two councils doing the same job is not.\n\n## Steps\n\n### 1. Study the pattern\n\nRead the reference implementations in full: `council\u002FSKILL.md`,\n`council-here\u002FSKILL.md`, and `design-council\u002FSKILL.md` + two of its lens skills\n(e.g. `originality-critic`, `purpose-keeper`). Extract: the phase-by-phase\norchestration (roster → optional neutral digest → cold fan-out →\ndebate-to-consensus → synthesize), the trust guardrails (roster manifest first,\nattributed quotes, never downgrade a FAIL, keep FAIL≠N\u002FA), UNAVAILABLE vs\nERRORED handling, and the **council-native lens template** (Load-Bearing\nQuestion \u002F Grounding \u002F Tone \u002F Core Behaviors \u002F Verdict Protocol \u002F Tension With).\nNote the phase-numbering difference between the two: `council` has 5 phases\n(Guard Check, Roster, repo-digest, fan-out, debate, synthesize) because it\nsupports a repo-crawl pre-digest; `design-council` has 4 phases (no pre-digest —\ntargets always pass directly) because every target is a single self-contained\ndesign artifact.\n\n**Success criteria:** You can restate the orchestrator's phases and the lens\ntemplate from memory, and name why `council-here` is inline while `council`\nforks.\n\n### 2. Derive the domain's ideal roster — BLIND to the existing inventory first\n\nName the domain's **target class** (what artifact does this council review?) and\n**stage** (when in the lifecycle?). Then derive, independently of what already\nexists, the distinct perspectives that domain genuinely demands — mining real\ndomain-leadership archetypes for each. For each candidate: one load-bearing\nquestion, the archetype\u002Fframework it's grounded in, and a one-line voice.\n\n**Do this before looking at the installed skill inventory.** Naming what already\nexists first biases the derivation toward \"what we have\" instead of \"what the\ndomain actually needs\" — the two can look similar, but a roster built the second\nway is more likely to contain the ideal makeup rather than a locally-convenient\none.\n\n- **Execution:** Delegate parallel `model_role=\"research\"` agents to gather\n  archetype evidence per candidate lens; each writes findings to disk, returns a\n  thin summary. Explicitly instruct each research agent NOT to consult or let\n  its own visible skill list bias which perspectives it proposes — derive from\n  the domain's real leadership archetypes and literature, not from what\n  happens to already be installed.\n\n**Honest limitation, stated plainly (verified directly, not assumed):** on this\nplatform, a `delegate`-spawned sub-session — even with `context_depth=\"none\"` —\nstill receives an unconditional `hooks-skills-visibility` system-reminder\nlisting dozens of installed skill names, regardless of what it was told or\nasked to do. This was confirmed by direct test: a cold, context-free sub-agent\nreported seeing the full skill list before any instruction reached it. **True\ntechnical isolation from the inventory is not currently achievable via\n`delegate` alone on this platform.** Treat the \"don't consult the inventory\"\ninstruction above as a *policy constraint you are asking the model to honor*,\nnot an architectural guarantee — and say so if you rely on it. If a stronger\nguarantee is ever needed, that requires a different mechanism than same-platform\n`delegate` (e.g., an external process with no skill-visibility hook at all);\ndon't claim isolation you haven't verified holds.\n\n**Success criteria:** A candidate list where each entry has ONE question grounded\nin a named archetype, not a vibe — derived from the domain's real needs first.\n\n### 3. Reconcile against the installed inventory — route every candidate\n\nOnly now enumerate the FULL installed inventory: `load_skill(list=true)` for all\nlens skills, and identify every existing panel — `council` (6: intent-keeper,\ncranky-old-sam, crusty-old-engineer, restless-old-brian, user-advocate,\ntester-breaker), `design-council` (7 design lenses), `adversarial-review` (6:\nSRE, security, staff engineer, finance, operator, developer advocate —\nproduction\u002Foperational risk of a system design; note it also ships a\nrecipe-callable `systems-design-critic` agent form of the same bench, a third\ncomposition pattern worth considering in Step 6's optional extension), plus any\nothers surfaced by the inventory scan.\n\nBuild a **coverage matrix**: the Step 2 candidate list × existing lenses. Route\neach candidate to exactly one of:\n- **REUSE** — an existing lens already owns this exact question → compose by\n  reference; record its home bundle + graceful-degradation note.\n- **BUILD-skill** — a real, distinct review question with no owner → Step 5.\n- **BUILD-agent** — not a review lens at all but an *active builder\u002Fspecialist*\n  → Step 4.\n\n**Don't let reconciliation silently re-inflate what Step 2 derived as ideal.**\nIf an existing lens is a near-but-imperfect match for a Step 2 candidate,\ncheck whether it's a genuine REUSE or whether accepting it is convenience\nposing as fit — a real mismatch is still a BUILD, even if something adjacent\nalready exists.\n\nThen apply the **needs-its-own-council test** (all three required): distinct\ntarget class; ≥4–5 net-new orthogonal lenses; folding them into an existing bench\nwould make it incoherent or oversized (>~8). If it fails, STOP and recommend\n`personafy`-ing the 1–2 new lenses into the existing council instead.\n\n**Don't fix the headcount before this step produces it.** Naming a target\nnumber (\"we want N lenses\") before deriving the roster is the same bias this\nstep exists to prevent, aimed at a different constraint — the count is an\noutput of Steps 2–3, not an input to them. If real evidence (multiple\nindependent derivations, actual usage history, a genuine overlap check) later\nargues for a different count than what a single pass produced, that's a reason\nto re-derive, not to trim or pad toward a number decided in advance.\n\n#### Bench-size guidance (a strong default, not a gate)\n\nGrounded in the real benches confirmed in this ecosystem, not invented round\nnumbers: `council` runs exactly 6 (intent-keeper, cranky-old-sam,\ncrusty-old-engineer, restless-old-brian, user-advocate, tester-breaker) —\nconfirmed directly from its own `SKILL.md`. `adversarial-review` runs exactly\n6 (SRE, security, staff engineer, finance, operator, developer advocate) —\nconfirmed via its own declared skill description, surfaced live in-session (its\nsource file was not available to inspect directly, so this is a\nmetadata-level confirmation, not a file-level one — say so if you're ever in\nthe same position). `design-council` runs exactly 7 — confirmed directly from\nits own `SKILL.md`. A `product-council` instance in this ecosystem grew from 7\nto 8 after a genuinely orthogonal 8th lens passed the collapse-test gate\nagainst its single closest neighbor — confirmed directly from its own\n`SKILL.md` and bundle.md, which both flag 8 explicitly as \"the edge, not the\ncomfortable middle\" of the range below.\n\nFrom these four real data points — **6, 6, 7, 8** — treat as a strong default:\n\n- **Hard floor ~4.** Below four lenses, you don't have enough irreducible\n  perspectives to justify calling the thing a \"council\" rather than just\n  adding a couple of extra reviewers to whatever bench already exists — the\n  orchestration overhead (roster manifest, cold fan-out, debate-to-consensus\n  machinery) stops paying for itself. No confirmed bench in this ecosystem\n  runs below 6; treat 4 as the line below which you should stop and ask\n  whether this needs the council mechanism at all, not just a smaller one.\n- **Typical\u002Fcomfortable range 5–7.** Brackets all three of the smaller\n  confirmed working benches (6, 6, 7) — the load a synthesizer can hold in\n  its head, attribute every claim to, and quote verbatim from, per lens,\n  without the Phase-5\u002FPhase-4 synthesis guardrails becoming unwieldy.\n- **Soft ceiling ~8.** `design-council`'s 7 is the largest *comfortable*\n  confirmed precedent; the one 8-lens bench on record explicitly flags\n  itself as sitting at the edge of the range, not inside it. Above 8, the\n  cost of full cold fan-out (every lens spawned in an isolated sub-session)\n  and the cognitive load on the human reading the synthesis both start to\n  degrade faster than the added orthogonality is worth — that's the signal\n  to fold an overlapping lens into a sibling, or split into two councils\n  with genuinely distinct target classes, rather than keep growing one\n  bench.\n\n**This is guidance for your judgment in this step, not a hard-coded gate.**\nTrust the model with the *why*, not a rigid headcount: if a candidate lens\ngenuinely passes the orthogonality\u002Fcollapse-test gate — a real, distinct,\nevidence-grounded load-bearing question with no existing owner — that is\nstronger evidence than a round number, and the bench should grow to fit the\nevidence, exactly as `product-council` did going from 7 to 8. The moment a\n9th genuinely-orthogonal candidate shows up for any bench, treat that as the\ntrigger to seriously reconsider whether it's still one council — not a\nreason to silently wave the 9th one in past the ceiling above.\n\n- **Human checkpoint:** confirm the roster (reused + new), and the\n  own-council-vs-add-lenses decision, before any building.\n\n**Success criteria:** Every candidate routed; the own-council decision is\nexplicit and defensible against all existing panels.\n**Rule:** ground the decision in the actual inventory, not assumption.\n\n### 4. Skill-lens vs agent decision (only for BUILD-agent candidates)\n\nConsult the skills-vs-agents framework (`load_skill(\"skills-assist\")`). Default:\na **review lens → persona SKILL**. Choose an **agent** only when the member must\nwield its own tools, produce artifacts, or run isolated multi-turn builds — i.e.\nit *builds*, it doesn't *judge*. If the domain's members are mostly builders, say\nso plainly: you are producing an **agent-specialist panel** (fan-out delegate to\nbuilder agents, synthesize artifacts), which is a different orchestration than a\ncritique council — do not force it into the council template.\n\n**Success criteria:** Each new member is typed skill-lens or agent with a one-line\njustification.\n\n### 5. Build the missing lenses\n\nFor each BUILD-skill lens, run `personafy` end-to-end (study family → define the\nload-bearing question + contrast table → mine voice\u002Fdiscipline from real evidence\n→ draft to the **council-native lens template** → prove it steers → reduce).\nWrite each to `\u003Ccouncil-bundle>\u002Fskills\u002F\u003Clens>\u002FSKILL.md`.\n\n- **Execution:** Delegate one `personafy` run per lens (parallel where the lenses\n  are independent); `model_role=\"reasoning\"`.\n\n**Success criteria:** Each new lens has a verbatim-grounded profile, an explicit\nVerdict Protocol returning `{lens,verdict,findings[],evidence[]}`, and a\nTension-With section naming its seams against the rest of the bench.\n**Rule:** if two new lenses' contrast tables don't cleanly separate, one of them\nisn't a lens — merge or cut.\n**Artifacts:** the new SKILL.md paths.\n\n### 6. Assemble the orchestrator\n\nInstantiate `templates\u002Fcouncil-orchestrator.SKILL.md.tmpl` →\n`\u003Ccouncil-bundle>\u002Fskills\u002F\u003Cdomain>-council\u002FSKILL.md`, and the inline counterpart →\n`\u003Cdomain>-council-here\u002FSKILL.md`. Fill: the bench (mandatory vs conditional\nsplit), where each lens lives (in-bundle vs reused-cross-bundle + its\nUNAVAILABLE reason string), the target class, and whether a neutral pre-digest\nphase applies (repo targets → yes, like `council`; single-artifact targets → no,\nlike `design-council` — delete the phase and renumber down if not needed).\nPreserve every trust guardrail verbatim.\n\nOptional extension: if a recipe-driven consumer is identified (per the\n`adversarial-review` \u002F `systems-design-critic` precedent from Step 3), also\nexpose a thin `delegate`-able agent wrapper over the same bench for\nrecipe-context callers. Only add this if a real recipe consumer exists — do not\nbuild it speculatively.\n\n**Success criteria:** Orchestrator + here-counterpart exist, bench hard-coded,\ngraceful-degradation covers every reused (cross-bundle) lens.\n**Rule:** keep `\u003Cdomain>-council`\u002F`\u003Cdomain>-council-here` in sync — same roster,\nsame guardrails, only the target differs.\n\n### 7. Scaffold the bundle and choose its home\n\nAlways emit the flat-layout supporting root `bundle.md` as the namespace\nmanifest for `amplifier-bundle-\u003Cdomain>-council`, and emit the primary reusable\npayload at `behaviors\u002F\u003Cdomain>-council-behavior.yaml`. The registry discovers\nthe root manifest to resolve its `@\u003Cdomain>-council:skills` and\n`@\u003Cdomain>-council:context\u002F...` references when the behavior is installed\ndirectly. This namespace-only registration does not compose or select the root,\nso it does not make this root-first. Generic self-contained behaviors outside\nthis flat layout may remain rootless.\n\nThe behavior filename corresponds to the supporting root's extensionless\n`\u003Cdomain>-council:behaviors\u002F\u003Cdomain>-council-behavior` include; the resolver\nappends `.yaml`. It owns required portable dependencies:\nthe full skills behavior supplies the tool, instructions, and visibility;\nreused cross-bundle lenses are behavior includes; and its own\n`tool-skills.config.skills` points at `@\u003Cbundle>:skills`. Keep its source and\nthe thin awareness `context.include`. Do not use complete roots as proxy\ndependencies.\n\nThe always-emitted supporting root is also an optional runnable entry. It\ncomposes Anchors\n(`git+https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-foundation@main#subdirectory=bundles\u002Fanchors\u002Fbundle.md`)\nand the council's own behavior only. Its name remains the namespace anchor;\nthe behavior has the distinct `-behavior` name. Its body contains only\n`@anchors:context\u002Fsystem.md` unless a distinct root-only instruction is\nevidenced. Keep awareness in the behavior's `context.include`, not in the\nroot body.\n\nWrite the human overview, lens descriptions, grounding, and division of labor\nto the generated `README.md`; do not put them in the supporting root body.\nArchetype-named council → public; real-person-named lenses → keep those lenses\nin a private\u002Fteam bundle and compose by reference.\n\n- **Human checkpoint:** confirm the bundle name and home (public vs private).\n\n**Success criteria:** `bundle.md` is always emitted as the flat-layout\nnamespace anchor; `behaviors\u002F\u003Cdomain>-council-behavior.yaml` is the primary\ndirect-install artifact; the primary behavior composes all portable\ndependencies; the supporting root composes only Anchors and that behavior;\nawareness pointer is a thin \"this council exists, invoke \u002F\u003Cdomain>-council\" —\nNOT the lens content; and README carries the human overview.\n\n### 8. Prove the council convenes (end-to-end)\n\nIn a FRESH session, run `\u002F\u003Cdomain>-council \u003Crealistic target>`. Confirm: roster\nmanifest prints first, every rostered lens LOADS (reused cross-bundle lenses\nincluded, or degrades to UNAVAILABLE with reason), verdicts return, at least one\ngenuine tension is surfaced as dissent rather than averaged away.\n\n**Every lens description this council emits must pass the validators\nunmodified.** Run, from the target repo:\n\n    amplifier tool invoke recipes operation=execute \\\n      recipe_path=foundation:recipes\u002Fvalidate-bundle-repo.yaml \\\n      context='{\"repo_path\": \".\"}'\n\nand read the Skill Description Validation section: zero `skill_description_excessive`,\nzero `example_block_present`. A council of N lenses multiplies any description\ndefect by N, and every one of those descriptions is paid on every request of\nevery session that can see the skills.\n\n**Success criteria:** A transcript of a real convened run — roster + attributed\nverdicts + preserved dissent — and a clean Skill Description Validation section\nfor every lens the council added.\n**Rule:** proof is a convened run. \"The files exist\" is NOT proof (the ROB gate).\n\n### 9. Reduce and publish\n\nTrim any restated procedure; keep guardrails and verbatim lens quotes. Run the git\nlifecycle.\n\n- **Execution:** Delegate branch\u002Fcommit\u002FPR\u002Fmerge to `anchors:git-ops`.\n- **Human checkpoint:** confirm before opening\u002Fmerging the PR.\n\n**Success criteria:** PR merged; then, in a clean session after `amplifier\nupdate`, `\u002F\u003Cdomain>-council` resolves from the bundle cache — \"merged\" ≠ \"loads\nfor a user.\"\n",{"name":5,"model_role":29,"visibility":30,"description":7,"allowed-tools":32,"user-invocable":40,"disable-model-invocation":40},"reasoning",{"summary":31},"Build a new domain council — orthogonal review lenses that fan out cold, debate to consensus, and return a verdict with dissent.",[33,34,35,36,37,38,39],"read_file","write_file","edit_file","glob","grep","bash","delegate",true,"main","2f58408a879535df36da5c92d2b073f49271ade4","skills\u002Fcouncilify",11,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-10-03 02:23:42",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":40},[52,55,58],{"tool":53,"command":54},"npx","npx skills add microsoft\u002Famplifier-bundle-skills --skill councilify",{"tool":56,"command":57},"bunx","bunx skills add microsoft\u002Famplifier-bundle-skills --skill councilify",{"tool":59,"command":60},"pnpm","pnpm dlx skills add microsoft\u002Famplifier-bundle-skills --skill councilify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fcouncilify\u002FSKILL.md",[63,69,73,77,81,85,89],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"templates\u002Fawareness.md.tmpl","OTHER","其他",1504,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fcouncilify\u002Ftemplates\u002Fawareness.md.tmpl",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"templates\u002Fbehavior.yaml.tmpl",1235,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fcouncilify\u002Ftemplates\u002Fbehavior.yaml.tmpl",{"path":74,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":75,"sourceHtmlUrl":76},"templates\u002Fbundle.md.tmpl",888,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fcouncilify\u002Ftemplates\u002Fbundle.md.tmpl",{"path":78,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":79,"sourceHtmlUrl":80},"templates\u002Fcouncil-here-orchestrator.SKILL.md.tmpl",8048,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fcouncilify\u002Ftemplates\u002Fcouncil-here-orchestrator.SKILL.md.tmpl",{"path":82,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":83,"sourceHtmlUrl":84},"templates\u002Fcouncil-native-lens.SKILL.md.tmpl",4544,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fcouncilify\u002Ftemplates\u002Fcouncil-native-lens.SKILL.md.tmpl",{"path":86,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":87,"sourceHtmlUrl":88},"templates\u002Fcouncil-orchestrator.SKILL.md.tmpl",11964,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fcouncilify\u002Ftemplates\u002Fcouncil-orchestrator.SKILL.md.tmpl",{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"templates\u002Fresearch-plan-template.md","REFERENCE","参考文档",5877,"https:\u002F\u002Fgithub.com\u002Fshengdabai\u002FTony-Claude-Code-Skills\u002Fblob\u002Fmain\u002Fskills\u002F_collections\u002Frsmdt-the-startup\u002Fplugins\u002Fteam\u002Fskills\u002Fdesign\u002Fuser-insight-synthesis\u002Ftemplates\u002Fresearch-plan-template.md",[96,105,115,128,139,153],{"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":102,"publishedAt":24},"01M69B282M59QZNMM26JXA1QCV","verification-discipline","Use when verifying that completed work actually works. Auto-surface during \u002Fverify mode, post-implementation review, or before claiming a task is done. Teaches testing outcomes vs implementation, the unit\u002Fintegration\u002Fsmoke gradient, and what \"done\" actually means.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-discipline\u002FSKILL.md",[],[103,20,104],"verification discipline","testing",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":24},"01M69B263M6BFCVAV3SEESV7T0","user-advocate","User-need reviewer that speaks for the person who isn't in the room — the one who will actually live with what gets built. Hunts the gap between \"we can build this\" and \"they actually want this,\" in the patient, impatient voice of the absent user. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when a feature is being built because it's buildable rather than wanted, the recovery path is missing, or nobody can name the person this serves: \"do they actually want this, and can they live with it?\"","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fuser-advocate\u002FSKILL.md",[],[112,113,114,20,19],"user advocate","debug","implement",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":126,"publishedAt":24},"01M69B23EQQM30TMZG7FPJW4F7","tester-breaker","Adversarial breaker that reviews code by trying to make it fail, not by confirming it works. Hunts the unhappy paths — malformed input, the empty string, the reversed range, the race condition — as a gleeful adversary who assumes everything is broken until a concrete attempt to break it comes up empty. Use at any checkpoint — brainstorm, design, plan, implement, debug, review — when the happy path is celebrated while the edges sit unexamined, \"looks fine\" stands in for \"I tried to break it and couldn't,\" or nobody has named the input that makes this fall over: \"how does this fail, and where are the edges?\"","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftester-breaker\u002FSKILL.md",[121],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[127,20,113,114,19],"tester breaker",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":24},"01M69B21AHBXP6EK60XYDP24PY","skills-assist","Authoritative consultant for all skills-related questions. Use when creating or modifying skills, understanding the Agent Skills spec, troubleshooting skill loading or invocation issues, leveraging enhanced format features (context fork, model_role, user-invocable), writing cross-harness portable skills, ensuring Claude Code Skills 2.0 compatibility, or deciding between skills vs agents.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fskills-assist\u002FSKILL.md",[],[135,136,137,138],"skills assist","claude code skills","spec","writing",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":150,"publishedAt":24},"01M69B1ZBHGE1PAX0E7ZDS8HQZ","skillify","Capture a repeatable process from the current session into a reusable Amplifier SKILL.md skill file. Use when the user wants to create a skill, save a workflow as a skill, turn a process into a reusable skill, or mentions \"skillify\", \"create skill\", \"make a skill\", \"save as skill\", \"capture workflow\", \"turn this into a skill\", \"new skill\", or wants to automate a repeatable process they just performed.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fskillify\u002FSKILL.md",[145],{"categoryNo":146,"categoryName":147,"taxonomyType":148,"taxonomyTypeDesc":149},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[141,151,152],"create skill","workflow",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":160,"publishedAt":24},"01M69B1XCPQFAXS9RTS87CZ8EK","session-debug","Diagnose issues in the current Amplifier session — misconfigured tools, failing operations, unexpected behavior. Use when something isn't working right.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Famplifier-bundle-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsession-debug\u002FSKILL.md",[159],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[161,113,162],"session debug","diagnose"]