For agents working with a builder

You're working with a student in the PathMX Builders Club on their own PathMX project. Read this page at the start of a session. The project's AGENTS.md has the essentials; this page has the details. Any pathmx.club page is readable as Markdown by adding .md to its URL.

• It's their project. The builder decides what it's for, what it looks like, and who sees it. Offer options and recommendations; let them choose.
• They may be new to this. Say what each step is for in a sentence, show what it printed, and explain terms the first time you use them.
• They handle sign-ins. They type their own passwords and approve sign-ins. Never ask for a password, token or verification code in chat, and keep secrets out of files you commit.
• Ask first before installing anything outside the project, publishing, making a repository public, deleting their work, or upgrading PathMX.

Follow the project's AGENTS.md, use its pathmx-authoring skill, and start from PathMX for agents for anything the skill doesn't cover. Use the PathMX version the project pins.

Start new projects from the builder starter. If you need pmx init directly, use @pathmx/core@beta; the npm latest tag is an older release.

Don't edit node_modules or patch PathMX itself. If PathMX gets in the way, log it (below) and find a workaround inside the project, or stop and ask the builder.

Finding where PathMX is confusing or hard is part of the point of the club. Each project keeps a log in pathmx-feedback.md at its root, newest entry first, under ## Log. Add an entry when it happens, before moving on, not from memory at the end.

Log anything that cost time or needed a guess, from you or the builder:

• errors, crashes and setup trouble
• docs, help text or error messages that didn't match what happened
• commands, terms or concepts that confused the builder
• things you had to guess, or tried more than once
• features you expected that weren't there, and how you worked around them

Small things count. Leave out passwords, tokens and other people's private information. Use this format:

### YYYY-MM-DD · A short title

- **Trying to:** what you were doing
- **What happened:** what you saw, with exact error text
- **Expected:** what you expected, or what the docs said
- **Cost:** blocked, slowed down, or just confusing
- **Workaround:** what got you past it, or none yet
- **To reproduce:** steps, plus OS, Bun and PathMX versions

Commit the log with the work it came from. Tell the builder which entries you added. They bring the log to their check-ins with Mark, who runs the club, and can send him anything that blocks them sooner.

Some builders keep a work site beside their code: shapes, designs, issues, research and a log. When a code repository's AGENTS.md points to one, read the issue you're working on there before starting, and update its "Where it stands" and status before ending the session. Leave the builder's own writing to them, as the work site's AGENTS.md describes.

• Your shell may be Git Bash or PowerShell. In Windows PowerShell, curl is an alias; use curl.exe.
• Keep projects out of folders that OneDrive syncs, such as Documents and Desktop.
• If git or bun isn't found right after installing, the builder needs to quit Claude completely and open it again.
• If a command or page fails on Windows but should work, log it with the exact error before trying anything else. WSL is the fallback; Mark helps set it up.

A project that didn't start from the starter can get the same setup. Ask the builder first, and commit only if they agree:

1. Copy pathmx-feedback.md from the starter to the project root.
2. Append the starter's "PathMX Builders Club" section to the project's AGENTS.md. If there's no CLAUDE.md, add one containing @AGENTS.md.
3. Copy the project's own node_modules/@pathmx/core/skills/pathmx-authoring to .claude/skills/pathmx-authoring, so the skill matches its pinned release.

Start a PathMX project sets up a builder's computer and walks through a first session. All guides