check-my-stack

name

check-my-stack

description

Evaluate whether a popular or hyped agent/dev tool is worth adopting or borrowing from, measured against the user's OWN existing stack — never in the abstract. Enforces inventory-first discipline — enumerate what the user already has and at what maturity BEFORE listing the tool's features, then divide each borrow candidate by existing maturity (most collapse toward zero when the user's personal infrastructure is already a superset). Use when the user asks for competitive or 借鑑 analysis of a specific named tool against their workflow/stack — e.g. "X 對我現有流程的競合", "評估 X 值不值得借鑑", "X vs 我的 stack", "深度評估 X 對我現狀", "is X worth adopting given what I already have", "should I learn from X". Also invokable manually via /check-my-stack. Do NOT use for plain factual research of a tool with no "versus my stack" framing — use research-before-answer for that.

Competitive Stack Analysis

Evaluate a hyped tool's real value to THIS user by dividing each capability by the maturity of what the user already has. The headline finding is usually "the user's existing infrastructure is already a superset" — surface that, do not bury it under a feature tour.

Governing rule (order is mandatory)

The analysis order is enumerate the user's existing stack maturity FIRST → then map the tool point-by-point onto it. Never "list the tool's highlights first, then look for where the user could apply them." Every borrow candidate's real value = capability ÷ maturity of the user's existing equivalent. Most popular plan/memory/session/hook/codebase tools converge to "competitor-landscape observation, not a stack-change input" because general tools solve the mass-market pain of not having disciplined personal infrastructure — which a power user already has.

This skill is rigid. The Step 1 gate exists specifically to prevent the failure mode of reading the tool's README and getting anchored on its highlights.

Workflow

Step 1 — Inventory the existing stack (HARD GATE, do this first)

Before reading the tool's README / SKILL.md / feature list, dispatch an Explore agent to enumerate what the user already has in the tool's domain and how mature each piece is. Do not inline this; the fan-out spans many files.

Inventory targets (adapt to the tool's domain):

• settings.json / settings.local.json hooks and ~/.claude/hooks/
• ~/.claude/skills/ (and its INVENTORY.md if present) and ~/.claude/commands/
• Any automation pipeline (launchd / cron / CI jobs, local-analysis-style routines)
• The memory + wiki system (~/.claude/projects/*/memory/, ~/.claude/wiki/)
• Installed plugins / agent suites (e.g. superpowers) and project CLAUDE.md / AGENTS.md
• Tools the user tried and removed in this domain, with the documented reason — these are the strongest signal of what does not fit

For each existing capability the Explore agent must return: capability name, the concrete mechanism (name the skill/agent/job/memory file/wiki entity precisely), maturity (mature / in-trial / rejected-and-removed / aspirational), and current status. Demand a one-paragraph overall maturity summary and an explicit list of removed tools + reasons.

Step 2 — Extract the tool's REAL value props and health

Use research-before-answer discipline (personal wiki + memory recall in parallel with external gh / docs / web). Separate substance from marketing — star count, i18n, badges, and sponsor funnels are not capabilities. Capture: actual mechanism, distribution model, license, activity/staleness, maintainer concentration.

Recall personal precedent for calibration: grep the user's memory store for prior competitive-analysis collapse cases (previously analyzed hyped tools and how they resolved). Cite only precedents actually returned by that grep. If the grep finds none (or cannot run), state "no prior precedent retrieved" — never invent a precedent or recall one from general knowledge to fill the calibration slot. If a slimmed governing feedback memory exists, treat it as the pointer to this skill plus the personal precedent log.

Step 3 — Point-by-point ÷ maturity mapping

For each tool capability, ask "does the user already have an equivalent, and at what maturity?" — map before judging. Each row's conclusion is the quotient (capability ÷ existing maturity), never a naked "the tool has X so we could learn X." Most rows resolve to ≈0 (already a superset), and some resolve to <0 (the tool re-litigates ground the user already settled and rejected — flag these explicitly).

Step 4 — Gap check

Identify the user's one genuine gap in this domain (Step 1 surfaces it). Ask plainly: does the tool actually solve THAT gap, or only pile onto already-covered surface area? A tool that does not close the real gap cannot be justified as "fills a gap."

Step 5 — Residual after dividing by maturity

List only the non-zero residuals. Where the residual is an architecture or presentation idea rather than the tool itself, frame it as "steal the architecture, do not adopt the tool" — an independent piece of work, not an introduction of the tool. Be honest that most residuals are thin.

Step 6 — Verdict (convergence judgment)

State where the tool converges for THIS user: stack-change candidate, thin-residual-only, or competitor-landscape observation. Name the structural root cause (mature personal infrastructure as superset) and cite the sibling precedents from Step 2 so the verdict is calibrated, not asserted.

Output contract

Produce exactly the four-block structure. The detailed skeleton, table column contracts, and table-width rules are in references/output-template.md — read it before writing the report.

Division of labor with sibling decision lenses

This skill owns competitive/borrow ordering and value discounting. It is complementary to, not a replacement for, two other decision lenses the user maintains:

• "Install or not" (Path A / A' / B — prompt-injection vs teach-the-agent) — a separate install-decision lens
• "Agent-in-loop vs background scraper applicability" — a separate suitability lens

If those personal feedback memories exist, recall them by grepping the memory store; reference them, do not duplicate their logic here.

Anti-patterns (reject these)

• ❌ Reading the tool README and listing highlights first, then back-filling where the user could apply them
• ❌ A borrow list of naked capabilities without dividing by existing maturity
• ❌ Assigning priority labels before the Step 1 Explore inventory has run
• ❌ Treating star count / fork count / i18n / sponsor badges as evidence of capability
• ❌ Concluding "fills a gap" without confirming it closes the user's one real gap from Step 4
• ❌ Citing a sibling or precedent case that was not actually retrieved in Step 2 (confabulated calibration to fill the template slot)