dotfiles

Use when auditing a TypeScript/JavaScript codebase for dead code and unused dependencies — unreferenced files, dead exports, orphaned modules, unused npm packages, phantom deps — and want a report separating safe removals from ones needing confirmation, then chunked cleanup. Keywords knip, depcheck, ts-prune, unused imports, unreachable code.

Shared investigative substrate for evidence-grounded, read-only analysis skills — provides capability-role source discovery, the evidence-vs-hypothesis standard, the parallel-subagent findings-digest schema, adversarial verification, the app-version/release dimension, local-markdown artifact conventions, and the optional ticketing flow. Invoked BY analytics-friction-analysis, error-triage, regression-analysis, and evidence-consolidation; NOT used directly and NOT a target for direct user requests.

Use when merging the findings of two or more evidence-analysis reports (analytics-friction-analysis, error-triage, regression-analysis) into one reconciled report — deduping overlapping findings, letting each domain's evidence raise or lower the other's confidence, and producing a single ranking plus a merged "considered & ruled out". Defaults to reading existing report artifacts (cheap); can optionally run the leaf skills fresh first. NOT for a single-domain analysis — invoke the relevant leaf directly.

Use when starting a new feature from a ticket or spec and need a technical design document before implementation. Outputs an authoritative design doc that locks in scope, alternatives considered, file layout, edge cases, and out-of-scope before any plan or code is written.

Use after a feature design doc is approved and an implementation plan is needed. Outputs a phased plan with explicit MANUAL REVIEW CHECKPOINT gates between phases (one commit per phase, not per task) and a paired risk-ordered QA checklist.

Use when reviewing a GitHub pull request or a diff with multiple specialized review agents and you want every finding verified against the actual code before it is reported. Triggers on "review this PR", "kick off a PR review", pre-merge review requests.

Use when investigating a metric-grounded regression — a measured worsening of latency, error rate, throughput, or similar tied to telemetry, a specific metric/dashboard, or an alert/incident. Fans out across the observability MCP servers the user has configured to produce evidence-ranked root-cause hypotheses. NOT for proactively mining product analytics funnels (use analytics-friction-analysis), NOT for digesting an error tracker (use error-triage), and NOT for speculative "feels slow" perf concerns during feature development — route those to systematic-debugging / investigate. To merge this report with another domain's, use evidence-consolidation.

Use when upgrading, updating, or bumping npm dependencies, especially major version upgrades spanning multiple packages or sessions. Also use when user asks to update outdated packages, resolve peer dependency conflicts, or plan a dependency migration.

Use when investigating bugs, test failures, or unexpected behavior — enforces disciplined scope control, root cause verification, and (for TypeScript) type-safe fixes

Use when generating release notes or changelogs from PR merges, production deployments, or when the user asks for a summary of changes between branches or releases

Use when auditing or remediating npm/pnpm security vulnerabilities, after CVE alerts, npm audit reports, GitHub security advisories, or Dependabot/Renovate security notifications. Applies minor and patch fixes automatically; pauses for user approval before any major upgrade.

Use when proactively mining product/session analytics (PostHog, Amplitude) to find where users get stuck — funnel drop-offs, friction points, and analytics events that may not be firing as expected — with no known metric regression to anchor on. Separates evidence-based findings from hypotheses, segments by app version, and produces a monitoring plan. NOT for a measured metric regression (use regression-analysis) and NOT for digesting error-tracker issues (use error-triage); to merge this report with another domain's, use evidence-consolidation.

Use when digesting or reviewing an error tracker (Sentry, PostHog error tracking) to raise signal-to-noise — classify and mitigate noise, and surface the biggest potential regressions substantiated against the codebase, then optionally file tickets with links to the related errors. NOT for proactively mining product analytics funnels (use analytics-friction-analysis) and NOT for a single measured metric regression (use regression-analysis); to merge this report with another domain's, use evidence-consolidation.

Use when cleaning up a feature branch at any stage of development — removes dev artifacts, checks scope compliance against a ticket or description, identifies test gaps, and auto-adds unit tests to existing suites. Usable standalone or as part of the pre-pr orchestrator.

Use before opening a pull request — orchestrates code-hygiene cleanup, verification (typecheck/lint/tests), and code review into a single combined report. Runs all steps without gating.

Use when starting a net-new feature from a ticket — orchestrates brainstorming, design-doc authoring, a hard sign-off gate, then implementation-plan and QA-checklist authoring. End-to-end ticket-to-plan flow with one hard stop between design and plan.

Use when reviewing Asana tasks for recent activity, checking notifications, or triaging work — surfaces tasks assigned to or followed by the user with drill-down, commenting, and status change capabilities

Use when investigating CI, EAS, Vercel, or local build failures and dependency-resolution errors — enforces requesting full logs upfront, listing prior failed attempts, and ranking hypotheses before any edits