Use when creating Continue rules - provides required name field, alwaysApply semantics, glob/regex patterns, and markdown format with optional frontmatter
Scanned 2/12/2026
Install to Claude Code
npx -y skills add pr-pm/prpm --skill creating-continue-packages --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Creating Continue Packages?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/pr-pm-creating-continue-packages)More formats (shields.io, HTML) on the badges page.
---
name: creating-continue-packages
description: Use when creating Continue rules - provides required name field, alwaysApply semantics, glob/regex patterns, and markdown format with optional frontmatter
---
# 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
```yaml
---
name: Rule display name (REQUIRED)
---
```
### Optional Frontmatter
```yaml
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:
```markdown
---
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)
```yaml
# Single pattern (string)
globs: "**/*.{ts,tsx}"
# Multiple patterns (array)
globs:
- "src/**/*.ts"
- "tests/**/*.ts"
```
## Creating Rules with Regex
Regex patterns match file content:
```markdown
---
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)
```yaml
# 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:
```markdown
---
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/`:
```yaml
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
```yaml
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
1. **Always include name**: Required field, not optional
2. **Be specific**: Target actual patterns in your codebase
3. **Include examples**: Show real code from your project
4. **Update regularly**: Keep rules in sync with codebase changes
5. **One concern per file**: Split large rule sets into focused files
6. **Understand alwaysApply**: Choose true/false/undefined based on use case
## Example: Complete Rule File
```markdown
---
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).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!