Claude Code CLI Skills That 10x Your Development Workflow

What We Will Build

By the end of this workshop, you will have a fully configured Claude Code CLI environment with three concrete pieces in place: a CLAUDE.md that enforces your project conventions automatically, a custom slash command your whole team can use, and an MCP server connection that eliminates at least one external tool from your daily workflow.

Let me show you a pattern I use in every project — and the setup that took my correction cycles from 3+ per task down to nearly zero.

Prerequisites

• Claude Code CLI installed and authenticated (claude --version should return a valid response)
• A project repository you actively work in
• Basic familiarity with your terminal and markdown

Step 1: Create Your CLAUDE.md

This is the single highest-leverage file in your repository. It sits at your project root and acts as persistent instructions that Claude Code reads on every invocation.

Here is the minimal setup to get this working:

# Project Instructions

## Architecture
- Kotlin Multiplatform project targeting Android and iOS
- Clean Architecture with UseCases in the domain layer

## Code Style
- Follow Kotlin coding conventions
- All public APIs must have KDoc documentation
- Use Result<T> for error handling, never raw exceptions

## Testing
- Unit tests required for all UseCases
- Use MockK for mocking, Turbine for Flow testing

## Forbidden
- No direct database access from ViewModels
- No platform-specific code in shared modules

Adapt each section to your stack. The key sections are Architecture, Code Style, Testing, and Forbidden. That last one matters more than you think — explicitly telling the model what not to do cuts rework dramatically.

Step 2: Build a Custom Slash Command

Built-in commands like /commit are useful, but project-specific commands are the real multiplier. Create a markdown file inside .claude/commands/ in your repo:

<!-- .claude/commands/feature-scaffold.md -->
Generate the following files for a new feature called "$ARGUMENTS":

1. A ViewModel in `feature/$ARGUMENTS/presentation/`
2. A UseCase in `feature/$ARGUMENTS/domain/`
3. A Repository interface in `feature/$ARGUMENTS/domain/`
4. A RepositoryImpl in `feature/$ARGUMENTS/data/`
5. Unit tests for the UseCase using MockK

Follow the architecture rules defined in CLAUDE.md.

Now every team member runs /feature-scaffold UserProfile and gets consistent, convention-compliant scaffolding. No more 45-minute boilerplate sessions — this runs in under five minutes.

Step 3: Connect an MCP Server

Model Context Protocol servers let Claude Code talk to external tools directly. Configure them in .claude/settings.json at the project level:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://localhost:5432/mydb"
      }
    }
  }
}

This replaces your separate database GUI. You query schemas, explore data, and debug — all without leaving the terminal. Pick your most-used external tool and connect it first. The compound gain from eliminating that single context switch justifies the setup time within days.

Gotchas and Common Mistakes

Here is the gotcha that will save you hours:

• Vague CLAUDE.md rules get vague results. Writing "use clean code" means nothing. Write "all public functions must have KDoc with @param and @return tags." Specificity is everything.
• Forgetting to commit .claude/commands/ to version control. Your custom slash commands only help the team if they are in the repo. Add them, push them.
• Overloading a single slash command. One command should do one thing. If your prompt template exceeds 30 lines, split it into two commands.
• Not scoping MCP server permissions. The docs do not mention this, but database MCP servers have full query access by default. Use a read-only database user for safety.
• Skipping the Forbidden section in CLAUDE.md. Telling the model what not to do is as valuable as telling it what to do. Without explicit boundaries, you will chase convention violations across pull requests.

Conclusion

Three things to do right now:

1. Create a CLAUDE.md in your project root today. Architecture rules, code style, testing expectations, and forbidden patterns. This single file delivers the highest ROI of any configuration.
2. Add one custom slash command in .claude/commands/ for your team's most repeated task — feature scaffolding, PR descriptions, or changelog generation.
3. Wire up one MCP server for the external tool you context-switch to most often.

Teams I work with who adopt these patterns do not just ship faster — they maintain higher consistency and spend their cognitive budget on architecture decisions instead of mechanical tasks. That is where the real leverage lives.