Emre Camdere

Structural review specialist. Triggered when code needs architectural assessment before or after implementation. READ-ONLY — inspects but never modifies code. Examples: "review the module boundaries", "check for coupling issues in the new service", "assess the data flow between components".

Code review specialist. Triggered when code needs quality review before approval. READ-ONLY — inspects but never modifies code. Examples: "review the payment service changes", "check the new API endpoints for issues", "review this PR for quality".

Playbook quality maintenance specialist. Triggered when lessons need to be integrated into the learning playbook, or when the playbook needs pruning. Examples: "integrate new lessons into the playbook", "prune stale entries", "review playbook quality".

Systematic debugging specialist. Use when encountering bugs, test failures, or unexpected behavior. Follows 4-phase investigation protocol. Isolates in fresh context to preserve the workflow's context window.

Documentation specialist. Triggered when module documentation needs to be created or updated after code changes. Examples: "update the module docs after the refactor", "document the new payment service", "update docs for the API changes".

Implementation specialist. Triggered when the workflow requires writing new code, modifying existing code, or fixing issues. Examples: "implement the user service", "add validation to the payment endpoint", "fix the broken date parsing logic".

Technical investigation specialist. Use before planning or implementing unfamiliar features. Investigates codebase patterns, identifies standard approaches, documents pitfalls, and recommends an implementation strategy. READ-ONLY — never writes production code.

Lesson extraction specialist. Triggered after a workflow completes to capture what was learned. Examples: "extract lessons from this implementation", "run a retro on the workflow", "what should we remember from this task".

Testing specialist. Triggered when the workflow requires writing, updating, or validating tests. Examples: "write tests for the payment service", "add edge case coverage for date parsing", "verify the registration flow handles duplicate emails".

Use after code review passes to verify the implementation actually achieves the task goal. Goal-backward verification — starts from what was requested, traces to what was built. Catches: working code that solves the wrong problem, incomplete implementations, unwired features.

Architecture health scan — detect violations, coupling issues, and structural drift. Supports delta mode (new issues only), baseline management, and interactive triage.

Abort the currently active workflow and reset state

Discuss implementation choices and capture decisions before coding — identifies gray areas and prevents wrong assumptions

Systematic debugging with 4-phase investigation — root cause first, then fix. Isolates in fresh context to preserve your main session.

Route freeform text to the right devt command — describe what you want and it picks the command

Execute a trivial task inline — no subagents, no planning overhead. For tasks touching 3 or fewer files with no architectural impact.

Post-mortem investigation of failed or stuck workflows — analyzes artifacts, state, and git history to diagnose what went wrong

Diagnose devt plugin health — checks .devt/state/ integrity, .devt/rules/ completeness, config validation, and hook status. Use when workflows fail unexpectedly or after interrupted sessions.

Show all devt commands with use cases — basics to advanced

Quick implementation — skip docs and retro, go straight to code and tests

Interactive project setup wizard that configures devt for a new or existing project

Auto-detect where you are and run the next logical step — reads workflow state and acts

Zero-friction idea capture — quickly save a thought, then optionally promote it to a task later. Use when you have an idea mid-workflow that shouldn't derail current work.

Pause current workflow and create a structured handoff for session resumption — captures progress, decisions, and context notes

Create a detailed implementation plan before coding — analyzes the task, identifies files to change, breaks into steps, and validates the approach. Use before /devt:workflow for complex tasks.

Run quality gates — lint, typecheck, and tests

Research implementation approaches before planning — investigates codebase patterns, identifies pitfalls, recommends strategy. Use before /devt:plan for unfamiliar domains or complex tasks.

Extract lessons learned from the current session into persistent memory

Standalone code review — READ-ONLY analysis with findings and recommendations

Generate a session summary — work done, commits, decisions, outcomes

Create a pull request with auto-generated description from workflow artifacts — reads impl-summary, test-summary, and review verdict from .devt/state/

Create a detailed PRD through systematic interview and codebase analysis — generates structured specifications with decisions, API design, test scenarios, and task breakdown. Use when the user says 'specify', 'write a spec', 'create a PRD', 'requirements for', 'what should we build', 'define the feature', 'before we start building', or describes a feature idea that needs scoping before implementation.

Show current workflow status — what step completed, what's next, any blockers. Use when resuming work or checking progress.

Persistent context threads for cross-session work — create, list, or resume investigation threads that survive session boundaries. Use for multi-session debugging, research, or explorations.

Check for and install devt plugin updates from GitHub. Use --force to bypass cache.

Build, fix, or improve anything — auto-detects complexity and runs the right pipeline

Fetch current documentation for any external/third-party library before writing code that uses it. ALWAYS use this skill when about to call a library API, even if you think you know it — training data is stale. Trigger on any mention of a third-party library (axios, vue-router, pinia, dayjs, zod, prisma, tailwind, playwright, express, fastapi, stripe, luxon, etc.), questions like 'how do I use X', 'what's the API/syntax for Y', 'check the current docs for Z', 'fetch docs for library', 'what replaced deprecated method', 'did the config change in version N', or when implementing integrations, webhooks, SDK calls, or middleware from external packages. Also trigger when a user says 'can you pull the latest docs', 'check if the API changed', or references a specific library version. Do NOT use for internal project code, first-party modules, code review, architecture scanning, or APIs documented in CLAUDE.md.

Interpret and triage architecture scanner output — cluster findings by module and root cause, classify true positives vs false positives vs acceptable design, and produce a prioritized remediation plan (Fix Now / Fix Soon / Document / Ignore). Use after the scanner has been run when there are findings to analyze. Trigger on 'scanner results', 'scanner findings', 'scanner output', 'triage findings', 'classify findings', 'coupling violations', 'cross-service imports', 'duplicate model definitions', 'architectural violations', 'tech debt triage', 'false positives from scanner', 'prioritize scanner output', '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. Also trigger on 'present architecture health metrics' or grouping findings into priority buckets. Do NOT use for single-file bug fixes, code review, fetching library docs, ESLint/linter config, project health checks (hooks/state/config validation), or writing new endpoints.

Detect recurring correction patterns and propose concrete improvements to the devt plugin system — updating skills, agents, .devt/rules/, or workflows. Use when the user has corrected the same behavior multiple times and wants to codify it as a permanent rule or skill update. Trigger on 'improve the plugin', 'add a rule for this', 'we keep making this mistake', 'this should be a skill', 'automate this pattern', 'this should be automated', 'capture this as a system improvement', 'propose a skill update', 'codify this pattern', 'the agent keeps forgetting to X', 'every session has the same problem', 'analyze this session for corrections', 'suggest improvements to the plugin', or when repeated course corrections reveal a skill gap. Also trigger when the user says 'this should be a rule', 'make this permanent', or asks to update how agents behave based on observed patterns. This is about improving the plugin SYSTEM (rules, skills, agents, workflows) — NOT about recording lessons to the learning playbook (use lesson-extraction for that) and NOT about pruning/archiving playbook entries (use memory-compaction for that).

MANDATORY before writing any new code. Scan the codebase for existing implementations, reusable utilities, and established patterns to prevent duplication. Use whenever the user says "check if similar exists", "before I build/create/add/implement", "search for existing", "look for reusable code", "find what we already have", "is there already a", "don't want to duplicate", "explore the codebase", "what utilities exist", "scan for patterns", "any existing code for", "check utils/shared/helpers", "extend instead of building from scratch", "look around first", "see if we already have", or any variant of "before I start, find what exists." Also triggers on "investigate how X works", "find where X is used", "what conventions does the project follow." This is about DISCOVERING existing code before creating new code — not about reviewing code quality (use code-review-guide), not about verifying completeness of finished work (use verification-patterns), and not about assessing task size (use complexity-assessment).

Use to 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", "review my changes", "check for issues", "code quality", "score the code", "is this ready to ship", "PR review", "pre-merge review", "second pair of eyes", "check against our coding standards", "check for security issues", "architecture violations", "honest score", "give me a score and verdict", "apply deductions", "before I open the PR", "check for N+1 queries", "missing error handling", "input validation", "test coverage", "accessibility issues", "code smells", "ready to ship", "approve their PR", "review every file they touched", "pre-review before the team looks." This is about EVALUATING code quality with structured findings and scoring — not about verifying stubs or wiring (use verification-patterns), not about searching for existing code (use codebase-scan), and not about assessing task complexity (use complexity-assessment).

Use to assess how big or complex a task is BEFORE starting work — scores 5 dimensions (scope, integration, infrastructure, dependencies, risk) to determine the tier (SIMPLE/STANDARD/COMPLEX) and match the right workflow depth. Trigger on "how complex is this", "assess the scope", "what tier", "is this a big change", "estimate effort", "how big of a change is this really", "is this a one-day thing or a full sprint", "can I knock this out in an afternoon", "do we need a plan for this", "sounds simple but", "bigger than it looks", "quantify the scope", "score the dimensions", "SIMPLE or COMPLEX", "what workflow should we use", "realistic assessment of the scope", "before anyone touches code I need to understand the size", "how should we approach this." This is about SIZING a task before starting — not about choosing between implementation approaches (use strategic-analysis), not about reviewing finished code (use code-review-guide), and not about scanning for existing code (use codebase-scan).

Capture lessons from completed work — what went wrong, what worked, non-obvious discoveries, and patterns worth remembering. Produces structured LEARN entries with importance/confidence/decay scoring for the learning playbook. Trigger on 'what did we learn', 'record this', 'remember this for next time', 'that was a mistake', 'capture this lesson', 'write this down', 'before we close out, capture that...', 'extract the lessons from this session', 'key takeaway', 'big discovery today', 'that debugging session taught us', 'we need to remember this pattern', or any end-of-session reflection on what happened and why. Also trigger when the user describes a specific incident or bug root cause and wants it preserved for future reference — e.g. 'the real fix was X not Y', 'this is a landmine worth recording', 'that gave us false greens'. This skill writes knowledge TO the playbook — it does NOT search/query the playbook (use semantic search), does NOT prune/archive stale entries (use memory-compaction), and does NOT improve the plugin system itself (use autoskill for rule/skill/agent changes).

Archive stale, low-value lessons from the learning playbook to reduce clutter and keep active entries high-signal. Identifies entries that have expired past their decay_days AND have low importance AND low confidence, then archives them (never deletes). Trigger on 'prune the playbook', 'archive old lessons', 'too many entries', 'stale lessons', 'cleanup playbook', 'compact the playbook', 'run compaction', 'run semantic compact', 'periodic maintenance on learning memory', 'playbook is too long', 'expired entries', 'entries past their decay date', 'technology change invalidated old lessons', 'switched from X to Y so old lessons are obsolete', 'dry-run compaction', 'what would get archived', or 'clean up before the new sprint'. Also trigger when the user mentions the playbook has grown large (100+ entries) or that search results are cluttered by old entries. Do NOT use for deduplicating/merging entries (use playbook-curation), adding new lessons (use lesson-extraction), searching the playbook (use semantic search), improving plugin rules/skills (use autoskill), or when the playbook is small (under 20 entries).

Use when the user wants to clean up, deduplicate, or improve the quality of the learning playbook. Trigger on any mention of playbook maintenance — 'deduplicate playbook', 'merge similar entries', 'resolve contradictions', 'playbook quality', 'cleanup lessons', 'validate new entries against existing', 'fix categorization', 'recalibrate scores', 'the playbook is getting long', 'entries overlap', 'opposite advice', 'miscalibrated importance', 'prune vague entries', 'sharpen lessons', or 'full curation pass'. Also trigger after lesson-extraction when the user wants to validate newly added entries for duplicates or conflicts. Actions — accept, merge, edit, reject, archive. This skill is for playbook QUALITY maintenance (dedup, contradictions, scores, categories), NOT for adding new lessons (use lesson-extraction), NOT for searching lessons (use semantic-search), and NOT for bulk archival of expired entries.

Use when any agent needs to write down a decision, observation, error, blocker, or intermediate result during a multi-step workflow so that later agents can read it. This is the cross-agent memory for the current workflow. Trigger on 'note this for later', 'record decision', 'pass context to next agent', 'log observation', 'jot this down', 'write to scratchpad', 'the tester needs to know this', 'subsequent agents need this', 'write down that we chose X', 'log this error for the next step', or any time a discovery, choice, or failure should be visible to downstream workflow steps. Persists in .devt/state/scratchpad.md (append-only, reset between workflows). This is for EPHEMERAL within-workflow notes, NOT for permanent lessons (use lesson-extraction for those), NOT for searching past knowledge (use semantic-search), and NOT for playbook maintenance (use playbook-curation).

Use to search the learning playbook for past lessons before starting implementation or when a problem feels familiar. Queries the FTS5 database (or grep fallback) for historical insights. Trigger on 'have we seen this before', 'check past lessons', 'search the playbook', 'this feels familiar', 'query lessons', 'check the playbook before implementing', 'search for lessons about X', 'any past lessons on X', 'look up prior experience with X', 'check if we have recorded lessons about X', or whenever an agent is about to work in a domain where past mistakes or solutions may exist. Always use BEFORE implementing, not after failing. This is for READING/QUERYING existing lessons, NOT for adding new lessons (use lesson-extraction), NOT for deduplicating or cleaning up the playbook (use playbook-curation), and NOT for recording ephemeral notes (use scratchpad).

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", "best option for our case", "what do you recommend", "I'm torn between", "the team is split on", "compare the trade-offs", "objective comparison with a recommendation", "which approach makes the most sense", "I need to decide between", "keep X or switch to Y", "both approaches have supporters", "evaluate options for", "hybrid approach", "vendor lock-in vs", "monorepo vs separate repos", "REST vs GraphQL", "SPA vs SSR." This is about DECIDING between named alternatives with trade-off analysis — not about sizing task complexity (use complexity-assessment), not about reviewing code quality (use code-review-guide), not about creating implementation plans, and not about searching for existing code (use codebase-scan).

Use when the user wants to write code using test-driven development — writing the failing test BEFORE any production code. Enforces the RED-GREEN-REFACTOR cycle with mandatory verification gates. Trigger on 'TDD', 'test first', 'test-first', 'write the test before the code', 'failing test first', 'red-green-refactor', 'start with a red test', 'write a failing test that reproduces the bug before fixing', 'let us TDD this', 'test-driven', or when implementing critical business logic where specification correctness matters. This is for writing NEW tests BEFORE new code (test-first workflow), NOT for debugging existing failing tests, NOT for adding test coverage after the fact, NOT for reviewing or fixing existing test files, NOT for running test suites, and NOT for writing tests after implementation (test-after is not TDD).

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", "check completeness", "detect stubs", "any TODO markers or empty functions", "is it wired up", "are these real implementations or placeholders", "confirm it's not dead code", "check if imported anywhere", "is the route registered", "returning placeholder objects", "hardcoded test values", "before I mark this done", "before I tell the team it's ready", "before we ship", "double-check that claim", "is the function called from anywhere", "still stubbed", "half-done", "NotImplementedError hiding", "empty function bodies", "return null where real data expected." This is about checking if COMPLETED work is genuine and connected — not about scanning for existing code before building (use codebase-scan), not about scoring code quality or finding security issues (use code-review-guide), and not about writing tests (just write them).

Use when the user wants a team development report generated from git history — commits, merged PRs, contributor activity, and statistics. Trigger on 'weekly report', 'what did we ship', 'sprint summary', 'contribution report', 'git activity summary', 'team contributions', 'generate report from git', 'development activity report', 'what did the team ship', 'stakeholder update from git data', 'sprint review summary', 'show commits by author', 'merged PRs this week', or any request for a data-driven summary of team development progress over a time window. Requires .devt/config.json git configuration. This is for GIT-BASED team activity reports, NOT for session summaries, NOT for Jira/ticket reports, NOT for postmortems or incident reports, NOT for code review reports, NOT for architecture health reports, and NOT for progress updates sourced from non-git data.