Back to blog

Six Claude Code setups that cut repetitive prompting

Store project rules, slash commands, MCP servers, subagents, plugins, and review steps in Claude Code so you do not repeat instructions in every session.


Repeating build commands, linter rules, and architecture rules in every prompt slows down your work. Move that fixed context into repository files and tool integrations once. Your prompt can then describe only the task in front of you.

Save project rules once with #

Press # inside Claude Code to save a rule directly to CLAUDE.md. CLAUDE.md holds instructions that Claude Code loads at the start of every session. Store rules for one repository in ./CLAUDE.md so the team shares them through version control. Store personal rules that apply across all repositories in ~/.claude/CLAUDE.md.

# Project rules

- Run `npm test` after any route or schema change.
- Keep SQL queries inside `src/db/`, never inside UI components.

One rule list replaces the same reminder across ten chat threads. When a project rule changes, update CLAUDE.md in the same commit that changes the code.

Build slash commands for recurring tasks

Save Markdown prompt templates in .claude/commands/ to turn recurring tasks into slash commands. Each file creates a command that you run with /name. Subfolders inside .claude/commands/ group related commands, and $ARGUMENTS passes inputs such as a file path or a route name.

Review the endpoint in `$ARGUMENTS` against `eslint.config.mjs`.
Check input validation, status codes, and error responses.
List failing checks before proposing edits.

Save that template at .claude/commands/review-endpoint.md, then run /review-endpoint src/routes/orders.ts. You stop typing the same linter and endpoint instructions every day.

Connect MCP servers for live documentation and tools

Connect external tools through the Model Context Protocol, known as MCP, so Claude Code reads live data instead of stale training memory. You configure these servers through Claude Code MCP. Four common servers cover different parts of a workflow:

  • Context7 fetches current library documentation so the model uses today’s API instead of an outdated training example.
  • Supabase inspects database schemas and runs migrations directly against your project.
  • Playwright or Chrome DevTools drives a browser to check rendered pages, network requests, and console errors.
  • Stripe or Vercel reads payment state and deployment logs so you do not copy logs from dashboards by hand.

Live documentation and real tool output prevent the model from calling methods that do not exist in your installed dependencies.

Run subagents in parallel with concrete jobs

Delegate separate tasks to subagents that run in parallel. Each subagent runs in its own context window, so its file reads and test output stay out of your main session.

Give each subagent a concrete job instead of an invented job title. Ask one subagent to optimize a slow query, another to update API documentation, and a third to verify UI states in a browser. A concrete task gives the subagent a clear stopping point, while a persona such as “Senior Backend Architect” does not.

Package the setup as a plugin

Bundle your slash commands, subagents, and MCP server configuration into one plugin. When you start a new repository, install the full setup with one command instead of copying hidden configuration files by hand.

Versioned plugins also keep a team on the same setup. When someone updates a review command or adds an MCP server, every developer receives that change on the next install.

Write the specification first and review in a fresh session

Write the specification before you ask for code. Break large tasks into small pieces as I described in AI-assisted coding needs smaller loops. When a requirement is still unclear, use Plan Mode so Claude Code asks questions before it edits any file.

Before you ship, open a fresh session to inspect git diff, the line-by-line record of what changed. Ask that new session to check specifically for security bugs, performance regressions, and missing error handling. The session that wrote the code remembers its own intent and often overlooks mistakes it justified earlier.

Fast code that breaks in production is not faster.