Skip to main content

Overview

Adding content to Impeccable involves creating source files, building, testing, and committing. The build system automatically transforms your content into formats for all 4 providers (Cursor, Claude Code, Gemini CLI, Codex CLI).

Adding a Skill

Skills are reusable instruction sets that teach the AI how to perform specific tasks.

1. Create the Source File

2. Add Frontmatter and Content

Skills follow the Agent Skills specification:

3. Field Requirements

Required Fields:
  • name: Skill identifier (1-64 chars, lowercase, numbers, hyphens only)
  • description: What the skill provides (1-1024 chars)
Optional Fields:
  • license: License or attribution information
  • compatibility: Environment requirements (1-500 chars)
  • metadata: Arbitrary key-value pairs
  • allowed-tools (experimental): Pre-approved tools list

4. Writing Skill Instructions

Good skill instructions:
  • Focus on one domain: Don’t try to do too much
  • Be explicit: State what to do AND what NOT to do
  • Include context: Explain why certain approaches are preferred
  • Provide examples: Show concrete use cases
  • Define success: Make clear what “done” looks like
Example:

5. Build and Test

Test with at least one provider:
  1. Copy the relevant dist/ output to a test project
  2. Invoke the skill
  3. Verify it works as expected
  4. Test edge cases

6. Commit

Commit both source and generated files:

Adding a Command

Commands are quick prompts users can invoke directly.

1. Create the Source File

2. Add Frontmatter and Content

3. Field Requirements

Required Fields:
  • name: Command identifier
  • description: What the command does
Optional Fields:
  • args: Array of argument objects
    • name: Argument identifier
    • description: What it’s for
    • required: Boolean (defaults to false)

4. Writing Command Prompts

Good command prompts:
  • Work without substitution: Cursor doesn’t support arguments, so write prompts that work by appending user input
  • Use clear placeholders: {{argname}} gets transformed to provider-specific syntax
  • Provide context: Explain the task clearly
  • Be concise: Commands should be quick to invoke
Example:

5. Argument Transformation

Placeholders are transformed for each provider:
  • Cursor: No transformation (arguments appended to prompt)
  • Claude Code: {{argname}} kept as-is
  • Gemini: {{argname}} → {{args}} (single args string)
  • Codex: {{argname}} → $ARGNAME (uppercase)

6. Build and Test

Test with multiple providers if possible:
  1. Copy outputs to test projects
  2. Try with and without arguments
  3. Verify output quality
  4. Test edge cases (missing args, unusual inputs)

7. Commit

Commit both source and generated files:

Testing Checklist

  • Source file has valid YAML frontmatter
  • Description is clear and concise
  • Build completes without errors
  • Works in at least one provider
  • Prompt works without argument substitution (for Cursor)
  • Examples are accurate and helpful
  • Edge cases handled gracefully

Common Mistakes

YAML Formatting Errors

Frontmatter Delimiters

Description Length

Build Troubleshooting

YAML Parsing Errors

  • Check frontmatter indentation (YAML is indent-sensitive)
  • Ensure --- delimiters are on their own lines
  • Verify colons have spaces after them (key: value)

Output Doesn’t Match Expectations

  • Check the transformer function for your provider in scripts/lib/transformers/
  • Verify source file has correct frontmatter structure
  • Run bun run rebuild to ensure clean build

Provider Doesn’t Recognize Files

  • Check installation path for your provider
  • Verify file naming matches provider requirements
  • Consult provider’s documentation

Best Practices

Skill Best Practices

  1. One domain, one skill: Don’t combine unrelated concerns
  2. Clear instructions: Write for clarity, not cleverness
  3. Examples over explanation: Show, don’t just tell
  4. State constraints: What NOT to do is as important as what to do
  5. Test thoroughly: Try edge cases and unusual inputs

Command Best Practices

  1. Clear purpose: User should know exactly what it does
  2. Flexible design: Work with or without arguments
  3. Concise prompts: Commands should be quick to invoke
  4. Good defaults: Provide sensible behavior when args are missing
  5. Cross-provider testing: Verify works in multiple tools

Getting Help

Need help adding content?
  • Check Architecture for system design
  • See Build System for build details
  • Review existing skills/commands in source/ for examples
  • Open an issue on GitHub for specific questions