creating-continue-packages

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

---
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

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

---
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).