skill-portfolio-existence-review

Skill Portfolio Existence Review

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.

The one question this skill answers

"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:

1. Web-verified differentiation against the outside world. Every "this is unique" / "this is just X with a skin" claim is checked against the current feature set of real competitor tools, not asserted from memory. This is where most existence verdicts are won or lost.
2. A forced kill/consolidate verdict. The user is explicitly inviting "should this die?" — so the output is a verdict table, not a polite summary. Panels drift toward "everything's fine"; this skill fights that.

When to use vs. the sibling skills (read this — don't create overlap)

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.

The verdict vocabulary (use exactly these)

• KEEP — earns its existence as-is.
• CONSOLIDATE — should be merged into / absorbed by another artifact, or its publication surface collapsed (e.g. retire a duplicate marketplace, keep the repo).
• KILL — should not exist; a better tool or a one-liner makes it unnecessary.
• PIVOT — has a reason to exist but is aimed wrong; reframe/refocus/rename/re-scope.

Pair each verdict with a confidence (high/medium/low) and the single most important next action.

Workflow

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.

Phase 1 — Gather & ground (orchestrator, before any reviewer)

1. Enumerate the target artifacts. Get the list from the user or 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.
2. Reconcile PUBLISHED vs LOCAL state. The published default branch is ground truth, not your local checkout — a stale clone will make you miscount plugins or flag shipped code as missing. Pull the manifest from the remote (gh api repos/<owner>/<repo>/contents/...) and note any drift (local-behind, manifest text vs actual contents). See discipline D5.
3. Map overlap inside the portfolio honestly. When two artifacts look similar, read what each actually computes/outputs — a shared data source is not a shared output. Don't assert self-overlap you haven't verified.
4. Pre-ground the differentiating facts (do NOT skip — this is the load-bearing step). For each artifact, identify its competitive space and web-verify the incumbent/competitor tools that might make it redundant. Capture the real, current feature sets before reviewers opine, so the panel reasons from fact, not from a model's stale memory of a tool. See discipline D1.
5. Apply the public-vs-private reframe. Confirm whether each artifact is actually public, private, WIP, or audience-of-one. A private/personal tool is NOT judged like a public product competing for users — the bar changes from "does it beat the incumbent" to "is it worth my build time." See D3.
6. Weight asymmetrically. Spend the sharpest thinking on artifacts whose existence is still un-sunk (in-progress, "should I keep building this") and on the cleanest redundancies. Artifacts the user uses daily are settled by revealed preference — for those, review the coupling, not the existence. See D4.

Compile a fact-grounded brief and hand it to every reviewer.

Phase 2 — Existence-pinned panel (parallel)

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).

Phase 3 — Debate & groupthink check

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.

Phase 4 — Completeness audit + competitive fact-check (parallel)

• Completeness auditor: what existence-relevant angle did the panel miss? (discoverability, the public-vs-private frame, whether a standalone artifact should fold into an existing one, etc.)
• Fact-checker (web-enabled): independently verify the discriminating external claims the verdicts rest on. Reverse any claim asserted from memory that the evidence contradicts. This is where "it's a skin on a solved problem" is confirmed or refuted with sources.

Phase 5 — Supreme judge

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.

Phase 6 — Output

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.

Core disciplines (the non-negotiables)

These are what separate a real existence verdict from a vibe. Full detail + worked examples in references/method.md.

• D1 — Web-verify differentiation; never assert a competitor's features from memory. External tools change weekly. A "this is unique" or "this is redundant with X" verdict that rests on un-verified memory is worthless — it's the exact failure this skill exists to prevent.
• D2 — Pin to existence, not quality. The moment a reviewer grades README polish or code structure, redirect. Quality is skill-portfolio-audit's job.
• D3 — Public vs private reframe. Judge a private/personal/WIP tool by "worth my build time," not "beats the incumbent." Confirm the artifact's actual audience before ruling.
• D4 — Asymmetric weighting + revealed preference. Un-sunk/in-progress decisions get the deepest scrutiny; daily-used artifacts are existence-settled — review their coupling instead.
• D5 — Published state is ground truth, not your local checkout. Reconcile remote manifest vs local before any "contains N / is missing X" finding.
• D6 — "Demote or delete," not just delete. A commodity feature that re-skins an incumbent doesn't have to be deleted — often the right call is "keep it but stop leading with it / stop investing in it." Aesthetic is delight, not a moat: distinctive ≠ defensible.
• D7 — A shared base model means correlated blind spots. State this limitation in the report; the completeness audit + fact-check exist to counter it.

Output: report structure (summary — full template in references/method.md)

# 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)

Recommended Fix per verdict (v1.1)

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:

• steps — the concrete, ordered actions (not "consolidate it" but "1. confirm single-plugin install resolves; 2. gh repo edit … / delete the duplicate marketplace; 3. update the citation in <file:line>").
• executor — who runs it. This skill is recommendation-only; name the tool/skill/manual path that actually performs the fix (skill-portfolio-audit for quality edits, skill-sync for repo↔local drift, git/gh for repo ops, manual for a marketplace retire).
• blast_radius — what else it touches and what could break (cross-repo citations, install paths, dependents, open PRs). This is where a careless CONSOLIDATE/KILL bites.
• effort — S / M / L, so the user can sequence.
• verification — the single check that proves the fix landed (e.g., "marketplace install still resolves", "the cited URL still 200s", "CI green"). Mirrors the disciplines: don't claim done unverified.

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).