Skills and Slash Commands: Customizing Claude Code for Your Workflow
Making Claude Code Yours
Making Claude Code Yours
Out of the box, Claude Code is powerful. But the real leverage comes when you customize it for your specific workflow. Skills and slash commands are how you turn a general-purpose AI coding tool into your personal development environment.
Skills in Claude Code are reusable capabilities that you can invoke with slash commands. Think of them as saved workflows — predefined instructions that Claude Code follows when you trigger them. Instead of typing the same detailed prompt every time you want to create a component or review a PR, you define it once and invoke it with a simple command.
Understanding Slash Commands
Slash commands are the interface to skills. When you type /commit or /review-pr, you are invoking a skill that has predefined behavior. Some come built-in, and you can create your own.
The built-in slash commands include:
/help— Shows available commands and usage information/clear— Clears the conversation context/compact— Compacts the conversation to save context space/review-pr— Reviews a pull request/commit— Creates a git commit with a well-crafted message
These are useful starting points, but the real power is in customization.
Creating Custom Skills
Custom skills live in your project configuration and can be shared across your team. Here is how I set them up for my React and Next.js projects.
The Component Creator
One of my most-used custom workflows is component creation. In my projects, every component follows a specific structure — the component file, a types file, a test file, and an index barrel export. Instead of describing this every time, I use a consistent prompt pattern:
me: Create a new component called PricingCard in components/pricing/.
Follow the existing component structure in components/ui/.
Include TypeScript types, a test file, and barrel export.
The component should accept: title (string), price (number),
features (string[]), highlighted (boolean), onSelect callback.
Claude Code reads the existing component structure, matches the patterns, and creates all the files consistently. Every time. No drift from the conventions.
The PR Reviewer
When I invoke /review-pr, Claude Code does not just scan for syntax issues. It follows a structured review process:
- Reads the full diff
- Checks for type safety issues
- Looks for missing error handling
- Verifies test coverage for new code
- Checks for accessibility concerns in UI changes
- Flags performance implications (unnecessary re-renders, missing memoization)
- Reviews naming consistency with the existing codebase
This structured approach catches issues that a quick human review might miss, especially on Friday afternoon PRs.
The Migration Helper
Frontend projects constantly need migrations — updating a library, changing an API pattern, moving to a new convention. I have a workflow for this:
me: Search the codebase for all uses of the old useAPI hook pattern
(importing from hooks/useAPI). List every file, then migrate each
one to use TanStack Query with our queryClient from lib/queryClient.
Preserve error handling behavior. Run tests after each file.
The key here is "run tests after each file." This incremental approach means if something breaks, we know exactly which migration caused it.
CLAUDE.md: The Skill Amplifier
Skills become dramatically more effective when paired with a well-written CLAUDE.md file. This file tells Claude Code about your project's conventions, and skills can reference those conventions implicitly.
For example, if your CLAUDE.md specifies:
## Component Conventions
- All components use forwardRef
- Props interfaces are named [ComponentName]Props
- Default exports, not named exports
- Tests use React Testing Library, not Enzyme
- Test files are co-located: Component.test.tsx
Then every skill that creates or modifies components automatically follows these conventions. You do not need to repeat them in every prompt. The CLAUDE.md acts as persistent context that skills inherit.
Workflow Composition
The real power emerges when you compose workflows. Here is how I handle a complete feature implementation:
Phase 1: Scaffold
me: Create the feature structure for user-notifications.
We need: a NotificationBell component, a NotificationList component,
a NotificationItem component, a useNotifications hook that connects
to our WebSocket service, and types in types/notification.ts.
Scaffold all files with TODO comments for implementation.
Phase 2: Implement
me: Implement the useNotifications hook. It should connect to our
existing WebSocket service in services/websocket.ts, subscribe
to the 'notifications' channel, and expose: notifications array,
unreadCount, markAsRead function, markAllAsRead function.
The hook should handle reconnection and cleanup.
Phase 3: Wire Up
me: Wire up NotificationBell to show unreadCount from useNotifications.
Clicking it should toggle NotificationList. NotificationList renders
NotificationItem for each notification. Clicking an item calls
markAsRead and navigates to the notification's target URL.
Add keyboard navigation and ARIA attributes for accessibility.
Phase 4: Test
me: Write tests for all notification components and the useNotifications
hook. Mock the WebSocket service. Test: initial load, receiving new
notification, marking as read, mark all as read, empty state,
error state, keyboard navigation.
Phase 5: Review
me: Review all the notification feature code we just wrote. Check for:
memory leaks in the WebSocket subscription, missing error boundaries,
accessibility issues, type safety, and edge cases.
Each phase builds on the previous one, and Claude Code maintains context throughout. This is not five separate tasks — it is one continuous workflow where each phase's output informs the next.
Team Workflows
When I work with teams as a fractional architect, I help them set up shared Claude Code configurations. The key files are:
Project-level CLAUDE.md — Conventions, patterns, and guidelines that everyone follows.
Shared skill definitions — Common workflows that the team uses, ensuring consistency regardless of who runs them.
The benefit is standardization without rigidity. Every developer can still use Claude Code their own way, but when they invoke shared skills, the output follows the team's conventions.
Tips for Effective Skill Usage
After months of using skills daily, here is what I have learned:
Be specific about file locations. "Create a component" is vague. "Create a component in components/dashboard/" tells Claude Code exactly where to look for patterns and where to put the output.
Reference existing files. "Follow the pattern in UserCard.tsx" is more effective than describing the pattern from scratch. Claude Code reads the reference file and matches its style.
Include verification steps. End your workflows with "run the build" or "run tests." This catches issues before you even look at the code.
Iterate on your prompts. The first version of a skill is never perfect. Refine it over a few uses until it consistently produces the output you want.
Keep skills focused. A skill that does one thing well is better than a skill that tries to do everything. Compose focused skills into larger workflows rather than creating monolithic instructions.
The developers who customize their tools outperform those who use them out of the box. Skills and slash commands are how you make Claude Code work for your specific projects, your specific patterns, and your specific standards. Invest the time to set them up, and they pay dividends on every task.