sirl0fty/dev-mentor

Compare two or three technical approaches for a feature or system (ownership, interfaces, data flow, failure behaviour, operational cost, migration, testing) and recommend one with its trade-offs, before anyone writes code. It first asks for architecture diagrams or docs the repo can't show and confirms how the system works. For a question about building or storing something, it proposes the simplest concrete design, starting from what already exists, (such as a table's keys and indexes) and walks every query in the question through it; can record the decision as a short ADR. Use for "how should we design this?", "A or B?", "which approach is better?", "should this be a queue or a cron job?", "where should this logic live?", or any design choice with real alternatives. For checking a recommendation already made, use challenge; to stress-test one option, use devils-advocate. (Dev Mentor)

Check a recommendation before acting on it, whether this AI made it or another agent did. Shows how the decision was reached, checks it against the codebase's own style and structure with real examples, names the alternatives it skipped, and when the case looks weak brings in a fresh devil's-advocate reviewer. Read-only. Use for "is this right?", "why this one?", "how did you decide?", "does this match our code?", "challenge this", or "I'm not sure about this". (Dev Mentor)

Guide someone through building a feature or fixing a ticket in their codebase, one small step at a time. Always shows where to start and why first; then for each edit they write it, copy an explained snippet, let the AI write it, or plan it as a spec or OpenSpec change. Checks their work after each step. Use for "help me build this", "I'll write the code", or a ticket to implement. (Dev Mentor)

Stress-test an engineering proposal. It first gathers shared context (the repo plus any architecture diagrams or docs you add) so every reviewer starts from the same picture. By default it checks which models this assistant can really run, then has three (or two) distinct models challenge each other until they all ratify one decision and its reasons, including a concrete proposed design when the question asks for one, starting from the simplest design that works; with only one model, or when asked for a quick take, it runs a clearly labelled single-model challenge. Use for "play devil's advocate", "poke holes in this", "multi-model debate", or "quick challenge". (Dev Mentor)

Explain how existing code or a system actually works by tracing one real example through the source (entry point, calls, data, tests) with a small flow map, at the person's level and pace. Read-only. Use for "how does this work?", "what happens when…", "trace this request", "where does this value come from?", "I don't understand this file", or getting to grips with unfamiliar code. Use walkthrough for changes that are already finished, review for a colleague's PR, and learn for a concept rather than this codebase. (Dev Mentor)

Teach an engineering concept, technology or certification topic properly, problem first, with a realistic example, one way it breaks and an optional hands-on exercise, with or without a codebase. Use for "teach me X", "help me understand X properly", "explain X with an example", "I keep getting confused by X", "quiz me on X", or exam and certification study (e.g. AWS, Kubernetes). For how this project's own code works, use explain. (Dev Mentor)

Start here. Onboards the person, sets how Dev Mentor talks to them (experience level, tone, pace, build mode such as guided, copy, AI-written, spec or OpenSpec, and ADHD mode), suggests where to start in this codebase, routes to the right workflow, saves and resumes several lessons, exports lessons as notes to Notion, Obsidian or Markdown, and watches a PR's comments and CI. Use for "help", "where do I start?", "settings", "save", "resume", "lessons", "export lesson", or any mentoring request without a chosen workflow. (Dev Mentor)

Shared style settings (experience level, tone, pace, build mode, ADHD mode) and ground rules used by every Dev Mentor skill. Load it before the first reply of any Dev Mentor workflow, or when the person says warmer, more direct, simpler, more technical, faster, slower, or ADHD mode on or off. (Dev Mentor)

Help someone understand a colleague's pull request well enough to review it themselves, step by step, by behaviour rather than file order, labelling each concern as a confirmed bug, question, preference or missing evidence. Read-only; never posts comments, approves or requests changes. Use for "help me review this PR", "what is this PR doing?", "is this PR safe to approve?", a PR link, or an unfamiliar diff from someone else. For a tour of your own finished changes, use walkthrough. (Dev Mentor)

Share a plan before building it (for a colleague or senior dev to review), a lesson as a learning note for Notion or Obsidian, or the outcome of a debate, challenge or review as a decision record (ADR) for a person or the team. Outcome records keep every reviewer's position, disagreement and open question instead of turning them into a new plan. Sends as an HTML file (optionally password-protected), the Markdown file, or in a tool you already use. Use for "share this plan with my senior", "share this lesson", "share this outcome", or "write up this debate as an ADR". (Dev Mentor)

Turn an agreed feature plan into a written spec, either portable Markdown with numbered requirements, scenarios, design and checkable steps, a Matt Pocock or pstack inspired format, or an OpenSpec change through the official openspec-propose skill. Writes the spec only; doesn't implement, create issues or notify anyone. Use for "turn this plan into a spec", "write this up as a spec", "make an OpenSpec change", "spec this feature before we build it", or build mode spec. (Dev Mentor)

Give a guided tour of changes that are already finished (your own branch, a commit range, or a PR you or the AI wrote), in the order the code runs, so the person understands them and can explain them to colleagues or a lead. Read-only. Use for "walk me through what changed", "explain my branch", "what did we just build?", "help me present this change", or preparing to talk about your own work. To prepare to review someone else's PR, use review. (Dev Mentor)