メニュー
Multi-persona analysis. Use when the user wants a persona-driven deep dive, second opinion, adversarial pressure on a held position, side-by-side perspectives, or a synthesized panel take.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when the operator states a held technical belief they're about to act on — an assertion about reality already shaping a decision ("RAG is sufficient", "the latency issue is network-bound", "we don't need observability yet") — and wants adversarial pressure before building on top of it. Symptoms — operator phrases it in the indicative ("X is Y", "we don't need Z") not as a question; resources (a roadmap line, a sprint, headcount, a rewrite) are about to depend on the belief being true; operator uses words like "obviously", "clearly", "enough", "we don't need".
Use when operator has run episodes and feels persistent friction with how the harness thinks, or when pointing the harness at a new domain where the default agent prompts and phase order seem off. Use when the operator wants to tailor the harness shape (agent prompts, scout PHASES, skill wording) to how their main persona and upstream personas actually reason — without touching signal/episode infrastructure. Symptoms — the same kind of objection keeps appearing in review.md across unrelated increments; operator says "this agent asks for the wrong things"; harness was ported from another project and hasn't been adapted.
Use when goal.md exists but no active plan is set in config — a stated goal needs to be broken into connected increments before the scout can walk them. Also use when re-planning an existing goal (produces a new goal-plan-N, leaves goal.md and prior plans intact). Symptoms — scout.py prints `no-goal-plan`; operator has a goal but no increment list; operator wants to try a different breakdown of an existing goal.
Use when `goal.md` and `goal.harness.json` both exist and the operator is ready to walk increments. Explains the scout's 4-phase episodic loop, the four work agents, and — critically — when to use which panel intent for upstream review. Default review pattern is `review` (parallel_with_main, upstream personas). This skill also documents when to reach for `challenge` / `explore` / `ask` instead.
Use when the panel harness has no goal.md yet — operator needs to turn a vague sense of "I should work on something" into a specific goal tied to their actual context. The harness models any system against the operator's persona; the subject can be technical (a refactor, an architecture decision, a research question) or not. Symptoms — scout.py prints `no-goal-statement`; operator describes wanting to start but can't name the specific thing.
Use when the operator is making a decision about an artifact, feature, or change that will sit inside a system with people, time, or relationships — and they want to surface emergent / cross-cutting / second-order effects that neither upstream (author-side) nor downstream (consumer-side) reads would catch. Symptoms — operator says "what am I missing?" / "what might happen that we didn't plan for?" / "something feels off and I can't name it"; the decision has multi-month unfold potential; the artifact touches an ecosystem, a team, or user behaviors that might reshape around it. NOT for intrinsic-quality reviews, NOT for audience-reception reads, NOT for belief stress-tests.
| name | panel |
| command | panel |
| description | Multi-persona analysis. Use when the user wants a persona-driven deep dive, second opinion, adversarial pressure on a held position, side-by-side perspectives, or a synthesized panel take. |
| argument-hint | ["setup <context> | <question>"] |
Panel is not for ordinary fact lookup or quick answers the model can handle directly. Use it when the answer should be shaped by the user's own self-models, or when a multi-vantage read will expose useful tension.
Before choosing a mode or persona, spend 1-2 sentences modeling who the user is and why they are asking. The question alone rarely picks the right call; the workflow shape does.
The main persona is a model of the user, built from a long interview. Treat panel outputs as privileged context about the user, not as generic expert answers.
answer is the default. Most questions go here. Pick the responder by workflow
shape:
If two branches plausibly fit, ask the user and explain what each would give.
Use parallel_with_main when multiple inputs should be synthesized into one
integrated take. It fits first contact with a complex topic, strategy, design,
planning, or high-stakes critique. The participants list contains both the input
personas and the synthesizer; the synthesizer is normally main:<name> or an
assistant persona.
Use parallel only when the user explicitly wants unintegrated side-by-side
views.
Skip parallel_with_main for single-voice rendering tasks such as character
sheets, copy, persona portraits, or any artifact where one coherent voice matters
more than synthesis; use answer instead.
Long parallel and parallel_with_main calls can take 8-15 minutes. The client
prints polling stage events such as stage: answer: generating response; pass
those through as live progress. If an answer drifts into philosophy or ethics
unprompted, or feels off-topic, treat that as ambiguity drift: re-prompt with
more context instead of presenting it as a clean result.
There are two user-facing flows:
/panel setup <context> bootstraps the working directory./panel <question> sends the question to the panel after you classify it and
choose CLI arguments.For real questions, use one unified client call:
python3 .claude/skills/panel/panel_client.py call --mode <mode> --participants "<refs>" --category "<category>" "<question>"
The available modes are:
answer: one persona gives a direct answer.parallel: multiple personas answer independently.parallel_with_main: multiple personas contribute and a main or assistant
persona synthesizes.If .claude/panel_state.json is missing, do not force setup. For a simple
question, run a bare answer call without --team, --main, or
--participants; the client will perform lightweight discovery, choose the first
available main persona as the only participant, and write minimal no-project
state. This uses discover only and does not call the setup advisor LLM endpoint.
Full setup calls the setup advisor, calls discover, fetches persona short descriptions when available, and writes richer state containing:
team and main_persona.project when panel memory is enabled.discover, the raw discover payload plus persona shorts.teams, a normalized roster by team with persona refs, branches, IDs returned
by the API, and short descriptions where available.recommended_participants for answer, parallel, and
parallel_with_main.history and category_participants, updated by call --category.If PANEL_API_KEY is missing, ask the user to set it. Generate it at
<PANEL_BASE_URL>/profile -> API Access; the default base URL is
https://panel.humx.ai. Do not read, write, or create .env.
Setup may recommend a project so panel memory can accumulate. Ask the user for confirmation before creating it:
python3 .claude/skills/panel/panel_client.py setup --create-project "<context>"
If the user does not want memory:
python3 .claude/skills/panel/panel_client.py setup --no-project "<context>"
If state already has project, keep using it. When a project is present, pass
--memory basic on panel calls. If there is no project, do not pass --memory.
For any /panel <question> that is not setup:
python3 .claude/skills/panel/panel_client.py state show --json
If state is missing and the request is a simple answer, run without setup:
do not pass --memory, --project, --team, --main, or --participants.
The client will call discover, pick the first main persona, and save minimal
state. For parallel or parallel_with_main, ask whether to run full setup
first.
Decide whether Panel is useful. Skip it for fact lookup, single-line answers, or work the model can do directly without persona depth.
Classify the question into answer, parallel, or parallel_with_main using
the decision rules above.
Choose a short reusable category key. Prefer stable keys over one-off labels
so category_participants can learn across calls.
Choose participants:
category_participants[category] for a similar prior task.recommended_participants[mode].parallel or parallel_with_main, inspect teams[team].personas if you
need a more tailored mix.branch:name, for example main:alex,
upstream:systems_reviewer, lateral:outside_operator.answer, omit participants; the client will discover
the first available main persona and use main:<name>.call.Examples:
No-state simple answer:
python3 .claude/skills/panel/panel_client.py call --mode answer --category "quick-answer" "What is your read on this?"
python3 .claude/skills/panel/panel_client.py call --mode answer --participants "main:alex" --category "quick-judgment" "Is this API shape too complex?"
python3 .claude/skills/panel/panel_client.py call --mode parallel --participants "upstream:reviewer,lateral:operator,downstream:translator" --category "side-by-side-critique" "Give independent reads on this launch plan."
python3 .claude/skills/panel/panel_client.py call --mode parallel_with_main --participants "upstream:reviewer,lateral:operator,main:alex" --category "architecture-review" --memory basic "Stress-test this rewrite plan and synthesize the best path."
The client renders results in a human-readable form. Pass through the result directly or summarize according to the user's request.
Long parallel and parallel_with_main calls can take several minutes. Let the
client poll normally unless you explicitly need to submit and return with
--no-poll, then use:
python3 .claude/skills/panel/panel_client.py status --job-id <id>
| Flag | When to use |
|---|---|
--search | Only when the question needs current or external facts, or the user asks for search. |
--memory basic | Use when state has a project. Do not pass memory if there is no project. |
--no-poll | Automation/dev use only; normally let the client poll and pass stage updates through. |
call per user question..claude/panel_state.json; use setup, state show, and
call --category.HTTP 429 with a running job ID, poll that job with
status --job-id <id> before submitting another panel call.$ARGUMENTS