Help us improve
Share bugs, ideas, or general feedback.
From skill-portfolio-existence-review
Run an existence/strategy audit on a portfolio of the user's PUBLISHED Claude Code skills, plugin bundles, or adjacent repos (including non-skill tools like dashboards/CLIs) — answering the one question the other portfolio skills never ask: *should each of these exist at all?* Produces a per-artifact KEEP / CONSOLIDATE / KILL / PIVOT verdict backed by an existence-pinned adversarial panel, WEB-VERIFIED differentiation against competitor/external tools ("is this a skin on a solved problem?"), and redundancy / maintenance-cost / coherence analysis. USE THIS WHENEVER the user asks "do my published skills/repos make sense to exist", "should I keep / kill / merge this skill", "is my tool redundant with X" or "is it just a reskin of an existing tool", "audit my skill portfolio strategically", "which of these repos earn their keep", "should I keep building this", "is there real differentiation here", "are any of my skills pointless", or wants a kill/consolidate decision across several published artifacts — even if they never say the word "existence". Especially reach for it when the user is deciding whether to START or KEEP BUILDING something, or suspects overlap between their own repos or with the wider ecosystem. Do NOT use for polishing READMEs/badges/versions or fixing factual errors (use skill-portfolio-audit), deciding which repo a skill belongs in (skill-portfolio-repo-placement-scan), finding unused/dormant skills (ecosystem-audit), scoring one skill's structural quality (schliff), syncing installed skills with their repos (skill-sync), or building/publishing a brand-new skill (skill-creator).
npx claudepluginhub wan-huiyan/skill-portfolio-existence-review --plugin skill-portfolio-existence-reviewHow this skill is triggered — by the user, by Claude, or both
Slash command
/skill-portfolio-existence-review:skill-portfolio-existence-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Built on [agent-review-panel](https://github.com/wan-huiyan/agent-review-panel).** This skill is a
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
Built on agent-review-panel. This skill is a specialization of that engine: it reuses the adversarial panel architecture (independent review → debate → completeness audit → verification → supreme judge), the persona + agreement-intensity + reasoning-strategy system, and the sycophancy/groupthink checks — and it adapts agent-review-panel's Live-State Claim Discipline (declarative vs. documentation; consensus-doesn't-compound; pre-promotion falsification) into discipline D1, web-verified differentiation. The existence- specific contributions here are the KEEP/CONSOLIDATE/KILL/PIVOT verdict vocabulary, the differentiation-grounding pre-step, and the five existence personas.
"Should each of these artifacts exist at all?" — a strategy verdict, not a quality verdict. A flawlessly-built skill that shouldn't exist still shouldn't exist. This skill judges artifacts on redundancy, differentiation/moat, maintenance cost for a solo maintainer, coherence of grouping, and "does it earn its keep" — and renders a decisive KEEP / CONSOLIDATE / KILL / PIVOT verdict per artifact, plus a portfolio-level consolidation plan.
The two things that make this review sharp — and that no sibling skill does — are:
| If the question is… | Use |
|---|---|
| Should this exist at all? Is it redundant / a reskin / worth my time? | this skill |
| Is each skill well-built? (READMEs, badges, factual errors, versions) — and fix them | skill-portfolio-audit |
| Which repo should a skill live in? (ADD/UPDATE/CROSS-LINK placement) | skill-portfolio-repo-placement-scan |
| Which skills are unused / dormant? (activity, HOT vs DORMANT) | ecosystem-audit |
| How structurally good is one skill? | schliff |
| Build or publish a new skill | skill-creator |
If the user's ask blends axes ("audit my portfolio"), name the axes and confirm which one they want before launching — existence review is expensive and answers a specific question.
Pair each verdict with a confidence (high/medium/low) and the single most important next action.
This is a multi-agent adversarial panel. The fastest path is the bundled Workflow template
scripts/existence_review_workflow.js — run it with the Workflow tool, passing
args = { contextBrief, artifacts } (the contextBrief is the Phase-1 grounded brief; it is
load-bearing — build it first). The template already encodes the five personas, the debate +
groupthink check, the web fact-check, and the judge with the verdict schema. Alternatively, delegate
the panel mechanics to agent-review-panel with the existence personas, or hand-orchestrate via the
Agent tool. Either way, the existence-specific scaffolding in references/method.md (personas, verdict
schema, disciplines) is what makes it this skill rather than a generic review. Read
references/method.md before launching; the script is the operational form of it.
gh repo list. For each, find the
local clone (or gh repo clone read-only) and read the high-signal files: README, marketplace.json,
plugin.json, SKILL.md frontmatter, package.json. Classify each: skill / plugin-bundle /
non-skill app / docs.gh api repos/<owner>/<repo>/contents/...) and note any drift
(local-behind, manifest text vs actual contents). See discipline D5.Compile a fact-grounded brief and hand it to every reviewer.
Launch the five existence personas (full prompts + reasoning strategies in references/method.md):
Product Strategist · Portfolio/Architecture Critic · Sustainability/Maintenance Risk Assessor ·
Devil's-Advocate (explicit KILL/CONSOLIDATE mandate) · Competitive Analyst (web-verifies
differentiation). Each returns a per-artifact verdict + rationale pinned to existence, not
quality + the strongest argument against its own verdict (steelman). Force every external/competitor
claim to be tagged with its basis (web-verified / read-repo / UNVERIFIED-from-memory).
One cross-examination round: reviewers see each other's verdicts and must engage where they disagree. Scrutinize easy unanimous KEEPs — agreement reached by reflex is the panel's most dangerous failure mode. Flag any verdict reached off the same artifact lines without independent verification.
Synthesize into a forced per-artifact verdict table + consolidation plan + preserved dissent. Weight the fact-check over reviewer assertions wherever they conflict. Do not default to "all fine"; do not manufacture drama either — where daily use or verified differentiation justifies KEEP, say so.
Write existence_review_report.md (and optionally an HTML dashboard). Use the template in
references/method.md. Always include: the verdict table, the round-0 vote matrix, per-artifact
reasoning + key action, the consolidation plan, preserved dissent, and a "what the fact-check changed"
note. Preserve the full panel output to state/ for the audit trail.
These are what separate a real existence verdict from a vibe. Full detail + worked examples in
references/method.md.
skill-portfolio-audit's job.# Portfolio Existence Review — should these exist at all?
**Reviewed:** … | **Date:** … | **Panel:** N reviewers + auditor + fact-checker + judge
**Headline verdict + existence-coherence score (0–10)**
## Verdict table (artifact | verdict | confidence | one line)
## How the panel voted (round-0 matrix → judge)
## Per-artifact verdicts (reasoning pinned to existence + key action + Recommended Fix)
## Portfolio consolidation plan (sequenced, with executor + verification per step)
## Why you can trust this (fact-check reversals + limitations)
A verdict the user can't act on is half a deliverable. Every non-KEEP verdict (and any KEEP that carries a hardening action) MUST ship a Recommended Fix block so the user knows exactly what to do, what it risks, and how to confirm it worked:
gh repo edit … / delete the duplicate marketplace; 3. update the citation in
<file:line>").skill-portfolio-audit for quality edits, skill-sync for repo↔local
drift, git/gh for repo ops, manual for a marketplace retire).Per-verdict fix patterns + worked examples are in references/method.md (§7). The Portfolio
Consolidation Plan orders these fixes across the whole portfolio (cheapest-safest first; anything that
could break a dependent gated behind its verification).
This skill is read-only / recommendation: it renders verdicts, a per-finding Recommended Fix, and a
sequenced plan — it does not implement the changes. Each fix names its executor so the handoff is
explicit (skill-portfolio-audit / skill-sync / git / manual).