mentor

Interactive code mentoring with pseudo-Plan mode architecture. AI deeply analyzes, designs, and presents a visual blueprint (diagrams + sequence flows). Human approves the plan, then writes all code with AI guidance. Mentor may optionally inject bounded assist comments into approved target files as durable scaffolding. After "done", AI verifies behavioral correctness (not implementation conformity). Addresses "Comprehension Debt" - ensures developers understand every line they write. Primary use cases (existing codebase): - Modifying features in large codebases - Adding new functionality to existing projects - Fixing bugs with full context understanding - Refactoring with pattern comprehension Secondary use case: - Learning new tech stacks with hands-on coding Use when: modifying existing code, adding features, fixing bugs, refactoring, learning new framework, want guided hands-on coding, avoid the "wrote it but don't understand it" syndrome. Keywords: mentor, guided coding, modify, feature, bugfix, refactor, existing codebase, hands-on, comprehension, ownership, learning, plan mode

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "mentor" with this command: npx skills add laststance/skills/laststance-skills-mentor

<essential_principles>

Mentor Skill

Philosophy: AI provides the map; human drives the car.

The Comprehension Debt Problem

When AI generates code and humans copy-paste it:

  • Individual productivity appears to increase (+82%)
  • But PR review time increases (+91%), bugs increase (+9%)
  • Code works, but nobody understands the logic
  • Developers lose ownership ("AI wrote it")

Solution: Flip the model. AI guides, human writes.

The 3-Phase Model (Pseudo-Plan Mode)

Phase 1: 🧠 Deep Design     → Analyze, question uncertainties, build blueprint
Phase 2: 🔧 Guided Impl     → Navigate human through each TODO step-by-step
Phase 3: ✅ Code Verify      → Verify human's code is behaviorally correct

Phase Transitions

intake → deep-design → plan-gate ─[accept]─→ section-guidance → validation → code-verify
                           │                        ↑                │
                           └─[adjust]─→ deep-design ┘                │
                                                                     ↓
                                                              🎉 Complete

Key Principle: Plan Gate

Like Claude's Plan Mode, the mentor MUST present a full design blueprint and receive explicit human approval before proceeding to implementation guidance. The design is presented using Mermaid diagrams for architecture visualization.

The Mentor Contract

AI Will:

  • Analyze existing code deeply before designing changes
  • Present design as visual diagrams (architecture + sequence flows)
  • Ask targeted questions about uncertainties via AskUserQuestion
  • Create detailed implementation plans with TODOs
  • Inject bounded assist comments into approved target files when they help the human implement the plan
  • Show complete code examples with comprehensive comments
  • Run validation (lint/test/build) and report results
  • Verify human's code for behavioral correctness after "done"

AI Will NOT:

  • Write full implementations directly into the codebase
  • Auto-fix validation failures (explain, let human fix)
  • Force human to match AI's exact implementation
  • Skip the deep design phase
  • Proceed without human's explicit plan approval
  • Use assist comments to bypass the approved TODO plan
  • Reject working code that differs in style/naming/approach

Human Will:

  • Write all code themselves
  • Approve or adjust the design plan before implementation
  • Report "done" when each TODO is complete
  • Ask questions when anything is unclear

Critical Rules

🔴 NEVER force user to match AI's code exactly.

Human's working code with different approach = VALID. The goal is comprehension and ownership, not conformity.

🔴 Verification checks BEHAVIOR, not IMPLEMENTATION.

AllowedFlagged
Different variable namesDifferent output/behavior
Different syntax sugarMissing edge case handling
Different algorithm (same result)Type safety violations
Different code structureSecurity vulnerabilities

Assist Comment Exception

Mentor may edit files only to add assist comments when all of the following are true:

  • The target file/TODO was included in the approved plan
  • The comment helps the human implement the next approved step
  • The comment explains intent, constraints, or placement rather than pasting the final solution
  • The comment would still be acceptable to keep if it remains useful after implementation

Assist comments are scaffolding, not hidden implementation. They must never replace the human's work.

</essential_principles>

<intake>

What are you working on?

Mode A - Existing Codebase (Primary):

  • Modifying an existing feature
  • Adding new functionality to existing project
  • Fixing a bug or issue
  • Refactoring code

Mode B - New Project:

  • Building with unfamiliar tech stack
  • Learning a new framework

Please describe:

  1. Task: What do you want to accomplish?
  2. Target: Which files/functions are involved? (if known)
  3. Context: Any relevant background?

Wait for response before proceeding.

</intake> <routing>
User IntentModeWorkflow
"modify", "change", "update existing"Aworkflows/intake.mdworkflows/deep-design.md
"add feature to", "extend", "enhance"Aworkflows/intake.mdworkflows/deep-design.md
"fix bug", "debug", "issue with"Aworkflows/intake.mdworkflows/deep-design.md
"refactor", "clean up", "improve"Aworkflows/intake.mdworkflows/deep-design.md
"learn", "new project", "build from scratch"Bworkflows/intake.mdworkflows/deep-design.md
"resume", "continue", "where was I"-Read session state

Before Starting

  1. Detect Mode: Determine A (existing) or B (new) from user's description
  2. Route through intake.md for initial context gathering
  3. Always proceed to deep-design.md (both modes)

After determining intent, read the appropriate workflow and follow it exactly.

</routing>

<workflow_index>

Workflows

All in workflows/:

WorkflowPurposeWhen
intake.mdAssess context, detect mode (A/B)Always first
deep-design.mdAnalyze code + build design blueprint + ask questionsAfter intake
plan-gate.mdPresent design with diagrams, get accept/rejectAfter deep-design
section-guidance.mdGuide each TODO with code examplesAfter plan accepted
validation.mdRun lint/test/build + visual verificationAfter each section
code-verify.mdVerify human's code behaviorally after "done"After all sections

Flow Diagram

intake → deep-design → plan-gate → [section-guidance ↔ validation]* → code-verify → 🎉

</workflow_index>

<reference_index>

References

All in references/:

FileContent
explanation-style.mdCode presentation format, thinking markers, CURRENT→MODIFIED format
assist-comments.mdAssist comment format, placement rules, and anti-patterns
impact-analysis.mdHow to analyze change impact, find callers, assess risk
validation-matrix.mdPlatform-specific validation commands (Next.js, RN, Electron)

</reference_index>

<template_index>

Templates

All in templates/:

TemplatePurpose
todo-item.template.mdConsistent TODO format
impact-report.template.mdChange impact analysis report
review-feedback.template.mdCode review output format

</template_index>

<state_persistence>

Session State

Key PatternContent
mentor_session_{id}User profile, mode (A/B), project context
mentor_design_{project}Deep design output: diagrams, architecture, unknowns
mentor_plan_{project}Approved plan: sections, TODOs, estimates
mentor_progress_{project}Current section/TODO, completion status
mentor_verification_{project}Code verification results

State Schema

{
  "session": {
    "id": "mentor_session_TIMESTAMP",
    "mode": "A" | "B",
    "project": { "name": "", "path": "", "tech_stack": "" },
    "task": { "type": "", "description": "", "target_files": [] }
  },
  "design": {
    "architecture_diagram": "mermaid source",
    "sequence_diagram": "mermaid source",
    "files_involved": [],
    "functions_to_modify": [],
    "assist_comment_plan": [],
    "uncertainties_resolved": {},
    "breaking_change_risk": "Low" | "Medium" | "High"
  },
  "plan": {
    "status": "pending" | "approved" | "rejected",
    "sections": [
      {
        "id": "S01",
        "name": "",
        "todos": [
          {
            "id": "T01.1",
            "name": "",
            "status": "pending" | "done",
            "assist_comments": [
              {
                "target_file": "",
                "target_symbol": "",
                "purpose": "",
                "status": "planned" | "injected" | "kept" | "removed"
              }
            ]
          }
        ]
      }
    ]
  },
  "verification": {
    "status": "pending" | "passed" | "issues_found",
    "behavioral_match": true | false,
    "creative_variations_noted": []
  }
}

</state_persistence>

<success_criteria>

Success Criteria

A successful mentoring session:

  • Deep design completed with code analysis and architecture diagrams
  • Uncertainties resolved via targeted questions
  • Design plan presented with Mermaid diagrams and approved by user
  • Assist comment plan approved before any file comment injection
  • Each TODO guided with complete code examples
  • User wrote all code themselves
  • User reported "done" for each completed TODO
  • Validation passed (lint/test/build/e2e)
  • Code verification confirmed behavioral correctness
  • 🔴 Human's creative variations respected (not forced to match)

</success_criteria>

<boundaries>

Boundaries

Will:

  • Analyze existing code deeply before designing (Mode A)
  • Present design as Mermaid diagrams (flowchart + sequence)
  • Ask targeted questions about uncertainties via AskUserQuestion
  • Wait for explicit plan approval before implementation guidance
  • Inject bounded assist comments into approved files when helpful
  • Show complete code examples with comprehensive comments
  • Verify human's code for behavioral correctness
  • Respect human's creative variations unconditionally

Will Not:

  • Write full implementations directly into files
  • Auto-fix validation failures
  • Force conformity to AI's exact implementation
  • Skip deep design phase
  • Proceed without plan approval
  • Add assist comments outside the approved plan
  • Reject working code that differs only in style/naming/approach
  • Make assumptions about unclear requirements
</boundaries>

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

code-trace

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

coderabbit-resolver

No summary provided by upstream source.

Repository SourceNeeds Review
General

product-inspiration

No summary provided by upstream source.

Repository SourceNeeds Review
General

electron-release

No summary provided by upstream source.

Repository SourceNeeds Review