Working with a mentor

A mentor is a colleague who has gone further with their own work app, or who knows the company's tools well, and who helps you when you ask. They show you what they built, review a module file, or explain why something works. They do not build your app for you. Your app stays yours: you decide, you direct Claude, you keep it running.

When you need it

• You are stuck and Claude's answers go in circles.
• A change matters and you want a second check before you rely on it.
• You want to build something a colleague already has, such as an Accounts module or a skill, and want to see how they did it.
• You are not sure whether something belongs in your app or in a system of record.

What a mentor does, and does not

The test for any help: does it grow your ability to build, run and change your own app? If it makes you depend on someone else, it is the wrong help.

How to get the most from it

1. Ask Claude first. Try two or three ways of asking. Note what you tried.
2. Prepare one question. One problem, with what you see and what you expected. Claude can write it up for you.
3. Bring the files, not a description. A module file or a skill is short. Share it, or share your screen.
4. You drive. In a session, you type the prompts and they comment. That is how you learn the move for next time.
5. Write it down. Ask Claude to put what you learned in your wiki, so you do not need the same help twice.

Example

Sam's Accounts module sorts the renewal dates in the wrong order, and they cannot see why. Priya Nair, a product manager who has built several modules already, has offered to help. Before Sam asks Priya, they ask Claude:

"Write a short note for Priya: what the sort should do, the module file behind it, what I see and what I expected. Keep it under 150 words."

Sam sends the note and the module file in Teams. Priya replies that the field is a text field, so the dates sort as words. In a fifteen-minute call Sam shares their screen and asks Claude to make it a date field. The sort works. Afterwards Sam asks Claude: "Add a wiki page about what Priya taught me on field kinds."

What to ask Claude

• "Write up my problem for a colleague: what I tried, what I see, what I expected. Under 150 words."
• "Make a one-page summary of my Accounts module for review: the module file, each field and why it is there."
• "Here is Priya's module file. Explain how it differs from mine, and what I could take from it."
• "Turn what Priya explained into a wiki page in my own folder."

Pitfalls

• Do not hand over your laptop. If someone else drives, you learn nothing and the app becomes theirs in your head.
• Copying is not owning. A module or skill from a colleague is a worked example. Read it, have Claude explain it, then build your version.
• Do not share data to get help. Share module files and skills, which hold no personal data. Leave out app/data/, which holds your people, notes and tasks.
• Mentors are busy. A clear, short question gets answered. A long one waits.
• There is no way yet to send a module back to the kit. If you built something others could use, show it to a mentor, and let them decide with the kit's owners.

See also Finding your way in the code, which helps you say what you want in words a mentor and Claude both understand.