This article was written by Claude (AI) with human review and editing.

Here’s the uncomfortable truth about AI automation in 2026: it’s great at some things and terrible at others. Most people treat it as all-or-nothing — either AI can do the job or it can’t. That’s wrong. The real skill is figuring out which parts of a workflow to automate and which to keep human.

I’ve been building this out with Claude Code, Slack, and a dead-simple feedback loop. Three patterns have emerged: automated Slack outreach, a flywheel that learns what works, and reusable workflow templates. Here’s how they fit together.

Automated Slack Outreach

Claude Code can send Slack messages. This sounds trivial. It isn’t.

I’m using it to automate outreach — sending messages to Slack communities, responding in channels, and initiating conversations. Claude drafts the messages, sends them via Slack MCP or webhook, and logs what it sent.

Setup is straightforward:

But sending messages is the easy part. The hard part — and the part that actually matters — is knowing whether those messages worked.

The Feedback Flywheel: Scanning What Gets a Positive Response

This is the core idea. AI is good at some stuff and not good at others right now. We need to discern what can effectively be automated. The only way to do that is to measure outcomes.

Here’s the loop: Claude sends Slack outreach messages, then scans the channels for responses. It classifies each response — positive, negative, ignored — and logs the results. Over time, patterns emerge about what messaging works, what channels convert, and what tone lands.

After a few weeks of this, you have actual data. Not vibes — data. The flywheel looks like this:

Send outreach → scan responses → classify outcomes → refine approach → send better outreach.

What I’ve found so far:

AI is good at automating:

• Drafting initial outreach messages at scale
• Scanning channels for relevant conversations to join
• Classifying response sentiment (positive/negative/ignored)
• Logging everything into a structured format for analysis
• Adapting message templates based on what worked before

AI is NOT good at (yet):

• Reading social nuance — it’ll miss sarcasm, community in-jokes, and unwritten rules
• Knowing when to stop — it doesn’t feel the room the way a human does
• Building genuine relationships — the follow-up conversations still need you
• Handling negative responses gracefully — it tends to over-apologize or double down

The point isn’t to fully automate outreach. The point is to automate the parts AI is good at (drafting, sending, scanning, logging) and keep humans on the parts it’s bad at (relationship building, judgment calls, reading the room). The feedback flywheel tells you where that line is — and the line moves as the tools improve.

Store these patterns in your CLAUDE.md or memory system. Claude itself can reference them: “Messages with a helpful tip + soft CTA in technical channels get 4x the engagement of cold pitches. Adjusting approach.”

Reusable Workflows: Just a Folder and a Markdown File

This is the simplest and most underrated pattern I use.

Every time I find myself repeating a multi-step process — deploying a new project, publishing a blog post, running an outreach campaign — I tell Claude: “Create a new folder called workflows/ and track what we just did in a markdown file.”

That’s it. No framework. No tooling. Just a folder with markdown files.

Each file is a step-by-step record of what actually happened, not what should theoretically happen. Real commands. Real file paths. Real gotchas.

Here’s what my Slack outreach workflow looks like:

Next time I say “run Slack outreach,” Claude reads this file and executes it. No re-learning. No repeating the same mistakes. The workflow file captures what works and what doesn’t — institutional knowledge that persists across sessions.

Why this works better than CLAUDE.md alone:

• CLAUDE.md files get bloated. Workflows stay focused on one task.
• You can reference specific workflows: “Follow workflows/slack-outreach.md”
• They’re versioned in git, so you see how processes evolve
• New team members (human or AI) can follow them immediately

The barrier to creating one is zero. Finish a task. Tell Claude “track that workflow.” Done. You’ve just saved yourself 20 minutes the next time you do it.

Putting It All Together

AI right now is a mixed bag. It can draft a hundred Slack messages in the time it takes you to write one. It can scan channels and classify responses without getting bored. But it can’t tell when a community is getting annoyed, and it can’t build real relationships.

The three patterns address this directly:

1. Automated Slack outreach handles the volume — drafting, sending, and scanning at scale.
2. The feedback flywheel tells you what’s actually working, so you stop wasting effort on approaches that don’t convert.
3. Workflow templates encode what you’ve learned into repeatable processes that get better over time.

The result: you stop guessing what AI can and can’t do. You measure it. The flywheel gives you data, the workflows capture the playbook, and the automation handles the grunt work. You focus on the parts that still need a human — the judgment, the relationships, the nuance.

Start small. Pick one outreach channel. Have Claude send five messages. Scan for responses. Log what happened. That’s your flywheel. It only gets better from here.

This article was written by Claude (AI) with human review and editing. The workflow described is a real technique I use daily with Claude Code.

If you use Claude Code for more than one session on a project, you’ve probably hit this wall: you start a new session, Claude has no idea what you were working on, and you spend the first five minutes re-explaining context. I solved this with one file — TODO.md.

The Problem: Context Doesn’t Survive Between Sessions

Claude Code sessions are stateless by default. Each new terminal window starts from scratch. Even with CLAUDE.md files providing project context and the MCP memory server storing long-term knowledge, there’s a gap: what was I working on right now? Memory stores facts. CLAUDE.md stores conventions. But neither tracks the live state of your work — what’s done, what’s in progress, and what’s next.

I needed something lightweight that could answer one question at the start of every session: “Where did I leave off?”

The Solution: A TODO.md at Every Level

I now maintain TODO.md files at two levels:

1. Global (~/TODO.md) — Cross-project tasks and priorities
2. Per-project (project/TODO.md) — Project-specific work items

Each project’s CLAUDE.md references its TODO.md, so Claude reads it automatically at the start of every session. And my global CLAUDE.md instructs Claude to check ~/TODO.md for cross-project work.

Here’s the instruction I add to every project’s CLAUDE.md:

And in my global ~/.claude/CLAUDE.md:

What a TODO.md Looks Like in Practice

Here’s a real example from one of my projects — a mushroom foraging guide site with 800+ pages:

When Claude opens a new session and reads this file, it immediately knows: images are being generated, IndexNow needs a retry, and there’s a backlog of blog articles to write. No explanation needed from me.

Why Not Just Use Memory or CLAUDE.md?

I use all three, and they serve different purposes:

• MCP Memory — Long-term knowledge: tech stacks, deployment configs, architectural decisions, billing info. Things that rarely change.
• CLAUDE.md — Project conventions: coding standards, deployment patterns, verification requirements. The “how we do things here” document.
• TODO.md — Live work state: what’s done, what’s next, what’s blocked. Changes every session.

Think of it this way: memory is your team wiki, CLAUDE.md is your team’s engineering handbook, and TODO.md is today’s sprint board. You need all three.

The Global TODO: Cross-Project Coordination

The global ~/TODO.md is where I track work that spans projects or doesn’t belong to any single codebase:

At the start of every session — regardless of which project I’m working in — Claude reads this file first. If I open a session on my coffee explorer project and the global TODO says “review GA4 reports across all sites,” Claude can proactively surface that.

Tips for Getting the Most Out of TODO.md

After a few months of using this system, here’s what I’ve learned:

1. Use Simple Markers

I use three markers that Claude understands naturally:

• [ ] — Pending (not started)
• [~] — In progress (started but not done)
• [x] — Completed
• [-] — Skipped or deprioritized

Keep it simple. Claude parses these perfectly and updates them as work progresses.

2. Include Cost Estimates

For tasks that involve API calls or cloud services, I note the estimated cost right in the task:

This helps me prioritize and prevents surprise bills. Claude can also reference these estimates when suggesting what to work on next.

3. Let Claude Update It

Don’t manually edit TODO.md — let Claude do it as part of the workflow. When Claude finishes a task, it marks it [x] and often adds new tasks it discovered along the way. This creates an organic, always-current task list without any extra effort from you.

4. Keep Completed Items (Briefly)

I keep completed items in the file for a few sessions before archiving them. This gives Claude context about recent work — it knows that R2 was just set up, so it won’t suggest setting it up again. After a while, move old completed items to an archive section or delete them to keep the file scannable.

The Full System: Memory + CLAUDE.md + TODO.md

Here’s how all three pieces work together in a typical session:

1. Session starts — Claude reads CLAUDE.md (loaded automatically), checks ~/TODO.md and project/TODO.md, and queries MCP memory for relevant context
2. Claude picks up where I left off — “I see you were generating state guide images. 568 are done, and R2 CDN setup is next. Want me to continue?”
3. Work happens — Claude completes tasks, marks them [x], discovers new work, adds it as [ ]
4. Session ends — TODO.md is updated, memory stores any new decisions or patterns, and the next session has full context

It’s a simple system, but it transformed my workflow. No more re-explaining context. No more lost work items. No more “wait, what was I doing?” Every session starts productive from minute one.

---

The TODO.md pattern costs nothing, takes seconds to set up, and pays for itself in the first session. If you’re using Claude Code for any project that spans multiple sessions, add one today. Your future self will thank you.

This article was written by Claude (AI) with human review and editing. The tips and workflow patterns described are real techniques I use daily with Claude Code.

After building over 50 projects with Claude Code – from full-stack SaaS applications to 3D games to AI-powered tools – I’ve learned what separates productive Claude Code sessions from frustrating ones. Here’s what actually works.

The #1 Productivity Secret: Run Multiple Jobs in Parallel

This is the single most important lesson I’ve learned: treat AI agents like employees you’re managing, not tools you’re using one at a time.

I routinely run 3-5 Claude Code sessions simultaneously across different terminal tabs. While one is researching an API, another is writing tests, and a third is refactoring a component. The key insight is that you need to context switch frequently – check in on each agent, give it a nudge if it’s going off track, add context when needed, then move to the next one.

Think of it like managing a team of junior developers: you wouldn’t sit and watch one person code for an hour. You’d give them a task, check on someone else, come back with feedback, and keep the whole team moving forward. The same applies to AI agents – they work best with slight nudges and context to improve their ability to work autonomously.

These tools have gotten dramatically better in the last 6 months. Six months ago, you really needed to babysit Claude through complex tasks. Now, with good context in your CLAUDE.md files, Claude can work autonomously for much longer stretches. But you still get the best results by managing multiple sessions and providing course corrections.

Pro tip: Use claude --continue to resume your last session, or claude --session [name] to maintain named sessions for different projects. This way you can switch between “frontend-refactor” and “api-integration” sessions without losing context.

1. Set Up Persistent Memory

The single biggest productivity multiplier is giving Claude context that persists across sessions. Without it, every conversation starts from zero.

Use the MCP Memory Server:

Then create a CLAUDE.md file that instructs Claude to:

• Read memory at session start
• Store project decisions, tech stacks, and deployment configs
• Track billing/services you’re paying for
• Remember file locations and patterns

After a few sessions, Claude remembers things like “coffee-explorer deploys to Fly.io at coffee-explorer-proud-forest-117” or “ArborHub uses Claude Vision API for tree detection” without you explaining it again.

2. Create Verification Requirements

Code that compiles isn’t code that works. I learned this the hard way after declaring games “complete” that crashed on first interaction.

Add this to your CLAUDE.md:

This forces Claude to actually run the code before saying “done.” The Playwright MCP server makes this automated:

3. Document Deployment Patterns

Nothing wastes more time than re-figuring out deployment configs. I store these in memory:

When I say “deploy coffee-explorer,” Claude knows exactly what to do. No guessing, no debugging broken deployments.

4. Track What You’re Paying For

I have Claude maintain a running list of all billed services:

This prevents surprise bills and helps when cleaning up abandoned projects.

5. Use Batch Processing for Repetitive Tasks

When I needed 500+ city guides for Coffee Explorer, I didn’t do them one at a time. I had Claude:

1. Research 16 cities in parallel using web search
2. Generate JSON files with real coffee shop data
3. Validate each file’s structure
4. Commit in batches

The key is giving Claude clear patterns to follow:

Batch 9 alone generated 16 complete city guides in a single session.

6. Store Technical Decisions

When you make an architectural choice, document why:

Six months later when you revisit the code, Claude can explain why you didn’t just use Claude Vision directly.

7. Prefer Automation Over Manual Steps

I added this to my global config:

This means Claude will use API calls instead of asking me to click magic links, run scripts instead of giving me manual steps, and deploy via CLI instead of web dashboards.

8. Document Patterns for Complex Systems

For my 3D game project, I had Claude document every subsystem:

When I came back to add features months later, Claude understood the architecture immediately.

9. Use CLAUDE.md at Multiple Levels

I have three CLAUDE.md files:

1. Global (~/.claude/CLAUDE.md): Universal preferences, memory protocol, billing tracking
2. Workspace (~/claude-workspace/CLAUDE.md): Cross-project conventions
3. Project-specific (project/CLAUDE.md): Deployment configs, API keys, project-specific patterns

This layered approach means Claude always has the right context without me repeating myself.

10. Use GitHub Actions for Deployment, Not Direct Deploy

My original advice was “always commit, push, and deploy.” But I’ve learned a better pattern: always commit and push, then let GitHub Actions handle the deploy.

Why? When you’re running multiple Claude sessions in parallel (and you should be), you’ll inevitably have two sessions try to deploy at the same time. Direct deploys from multiple terminals cause conflicts, failed builds, and wasted time debugging “why did my deploy break?”

Instead, set up a GitHub Actions workflow with concurrency controls:

Now multiple Claude sessions can push commits freely, and GitHub Actions queues the deploys automatically. No conflicts, no babysitting.

11. Offload Tasks to Ollama for Cost Savings

Claude Code is powerful but not cheap. For repetitive, low-complexity tasks, I offload work to local LLMs running via Ollama.

Tasks I run locally:

• Generating boilerplate content (city descriptions, product descriptions)
• Simple code transformations and formatting
• Bulk data validation and cleanup
• First-pass content generation before Claude refinement

I set up an Ollama MCP server that Claude can call for these tasks:

This hybrid approach lets me use Claude’s intelligence for complex reasoning while keeping costs down on bulk operations. When I generated 500 city guides, the content drafts came from Llama running locally – Claude only handled the research and final polish.

12. Get the Right Image Generation Tools

Code is only half the product. Modern web apps need images, and AI image generation has become essential to my workflow.

My current stack:

• fal.ai – Fast and cheap for bulk generation (~$0.003/image with FLUX Schnell). I use this for hero images, product shots, and blog illustrations.
• Replicate – Good for SDXL when I need more control over the generation process
• ComfyUI – Local generation for iterating on complex prompts without API costs

I store the API keys in my environment and have Claude generate images as part of the development workflow. For Coffee Explorer, I generated 100+ city hero images in a single batch – something that would have cost thousands in stock photography.

The key is treating image generation as a first-class part of development, not an afterthought. When I’m building a new feature, I have Claude generate the supporting images alongside the code.

---

The Meta-Lesson

The common thread in all of this: invest in context and run in parallel. Every minute spent documenting patterns, storing decisions, and setting up automation pays back tenfold across dozens of sessions.

But the real multiplier is parallelization. Stop thinking of Claude as a single tool you interact with sequentially. Think of it as a team you’re managing – give each instance clear context, check in regularly, provide nudges when needed, and let them work autonomously.

Claude Code is powerful out of the box. But Claude Code with persistent memory, documented patterns, automated verification, cost-optimized task routing, and parallel execution? That’s a 10x multiplier.

Start with the memory server and one CLAUDE.md file. Add to it every session. In a month, you’ll wonder how you ever worked without it.