My daily workflow looks nothing like it did a year ago. A lot has landed in Claude Code recently. Skills replaced custom slash commands, subagents and plugins followed, and four days ago /goal shipped, which lets an agent run autonomously for hours or days against a completion condition. Cursor 3 came out with an agents-first interface and a cheap in-house model. MCP went from "interesting protocol" to how every tool plugs into every other tool.

The net effect is that I now run Claude Code as the primary engine and treat Cursor as the cockpit. Cursor is where I drop in when I want a GUI, design mode, or a real-time view of a diff landing. Most everything else, including the long-running stuff, lives in Claude Code.

Five patterns that stuck.

Pattern 1: Claude Code is the engine, Cursor is the cockpit

The biggest mindset shift was treating the two tools as different categories of thing rather than competitors.

Claude Code runs in the terminal with Opus 4.7 behind it, and it's built around the idea that you can describe an outcome and let it work. /goal and skills make it possible to run multi-hour tasks against verifiable end conditions, then codify the workflows you do over and over. That's the engine.

Cursor is where I go when I specifically need to see something. The new agents window is where I manage parallel work, but for the tight inline loops I still flip back to the editor window, where Tab predictions and Composer beat anything else. Design mode lives there too, which is where I end up when I'm chasing a UI tweak. With Composer 2 sitting at 50 cents per million input tokens, Cursor 3 also makes a cheap surface for parallel cloud agents on smaller tasks. The cloud agents are the ones I'll fire off before a meeting, expecting a PR to be waiting when I get back. That's the cockpit.

My rough heuristic now:

• One-sentence tasks I can walk away from for an hour go to Claude Code, usually with /goal.
• Anything I want to watch happen in my editor goes to Cursor.
• Repeatable workflows I've done more than twice get codified as a Claude Code skill, so it doesn't matter which surface I call them from.

A bonus trick that applies in both tools: plan with a smart slow model, execute with a fast cheap one. In Cursor 3, plan in plan mode with Opus 4.7, then switch to Composer 2 Fast to build. In Claude Code, draft the plan with the default Opus model and hand the execution off via /goal so a smaller verifier model does the per-turn checking. Saves real money and almost never costs you quality.

Pattern 2: One conventions file, two readers

Both tools support project-level instruction files, and as of Cursor 3 they both support skills as well. Claude Code reads CLAUDE.md at the repo root plus nested ones for subdirectories, with skills in .claude/skills/. Cursor reads from .cursor/rules/ and pulls skills from .cursor/skills/. Same primitives, two surfaces.

The mistake I made early was treating these as separate. Different rules in each file, drift between them, and inevitably one tool would produce code that violated rules the other knew about.

The fix is to write conventions once in a canonical file, then have both CLAUDE.md and your top-level Cursor rule reference it. Mine live at docs/conventions.md. One source of truth, two readers.

What goes in there: naming conventions, error handling patterns, the testing approach you actually use, libraries you prefer alongside libraries you've banned, PR structure expectations. And the one most people forget, feature flag conventions. If your team uses LaunchDarkly, this is the place to write down which flag types map to which use cases, your naming conventions, and the standard rollout cadence. Both agents will then default to writing flag-gated code correctly without you reminding them every time.

You can use these files for tone, too. A line still earning its keep at the bottom of my CLAUDE.md:

When you finish a non-trivial task, summarize what you did in the voice of a tired senior engineer who has seen it all.

Commit the file. Your teammates' agents inherit your conventions, and your sense of humor, for free.

Pattern 3: /goal for anything bigger than one conversation

This is the new one. Claude Code shipped /goal on May 12, 2026. Codex shipped its equivalent the same week. If you're not using it yet, this is the upgrade with the biggest leverage in years.

The premise is that you give Claude Code a completion condition instead of a list of steps. After each turn, a small verifier model checks whether the condition holds. If it doesn't, Claude takes another turn. If it does, the goal clears and control comes back to you. In practice this means handing off tasks that would have eaten a whole afternoon of back-and-forth, and getting a PR when you wake up.

What makes a good goal:

• One measurable end state. "All TypeScript errors resolved, all tests passing, PR opened against main" is a goal. "Make the auth flow better" is a wish.
• A roadmap or PRD to drive against. The pattern working best for me right now is to hand it a docs/roadmap.md with a checklist of tasks, then write the goal as "every task on the roadmap is checked off and verified." The verifier has something concrete to check.
• Explicit constraints for anything that must not change. /goal accepts up to 4,000 characters in the condition, so there's room to write "do not touch payments/" and "do not modify the public API surface."

A LaunchDarkly-shaped example that has earned its keep on my machine:

/goal Walk the release-checkout-redesign flag from 0% to 100% using
our standard rollout cadence in docs/conventions.md. After each ramp,
check error rate from the metrics MCP server. Stop and return to me
if any ramp shows error rate above baseline + 10%, or when the flag
is at 100% with three consecutive green ramps. Do not modify any code,
only the flag targeting.

That's a task I used to babysit for half a day. Now I run it while writing the next feature in Cursor.

Pattern 4: Skills for the workflows you do more than twice

The single most underused feature in Claude Code is skills. They replaced what used to be custom slash commands, they auto-invoke when the description matches, and they cost almost nothing in tokens until they actually load.

A skill is a folder at .claude/skills/<name>/ with a SKILL.md inside. The file has YAML frontmatter with a name and description, and a markdown body underneath. That's it. Supporting scripts, example templates, helper files are optional and all live in the same folder.

The mental flip that helped me: anything I've copy-pasted into Claude Code twice should be a skill. Not eventually. Today.

Skills that have earned their place in my repos:

• pr-prep. Runs the linter, runs the test suite, drafts a PR description against the convention in CLAUDE.md, and stops short of pushing.
• flag-rollout. The LaunchDarkly rollout playbook. Reads the cadence from docs/conventions.md, has access to the LaunchDarkly MCP server and the metrics MCP server, and walks a flag through staged ramps with verification between each. Same shape as the /goal example above, but invocable as /flag-rollout without retyping the condition.
• test-writer. Writes tests strictly using the conventions in the repo's testing doc. Vitest for unit and integration, Playwright for E2E, no Jest, no surprise mocks.
• project-context. A tiny per-repo skill that tells the agent which Jira board, which LaunchDarkly project, and which feature flag prefix this codebase maps to. Sounds trivial. It killed the entire class of "wait, which board are we looking at" questions every agent used to ask me.

Each one is maybe 30 lines of Markdown. The compounding effect shows up within a week.

One more distinction worth pinning down, because it tripped me up early. Rules versus skills. Rules are the what. They go into every conversation as ambient context. "We use TypeScript. Vitest for tests. No new ORMs without a discussion." Skills are the how. They're loaded on demand when the description matches. "Walk a LaunchDarkly flag through staged ramps with verification" is a skill. "Always wrap network calls in our retry helper" is a rule. Keep rules brief and ambient. Push the heavy procedural stuff into skills, where it costs nothing in tokens until the agent actually pulls it in.

A quick note on skills versus subagents, because the difference matters. A skill is inline. Its instructions load into the current conversation and shape how the main agent behaves. A subagent is a separate, isolated context that the main agent delegates to and gets a summary back from. Use skills for "do it this way." Use subagents for "go do this heavy thing and come back when you're done." Most people want a skill 90 percent of the time.

Pattern 5: MCP servers, configured once, available everywhere

MCP went from "interesting protocol" in 2025 to the standard way every tool talks to every other tool by May 2026. Both Claude Code and Cursor have first-class MCP support with effectively identical configuration semantics, so a server you set up in one is a five-minute job to mirror in the other.

The LaunchDarkly MCP server is a good example of why this matters. Same server. Same credentials. Same flag set. Accessible from either surface. In practice that means I can ask the agent to "wrap this checkout component in a flag called release-checkout-redesign, default off" while I'm in Cursor writing the component, then switch to Claude Code in the terminal and run the /flag-rollout skill against that same flag. One mental model across two tools.

A few things I've learned that aren't obvious from the docs:

1. Resist the urge to connect every server you've heard of. Both tools handle large MCP rosters better than they used to, but every active tool eats a slice of your context budget. Keep four to six servers active and rotate as projects change.
2. Configure the same set in both tools. It removes the "wait, which one has the GitHub MCP" friction and lets you move work between them without thinking.
3. MCP servers compose with skills. A skill can specify which MCP tools it's allowed to use via allowed-tools in the frontmatter. Scoping a skill to only the LaunchDarkly MCP server makes it physically incapable of touching anything else, which is much safer than relying on the model to behave.

Conclusion

The May 2026 stack, as I run it:

1. Claude Code as the engine, for /goal-driven long tasks, skills, and anything else that should run without supervision.
2. Cursor as the cockpit, for visual work, design mode, tight inline edit loops, and cheap parallel cloud agents.
3. A shared conventions file both tools read from, so they code the same way.
4. /goal for anything bigger than one conversation.
5. Skills for anything you've done more than twice.
6. MCP servers mirrored across both tools, kept to a tight set you actually use.

The shift this year is that the highest-leverage work isn't editor tricks anymore. It's setting up the agents to run without you and getting them to do the same thing the same way every time. The editor matters less every quarter. The skill library and the goals you can hand off are what compound.

If you've got skills or MCP setups I should steal, send them my way. You can find me on LinkedIn.