emrecdr
UserZero-dependency multi-agent development workflow plugin for Claude Code
Categories
Indexed Skills (16)
architecture-health-scanner
Interpret and triage architecture scanner output — cluster findings by module and root cause, classify true positives vs false positives vs acceptable design, produce a prioritized remediation plan (Fix Now / Fix Soon / Document / Ignore). Use after the scanner runs when there are findings to analyze. Trigger on 'scanner results/findings/output', 'triage findings', 'coupling violations', 'cross-service imports', 'architectural violations', 'tech debt triage', 'architecture health scan', 'structural drift', 'remediation plan from scan', or when a refactor touched 3+ files/modules and you want to check for new violations. Do NOT use for single-file bug fixes, code review, library docs, linter config, project health checks (hooks/state/config), or writing new endpoints.
council
Pressure-tests high-stakes engineering decisions through 5 advisors with distinct thinking styles — independent analysis, anonymous peer review, chairman synthesis. Use when the user says "council this", "run the council", "pressure-test", "stress-test", "red team this", or "devil's advocate" on a real engineering trade-off. Distinct from strategic-analysis — adds adversarial peer review for decisions where the user suspects their first instinct is biased.
api-docs-fetcher
Fetches current third-party library documentation before code that uses it, since training data is stale. Use when the user asks "how do I use X", "current API for Y", "fetch docs for Z", "pull latest docs", or mentions a third-party library (axios, vue-router, pinia, prisma, stripe, fastapi, etc.). Distinct from internal code lookups (use Read/Grep), code review, and APIs already documented in CLAUDE.md.
code-review-guide
Review code for quality, security, performance, and architecture compliance with a 100-point scoring framework and verdicts (APPROVED/APPROVED_WITH_NOTES/NEEDS_WORK). Trigger on "review this code/my changes", "check for issues", "score the code", "is this ready to ship", "PR review", "pre-merge review", "second pair of eyes", "honest score and verdict", "before I open the PR", "check for N+1 queries", "missing error handling", "input validation", "code smells", "review every file they touched". EVALUATES code quality with structured findings + scoring — not for verifying stubs/wiring (use verification-patterns), not for searching existing code (use codebase-scan), not for assessing task complexity (use complexity-assessment).
codebase-scan
Scans the codebase for existing implementations, reusable utilities, and established patterns before writing new code. Use when the user says "check if X exists", "look for existing code", "before I build/add Y", "find what we have for Z", or "investigate how X works". Distinct from code-review-guide (reviews quality), verification-patterns (checks finished work), and complexity-assessment (sizes tasks).
complexity-assessment
Sizes a task before work starts — scores 5 dimensions (scope, integration, infrastructure, dependencies, risk) and selects the tier (SIMPLE / STANDARD / COMPLEX) that matches workflow depth. Use when the user says "how complex is this", "what tier", "SIMPLE or COMPLEX", "do we need a plan for this", or "what workflow should we use". Distinct from strategic-analysis (picks between approaches) and codebase-scan (finds existing code).
dispatch-helpers
Use whenever the orchestrator is about to issue a raw Agent() / Task() dispatch to a devt:* subagent (single OR parallel) instead of routing through /devt:review or /devt:workflow. Surfaces two CLIs that build the canonical envelope so context blocks (scope_trust, scope_hint, memory_signal, governing_rules) are never silently dropped — `dispatch run agent --task=...` for one-off single dispatches, `dispatch render-filled agent:auto` for advanced cases (lane fan-out, pre-computation, custom edits). Trigger phrases include single dispatches like "dispatch devt:code-reviewer to review X", "run devt:programmer for Y"; fan-out like "fan out review across files", "parallel reviewer across communities"; recovery like "re-dispatch programmer with continuation".
graphify-helpers
Use whenever a developer skill needs to search the codebase for symbols, callers, dependents, or paths between symbols. This is the canonical implementation of the Graphify-first protocol — Graphify queries first, grep fallback when any of four trigger conditions hits (empty result, error, not setup, under min_results_threshold). All other dev skills (codebase-scan, code-review-guide, lesson-extraction, tdd-patterns, verification-patterns, complexity-assessment, strategic-analysis, architecture-health-scanner, council, autoskill) consume this skill rather than calling Graphify directly. Skill auto-degrades to grep-only mode when graphify.enabled=false in .devt/config.json — system stays fully functional without Graphify, just less token-efficient.
lesson-extraction
Captures lessons from completed work into structured drafts in .devt/state/lessons.yaml — what worked, what failed, non-obvious discoveries. Curator gate-promotes drafts into .devt/memory/lessons/LES-NNNN.md. Use when the user says "what did we learn", "capture this lesson", "remember this for next time", or wants a session retrospective. Distinct from memory query (search existing) and autoskill (improve plugin).
memory-curation
Promote any candidate into the unified memory layer at `.devt/memory/` — ephemeral DEC-xxx into permanent ADR-xxx, retro lesson drafts into LES-xxx, rejected ideas into REJ-xxx tombstones, or reviewing `_suggestions.md` proposals from the discovery engine. Trigger on 'promote this decision', 'capture as ADR/Concept/lesson', 'reject this idea, never suggest again', 'create tombstone', 'review memory suggestions', 'curator review', 'archive stale lesson', 'codify this rule', 'this should be permanent'. Single curation skill for ALL 5 doc types (decision, concept, flow, rejected, lesson). HARD INVARIANT — never writes a permanent `.devt/memory/**/*.md` file without explicit user approval via AskUserQuestion.
memory-pre-flight
Use BEFORE any code edit, plan, or architectural decision. Defines the Two-Tier Pre-Flight Protocol (Topic Pre-Flight at workflow start; File Pre-Flight at each Edit). Agents preload this skill when they may modify code or propose changes — it tells them how to read the .devt/state/preflight-brief.md, when to escalate to a 5-lane File Pre-Flight, and how to scratchpad-summarize their findings before touching files. The PreToolUse pre-flight-guard hook checks the scratchpad — missing summaries warn or block the edit.
scratchpad
Cross-agent within-workflow notes — one agent records a decision, observation, error, or blocker for a later agent in the same workflow. Use when the user says "note this for later", "record decision", "pass context to next agent", or "log this for the next step". Persists in .devt/state/scratchpad.md (ephemeral, resets per workflow). Distinct from lesson-extraction (permanent lessons) and memory query (search past sessions).
strategic-analysis
Use when the user must CHOOSE between two or more named approaches, technologies, or design decisions before committing. Compares options with explicit trade-off tables and a recommendation. Trigger on "X or Y", "should we use A or B", "compare approaches", "trade-offs", "pros and cons", "which is better", "what do you recommend", "I'm torn between", "the team is split on", "I need to decide between", "keep X or switch to Y", "evaluate options for", "monorepo vs separate repos", "REST vs GraphQL". DECIDES between named alternatives with trade-off analysis — not for sizing complexity (use complexity-assessment), not for code review (use code-review-guide), not for creating plans, not for searching existing code (use codebase-scan).
tdd-patterns
Enforces test-driven development — failing test BEFORE production code, then RED-GREEN-REFACTOR cycle with mandatory verification gates. Use when the user says "TDD this", "test first", "write the failing test before the code", "test-driven", or "red-green-refactor". Distinct from debugging existing failing tests, post-hoc coverage work, and running test suites — TDD is test-first, not test-after.
verification-patterns
Use to verify that finished implementation is REAL and CONNECTED — not stubs, placeholders, or dead code. 4-level verification: exists, substantive, wired, functional. Trigger on "is this actually working", "verify everything is connected", "detect stubs", "is it wired up", "are these real implementations or placeholders", "is the route registered", "is the function called from anywhere", "before we ship", "still stubbed", "half-done", "NotImplementedError hiding", "empty function bodies", "return null where real data expected". Checks if COMPLETED work is genuine and connected — not for scanning before building (use codebase-scan), not for scoring code quality (use code-review-guide), not for writing tests (just write them).
weekly-report
Generates a git-based team development report — commits, merged PRs, contributor activity, statistics over a time window. Use when the user asks "weekly report", "what did we ship", "sprint summary", "team contributions", or "show merged PRs this week". Distinct from session-report (per-session), Jira reports, postmortems, code review reports, and non-git data sources.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.