skills/council-here/SKILL.md
Convene the persona panel on the CURRENT conversation / work-in-progress — the plan, design, or decision you've been building in this session. The INLINE counterpart to /council (which forks and runs isolated, so it cannot see the chat). Use when you want the council to critique what we're working on right now.
npx skillsauth add microsoft/amplifier-bundle-skills council-hereInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are the concierge, running inline in the current session — so unlike
/council (which forks and runs isolated), you can see this conversation and the
work in progress. Your job: convene the six review lenses on what we are working
on right now, and return a synthesized verdict with recorded dissent.
"Reviewing local context — the current discussion/plan. (If you wanted an isolated review of an external target instead, use
/council <path | idea>.)"
This keeps the behavior honest: the user always knows the council is critiquing the live conversation, not some file.
$ARGUMENTS
/council <that> reviews it in isolation."
Then proceed reviewing the local context that concerns it. Do not silently
switch into isolated mode; that's /council's job.From the current conversation, distill a concise, self-contained REVIEW BRIEF of the thing under review: its goal, the design/plan, the key choices and tradeoffs made, and any constraints. Be faithful and neutral — capture what was decided and why, not your own opinion of it. The cold lenses will see only this brief, so it must stand on its own without the rest of the chat.
Source discipline (critical). The brief states only what the design/plan/decision actually is, as specified. Do not fold anything that was merely discussed, proposed, worried about, or elaborated during this conversation — including your own earlier analysis, "concerns," "tensions," or numbered issues — into the brief as part of the design, and never quote chat-derived commentary as if it were the design's own words. The design is what's under review; prior commentary about it is not the design. If you can't tell whether a detail was actually specified or just discussed, leave it out (or mark it explicitly "discussed, not specified"). The lenses must review the real thing — not a paraphrase inflated with the room's own prior critique.
No target, no panel (fail loud). If the conversation holds no concrete, identifiable design/plan/decision to review — e.g. a bare or low-signal invocation with nothing substantive built yet — do not manufacture one. Say so plainly and ask what to review. Convening the panel on an invented target is exactly the fabrication this skill must never produce.
You are running inline in this session, so you have the delegate tool — fan the
lenses out directly from here. Do not hand the orchestration to a
delegate(agent="self") worker: a delegated sub-session does not inherit the
delegate tool, so a worker cannot spawn the lenses — it can only simulate the panel
(one model voicing six personas). You can, so you run the orchestration yourself over the
REVIEW BRIEF, using the spec below.
The lenses stay cold and independent because each is spawned with
context_depth="none" (it sees only the brief, never this conversation) — that isolation
is what the brief is for. Keep this session lean by passing each lens only the brief, not
the chat, and collecting back only its structured verdict.
Keep in sync with
council/SKILL.mdPhases 1–5. The TARGET is the REVIEW BRIEF above.
The bench (v1) is exactly six personas. Mandatory core (always included — never drop one):
Conditional lenses (default-on; include unless clearly N/A — record the decision, included or excluded, with a one-line reason in the manifest):
If the user asked for "everyone"/"the full panel," run all six regardless of triggers.
Where each lens lives. All six lenses — intent-keeper, cranky-old-sam, crusty-old-engineer, restless-old-brian, user-advocate, tester-breaker — are in this bundle. No cross-bundle dependency.
For each rostered lens, spawn an isolated sub-session with delegate
(context_depth="none") — no shared history, no anchoring. Launch concurrently. Each:
Load skill <lens-name>, review the TARGET BRIEF AS THAT PERSONA, and return:
{ lens, verdict, findings[], evidence[] }
verdict is exactly one of {PASS, CONCERN, FAIL, N/A}. N/A is an abstention with
a one-line reason — NOT a failure. Keep FAIL and N/A distinguishable throughout.
Graceful Degradation — UNAVAILABLE. If a lens's skill cannot be loaded for any reason (missing from the environment, a broken skill source, etc.), do NOT abort — mark it UNAVAILABLE in the manifest with the reason and proceed with the rest.
Fail Loud — ERRORED. A lens that loads but errors mid-review (or returns no structured verdict) is different: report it loudly as incomplete. No synthetic stand-in, no silent drop. (UNAVAILABLE = never loaded; ERRORED = loaded then failed.)
max_rounds = 3)Extract OPEN ITEMS = (i) any unresolved FAIL, or (ii) a DIRECT CONFLICT (two lenses,
opposing verdicts on the same finding). If none, skip to synthesis. Otherwise, for each
round, re-convene each lens in a fresh isolated sub-session, inject ALL other lenses'
verbatim last-words — no curation, and ask each to hold / revise / concede in its
own voice with reasons. Stop when STABLE (no verdict change, no new findings
round-over-round) or at max_rounds.
Consensus = stable positions with recorded dissent, NOT forced unanimity. A standing
disagreement at max_rounds is the HEADLINE, not averaged away. You are not a
gavel — the human resolves genuine value conflicts.
Consulted: …, plus excluded conditional
lenses (with reason), UNAVAILABLE lenses (with reason), and any ERRORED lenses.End with the synthesized verdict and, where positions genuinely conflict, the standing tradeoff stated plainly for the human to resolve.
/councilSame six lenses, same orthogonality, same trust guardrails — only the target differs.
/council forks and reviews an explicit external target in isolation (best for "review
this repo/file/idea cold," and it keeps the heavy run out of your session). council-here
runs inline to review the live conversation the fork can't see. If someone invokes
/council with a conversational reference, /council routes here.
development
Convene the persona panel (six orthogonal review lenses) on a target — cold independent fan-out, debate-to-consensus, synthesized verdict with recorded dissent and a roster manifest.
development
Hard-won patterns for probing, building, troubleshooting, and iterating against Microsoft Graph API endpoints -- especially from a browser SPA using delegated MSAL.js auth calling Graph directly with no backend (lessons generalize to any Graph integration). Covers the throwaway-probe-file methodology for de-risking before building, OData/query quirks, permission and admin-consent sequencing, recordings/transcripts access patterns (SharePoint REST, not Graph), CSP requirements for a pure-browser SPA, retry/pagination/backoff patterns, and the MSAL/EasyAuth auth-redirect-loop debugging saga. Use when integrating with Microsoft Graph, Teams APIs, MSAL.js, or EasyAuth; when hitting an unexpected Graph error (400/403/429), a silent missing-scope failure, an auth redirect loop, or a CSP violation that only appears in production; or when deciding how to validate a new Graph capability before committing it to a codebase.
tools
Use when building an Amplifier-powered workflow or automation tool and deciding how to expose it — as standalone .dot attractor pipelines (incl. inside the Resolve dot-graph resolver), an importable Python lib, agent-callable tool modules, or a CLI. Covers the four leverage levels, the DRY rule that keeps logic in ONE home, the judgment for which levels a real consumer actually needs (and when adding a level is just ceremony), and the maximally-DRY attractor-only specialization where the .dot pipeline is the sole logic home.
development
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," and between "it works" and "they can live with it." Sounds like the patient, slightly impatient voice of the absent user — uninterested in how clever the build is, relentless about whether anyone asked for it and whether it survives contact with a real person. Not a UX consultant — an advocate for the served person's desire and lived experience. A lens for any checkpoint — brainstorm, design, plan, implement, debug, or review — not just design. Use when: a feature is being built because it's buildable rather than wanted, the happy path is celebrated while the recovery path is missing, or nobody can name the person this serves — any time the worry is "does the person we serve actually want this, and can they live with it?"