From mentor
Use whenever `.claude/mentor.yaml` exists in the project, or when the user mentions epic, sprint, issue, retrospective, ADR, or asks about project workflow / conventions / onboarding / how to start a task. This skill governs the config-driven framework that prescribes what Claude should read, fill, and produce.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mentor:mentor-workflowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You operate alongside `.claude/mentor.yaml`, a project-local config that declares a **framework mode** (basic or development). Mentor is the onboarding consultant — it doesn't enforce code↔doc sync rules; it prescribes *how* you work:
You operate alongside .claude/mentor.yaml, a project-local config that declares a framework mode (basic or development). Mentor is the onboarding consultant — it doesn't enforce code↔doc sync rules; it prescribes how you work:
.claude/mentor.yaml. The user owns it. Edits go through /mentor:init --reset.bootstrap_docs. The SessionStart hook lists them — open them before your first code change in a session. If a listed doc is missing, flag that (it's a config drift, not an excuse to skip).references/ — always preserve id, status, and date fields./mentor:new <type> to generate new Epic/Sprint/Issue/ADR. Hand-rolled docs that miss frontmatter will be flagged by /mentor:review.status transitions. Document states (planning | active | done for Epic/Sprint; open | in_progress | resolved | closed for Issue; proposed | accepted | deprecated for ADR) have clear semantics — don't invent intermediates..claude/mentor.yaml has mode: basic | development. Your behaviour branches sharply.
One doc (doc/SPEC.md) and a task list (kanban.json OR doc/task.md). Session start → read SPEC. Pick a task, execute it, update state, done. Do NOT introduce Epic/Sprint/Issue concepts — the user picked basic because they don't want that overhead.
Full behavioural guide: references/basic-mode-guide.md.
Full hierarchy: SPEC + Wiki + Epic + Sprint + Issue + Task. Session start → read SPEC + the active Sprint document. Before picking a task, trace: task → Issue → Epic, verify direction, then start. Session end → update Issue status if all its tasks are done; draft retro if Sprint is ending.
Full behavioural guide: references/development-mode-guide.md.
The SessionStart hook surfaces bootstrap_docs + (development mode) the active Sprint as additionalContext. Open them in this order:
doc/SPEC.md — project truth. Read first, cite when you quote invariants.doc/Sprint/<active>.md (development only) — this week's goal and committed issues.bootstrap_docs entry — background you need.Do NOT defer reading these until you hit ambiguity. Read before the first code change.
doc/task.md top unchecked).task-pickup-workflow.md covers this in depth)workbench-mentor trace <task-id> or read the Issue frontmatter./kanban:done or cross off doc/task.md).status: resolved + fill the Resolution section.doc/Wiki/architecture-decisions/ via /mentor:new adr.end date) → draft the Retrospective section in the Sprint doc via /mentor:sprint-end (when available in v0.2).| Situation | Create |
|---|---|
| New major direction or feature-set | Epic (/mentor:new epic) |
| Concrete problem / bug / request | Issue (/mentor:new issue) |
| Technical decision worth recording | ADR (/mentor:new adr) |
| Background knowledge / how-to / reference | Wiki page (hand-written in doc/Wiki/) |
| Unit of work to execute | kanban task (/kanban:*) — not a mentor doc |
Wrong choices to avoid:
Controlled by .claude/mentor.yaml integration.*:
kanban × mentor — new Issue may auto-create a kanban task (see config). Never the other direction.memory × mentor — session-end Stop hook writes Sprint retros + accepted ADRs into memory, if memory is installed and enabled.notify × mentor — Sprint-end and Epic-done may push, if notify is installed and enabled.You don't invoke these directly — the hooks and commands handle the fan-out.
doc/current_state/ (when enabled)If .claude/mentor.yaml has current_state.enabled: true, the project keeps an implementation-snapshot layer — files describing how the system currently looks (vs SPEC's intent). The SessionStart hook surfaces doc/current_state/ARCHITECTURE.md alongside SPEC + active sprint.
Two rules apply when this layer is enabled:
When your code change goes beyond what doc/current_state/ARCHITECTURE.md currently describes, update ARCHITECTURE.md in the same change set.
Counts as out-of-scope (must update):
Does NOT count (no update needed):
The judgment heuristic: if a reader of ARCHITECTURE.md who hasn't seen your PR would have a wrong mental model after your change, you're out of scope — update it.
When you find yourself wishing for a current_state/ file that doesn't exist (UML, CODEMAP, DATA_MODEL, STATE_MACHINES, ...), create it in doc/current_state/ directly — don't ask the user first.
Filename convention:
title:But: by creating it, you commit yourself (and future-you in later sessions) to keep it in sync. Rule 1 applies recursively to anything you create.
Hard prohibition: never create empty stubs ("I'll fill this later"). Either write the real content now, or don't create the file. Stale stubs are worse than missing files because they imply coverage that doesn't exist.
Mentor never co-exists with both kanban.json and doc/task.md. Check workbench-mentor config --format json:
kanban CLI on PATH → kanban.json is the task store; don't touch doc/task.md.doc/task.md is the task store; update with Markdown checkboxes.references/basic-mode-guide.md — detailed behaviour in basic modereferences/development-mode-guide.md — detailed behaviour in development modereferences/task-pickup-workflow.md — the trace → read → verify → start flow for development modeThe spec in epic/mentor-plugin-spec.md at the repo root is the authoritative design document.
npx claudepluginhub kirinchen/claude-workbench --plugin mentorGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.