creating-continue-packages
About
This skill helps developers create Continue rules by providing the required structure and syntax. It covers essential elements like the mandatory name field, alwaysApply semantics, and pattern matching with globs or regex. Use it when writing rules in markdown format with optional YAML frontmatter for context-aware coding assistance.
Quick Install
Claude Code
Recommended/plugin add https://github.com/pr-pm/prpmgit clone https://github.com/pr-pm/prpm.git ~/.claude/skills/creating-continue-packagesCopy and paste this command in Claude Code to install this skill
Documentation
Creating Continue Packages
Overview
Continue uses markdown files with YAML frontmatter in .continuerules/*.md or YAML configuration in config.yaml. Rules are context-aware using glob patterns, regex matching, or always-applied globally.
CRITICAL: The name field is REQUIRED in frontmatter (unlike other formats where it's optional).
Quick Reference
Required Frontmatter
---
name: Rule display name (REQUIRED)
---
Optional Frontmatter
description: Description of when rule should be used
globs: "**/*.{ts,tsx}" # String or array
regex: "^import .* from '.*';$" # String or array
alwaysApply: true # true, false, or undefined
version: "1.0.0"
schema: "v1"
AlwaysApply Semantics
| Value | Behavior |
|---|---|
true | Always included, regardless of context |
false | Included if globs match OR agent decides based on description |
undefined (default) | Included if no globs exist OR globs match |
Creating Rules with Globs
Glob patterns match file paths:
---
name: Documentation Standards
globs: docs/**/*.{md,mdx}
alwaysApply: false
description: Standards for writing and maintaining documentation
---
# Documentation Standards
## Structure
- Follow consistent heading hierarchy starting with h2 (##)
- Include YAML frontmatter with title, description, and keywords
- Use descriptive alt text for images
## Writing Style
- Keep paragraphs concise and scannable
- Use code blocks with appropriate language tags
- Include cross-references to related documentation
Glob Patterns (String or Array)
# Single pattern (string)
globs: "**/*.{ts,tsx}"
# Multiple patterns (array)
globs:
- "src/**/*.ts"
- "tests/**/*.ts"
Creating Rules with Regex
Regex patterns match file content:
---
name: React Component Standards
regex: "^import React"
globs: "**/*.{tsx,jsx}"
alwaysApply: false
description: Standards for React component development
---
# React Component Standards
## Component Structure
- Use functional components with hooks
- Keep components under 200 lines
- Extract logic into custom hooks when appropriate
- Co-locate styles with components
## Examples
\`\`\`typescript
// Good: Focused component
function UserProfile({ userId }: Props) {
const user = useUser(userId);
return <div>{user.name}</div>;
}
\`\`\`
Regex Patterns (String or Array)
# Single pattern (string)
regex: "^import .* from '.*';$"
# Multiple patterns (array)
regex:
- "^import .*"
- "^export .*"
Creating Always-Applied Rules
Rules that apply to all files in the project:
---
name: Code Quality Standards
alwaysApply: true
---
# Code Quality Standards
These standards apply to all code in the project.
## General Principles
- Write self-documenting code
- Keep functions under 50 lines
- Use meaningful variable names
- Add comments only for complex logic
YAML Configuration Format
Alternative to markdown files in .continuerules/:
name: API Development Rules
version: 1.0.0
schema: v1
rules:
- name: REST API Standards
globs:
- "src/api/**/*.ts"
- "src/routes/**/*.ts"
alwaysApply: false
rule: >
## REST Conventions
- Use semantic HTTP methods (GET, POST, PUT, DELETE)
- Return appropriate status codes (200, 201, 400, 404, 500)
- Include error messages in response body
- Version APIs using URL paths (/api/v1/)
- name: TypeScript Standards
globs: "**/*.{ts,tsx}"
regex: "^import.*typescript"
alwaysApply: false
rule: >
## Type Safety
- Always define explicit types for function parameters
- Avoid using `any` type
- Use strict mode in tsconfig.json
Common Glob Patterns
globs:
- "**/*.ts" # All TypeScript files
- "src/**/*.tsx" # React components in src/
- "**/*.{ts,tsx}" # Multiple extensions
- "tests/**/*" # All files in tests/
- "*.config.js" # Config files in root
- "docs/**/*.md" # Documentation files
Common Mistakes
| Mistake | Fix |
|---|---|
| Missing name field | Name is REQUIRED in Continue frontmatter |
| Using MDC format | Continue uses plain markdown, not MDC |
| Complex frontmatter | Keep frontmatter minimal (name + optional fields) |
| Mixing alwaysApply semantics | Understand true/false/undefined behavior |
When to Use Each Approach
alwaysApply: true - Core standards that influence all code generation:
- Workspace-wide standards
- Technology preferences
- Security policies
- Universal coding conventions
globs with alwaysApply: false - Domain-specific standards:
- Component patterns
- API design rules
- Testing approaches
- Deployment procedures
No globs (undefined alwaysApply) - Agent-decided relevance:
- Let agent determine when to include based on description
- Flexible application based on context
Content Format
Plain markdown after frontmatter:
- H1 title: Main heading
- H2/H3 sections: Organize content
- Lists: Rules and guidelines
- Code blocks: Examples with language tags
- Standard markdown: Bold, italic, links
Validation
Schema location: /Users/khaliqgant/Projects/prpm/app/packages/converters/schemas/continue.schema.json
Documentation: /Users/khaliqgant/Projects/prpm/app/packages/converters/docs/continue.md
Best Practices
- Always include name: Required field, not optional
- Be specific: Target actual patterns in your codebase
- Include examples: Show real code from your project
- Update regularly: Keep rules in sync with codebase changes
- One concern per file: Split large rule sets into focused files
- Understand alwaysApply: Choose true/false/undefined based on use case
Example: Complete Rule File
---
name: TypeScript Type Safety
description: Type safety standards for TypeScript code
globs:
- "**/*.ts"
- "**/*.tsx"
alwaysApply: false
---
# TypeScript Type Safety Standards
## Type Definitions
- Always define explicit types for function parameters
- Avoid using `any` type
- Use `unknown` instead of `any` for truly unknown types
- Define return types for public functions
## Examples
\`\`\`typescript
// ❌ Bad: Using any
function processData(data: any): any {
return data.value;
}
// ✅ Good: Explicit types
interface DataInput {
value: string;
}
function processData(data: DataInput): string {
return data.value;
}
\`\`\`
## Type Guards
Use type guards for narrowing:
\`\`\`typescript
function isString(value: unknown): value is string {
return typeof value === 'string';
}
\`\`\`
Remember: Continue REQUIRES name field in frontmatter. Use globs/regex for file matching. Understand alwaysApply semantics (true/false/undefined).
GitHub Repository
Related Skills
langchain
MetaLangChain is a framework for building LLM applications using agents, chains, and RAG pipelines. It supports multiple LLM providers, offers 500+ integrations, and includes features like tool calling and memory management. Use it for rapid prototyping and deploying production systems like chatbots, autonomous agents, and question-answering services.
Algorithmic Art Generation
MetaThis skill helps developers create algorithmic art using p5.js, focusing on generative art, computational aesthetics, and interactive visualizations. It automatically activates for topics like "generative art" or "p5.js visualization" and guides you through creating unique algorithms with features like seeded randomness, flow fields, and particle systems. Use it when you need to build reproducible, code-driven artistic patterns.
webapp-testing
TestingThis Claude Skill provides a Playwright-based toolkit for testing local web applications through Python scripts. It enables frontend verification, UI debugging, screenshot capture, and log viewing while managing server lifecycles. Use it for browser automation tasks but run scripts directly rather than reading their source code to avoid context pollution.
requesting-code-review
DesignThis skill dispatches a code-reviewer subagent to analyze code changes against requirements before proceeding. It should be used after completing tasks, implementing major features, or before merging to main. The review helps catch issues early by comparing the current implementation with the original plan.
