You've set up SuperClawd. You've created a workspace. Now comes the important part: writing skills that actually work.

Good skills make AI output consistent and high-quality. Bad skills get ignored or cause confusion. This guide shows you how to write skills that deliver results.

The Anatomy of an Effective Skill

Every effective skill has these characteristics:

  1. Focused - One topic, one purpose
  2. Actionable - Clear instructions, not vague guidelines
  3. Specific - Concrete examples, not abstract principles
  4. Concise - Says what's needed, nothing more

Let's break down each one.

Principle 1: Keep Skills Focused

The Problem with Kitchen Sink Skills

It's tempting to put everything in one big skill:

MARKDOWN
# Coding Standards

- Use TypeScript
- Write tests
- Handle errors
- Use React hooks
- Follow REST conventions
- Validate input
- Document functions
- Use meaningful names
- Keep functions small
- ... (500 more lines)

This doesn't work. When everything is in one skill:

  • It loads when any part might be relevant (token waste)
  • Important instructions get buried
  • Updates affect unrelated areas
  • It's hard to maintain

The Solution: One Topic Per Skill

Split into focused skills:

├── TypeScript Standards
├── Testing Guidelines
├── Error Handling
├── React Patterns
├── API Design
├── Input Validation
├── Documentation Standards
└── Naming Conventions

Each skill loads only when relevant. Each is easy to maintain and update.

How to Decide Scope

Ask yourself: "Would this skill ever apply without the rest?"

If you're writing React components, you need React patterns but maybe not API design. If you're writing tests, you need testing guidelines but maybe not documentation standards.

If two topics always go together, combine them. If they can apply separately, split them.

Principle 2: Make Instructions Actionable

Vague vs. Actionable

Vague (ineffective):

MARKDOWN
- Use good naming conventions
- Handle errors appropriately
- Write clean code

Actionable (effective):

MARKDOWN
- Use camelCase for variables and functions
- Use PascalCase for classes and components
- Wrap async operations in try/catch
- Return error objects instead of throwing in utility functions
- Keep functions under 30 lines
- Extract repeated code into named functions

The Test: Can You Verify It?

For each instruction, ask: "Could I check if this was followed?"

  • "Use good names" → Can't verify (what's "good"?)
  • "Use camelCase for functions" → Can verify (is it camelCase or not?)

If you can't verify it, the AI can't reliably follow it.

Use Imperative Mood

Write instructions as commands:

Yes:

  • "Use explicit return types"
  • "Validate all user input"
  • "Include error messages in exceptions"

No:

  • "You should consider using explicit return types"
  • "It would be good to validate input"
  • "Error messages are helpful"

Direct commands are clearer and more likely to be followed.

Principle 3: Be Specific with Examples

Abstract vs. Specific

Abstract (less effective):

MARKDOWN
Use proper error handling in async functions.

Specific (more effective):

MARKDOWN
Use proper error handling in async functions:

// Good
async function fetchUser(id: string): Promise<User> {
  try {
    const response = await api.get(`/users/${id}`);
    return response.data;
  } catch (error) {
    logger.error('Failed to fetch user', { id, error });
    throw new UserNotFoundError(id);
  }
}

// Bad - don't do this
async function fetchUser(id: string) {
  const response = await api.get(`/users/${id}`);
  return response.data;
  // No error handling!
}

When to Include Examples

Include examples when:

  • The instruction could be interpreted multiple ways
  • You're introducing a pattern the AI might not default to
  • The correct approach isn't obvious
  • You want to show good vs. bad

Good vs. Bad Examples

Showing what NOT to do is as important as showing what to do:

MARKDOWN
## Component Props

// Good - interface with explicit types
interface ButtonProps {
  label: string;
  onClick: () => void;
  disabled?: boolean;
}

// Bad - inline types
function Button({ label, onClick, disabled }: { label: string; onClick: () => void; disabled?: boolean }) {
  // ...
}

// Bad - any types
function Button(props: any) {
  // ...
}

Principle 4: Keep It Concise

The Token Tax

Every word in your skill consumes tokens when loaded. Verbose skills cost more and dilute important instructions.

Before and After

Verbose (wasteful):

MARKDOWN
When you are writing TypeScript code, it is very important that you remember to always use explicit return types on your functions. This helps with code readability and makes it easier for other developers to understand what the function returns. It also helps catch bugs early because TypeScript will warn you if you try to return the wrong type.

Concise (effective):

MARKDOWN
Always use explicit return types on functions:

// Good
function getUser(id: string): User | null { ... }

// Bad
function getUser(id: string) { ... }

Same instruction, fraction of the tokens.

Cut the Fluff

Remove:

  • Explanations of why (unless critical)
  • Encouragement ("Great job following these!")
  • Redundant phrases ("Remember to...", "Make sure to...", "Always ensure that...")
  • Multiple ways of saying the same thing

Keep:

  • The instruction itself
  • Examples where helpful
  • Edge cases that matter

Common Mistakes to Avoid

Mistake 1: Too Many Conditionals

Problematic:

MARKDOWN
If you're writing a React component and it's a form component, use controlled inputs, but if it's a display component, you can use uncontrolled inputs, unless the display component needs to track focus state, in which case...

AI struggles with complex conditional logic. Simplify:

Better:

MARKDOWN
## Form Components
Use controlled inputs with useState or useForm.

## Display Components
Use uncontrolled inputs with refs when no state tracking needed.

Mistake 2: Contradictory Instructions

Problematic:

MARKDOWN
- Keep functions small and focused
- Include comprehensive error handling in every function
- Add detailed logging for debugging
- Keep functions under 20 lines

These conflict. A function with comprehensive error handling and detailed logging can't be 20 lines.

Better: Prioritize and be realistic:

MARKDOWN
- Keep functions under 30 lines for logic, excluding error handling boilerplate
- Extract error handling into wrapper utilities when possible
- Log at entry and exit points of public functions

Mistake 3: Framework-Specific Assumptions

Problematic:

MARKDOWN
Use the useQuery hook for data fetching.

What if the project uses SWR? Or vanilla fetch? Or Axios?

Better:

MARKDOWN
Use the project's established data fetching pattern:
- If using React Query: useQuery hook
- If using SWR: useSWR hook
- If using fetch: custom hooks in /hooks/api/

Or, create separate skills for different tech stacks.

Mistake 4: Outdated Information

Skills aren't set-and-forget. Review them periodically for:

  • Deprecated patterns
  • New best practices
  • Changed team conventions
  • Feedback from code reviews

Set a reminder to audit skills quarterly.

Skill Templates

Template: Language Standards

MARKDOWN
# [Language] Standards

## Types
- [Type system rules]
- [Preferred patterns]

## Naming
- [Naming conventions by construct type]

## Structure
- [File organization]
- [Import ordering]

## Patterns to Use
- [Pattern 1 with example]
- [Pattern 2 with example]

## Anti-patterns to Avoid
- [Anti-pattern 1 with example of what not to do]
- [Anti-pattern 2 with example of what not to do]

Template: Framework Patterns

MARKDOWN
# [Framework] Patterns

## Component Structure
[Standard structure with example]

## State Management
[Preferred approach with example]

## Common Patterns
### [Pattern Name]
[Description and example]

## Avoid
- [Thing to avoid with why in 1 line]

Template: Process Guidelines

MARKDOWN
# [Process Name] Guidelines

## When to Apply
[Clear criteria for when this applies]

## Steps
1. [Step with detail]
2. [Step with detail]
3. [Step with detail]

## Checklist
- [ ] [Checkable item]
- [ ] [Checkable item]

## Examples
### Good
[Example of good execution]

### Needs Improvement
[Example of common mistakes]

Testing Your Skills

After writing a skill, test it:

  1. Trigger relevant scenarios - Ask the AI to do tasks where this skill applies
  2. Check output - Does it follow your instructions?
  3. Try edge cases - Does it handle variations correctly?
  4. Compare with/without - Is the skill making a difference?

If the AI isn't following a skill:

  • Is the instruction clear enough?
  • Are there conflicting instructions?
  • Is the skill being loaded?

Iterating on Skills

Skills improve over time. Use this feedback loop:

  1. Monitor code reviews - What issues still appear?
  2. Update skills - Add rules for recurring issues
  3. Prune skills - Remove instructions that aren't needed
  4. Test changes - Verify updates work as expected

The best skills evolve from real-world feedback, not theoretical ideals.

Summary

Writing effective AI skills:

PrincipleKey Action
FocusedOne topic per skill
ActionableVerifiable instructions
SpecificConcrete examples
ConciseCut the fluff

Start with the 10 essential skills, customize them for your team, and iterate based on results.


Ready to create your skills? Set up your SuperClawd workspace and start writing skills that work.

Pro tip: Use coupon code WELCOME in your billing settings to get free credits when you sign up!