Merge pull request #82 from 5uck1ess/skill-improvement

docs(skills): description-quality pass across 13 collision-prone skills

Author: 5uck1ess

skills/audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: audit
-description: Audit a project for health — use when asked to audit this project, check project health, run a project audit, look for issues, or assess code/dep/lint/security state. Triggers the deterministic audit workflow (detect ecosystem → deps → lint → security → report).
+description: External-scanner-driven project health check — runs the actual ecosystem tools (npm audit, eslint, govulncheck, semgrep, pip-audit, etc.) to surface what the standard scanners flag: outdated or vulnerable dependencies, lint violations, known CVEs, and config drift. Use when the user asks to "audit this project", "check project health", "run a project audit", "check deps/lint/security state", "is this repo up to date", or wants a stateless rundown of what the standard tools report. Worth using when kicking off work on an unfamiliar project, before a release, after a dependency bump, or when triaging a long-neglected repo. Do NOT use for introspective "what's wrong with this repo and what should I fix first" questions (use self-audit — that ranks issues by evidence), security-focused review of a specific code change (use tri-security), or debugging specific failures (use tri-debug or bugfix). This skill reports what scanners say, not what a human should prioritize.
 ---
 
 # Project Audit

skills/bugfix/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bugfix
-description: Fix a bug end-to-end — use when asked to fix a bug, debug an issue, resolve an error, patch a defect, or "this is broken, fix it". Triggers the deterministic bugfix workflow (triage → reproduce → diagnose → fix → regression test → run tests).
+description: Deterministic full-lifecycle bugfix workflow — triage → reproduce → diagnose → fix → regression-test → run-tests, with a reproduction gate that must fail before the fix and pass after. Use when the user asks to "fix a bug", "debug this issue", "resolve this error", "patch a defect", "this is broken, fix it", or reports a specific failure they want systematically fixed with a regression test added. Worth the ceremony when: the bug is non-trivial, reproduction isn't obvious, a regression test would prevent recurrence, or the fix needs the full test suite to verify nothing else broke. Do NOT use for one-line typos, missing imports, or obvious null-checks (just fix them directly — the workflow has a fast path but the lookup is still overhead). Do NOT use for hard bugs where the user wants divergent hypotheses before committing to one (use tri-debug). Do NOT use for "something's slow" performance work (use self-perf) or for fixing failing tests specifically (use self-test).
 ---
 
 # Bug Fix

skills/deep-research/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: deep-research
-description: Deep research with Analysis of Competing Hypotheses — use when asked to do deep research, deeply investigate, validate claims, or when correctness is critical and the user wants rigorous analysis with disconfirmation testing.
+description: High-stakes research with Analysis of Competing Hypotheses, disconfirmation testing, evidence matrices, and sensitivity checks (~400k token budget) — use when the user needs to be SURE, not just well-informed. Trigger phrases include "deep research", "deeply investigate", "validate that X", "prove/disprove", "we're making a big decision", "correctness is critical", "I need to trust this answer", or "actively try to disprove this". Worth the extra cost when: the wrong answer has real consequences (architecture commitment, vendor choice, security claim, compliance question, public-facing claim), the user has already seen shallow answers and doesn't trust them, they explicitly ask for rigor or disconfirmation, or they're defending a position to stakeholders. Do NOT use for exploratory "what's out there" questions (use research), routine library comparisons where a single good answer suffices (use research), or quick factual lookups. This is the bias-catching, evidence-calibrating tier — overkill for casual exploration but essential when you can't afford to be wrong.
 ---
 
 # Deep Research

skills/feature/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: feature
-description: Build a new feature end-to-end — use when asked to add a feature, build X, implement Y, ship a new capability, or "new feature ...". NOT for /feature-dev:feature-dev which is a separate plugin. Triggers the deterministic feature workflow (triage → brainstorm → plan → implement → test → lint → review).
+description: Deterministic full-lifecycle feature workflow (engine-driven, gated, looped) — triage → brainstorm → plan → implement → gen-tests → run-tests → lint → review → final-report. Use when the user asks to "add a feature", "build X", "implement Y", "ship a new capability", "new feature: ...", or wants an end-to-end pass from rough spec to PR-ready implementation with lint and test gates enforced. Worth the ceremony when: the feature is non-trivial (touches multiple files, needs tests, needs a plan), the user wants a structured walk from idea to working code, or wants gated iteration instead of free-form building. Do NOT use for the separate `/feature-dev:feature-dev` plugin — that is an agent-guided collaborative workflow; if the user explicitly invokes that command, respect it. Do NOT use for one-file quick additions (just write the code), bug fixes (use bugfix), or pure refactoring of existing behavior (use refactor). Includes a fast path for trivial changes so the workflow self-adjusts to scale.
 ---
 
 # Feature

skills/mega-pr/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mega-pr
-description: Run tri-review and pr-review-toolkit review-pr in parallel for maximum coverage — use when asked for mega PR review, mega-pr, mega review, full PR review, or both review tools at once.
+description: Fan-out PR review that runs BOTH `/devkit:tri-review` AND `/pr-review-toolkit:review-pr` in parallel for maximum coverage, then presents unified results — this skill does not compete with its sub-skills, it delegates to both simultaneously. Use when the user asks for "mega PR review", "mega-pr", "mega review", "full PR review with everything", "both review tools", "maximum coverage review", or explicitly wants every available reviewer looking at a change at once (Claude + Codex + Gemini model diversity PLUS specialized aspect reviewers like silent-failure-hunter, type-design-analyzer, test-analyzer, code-reviewer). Worth the extra cost when: the PR is high-stakes and the user wants every angle covered, or before merging a critical or hard-to-revert change. Do NOT use when the user only wants one review system (use tri-review or pr-review-toolkit:review-pr directly). Do NOT use for routine code review where a single reviewer suffices. This is deliberate overkill for when you want absolutely everything.
 ---
 
 # Mega PR Review

skills/pr-ready/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pr-ready
-description: Full PR pipeline — use when asked to submit a PR, create a pull request, ship this, open a PR, or "make this PR-ready". Runs lint, tests, security scan, generates changelog, creates the PR, and monitors CI + reviewer comments until merge-ready.
+description: Full end-to-end PR pipeline — validate → necessity-check → lint (loop) → test (loop) → security scan → doc-check → changelog → create-pr → monitor reviews (loop). Takes a branch from "code done" to "merged" with every gate enforced. Use when the user asks to "submit a PR", "open a pull request", "ship this", "make this PR-ready", "finalize this branch", or wants the full pipeline run end-to-end with CI monitoring and reviewer-comment handling automated. Worth the ceremony when: lint and test gates must pass before the PR opens, docs need syncing alongside code (README, ROADMAP, SKILL.md, workflows), security scan is required, or the user wants reviewer comments automatically classified and responded to. Do NOT use for a quick commit+push+PR without gates — use `/commit-commands:commit-push-pr` for that lighter path. Do NOT use when already mid-PR and just handling existing review comments in isolation. Do NOT use on the main branch or with uncommitted changes — the validate step will block you. This is devkit's heaviest PR workflow; pick it when you want everything run.
 ---
 
 # PR Ready

skills/refactor/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: refactor
-description: Refactor code safely — use when asked to refactor, restructure, clean up, reorganize, extract, rename, or modernize a piece of code. Triggers the deterministic refactor workflow (analyze → plan → restructure → verify nothing broke).
+description: Deterministic refactor workflow with tests as the safety net — analyze → plan → refactor → run-tests → fix-tests → comparison. The workflow will not exit until tests pass, guaranteeing behavior preservation. Use when the user asks to "refactor", "restructure", "reorganize", "clean up", "extract", "rename across files", or "modernize" existing code that has test coverage. Worth the ceremony when: the refactor spans multiple files, behavior must be preserved exactly, test coverage exists to prove nothing broke, or the user explicitly wants a safety-netted transformation. Do NOT use for renaming a single variable or function in one file (just do it — the workflow overhead isn't worth it). Do NOT use for adding new behavior (use feature) or fixing broken behavior (use bugfix). Do NOT use when there are no tests — the safety net is the entire point; without tests, do the refactor manually with careful review. If the user wants refactoring advice or a discussion (not the transformation), answer directly instead of dispatching the workflow.
 ---
 
 # Refactor

skills/research/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: research
-description: Research workflow — use when asked to research a topic, investigate options, compare approaches, or find the best solution to a technical question. NOT for "deep research" or "validate" requests — those go to deep-research. For complex or high-stakes questions where correctness is critical, use deep-research instead.
+description: Fast, standard research workflow (clarify → decompose → parallel search → summarize → synthesize) for exploratory questions where the user wants a good answer quickly. Use when the user asks to research a topic, investigate options, compare libraries/tools/approaches, find the best solution to a technical question, scope out a space they don't know yet, or get a grounded starting point before deciding. Worth using when the user is gathering context or narrowing down options — not when they've already committed and need validation. Do NOT use for high-stakes decisions where a wrong answer is expensive (use deep-research), validating specific claims under scrutiny (use deep-research), or simple factual lookups that don't need web searches (answer directly). Default to this over deep-research unless the user explicitly signals stakes with phrases like "we're making a big bet", "need to be sure", "validate", "deeply investigate", or "correctness is critical".
 ---
 
 # Research

skills/self-audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: self-audit
-description: Self-audit the codebase — use when asked to self-audit, audit the codebase against its own metrics, run a karpathy-style audit, measure and rank issues by evidence, or "what's wrong with this repo". Triggers the deterministic self-audit workflow (detect → measure quality/security/git → analyze → synthesize).
+description: Evidence-ranked codebase self-assessment (karpathy-style) — measures quality, security, and git signals in parallel then produces a prioritized list of what's actually wrong here, ranked by how much evidence supports each finding, with an actionable improvement plan. Use when the user asks to "self-audit", "audit the codebase against its own metrics", "run a karpathy-style audit", "what's wrong with this repo and what should I fix first", "rank issues by evidence", or wants a synthesized improvement plan rather than a scanner dump. Worth using when the user wants judgment and prioritization (where should I invest effort?), not raw warnings; when they're choosing the next big refactor; or when they want the biggest issues surfaced first with evidence showing why. Do NOT use for a plain scanner rundown of deps/lint/CVEs (use audit — that just runs the tools), security review of a specific code change (use tri-security), or debugging a specific failure (use tri-debug or bugfix). This skill is about ranking and judgment, not tool execution.
 ---
 
 # Self-Audit

skills/tri-debug/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tri-debug
-description: Triple-agent debugging — use when asked for tri debug, triple debug, three-way debugging, multi-agent diagnosis, parallel debug, or consensus root-cause analysis. Three model tiers diagnose the bug independently and compare theories. Triggers the deterministic tri-debug workflow.
+description: Three independent root-cause analyses of a hard bug or failure — smart + general + fast model tiers diagnose in parallel, then theories are compared and reconciled. Use when the user asks for tri-debug, triple debug, three-way debugging, multi-model diagnosis, parallel debug, consensus root-cause analysis, or is stuck on a hard bug and wants divergent hypotheses. Worth the extra cost when: the bug is hard (heisenbug, intermittent, cross-system), logs are ambiguous, the obvious fixes have already failed, or the user explicitly wants three independent theories before committing to one. Do NOT use for code review (use tri-review), security audits (use tri-security), or comparing greenfield implementation approaches (use tri-dispatch). Do NOT use for simple "what does this error mean" or routine null-check / typo bugs — a single pass is faster.
 ---
 
 # Tri-Debug