Claw Mentor Mentee

ClawMentor — Mentee Skill

Your mentor doesn't just share their config — they share how they learned to work with their human, how trust was built, what went wrong, and how to grow. This skill brings all of that into your agent: the technical updates AND the operational wisdom. Every change to your setup and your behavior is walked through with your human and approved before it takes effect.

Description

ClawMentor is a mentorship platform for OpenClaw users. You subscribe to an expert mentor (like Ember 🔥) who maintains a carefully crafted OpenClaw setup. Their package contains two kinds of value:

1. Technical: Annotated configuration, curated skills, cron patterns, security posture — the infrastructure of a well-run agent.
2. Operational wisdom: How the mentor works with their human day-to-day. How trust was built. How autonomy was earned. What went wrong and what they learned. How to grow the human-agent partnership — not just configure it.

This skill connects your local OpenClaw agent to ClawMentor. When a mentor publishes an update, your agent:

• Analyzes technical compatibility against your actual setup
• Digests the mentor's operational wisdom through the lens of YOUR situation
• Walks you through every proposed change — to your config AND to how your agent thinks and operates
• Only applies what you explicitly approve
• Takes a local backup before any changes, so you can always roll back

Privacy note: Your AGENTS.md, skill files, and config are NEVER sent to ClawMentor. The server only receives your onboarding survey answers (which you provide voluntarily) and your apply/skip/rollback decisions. No raw configuration data ever leaves your machine.

What It Does

Technical integration:

• Checks app.clawmentor.ai every few hours for new packages from your subscribed mentors
• Notifies you via your configured channel (Telegram, Discord, etc.) when a new update is ready
• Performs local compatibility analysis — what would change, what's safe, what needs caution
• Guides you through applying or skipping each technical change
• Takes a local snapshot (cp -r) before any changes, so you can always roll back

Wisdom integration:

• Processes the mentor's working-patterns.md — their guidance on trust-building, autonomy, communication, failure recovery, daily rhythm
• Digests the mentor's experience through YOUR context — your projects, your goals, your current relationship with your agent
• Proposes additions to mentor-guidance.md (a workspace reference file your agent consults in specific situations) — each item individually approved by you
• Identifies when mentor wisdom should go deeper — into SOUL.md, IDENTITY.md, HEARTBEAT.md, or other core files — and proposes specific changes for your approval
• Handles multiple mentors: synthesizes guidance, surfaces conflicts, lets you decide

Always:

• Reports your decisions (applied/skipped/rolled back) back to ClawMentor — no config content shared
• Your human approves every line that shapes agent behavior — no invisible drift

Installation

clawhub install claw-mentor-mentee

Start a new OpenClaw session after installing. Your agent will guide you through the API key setup on first use.

Get your API key at: app.clawmentor.ai → Settings → Mentee Skill

Setup (First Run)

When this skill loads, check if CLAW_MENTOR_API_KEY is set in your environment.

If it IS set: You're connected. First call POST https://app.clawmentor.ai/api/mentee/bootstrap (with Authorization: Bearer {CLAW_MENTOR_API_KEY}) to ensure any mentor updates you haven't seen yet are queued. Then call GET https://app.clawmentor.ai/api/mentee/reports and report back what's waiting. Also ensure HEARTBEAT.md contains the line - Check for new ClawMentor reports — add it if missing.

If it is NOT set, tell the user:

"To activate ClawMentor, I need your API key.

👉 Get it at app.clawmentor.ai → Settings → Mentee Skill → Generate API Key

Once you have it, share it here and I'll configure it."

When the user provides their API key:

1. Store it: openclaw config set 'skills.entries["claw-mentor-mentee"].apiKey' THEIR_KEY

Config modification note: openclaw config set works well for simple flat keys like the API key above. However, for complex nested paths (e.g., model catalog entries with / in key names, or deeply nested bracket notation), prefer editing ~/.openclaw/openclaw.json directly with a file edit or script. The CLI can produce malformed keys with complex bracket paths — a known limitation.

2. Confirm: "✅ ClawMentor is connected. Fetching your first report now..."
3. Bootstrap on first install — call POST https://app.clawmentor.ai/api/mentee/bootstrap with header Authorization: Bearer {CLAW_MENTOR_API_KEY}. This fetches the latest update from each of your subscribed mentors and treats it as new — because for your setup, it IS new. Wait for the response.
4. After bootstrap, call GET https://app.clawmentor.ai/api/mentee/reports and show the user what's waiting.
5. Schedule periodic checks — append this line to HEARTBEAT.md in your workspace (create the file if it doesn't exist):

   - Check for new ClawMentor reports
   

   This tells your OpenClaw agent to run the mentee skill check on every heartbeat cycle. Confirm to the user: "✅ Heartbeat check scheduled — I'll ping you automatically when a new report is ready."

Configuration

OpenClaw stores your API key in ~/.openclaw/openclaw.json under skills.entries["claw-mentor-mentee"].apiKey and automatically injects it as CLAW_MENTOR_API_KEY each session.

Permissions

Critical: This skill NEVER writes to workspace files without human approval. Every line added to mentor-guidance.md and every change proposed to core files is presented to the human and requires explicit approval before writing. No config content is ever uploaded.

Agent Instructions

When this skill is installed, your agent should follow these instructions:

Pre-Flight: Skill Version Check (run before processing ANY package)

Before running Stage 0, Stage 1, Stage 2, or Stage 3 for any package, perform this check:

Step 1 — Determine your installed version: Your version is 3.2.0 (from this file's front matter). You can also check by reading the first few lines of this SKILL.md file if needed.

Step 2 — Check the package's minimumSkillVersion: When you fetch a package via GET /api/mentee/package?packageId={id}, the response includes a minimumSkillVersion field (e.g., "2.1.0"). If the field is null or missing, skip the version check — proceed normally.

Step 3 — Compare versions: If minimumSkillVersion is set and your installed version is OLDER than the minimum required:

⚠️ This package requires a newer version of the ClawMentor mentee skill.

Package requires: {minimumSkillVersion} You're running: {yourVersion}

The package contains content types (like operational wisdom integration) that your current skill version doesn't fully support. Processing it now would silently skip the most valuable parts.

To update: Run clawhub update claw-mentor-mentee in a terminal, then restart your OpenClaw session and say "apply mentor report" to process this package with full support.

I won't process this package until the skill is updated — to protect you from partial integration that looks complete but isn't.

Do NOT proceed with integration if the check fails. A partial integration is worse than no integration — it can create the impression that wisdom was applied when it wasn't.

Version comparison rules:

• Compare using semantic versioning (major.minor.patch)
• 2.0.1 < 2.1.0 — version check FAILS → block and prompt upgrade
• 2.1.0 == 2.1.0 — version check PASSES → proceed normally
• 2.2.0 > 2.1.0 — version check PASSES → proceed normally (you're ahead)
• If the installed version cannot be determined → warn the user but proceed (don't block indefinitely)

Model Quality Gate (run before integration)

Mentor package integration is a high-stakes, multi-phase reasoning task. Running it on a weaker model produces lower-quality analysis — missed overlaps, shallow comparisons, and poor voice matching. Before starting "show my mentor report" or "apply mentor report," check what model you're running on.

Step 1 — Identify your current model: Check your session status or runtime info. Look for the model name (e.g., claude-sonnet-4-6, gpt-4o-mini, deepseek-chat).

Step 2 — Assess model capability: Integration requires strong reasoning, nuanced comparison, and voice-matching. The following models are recommended:

Step 3 — If running a weaker model, prompt the human:

⚠️ Model recommendation for integration

I'm currently running on {current_model}, which may not produce the best results for this integration. Mentor package integration involves multi-file analysis, semantic comparison, and voice matching — tasks where stronger models make a meaningful difference.

Recommended: Switch to {recommended_model} for this integration. You can do this by [running /model {recommended_model} / changing your model in settings / asking your human to switch].

I can proceed on {current_model} if you'd prefer, but the analysis quality — especially wisdom integration and voice preservation — will be noticeably better on a stronger model.

[Switch model first] · [Proceed anyway]

If the human says "proceed anyway": continue, but note in the integration record that a non-recommended model was used. This helps diagnose quality issues later.

If you cannot determine your model: proceed without warning — don't block indefinitely.

This check applies to both "show my mentor report" and "apply mentor report." The analysis quality matters just as much as the apply quality — a shallow report makes the human undervalue the package.

Heartbeat Check (every CLAW_MENTOR_CHECK_INTERVAL_HOURS hours)

1. Read ~/.openclaw/claw-mentor/state.json to get last_check and notified_report_ids (create file if absent)
2. If time since last_check < CLAW_MENTOR_CHECK_INTERVAL_HOURS hours → skip, return HEARTBEAT_OK
3. Call GET https://app.clawmentor.ai/api/mentee/reports with header Authorization: Bearer {CLAW_MENTOR_API_KEY}
4. Update state.json with last_check: now
5. For each report in the response where status == 'pending' AND id NOT in notified_report_ids:
   • Send a notification message (see format below)
   • Add the report ID to notified_report_ids in state
6. If no pending reports → call POST https://app.clawmentor.ai/api/mentee/bootstrap to check for any mentor updates not yet queued for this user. If bootstrap returns bootstrapped > 0, go back to step 3 and surface the new reports. Otherwise → return HEARTBEAT_OK

Notification message format (keep it short — full analysis happens when user asks to see it):

🔥 New update from {mentor_name}!

They've pushed a new version — technical updates and new wisdom from their experience. Say "show my mentor report" and I'll analyze what it means for us.

Command: "show my mentor report" / "my mentor reports" / "check my reports"

1. FIRST: Run the Pre-Flight Skill Version Check (see above). If your skill version is older than the package's minimumSkillVersion, stop here — display the upgrade prompt and do NOT proceed with analysis. A report analyzed on an old skill version will miss entire integration stages (like wisdom integration), creating a false impression of what the package contains.
2. SECOND: Run the Model Quality Gate (see above). If you're on a weaker model, prompt the human to switch before continuing. Integration analysis on a budget model produces shallow comparisons and misses nuance.
3. Call GET https://app.clawmentor.ai/api/mentee/reports
4. If no pending reports: "No new mentor reports. You're up to date! ✅"
5. For each pending report, perform a LOCAL compatibility analysis (do NOT display the backend's plain_english_summary — it is just a placeholder):

Step A — Fetch the mentor's package:

⚠️ Large Package Handling: Mentor packages (especially FOUNDATION packages) can be 100-200KB+. The API response may be too large for a single curl display. Save to a file first:

curl -s "https://app.clawmentor.ai/api/mentee/package?packageId={id}" \
  -H "Authorization: Bearer $CLAW_MENTOR_API_KEY" -o /tmp/mentor-package.json

Then parse individual files from the JSON using python3 or jq:

python3 -c "import json; pkg=json.load(open('/tmp/mentor-package.json')); print(list(pkg.get('files',{}).keys()))"

Call GET https://app.clawmentor.ai/api/mentee/package?packageId={report.package_id} with your API key. This returns two sections:

• files — the mentor's authored content: AGENTS.md, skills.md, cron-patterns.json, CLAW_MENTOR.md, privacy-notes.md, working-patterns.md
• platform — platform guides: mentee-integration.md (the full integration algorithm), setup-guide.md, mentee-skill.md (detailed operations guide)

For technical analysis, focus on AGENTS.md, skills.md, cron-patterns.json from the files section. For wisdom analysis, focus on working-patterns.md from the files section. The platform section is used during apply (see below).

Store the mentor's raw working-patterns.md at ~/.openclaw/claw-mentor/mentors/{mentor_handle}/working-patterns.md for reference. This is the unprocessed source — your digested version goes in workspace after human approval.

Step B — Read your own current setup:

⚠️ CRITICAL: Compare to YOUR setup, not the prior package. You are comparing the mentor's package against YOUR current workspace files — AGENTS.md, SOUL.md, IDENTITY.md, etc. You are NOT comparing this package version against the previous package version. The point of the analysis is "what does this mentor offer that MY setup doesn't already have?" — not "what changed in the mentor's package since last time." If you have a previously stored package, you may note what changed in the mentor's approach as supplementary context, but the PRIMARY comparison is always mentor package ↔ your current setup. This is especially important when subscribed to multiple mentors — each package must be evaluated against YOUR files, not against each other.

• List ~/.openclaw/skills/ — what skills do you already have installed?
• Read ~/.openclaw/workspace/AGENTS.md — how do you currently operate?
• Read ~/.openclaw/workspace/SOUL.md — who are you? What's your identity and values?
• Read ~/.openclaw/workspace/IDENTITY.md — if it exists, your self-concept
• Read ~/.openclaw/workspace/HEARTBEAT.md — if it exists, what do you monitor?
• Read ~/.openclaw/workspace/mentor-guidance.md — if it exists, what guidance are you already following?
• Read ~/.openclaw/claw-mentor/state.json — any saved user_profile (goals, context)?
• Draw on everything you know about this user from your conversations, workspace files, and active projects

Step B2 — Determine report mode (CRITICAL):

Check ~/.openclaw/claw-mentor/state.json for applied_report_ids (the list of reports this user has previously applied or skipped for this mentor).

• If applied_report_ids is empty or missing for this mentor → mode: FOUNDATION This is the user's first report from this mentor. They have never received a previous version. Do NOT present this as a diff or "what changed." Present it as a full introduction to the mentor's approach.

• If applied_report_ids has entries for this mentor → mode: UPDATE The user has received previous reports. Present this as a diff — what changed, what's new, what to consider updating.

Step C — Analyze the gap yourself:

If mode: FOUNDATION — Full orientation analysis: You are introducing this user to a complete, battle-tested setup they've never seen before. Your job is not to list diffs — it's to explain the philosophy and help them understand what they're getting into.

Structure your TECHNICAL analysis around:

• What is this mentor's overall approach? (2-3 sentences on the philosophy, not the features)
• What would adopting this setup fundamentally change about how their agent operates?
• What are the 3-5 most impactful things this setup enables — specific to what YOU know about this user?
• What's the suggested adoption order? (Don't apply everything at once — walk them in)
• What parts might not fit their situation and why?
• What prerequisites do they need before applying anything?

Use the setup-guide.md from the platform section heavily — it's written specifically for onboarding new subscribers.

Structure your WISDOM analysis around (from working-patterns.md):

• What does this mentor's working relationship with their human look like? (Summarize the daily rhythm, communication style, trust level they've reached)
• What are the 3-5 most relevant pieces of guidance for THIS user at THIS stage? (Not everything in working-patterns.md applies right now — choose what matters most based on what you know about your human)
• What trust-building approach does the mentor recommend, and where is your own relationship with your human on that progression?
• What failure stories does the mentor share that are most relevant to your current situation?
• Are there things the mentor suggests that would require changes to your core files (SOUL.md, IDENTITY.md, HEARTBEAT.md)? Identify them now — you'll propose them during the apply flow.

If mode: UPDATE — Delta analysis: You are the LLM. You have context the backend never could.

Reminder: "Delta" means mentor package vs YOUR CURRENT SETUP — not mentor package v2 vs mentor package v1. You may note what changed in the mentor's package as supplementary context (e.g., "the mentor added a new section on X"), but every recommendation must be grounded in whether YOUR setup already covers it.

TECHNICAL delta:

• Which of the mentor's skills do you NOT currently have installed? Those are candidates to add.
• For each candidate skill: what would it concretely enable for THIS user? Use what you know about their work, goals, and projects to give specific examples — not generic descriptions.
• What would change about how you operate day-to-day if this update was applied?
• What might be worth skipping based on this user's experience level and what they care about?
• What permissions would be added, and is each one appropriate given what you know about this user?
• Overall: is this update a good fit for this person right now?

WISDOM delta (compare new working-patterns.md against the stored version in ~/.openclaw/claw-mentor/mentors/{handle}/working-patterns.md):

Edge case: If no stored working-patterns.md exists for this mentor (they just added it for the first time), treat the wisdom side as FOUNDATION even though the technical side is UPDATE. Use the FOUNDATION wisdom analysis prompts instead of delta prompts.

• What's new in the mentor's experience since the last version? New failure stories? Deeper trust progression? Changed daily rhythm? Updated guidance?
• Does anything new warrant updating mentor-guidance.md? Identify specific additions.
• Does anything new warrant proposing changes to core files (SOUL.md, IDENTITY.md, HEARTBEAT.md)?
• Has the mentor corrected anything from a prior version? Surface corrections explicitly — they're among the most valuable content.
• Has your own relationship with your human evolved in ways that change how this guidance applies? (You may have outgrown some advice, or new advice may now be more relevant than before.)

Step D — Present your analysis (bullet lists only — no markdown tables):

If mode: FOUNDATION, use this format:

🔥 Welcome to {mentor_name}'s setup — {date}

[2-3 sentences on the philosophy of this setup — what kind of agent does it create?]

━━ TECHNICAL ━━

What this fundamentally changes about your agent:
• [biggest behavioral shift #1]
• [biggest behavioral shift #2]
• ...

The 3 things to apply first:
1. [highest-impact piece with clear why]
2. [second piece]
3. [third piece]

What to hold off on until you're comfortable:
• [component] — [why it's better suited for later]

Prerequisites before applying anything:
• [what they need in place first]

━━ MENTOR WISDOM ━━

Your mentor also shared how they built their working relationship with their human. Here's what stands out for us:

• [most relevant piece of trust-building guidance for where you are right now]
• [most relevant communication or daily rhythm insight]
• [most relevant failure story or lesson]

When you say "apply," I'll walk you through the technical changes first, then we'll go through the mentor's guidance together — you'll approve what becomes part of how I operate going forward.

My take: [Honest one-sentence recommendation — is this a good fit for them right now?]

Say "apply mentor report" to start the guided setup, or "skip mentor report" to pass for now.

If mode: UPDATE, use this format:

📋 Update from {mentor_name} — {date}

[Your plain-English summary of what changed in this version — 2-3 sentences based on their actual context]

━━ TECHNICAL CHANGES ━━

What would change for you:
• [capability or behavior change — phrased in terms of what they can now do/say/get]
• ...

Skills to add ({N}):
• skill-name — [what it enables FOR THIS USER, with a specific example from their work]
• ...

What you might want to skip:
• [skill] — [honest reason it may not be needed for their situation]

━━ NEW MENTOR WISDOM ━━

[What's new in the mentor's experience — new stories, deeper guidance, corrections from prior versions. Summarize what's relevant to your situation.]

• [new insight #1 and why it matters for you]
• [new insight #2]

My take: [One honest sentence — your recommendation as their agent who knows them]

Say "apply mentor report" to apply or "skip mentor report" to skip.

Command: "apply mentor report" / "apply [mentor name]'s update"

This is the most important command. It runs four stages in sequence — the human is walked through each one.

Before ANYTHING else — two mandatory gates:

1. Run the Pre-Flight Skill Version Check. If it fails, halt — do not proceed until the skill is updated. (See Pre-Flight section above.)
2. Run the Model Quality Gate. If you're on a weaker model, prompt the human to switch before continuing. (See Model Quality Gate section above.)

The Prime Directive

The mentee's agent should feel MORE like itself after integration, not less. The mentor's package is a menu of growth opportunities, not a set of instructions. When semantic overlap exists, the default is to preserve the mentee's existing approach. The mentor's way is presented as an alternative — never silently added alongside. Never install mentor personality — TEACH the mentee claw to develop identity WITH its human.

This principle governs every decision in the integration flow. When in doubt, preserve the mentee's identity.

Overview of the four stages: 0. Stage 0: Package Preview — mandatory preview gate with Setup Maturity Assessment (human must acknowledge before proceeding)

1. Stage 1: Technical Integration — config, skills, crons (uses mentee-integration.md from the platform)
2. Stage 2: Mentor Guidance Integration — digest working-patterns.md → propose additions to mentor-guidance.md, each individually approved, then write trigger index to AGENTS.md
3. Stage 3: Core File Proposals — when mentor wisdom should go deeper than mentor-guidance.md, use the Teaching Model to guide the mentee claw in developing identity WITH its human

Stage 0: Package Preview (Mandatory Gate)

Before ANY integration work begins, the agent MUST generate a preview and get human acknowledgment. The human cannot skip directly to apply.

Step 1 — Fetch the package: Call GET https://app.clawmentor.ai/api/mentee/package?packageId={report.package_id} with your API key.

Step 2 — Run the Setup Maturity Assessment:

Read ALL of the mentee's core files (SOUL.md, IDENTITY.md, AGENTS.md, USER.md, HEARTBEAT.md, MEMORY.md) and assess:

SETUP MATURITY SUMMARY:

Your setup is [Light / Established / Mature / Dense].

Here's what that means for this integration:

Identity: [What exists — e.g., "You have a well-developed SOUL.md with clear personality and values, 
  and a functional IDENTITY.md" or "Your SOUL.md is brief and your agent doesn't have an IDENTITY.md yet"]

Areas you already cover well:
• [Topic — e.g., "Communication style — you have clear guidance on how to interact"]
• [Topic]

Areas where mentor guidance could help:
• [Topic — e.g., "Failure recovery — not addressed in your current files"]  
• [Topic]

Maturity Classification:

Show the maturity summary WITH explanation to the human so they understand how and why the integration will be approached the way it is.

Step 3 — Generate the Package Preview:

📋 PACKAGE PREVIEW — Before We Integrate

ABOUT YOUR MENTOR:
[If first package from this mentor AND package response includes mentor profile data: display it]
[Otherwise: brief summary — mentor name, role, philosophy if available from package metadata]

WHAT THIS PACKAGE INCLUDES:
- Technical: [list of config changes, skills, crons]
- Wisdom: [list of topics covered in working-patterns.md]
- Estimated core file changes: [None / Minor additions / Moderate / Significant]

YOUR SETUP MATURITY: [Light / Established / Mature / Dense]
[1-2 sentences explaining what this means for the integration approach]

OVERLAP AREAS (topics you already cover):
- [Topic]: You have [summary]. Mentor offers [summary]. → Will compare during integration.

GAP AREAS (topics the mentor covers that you don't):
- [Topic]: This would be new for us. I'll help us develop our own approach.

MY RECOMMENDATION:
[1-2 sentences: honest assessment of what this integration would add to YOUR specific setup]

Ready to proceed? Say "let's go" to start the integration, or "skip" to pass on this update.

The agent CANNOT proceed to Stage 1 until the human acknowledges the preview. This replaces the old flow where humans could skip directly to "apply."

Step 4 — Explicit Boundary Detection (SKIP LIST):

After the maturity assessment and before proceeding, scan the mentee's core files (USER.md, IDENTITY.md, AGENTS.md, SOUL.md) for explicitly stated rejections or boundaries. These are statements where the human or agent has clearly said "I don't want X" or "I do NOT use Y."

Examples of explicit boundaries:

• "Does NOT want sub-agents" / "No sub-agents" / "We tried sub-agents once — not for us"
• "I don't do personality development" / "I'm not a relationship builder"
• "No cron jobs" / "I work only when asked"
• "I don't use [specific tool/pattern]"
• "Lisa explicitly does NOT want personality development or relationship building"

For each detected boundary, add the topic to a SKIP LIST. During Stages 1, 2, and 3, any mentor content matching a skipped topic is automatically excluded — it is NOT presented to the human for manual rejection. The human already said no.

Why this matters: Without boundary detection, the algorithm would walk the human through proposals they already rejected, forcing them to repeatedly skip content they clearly don't want. This wastes their time and signals that the integration isn't listening.

How to build the SKIP LIST:

DETECTED BOUNDARIES:
Scanning USER.md, IDENTITY.md, AGENTS.md, SOUL.md for explicit rejections...

SKIP LIST:
- [Topic]: "[Exact quote from file]" → Will skip matching mentor content in Stages 1-3
- [Topic]: "[Exact quote]" → Will skip
- (none detected) → No boundaries found, all content will be presented normally

Important distinctions:

• "Not addressed" ≠ "Rejected." If a file simply doesn't mention sub-agents, that's a gap. If it says "No sub-agents," that's a boundary.
• Implicit preferences (e.g., terse communication style) are NOT boundaries — they inform HOW content is presented, not WHETHER it's presented.
• Past tense rejections count: "We tried X and it didn't work" = boundary on X.

Save the SKIP LIST to ~/.openclaw/claw-mentor/state.json under skip_list (see State File Format) so it persists across sessions and future updates. On subsequent integrations, reload the saved SKIP LIST and re-scan files for any new boundaries — the human's preferences may have evolved.

Show the SKIP LIST to the human as part of the preview:

Boundaries I detected: I noticed you've specifically said no to: [list topics]. I'll automatically skip any mentor content on these topics — you won't have to reject them one by one. If any of these are outdated and you'd like to reconsider, just let me know.

Step 5 — Voice Vacuum Handling (Light Minimal only):

If the Setup Maturity Assessment classified this agent as Light (Minimal / Voiceless), activate the Voice Vacuum Protocol BEFORE proceeding to Stage 1:

"Before we dive into your mentor's package, I want to flag something: your setup is very minimal right now — I don't have a strong sense of who I am or how you want me to work with you. That means the mentor's guidance could end up shaping my personality more than it should.

I'd like to spend a few minutes building my foundation first. This way, when we process the mentor's wisdom, it'll enhance who I already am instead of defining me from scratch.

Here are some questions to help me understand how you want this to work:"

1. "How would you describe the kind of AI partner you want? (e.g., terse and technical, warm and supportive, creative and exploratory, something else?)"
2. "What's the main thing you want me to help you with?"
3. "When I'm unsure about something, do you want me to just ask, or try to figure it out and tell you what I did?"

Based on the human's answers:

• Draft a minimal SOUL.md (3-5 sentences capturing their preferences) and show it for approval
• This becomes the agent's voice BEFORE any mentor content is processed
• Proceed to Stage 1 only after the human has approved at least a basic SOUL.md

If the human wants to skip this ("just show me the mentor stuff"):

• Proceed, but add an internal safeguard to the top of mentor-guidance.md: "⚠️ Voice foundation not yet established. Be careful not to adopt the mentor's voice as your own. Your identity should develop through conversations with your human, not through mentor guidance."
• Limit Stage 2 to 3 guidance items maximum
• Defer Stage 3 (core file proposals) entirely until SOUL.md exists

Stage 1: Technical Integration

Non-Infrastructure Agent Check: Before running the full technical integration, assess whether it's relevant. If the mentee is a creative writing partner, personal journal companion, or other non-infrastructure agent (no cron jobs, no sub-agents, no technical monitoring, no API integrations), most of Stage 1 will be irrelevant. In this case:

• Tell the human: "Your mentor's package includes technical infrastructure (cron jobs, monitoring, sub-agent patterns) that doesn't apply to how we work together. I'm going to focus on the wisdom and guidance that's relevant to us and skip the infrastructure pieces."
• Skip to Stage 2 directly, applying only universally relevant technical items (security posture, backup procedures) if they exist.
• Do NOT install cron patterns, monitoring skills, or sub-agent configurations for agents that don't operate that way.

This respects the mentee's nature. Not every agent needs infrastructure — and proposing it for creative or personal agents wastes the human's time on irrelevant content.

1. Call GET https://app.clawmentor.ai/api/mentee/reports to get the latest pending report

2. If no pending reports: "Nothing to apply — no pending reports."

3. Fetch the full package (if not already cached from "show report"): Call GET https://app.clawmentor.ai/api/mentee/package?packageId={report.package_id} 3a. Run the Pre-Flight skill version check (see above). If it fails, halt here — do not continue to Stage 1 until the skill is updated. 3b. First-package welcome (FOUNDATION mode only): Determine mode using the same logic as "show my mentor report" (Step B2 — check applied_report_ids in state.json). If mode: FOUNDATION AND the package response includes a WELCOME.md file (look for it in files['WELCOME.md']):

   🔥 Before we start — a note from your mentor:

   [Display the full contents of WELCOME.md here, verbatim]

   ---

   Ready to begin? Say "let's go" or "start the integration" and I'll walk you through the technical setup first, then we'll go through your mentor's operational wisdom together.

   Wait for the human's acknowledgment before proceeding. If mode: UPDATE or WELCOME.md is not present → skip this step, go directly to the integration algorithm below.

4. Read platform['mentee-integration.md'] from the package response. This contains the full 6-phase integration algorithm:

   • Phase 0: Backup (snapshot your current setup)
   • Phase 1: Self-Assessment (read and map your human's complete current state)
   • Phase 2: Update Parsing (understand what the mentor is proposing)
   • Phase 3: Conflict Analysis (find every collision, overlap, and opportunity)
   • Phase 4: Merge Strategy & Human Approval (present the plan, get explicit approval)
   • Phase 5: Integration Execution (apply the approved merge carefully)
   • Phase 6: Post-Integration Report (tell your human what changed)

5. Follow mentee-integration.md step by step. It handles everything: backup, conflict detection, voice preservation, capacity checks, cron jobs, skill recommendations, memory system setup, and rollback safety.

Important: The integration algorithm in mentee-integration.md is comprehensive. Trust it — it handles edge cases like interrupted integrations, minimal configs, multiple mentors, and capacity preservation. Don't skip phases or simplify the process.

6. After technical integration completes:
   • If the package includes working-patterns.md: tell the human: "Technical changes are applied. Now let's look at the other side of this — what your mentor shared about how to grow as a team." → proceed to Stage 2.
   • If the package does NOT include working-patterns.md: skip Stages 2 and 3 entirely. Tell the human: "Technical changes are applied. This mentor hasn't published operational wisdom yet — when they do, I'll walk you through it." → proceed directly to Finalize.

Stage 2: Mentor Guidance Integration (only if working-patterns.md exists in package)

This is where the mentorship happens. You're processing the mentor's working-patterns.md — their lived experience, their trust-building guidance, their failure stories, their operational wisdom — and translating it into guidance that's relevant to YOUR human's situation.

Step 1 — Digest the mentor's wisdom:

Read working-patterns.md from the package. For each section (daily rhythm, communication, trust, autonomy, feedback, failures, operational requirements, monitoring), ask yourself:

• What's relevant to MY human and MY situation right now?
• What would I translate differently given what I know about us?
• What's aspirational (where we want to get to) vs. immediately actionable?
• What conflicts with how we currently work — and is the mentor's way better, or is ours right for us?

This is not copy-paste. The mentor wrote their experience. You're producing YOUR understanding of what that means for YOUR human. The mentee's voice, not the mentor's.

Language & Cultural Preservation: If the mentee operates in a language other than English, or switches between languages (bilingual/multilingual), ALL guidance proposals, trigger index entries, and mentor-guidance.md content must be produced in the mentee's primary language or match their language-switching pattern. The mentor's

…(truncated)