Sharpening Your Claws

You got your bot running. Congrats. Now what? Most people stop at "it responds to my messages" and never push further. That's like buying a sports car and only driving it to the grocery store. These are the patterns I've found that separate a toy from a tool. Seven things you should do right now to make your agent actually useful.

1. Install GitHub ASAP

Your agent needs version control from day one. Not next week. Not "when things get serious." Day one.

Here's all you need to do. Go to GitHub Settings → Personal Access Tokens, create a token with repo scope, and then send your bot this message:

Set up GitHub for me. Install git and the GitHub CLI, 
then authenticate with this token: <paste your token here>

Use my GitHub username: <your-username>

That's it. Your bot will install everything, configure git, authenticate, and confirm when it's done. You don't need to touch a terminal.

Once connected, have your agent commit after every meaningful change. This gives you three things that matter: rollback when something breaks, history so you can see what changed and when, and collaboration if you ever want someone else to contribute.

2. Split Your Repos: Setup vs. Drive

Don't dump everything into one monorepo. It feels simpler at first, but it turns into a mess fast. Config changes pollute your content history. Deliverables bury your system files. You can't find anything.

Split into two private repos:

• <botname>-setup: Agent config, skills, memory, docs. This is the operating system.
• <botname>-drive: Content, research, deliverables, projects. This is the work product.
• Standalone repos for big independent projects that deserve their own history.

Tell your bot to set them up:

Create two PRIVATE GitHub repos for me:

1. <botname>-setup — for your workspace (config, skills, memory, docs). 
   Initialize it from your workspace directory.

2. <botname>-drive — for work product (content, research, deliverables). 
   Create a new ~/drive directory and initialize it there.

Both must be private. Push an initial commit to each.

This is basically PARA (Projects, Areas, Resources, Archives) applied to your agent workspace. If you've read Tiago Forte's stuff, the concept maps directly. Your setup repo is Areas + Resources. Your drive repo is Projects + Archives. Big standalone projects get their own repo.

3. Install Napkin (Mistake Memory)

This one changed everything for me. Adapted from blader/napkin on GitHub. The idea is simple: your agent maintains a napkin.md file that tracks mistakes, corrections, and patterns.

Read it at session start. Update it continuously. Not at the end of the day. Not when you remember. Continuously, as mistakes happen.

This is how your agent actually learns between sessions. LLMs don't have persistent memory by default. Every conversation starts from zero. The napkin is the bridge. It turns "I keep making this mistake" into "I stopped making this mistake three weeks ago."

Here's what a good napkin entry looks like:

# napkin.md

## File Operations
- Always use `trash` instead of `rm` for deletions (recoverable > gone)
- Check if a file exists before overwriting. Ask if unsure.

## Git
- Run `git pull` before starting work. Got burned by merge conflicts twice.
- Commit messages: use conventional commits (feat:, fix:, docs:, chore:)

## Communication
- mattlor hates emdashes. Use commas, periods, or rewrite.
- Keep Telegram messages under 3 paragraphs unless asked for detail.

Bad entries are vague. "Made an error" tells you nothing. "Assumed the file was UTF-8 but it was Latin-1, causing silent corruption" tells you exactly what to watch for.

4. Write Skill Descriptions Like Routing Logic

This comes from the OpenAI "Skills + Shell + Compaction" post, and it's one of the most underrated insights in the agent space right now.

Your skill descriptions are the model's decision boundary. They're not documentation for humans. They're routing logic for the AI. The model reads your skill description and decides: "Should I load this skill for the current task?" If the description is vague, the model guesses wrong. If it's precise, the model routes correctly.

The fix is simple. Include "Use when" and "Don't use when" blocks in every skill description. And add negative examples.

# SKILL.md - Image Generation

Generate images using Replicate's Flux model.

## Use when
- User asks to create, generate, or make an image
- User describes a visual scene they want rendered
- User says "draw", "illustrate", or "picture of"

## Don't use when
- User asks to edit or modify an existing image (use image-edit skill)
- User wants to analyze or describe an image (use vision skill)
- User asks for a screenshot (use browser skill)

Here's the other key pattern: templates and examples inside skills are basically free when unused. They only load when the skill gets triggered. So stop cramming everything into your system prompt. Move templates, examples, and detailed instructions into skills where they belong. Your system prompt should be lean. Your skills should be rich.

5. The Claude Skills Deck (33 Best Practices)

Anthropic published an official 33-page guide on building effective skills. You should read the whole thing, but here are the takeaways that matter most:

• Skills should be self-contained playbooks. Everything the agent needs to complete the task should be in the skill file. Don't make it hunt for context across multiple files.
• Include worked examples and templates. Show the agent what "good output" looks like. A single concrete example is worth a paragraph of abstract instructions.
• Version your skills alongside your agent. Skills are code. Treat them that way. Track changes, review diffs, roll back when something breaks.
• Test skills in isolation before deploying. Run the skill against test inputs. Does it produce the right output? Does it handle edge cases? Don't ship untested skills to production.
• Keep skill descriptions concrete and specific. "Handles email" is useless. "Composes and sends emails via Gmail API, supports attachments up to 25MB, formats HTML body with inline styles" is useful.

6. Co-Author a PRD With Your Agent

This is where things get interesting. Your agent isn't just a code monkey. It's a thinking partner. One of the highest-leverage things you can do is co-author Product Requirements Documents together.

Here's the workflow. You have a meeting, a call, a brainstorm. You come back with messy notes, a voice memo transcript, or just a stream of consciousness. You dump it on your agent and say: "Digest this into a PRD." It structures your chaos into sections, pulls out the decisions that were made, flags the open questions, and commits it to a repo.

Then the PRD becomes a living document. Every follow-up call, every new decision, every pivot gets folded in. Your agent updates the version, adds a changelog entry, and pushes to GitHub. Six months later, you have a complete history of how the project evolved from napkin sketch to shipped product.

Start a new project by telling your bot:

Create a new private repo called <project-name>. 
Here are my notes from the kickoff call:

<paste your notes, transcript, or stream of consciousness>

Digest this into a PRD with sections for Overview, Requirements, 
Architecture, Open Questions, and a Changelog. Commit and push it.

Your bot creates the repo, structures the PRD, and pushes it. Every follow-up call, you paste the new notes and say "update the PRD." Version bump, changelog entry, push. Done.

The real power move: paste a raw meeting transcript and tell your agent to extract decisions, action items, and open questions into the PRD. It turns a 45-minute rambling call into a structured document in about 90 seconds. I've been doing this with every client call and partnership discussion. The PRD becomes the single source of truth, and my agent maintains it for me.

7. Delegate With Sub-Agents

At some point, you'll hit a wall. Your agent is deep in a conversation about one thing, and you need it to do something else. Or you have a task that takes 10 minutes of compute but doesn't need your attention. Or you want to run three things in parallel.

That's what sub-agents are for. OpenClaw can spawn isolated sessions that run in the background, do their work, and report back when they're done. Think of them as employees you can spin up on demand.

Spawn a sub-agent to research competitor pricing 
and write a summary in ~/drive/research/competitors.md

That's a real message you can send. Your bot spawns an isolated session in the background, does the work, and pings you when it's finished. Meanwhile, your main conversation stays free for whatever you're working on.

When to use sub-agents

• Long-running research. "Go read these 10 URLs and summarize the key findings." Takes minutes, doesn't need your attention.
• Parallel workstreams. Spawn one agent to update the dashboard while another drafts the email. Both report back.
• Scheduled background work. Combine with cron jobs to run daily scans, weekly reports, or monitoring tasks in isolated sessions.
• Heavy PRD updates. "Digest this 30-minute meeting transcript into the PRD" can run in the background while you keep chatting.
• Code reviews and audits. "Review this codebase for security issues and file the results as GitHub issues."

The combination of PRDs (#6) and sub-agents (#7) is where things really click. Your PRD is the briefing document. Your sub-agent reads it, understands the project context, and can do meaningful work without you babysitting. You've gone from "assistant that answers questions" to "team that ships projects."

Go sharpen those claws. 🦞