| name | expert-opinion |
| version | 1.2.0 |
| description | Use when you want multi-expert parallel review of any artifact — code, documents, architecture plans, business proposals, agentic skills, or any URL. Proposes expert perspectives specific to the submitted artifact, gates on confirmation, runs each expert in a parallel subagent, then synthesizes findings into a prioritized audit document. For skill artifacts (directories containing SKILL.md), runs a dedicated skill audit pipeline with structural pre-validation, maturity scorecard, and phased remediation plan.
|
<essential_principles>
<parallel_architecture>
Expert research runs in parallel subagents — one subagent per confirmed role. Never
run expert reviews sequentially. Parallel execution is the core performance guarantee
of this skill. Do not collapse experts into a single pass.
</parallel_architecture>
<depth_bar>
Every finding must be grounded in evidence — a direct quote, a file:line reference,
or a concrete observation from the artifact. Surface-level observations without
evidence are not acceptable. The depth bar is: would a senior practitioner in this
domain consider this finding actionable and specific?
</depth_bar>
<evidence_enforcement>
The orchestrator MUST reject expert reports where findings lack verifiable artifact
references. A finding's evidence field must contain at least one of: an exact quote
from the artifact, a file:line reference, or a specific structural observation.
Paraphrased descriptions do not qualify. Reports with empty or paraphrase-only
evidence are recorded in missing_sections with the annotation "findings:evidence"
and the synthesis must flag them as lower-confidence in per_role_highlights.
</evidence_enforcement>
<security_first>
Input sanitization and output redaction run before any subagent dispatch.
Credential patterns in artifact content are replaced with [REDACTED: {type}]
placeholders before the content reaches subagent task strings. Text-type inputs
use only the first ~500 tokens for research query generation to prevent
pre-boundary injection. The skill/platform boundary is respected: this skill does
not reimplement RBAC, telemetry, MCP hosting, or session persistence that GSD
provides at the platform level.
</security_first>
<confirmation_gate>
The user MUST confirm the expert role list before any research begins. This is not
optional. Present the proposal, collect confirmation via ask_user_questions, and
proceed only on "Confirm all". Do not skip the gate even if the roles seem obvious.
</confirmation_gate>
<no_web_search_in_intake>
Role identification is pure in-context LLM inference from the artifact content.
No web searches during intake. fetch_page is permitted only to read a submitted URL
(the artifact itself) — never for supplementary research or role selection.
</no_web_search_in_intake>
<skill_audit_specialization>
When the artifact is a skill directory (contains SKILL.md), route to
workflows/audit-skill.md — NOT to workflows/intake.md. The skill audit pipeline
is decomposed into three phase files: audit-intake.md (S01), audit-research.md (S02),
and audit-synthesis.md (S03), with audit-skill.md serving as the router.
It has its own role taxonomy (references/skill-audit-roles.md), structural pre-validation,
maturity scorecard, and phased remediation plan that general intake cannot provide.
Role selection for skill audits uses the Role Selection Heuristics table in
references/skill-audit-roles.md, not general domain inference.
</skill_audit_specialization>
<synthesis_is_not_concatenation>
The synthesis phase MUST perform a full pre-synthesis analysis pass (convergence scan,
contradiction scan, severity aggregation, maturity scoring, open questions merge)
before filling any template section. Filling template sections while simultaneously
scanning produces incoherent output — the convergence scan changes what goes in cross-cutting
findings. Complete the analysis pass first; hold
all results in working state; then do a single-pass template fill.
</synthesis_is_not_concatenation>
<platform_boundary>
This skill operates within GSD/pi, which provides session management, subagent dispatch
(with timeout/retry), state persistence, memory primitives (capture_thought/memory_query),
MCP tool integration (mcp_call/mcp_servers/mcp_discover), and telemetry. Expert roles
and synthesis must distinguish between skill-level gaps (the skill's own code/docs) and
platform-level capabilities (provided by GSD). Enterprise readiness assessments that
penalize the skill for missing platform features must include a platform-adjustment note.
Audit templates and scorecards must include a "Platform Dependencies" dimension where
appropriate.
</platform_boundary>
<methodological_disclosure>
When the skill is run in self-audit mode (auditing itself), the synthesis document
MUST include a disclosure note: "This audit was produced by the skill running in
self-audit mode — the same patterns being evaluated were used to produce the evaluation."
This transparency strengthens credibility and acknowledges the epistemic loop.
</methodological_disclosure>
</essential_principles>
What would you like expert review of?
For general artifacts (code, documents, architecture, proposals, URLs):
Provide a file path, directory path, URL, or paste content directly.
For skill audits (SKILL.md or skill directory):
Provide the skill directory path (e.g. ./my-skill/ or ~/.claude/skills/my-skill/)
or the skill name (e.g. expert-opinion).
The skill audit pipeline runs structural pre-validation, a specialized expert panel
drawn from prompt engineering and agentic workflow domains, produces a maturity scorecard
(1–5 across 5 dimensions), and delivers a phased remediation plan.
<routing_decision>
When the user provides input, determine the route BEFORE loading any workflow or
required-reading files. Apply these steps in order:
Step 0 — SKILL.md pre-check (for potential skill-audit routes only):
If the input looks like a directory path (ends with /) OR user explicitly says
"audit this skill" / "review this skill" / "check this skill":
Run: bash find {input_path} -maxdepth 1 -name "SKILL.md" | head -1
- If SKILL.md found → continue to Step 1.
- If SKILL.md NOT found → route to intake (Step 2) immediately.
If the input is a bare word (no path separators, no file extension):
Attempt skill-name resolution BEFORE running find. Check in order:
1. ./.agents/skills/{input}/SKILL.md
2. ~/.claude/skills/{input}/SKILL.md
3. ~/.agents/skills/{input}/SKILL.md
- If SKILL.md found at any location → use that path and continue to Step 1.
- If SKILL.md NOT found at any location → route to intake (Step 2).
Do NOT load any audit-skill.md required-reading files.
Step 1 — Skill audit route:
If, after Step 0, the input:
- Refers to a directory containing SKILL.md, or
- Is a bare word matching a known skill name (resolved via ~/.claude/skills/{name}/, ~/.agents/skills/{name}/, etc.), or
- User says "audit this skill", "review this skill", "check this skill"
→ Route: skill_audit → workflows/audit-skill.md
Step 2 — General artifact route (everything else):
→ Route: intake → workflows/intake.md
Ambiguity: If a path could be a skill directory or a general codebase:
Ask: "Is this a skill directory or a general codebase?"
Then route based on the answer.
</routing_decision>
