File Formats Reference

Technical specification for task files, rule files, and bootstrap scripts.

Task Files

Task files define what the AI agent should do. They are Markdown files with YAML frontmatter.

Format

---
<optional-frontmatter-fields>
---

# Task content in Markdown

Content can include ${parameter_placeholders}.

Note: The task_name field is optional. Tasks are matched by filename (without .md extension), not by task_name in frontmatter. The task_name field is useful for metadata but task frontmatter is NOT included in the output - only the task content below the frontmatter delimiters appears in the final assembled context.

Frontmatter Fields

`id` (optional, standard field)

Type: String
Purpose: Unique identifier for the task. This field is metadata only and does not affect task matching or filtering.

Example:

---
id: task-12345
---

Note: The id field is purely informational and can be used to track tasks in external systems or for auditing purposes.

`name` (optional, standard field)

Type: String
Purpose: Human-readable name for the task. This field is metadata only and does not affect task matching or filtering.

Example:

---
name: Fix Critical Authentication Bug
---

Note: The name field is useful for display purposes and documentation, but tasks are still matched by their filename.

`description` (optional, standard field)

Type: String
Purpose: Description of what the task does. This field is metadata only and does not affect task matching or filtering.

Example:

---
description: Fix the critical bug affecting user authentication in the login flow
---

Note: The description field provides additional context about the task’s purpose and goals.

`task_name` (optional)

Type: String
Purpose: Metadata field that identifies the task. Tasks are matched by filename (without .md extension), not by this field. This field is metadata only.

Important: Task frontmatter is NOT included in the output - only the task content below the frontmatter delimiters appears in the final assembled context.

Example:

---
task_name: fix-bug
---

Usage:

# Task is matched by filename "fix-bug.md", not by task_name field
coding-context fix-bug

Note: The task_name field is optional. If omitted, the task is still matched by its filename.

`languages` (optional, standard field)

Type: Array (recommended) or String
Purpose: Metadata field that specifies the programming language(s) for the task. This field does NOT filter rules - it is metadata only and appears in the task frontmatter output.

The languages field is a standard frontmatter field that provides metadata about which programming language(s) the task relates to. Unlike selectors, this field does not automatically filter rules. To filter rules by language, use the selectors field or the -s languages=go command-line flag.

Recommended format (array with lowercase values):

---
languages:
  - go
---

Example (multiple languages):

---
languages:
  - go
  - python
  - javascript
---

Note: Both language (singular) and languages (plural) are accepted in YAML and map to the same field, but languages (plural) is recommended. Language values should be lowercase (e.g., go, python, javascript). The field is stored in frontmatter output but does not affect rule filtering.

To filter rules by language, use selectors:

Important distinction:

Frontmatter metadata field: languages: (plural) - does NOT filter rules
Selector key: languages: (plural) - used for filtering rules

In task frontmatter selectors:

---
selectors:
  languages: go
---

On the command line:

coding-context -s languages=go implement-feature

Note:

Use -s languages=go (selector flag, plural languages)
Do NOT use -p languages=go (-p is for parameter substitution, not filtering)
Language values should be lowercase (e.g., go, python, javascript)

`single_shot` (optional, standard field)

Type: Boolean
Purpose: Indicates whether the task should be run once or many times; stored in frontmatter output but does not filter rules

The single_shot field is a standard frontmatter field that provides metadata about task execution. It does not act as a selector.

Example:

---
single_shot: true
---

Common values:

true - Task runs once
false - Task can run multiple times

`timeout` (optional, standard field)

Type: String (time.Duration format)
Purpose: Specifies the timeout duration for the task using Go’s time.Duration format; stored in frontmatter output but does not filter rules

The timeout field is a standard frontmatter field that provides metadata about task execution limits. It does not act as a selector.

Example:

---
timeout: 10m
---

Common time.Duration formats:

30s - 30 seconds
5m - 5 minutes
1h - 1 hour
1h30m - 1 hour 30 minutes

`agent` (optional, standard field)

Type: String
Purpose: Specifies the target agent and automatically filters rules with matching agent selector

The agent field is a standard frontmatter field that acts as a default selector. When a task specifies an agent, only rules with that same agent value (or no agent field) will be included in the context.

Example:

---
agent: cursor
---

Supported agents: cursor, copilot, claude, gemini, opencode, augment, windsurf, codex

Behavior:

Rules with agent: cursor are included
Rules without an agent field are included (generic rules)
Rules with different agent values (e.g., agent: copilot) are excluded

Equivalent command-line usage:

# These are equivalent:
coding-context implement-feature  # (task has agent: cursor)
coding-context -a cursor implement-feature

`model` (optional, standard field)

Type: String
Purpose: Specifies the AI model to use; stored in frontmatter output but does not filter rules

The model field is a standard frontmatter field that provides metadata about which AI model should be used for the task. Unlike the agent field, the model field does not act as a selector and does not filter rules.

Example:

---
agent: copilot
model: anthropic.claude-sonnet-4-20250514-v1-0
---

Common model values:

anthropic.claude-sonnet-4-20250514-v1-0
gpt-4
gpt-4-turbo
gemini-pro

Note: The model field is purely informational and appears in the task frontmatter output for the AI agent to use as configuration.

Custom Fields (optional)

Any additional YAML fields can be used for selector-based filtering.

Example:

---
environment: production
region: us-east-1
---

Usage:

coding-context -s environment=production -s region=us-east-1 deploy

`selectors` (optional)

Type: Map of key-value pairs
Purpose: Automatically filter rules and tasks without requiring -s flags on the command line

The selectors field allows a task to specify which rules should be included when the task is executed. This is equivalent to passing -s flags but is declared in the task file itself.

Example:

---
selectors:
  languages: go
  stage: implementation
---

Usage:

# Automatically includes rules with languages=go AND stage=implementation
coding-context implement-feature

This is equivalent to:

coding-context -s languages=go -s stage=implementation implement-feature

OR Logic with Arrays:

You can specify multiple values for the same key using YAML arrays for OR logic:

---
selectors:
  languages: [go, python, javascript]
  stage: testing
---

This matches rules where (languages=go OR languages=python OR languages=javascript) AND stage=testing.

Combining with Command-Line Selectors:

Selectors from the task frontmatter and command-line -s flags are combined (additive):

# Task frontmatter has: selectors.languages = go
# Command line adds: -s priority=high
# Result: Rules must match languages=go AND priority=high
coding-context -s priority=high implement-feature

Special Selector: rule_name

You can filter to specific rule files by their base filename (without extension):

---
selectors:
  rule_name: [security-standards, go-best-practices]
---

This would only include the rules from security-standards.md and go-best-practices.md.

`expand` (optional)

Type: Boolean
Purpose: Controls whether parameter expansion should occur in the task content. Defaults to true if not specified.

When set to false, parameter placeholders like ${variable} are preserved as-is in the output, rather than being replaced with values from -p flags.

Example (with parameter expansion disabled):

---
expand: false
---

Issue: ${issue_number}
Title: ${issue_title}

Usage:

# Even with -p flags, parameters won't be expanded
coding-context -p issue_number=123 -p issue_title="Bug" preserve-template
# Output will contain: ${issue_number} and ${issue_title}

Use cases:

Passing templates to AI agents that handle their own parameter substitution
Preserving template syntax that conflicts with the parameter expansion format
Keeping templates intact for later processing

Default behavior (expand: true or omitted):

---
# expand defaults to true
---

Issue: ${issue_number}
Title: ${issue_title}

coding-context -p issue_number=123 -p issue_title="Bug" normal-task
# Output will contain: Issue: 123 and Title: Bug

Content Expansion

Task and command content supports three types of dynamic expansion, processed in a single pass to prevent injection attacks.

Parameter Expansion

Use ${parameter_name} syntax to substitute parameter values from -p flags.

Syntax: ${parameter_name}

Example:

# Fix Bug: ${issue_key}

Issue: ${issue_key}
Description: ${description}
Severity: ${severity}

Usage:

coding-context \
  -p issue_key=BUG-123 \
  -p description="Crashes on startup" \
  -p severity=critical \
  /fix-bug

Behavior: If a parameter is not found, the placeholder remains unchanged (e.g., ${missing} stays as ${missing}) and a warning is logged.

Command Expansion

Use !`command` syntax to execute shell commands and include their output.

Syntax: !`command`

Example:

# System Information

Current date: !`date +%Y-%m-%d`
Current user: !`whoami`
Git branch: !`git rev-parse --abbrev-ref HEAD`

Output:

Current date: 2025-12-11
Current user: alex
Git branch: main

Behavior:

Command output is included as-is (including any trailing newlines)
If the command fails, the original syntax remains unchanged (e.g., !`false` stays as !`false`) and a warning is logged
Commands are executed using sh -c

Security Note: Only use with trusted task files, as commands are executed with your user permissions.

Path Expansion

Use @path syntax to include the contents of a file.

Syntax: @path (delimited by whitespace; use \ to escape spaces in filenames)

Example:

# Current Configuration

@config.yaml

# API Documentation

@docs/api.md

With spaces in filenames:

Content from file: @my\ file\ with\ spaces.txt

Behavior:

File content is included verbatim
If the file is not found, the original syntax remains unchanged (e.g., @missing.txt stays as @missing.txt) and a warning is logged
Path can be absolute or relative to the current directory

Security: Single-Pass Expansion

All three expansion types are processed in a single pass, rune-by-rune to prevent injection attacks:

Expanded content is never re-processed for further expansions
Command output containing ${param} will not be expanded
File content containing !`command` will not be executed
Parameter values containing @path will not be read as files

This prevents command injection where expanded content could trigger further, unintended expansions.

File Location

Task files must be in these directories within any search path directory:

.agents/tasks/

Tasks are matched by filename (without .md extension). The task_name field in frontmatter is optional and used only for metadata. For example, a file named fix-bug.md is matched by the task name fix-bug, regardless of whether it has task_name in its frontmatter.

Command Files

Command files are reusable content blocks that can be referenced from task files using slash command syntax (e.g., /command-name). They are Markdown files with optional YAML frontmatter.

Format

---
<optional-frontmatter-fields>
---

# Command content in Markdown

This content will be substituted when the command is referenced.

Frontmatter Fields (optional)

`id` (optional, standard field)

Type: String
Purpose: Unique identifier for the command. This field is metadata only and does not affect command matching or filtering.

Example:

---
id: cmd-12345
---

Note: The id field is useful for tracking commands in external systems.

`name` (optional, standard field)

Type: String
Purpose: Human-readable name for the command. This field is metadata only and does not affect command matching or filtering.

Example:

---
name: Database Setup
---

Note: The name field helps identify the command’s purpose in documentation.

`description` (optional, standard field)

Type: String
Purpose: Description of what the command does. This field is metadata only and does not affect command matching or filtering.

Example:

---
description: Sets up PostgreSQL database with authentication
---

Note: The description field provides context about the command’s functionality.

`expand` (optional)

Type: Boolean
Purpose: Controls whether parameter expansion should occur in the command content. Defaults to true if not specified.

When set to false, parameter placeholders like ${variable} are preserved as-is in the output.

Example:

---
expand: false
---

Deploy to ${environment} with version ${version}

Usage in a task:

---
---

/deploy-steps

Command line:

coding-context -p environment=prod -p version=1.0 my-task
# Command output will contain: ${environment} and ${version} (not expanded)

This is useful when commands contain template syntax that should be preserved.

`selectors` (optional)

Type: Map of key-value pairs
Purpose: Specifies selectors that filter which rules are included when this command is used. Command selectors are combined with task selectors and CLI selectors using OR logic.

When a task uses a command that has selectors, those selectors are merged with the task’s selectors to filter rules. This allows commands to specify which rules they need (e.g., database-specific rules, authentication rules, etc.).

Example:

---
selectors:
  database: postgres
  feature: auth
---

# Database Setup Instructions

This command provides database setup instructions.

Usage in a task:

---
selectors:
  env: production
---

Deploy to production environment.

/setup-database

When this task runs:

Rules with env: production will be included (from task selector)
Rules with database: postgres will be included (from command selector)
Rules with feature: auth will be included (from command selector)
Rules that match any of these selectors will be included (OR logic)

This allows commands to declare their dependencies on specific rules without requiring every task to manually specify them.

Slash Command Syntax

Commands are referenced from tasks using slash command syntax:

# Deployment Steps

/pre-deploy

/deploy

/post-deploy

Commands can also receive inline parameters:

/greet name="Alice"
/deploy env="production" version="1.2.3"

File Locations

Command files must be in these directories within any search path directory:

.agents/commands/
.cursor/commands/
.opencode/command/

Commands are matched by filename (without .md extension). For example, a file named deploy.md is matched by the slash command /deploy.

Rule Files

Rule files provide reusable context snippets. They are Markdown or .mdc files with optional YAML frontmatter.

Format

---
<optional-frontmatter-fields>
---

# Rule content in Markdown

Guidelines, standards, or context for AI agents.

Frontmatter Fields (optional)

All frontmatter fields are optional and used for filtering.

Standard fields for rules:

`id` (optional, standard field)

Type: String
Purpose: Unique identifier for the rule. This field is metadata only and does not affect rule matching or filtering.

Example:

---
id: rule-12345
---

Note: The id field is useful for tracking rules in external systems or for documentation purposes.

`name` (optional, standard field)

Type: String
Purpose: Human-readable name for the rule. This field is metadata only and does not affect rule matching or filtering.

Example:

---
name: Go Implementation Standards
---

Note: The name field helps identify the rule’s purpose in documentation and tooling.

`description` (optional, standard field)

Type: String
Purpose: Description of what the rule provides. This field is metadata only and does not affect rule matching or filtering.

Example:

---
description: Standards and best practices for implementing Go code
---

Note: The description field provides context about what guidance the rule offers.

`task_names` (rule selector)

Specifies which task(s) this rule applies to. Can be a string or array. The field name is task_names (plural).

---
task_names:
  - fix-bug
---
# This rule only applies to the 'fix-bug' task

Multiple tasks (OR logic):

---
task_names:
  - fix-bug
  - implement-feature
  - refactor
---
# This rule applies to any of these three tasks

Behavior:

When a task is run (e.g., coding-context fix-bug), the task name fix-bug is automatically added as a selector task_name=fix-bug (singular)
Rules with task_names: [ fix-bug ] (plural) should match this selector
Rules without task_names are included for all tasks (generic rules)
Note: The code uses task_names (plural) in rule frontmatter, but sets selector as task_name (singular)

`language` or `languages` (rule selector)

Specifies which programming language(s) this rule applies to. Can be a string or array. Language values should be lowercase. The recommended format is languages: (plural) with an array.

Recommended format (array):

---
languages:
  - go
---
# This rule only applies when languages=go is selected

Multiple languages (OR logic):

---
languages:
  - go
  - python
  - javascript
---
# This rule applies to any of these languages

Behavior:

Rules with languages: [ go ] are included when -s languages=go is specified (or via task selectors.languages)
Rules without languages are included (generic rules)
The task’s languages field (metadata) does NOT automatically filter rules - use selectors.languages or -s languages=go instead
Language values should be lowercase (e.g., go, python, javascript)
Both language (singular) and languages (plural) are accepted in frontmatter, but languages (plural) with array format is recommended
Important: When using selectors (-s flag or selectors: in frontmatter), use languages (plural) as the key

`agent` (rule selector)

Specifies which AI agent this rule is intended for.

---
agent: cursor
---
# Rule specific to Cursor AI agent

Behavior:

If task/CLI specifies agent: cursor, only rules with agent: cursor or no agent field are included
Rules without an agent field are considered generic and always included (unless other selectors exclude them)

`mcp_server` (rule metadata)

Specifies an MCP server configuration for this rule. Each rule can specify one MCP server configuration with standard and arbitrary custom fields. Does not filter rules.

Important: MCP servers are specified in rules only, not in tasks. Tasks select rules (and thus MCP servers) via selectors.

---
mcp_server:
  command: python
  args: ["-m", "server"]
  env:
    PYTHON_PATH: /usr/bin/python3
  custom_config:
    host: localhost
    port: 5432
---
# Rule with MCP server configuration

Standard configuration fields:

command: The executable to run (e.g., “npx”, “python”, “docker”)
args: Array of command-line arguments
env: Map of environment variables
type: Connection protocol - “stdio” (default), “http”, or “sse”
url: Endpoint URL (required for HTTP/SSE types)
headers: Custom HTTP headers (for HTTP/SSE types)

Additional arbitrary fields: You can include any custom fields for your specific server needs (e.g., custom_config, monitoring, cache_enabled, etc.). All fields are preserved in the configuration.

Note: This field is metadata and does not affect rule selection.

`expand` (optional)

Type: Boolean
Purpose: Controls whether parameter expansion should occur in the rule content. Defaults to true if not specified.

When set to false, parameter placeholders like ${variable} are preserved as-is in the output.

Example:

---
languages:
  - go
expand: false
---

Use version ${version} when building the project.

Usage:

coding-context -p version=1.2.3 my-task
# Rule output will contain: ${version} (not expanded)

This is useful when rules contain template syntax that should be preserved for the AI agent to process.

Other common fields:

---
languages:
  - go
stage: implementation
priority: high
team: backend
agent: cursor
---

Note: Language values should be lowercase (e.g., go, python, javascript). Use languages: (plural) with array format.

Supported Extensions

.md - Markdown files
.mdc - Markdown component files

File Locations

Rules are discovered in many locations. See Search Paths Reference for the complete list.

Bootstrap Scripts

Bootstrap scripts are executable files that run before their associated rule file is processed.

Naming Convention

For a rule file named my-rule.md, the bootstrap script must be named my-rule-bootstrap (no extension).

Example:

Rule: .agents/rules/jira-context.md
Bootstrap: .agents/rules/jira-context-bootstrap

Requirements

Executable permission: chmod +x script-name
Same directory: Must be in same directory as the rule file
Naming: Must match rule filename plus -bootstrap suffix

Output Handling

Bootstrap script output goes to stderr, not the main context
The script’s stdout is not captured
Use stderr for logging and status messages

Example:

#!/bin/bash
# my-rule-bootstrap

echo "Fetching data..." >&2  # Goes to stderr
curl -s "https://api.example.com/data" > /tmp/data.json
echo "Data fetched successfully" >&2

Environment Access

Bootstrap scripts can access all environment variables from the parent process.

Example:

#!/bin/bash

# Access environment variables
API_KEY="${JIRA_API_KEY}"
ISSUE="${JIRA_ISSUE_KEY}"

if [ -z "$API_KEY" ]; then
    echo "Error: JIRA_API_KEY not set" >&2
    exit 1
fi

# Fetch and process data
curl -s -H "Authorization: Bearer $API_KEY" \
    "https://api.example.com/issue/$ISSUE" \
    | jq -r '.fields' > /tmp/issue-data.json

YAML Frontmatter Specification

Valid Frontmatter

---
key: value
another_key: another value
numeric_key: 123
boolean_key: true
---

Limitations

Top-level fields only:

# ✅ Supported
---
languages:
  - go
stage: testing
---

# ❌ Not supported (nested fields)
---
metadata:
  language: go
  stage: testing
---

Selectors match top-level only:

# Works with top-level fields
coding-context -s languages=go fix-bug

# Doesn't work with nested fields
coding-context -s metadata.language=go fix-bug  # Won't match

Data Types

Frontmatter values are treated as strings for matching:

---
priority: 1
enabled: true
languages:
  - go
---

# All values are matched as strings
coding-context -s priority=1 task       # Matches priority: 1
coding-context -s enabled=true task     # Matches enabled: true
coding-context -s languages=go task      # Matches languages: [ go ]

Skill Files

Skill files provide specialized capabilities with progressive disclosure. Each skill is a directory containing a SKILL.md file with frontmatter metadata and content.

Format

---
name: skill-identifier
description: Brief description of what the skill does and when to use it
license: MIT
metadata:
  author: team-name
  version: "1.0"
---

# Skill Content

Full skill documentation, workflows, and procedures here.

Directory Structure

Skills are organized in subdirectories within .agents/skills/:

.agents/skills/
├── data-analysis/
│   └── SKILL.md
├── pdf-processing/
│   └── SKILL.md
└── api-testing/
    ├── SKILL.md
    └── references/
        └── REFERENCE.md

Frontmatter Fields

`name` (required)

Type: String
Length: 1-64 characters
Purpose: Unique identifier for the skill

Example:

---
name: data-analysis
---

`description` (required)

Type: String
Length: 1-1024 characters
Purpose: Explains what the skill does and when to use it. This description is shown in the initial context for progressive disclosure.

Example:

---
name: pdf-processing
description: Extract text and tables from PDF files, fill PDF forms, and merge multiple PDFs. Use when working with PDF documents or when the user mentions PDFs, forms, or document extraction.
---

`license` (optional)

Type: String
Purpose: Specifies the license applied to the skill

Example:

---
license: Apache-2.0
---

`compatibility` (optional)

Type: String
Max Length: 500 characters
Purpose: Indicates environment requirements

Example:

---
compatibility: Requires Python 3.8+ with pandas and matplotlib installed
---

`metadata` (optional)

Type: Map of string key-value pairs
Purpose: Arbitrary metadata about the skill

Example:

---
metadata:
  author: data-team
  version: "2.1"
  category: analytics
---

Progressive Disclosure

Skills use progressive disclosure to minimize token usage:

Initial Context: Only skill metadata (name, description, location) is included
Full Content: AI agents can load full skill content by reading the SKILL.md file when needed

XML Output in Context:

<available_skills>
  <skill>
    <name>data-analysis</name>
    <description>Analyze datasets, generate charts, and create summary reports...</description>
    <location>/absolute/path/to/.agents/skills/data-analysis/SKILL.md</location>
  </skill>
  <skill>
    <name>pdf-processing</name>
    <description>Extract text and tables from PDF files...</description>
    <location>/absolute/path/to/.agents/skills/pdf-processing/SKILL.md</location>
  </skill>
</available_skills>

Selector Filtering

Skills can be filtered using selectors in their frontmatter, just like rules:

---
name: go-testing
description: Write and run Go tests with best practices
languages:
  - go
stage: testing
---

# Only include Go testing skills
coding-context -s languages=go -s stage=testing implement-feature

Skills without matching selectors are excluded from the output.

File Location

Skill files must be in these directories within any search path directory:

.agents/skills/*/SKILL.md (each subdirectory must contain a SKILL.md file)

Validation

The CLI validates:

✅ name field is present and 1-64 characters
✅ description field is present and 1-1024 characters
✅ YAML frontmatter is well-formed
✅ Skills match selectors (if provided)

The CLI does NOT validate:

Skill content format or structure
Reference links within skills
Whether additional files in skill directory exist

Special Behaviors

Multiple Tasks with Same Filename

If multiple task files have the same filename (without .md extension) in different search path directories, selectors determine which one is used. Remember, tasks are matched by filename, not by the task_name field in frontmatter.

Without selectors:

Error: “multiple tasks found with name: X”

With selectors:

The task matching all selectors is used
If no task matches: “no task found”
If multiple match: Error

Rules Without Frontmatter

Rules without frontmatter are always included (unless resume mode is active).

# General Standards

These standards apply to all projects.

This rule is included in every context assembly.

Resume Mode Special Handling

The -r flag:

Skips all rule file output
Adds implicit -s resume=true selector

Equivalent commands:

# These are NOT exactly equivalent:
coding-context -r fix-bug                    # Skips rules
coding-context -s resume=true fix-bug        # Includes rules

Validation

The CLI validates:

✅ Task files match by filename (.md files with matching base name)
✅ YAML frontmatter is well-formed (if present)
✅ At most one task matches the selectors

The CLI does NOT validate:

Content format or structure
Parameter references exist
Bootstrap script success/failure

File Formats Reference

Task Files

Format

Frontmatter Fields

id (optional, standard field)

name (optional, standard field)

description (optional, standard field)

task_name (optional)

languages (optional, standard field)

single_shot (optional, standard field)

timeout (optional, standard field)

agent (optional, standard field)

model (optional, standard field)

Custom Fields (optional)

selectors (optional)

expand (optional)

Content Expansion

Parameter Expansion

Command Expansion

Path Expansion

Security: Single-Pass Expansion

File Location

Command Files

Format

Frontmatter Fields (optional)

id (optional, standard field)

name (optional, standard field)

description (optional, standard field)

expand (optional)

selectors (optional)

Slash Command Syntax

File Locations

Rule Files

Format

Frontmatter Fields (optional)

id (optional, standard field)

name (optional, standard field)

description (optional, standard field)

task_names (rule selector)

language or languages (rule selector)

agent (rule selector)

mcp_server (rule metadata)

expand (optional)

Supported Extensions

File Locations

Bootstrap Scripts

Naming Convention

Requirements

Output Handling

Environment Access

YAML Frontmatter Specification

Valid Frontmatter

Limitations

Data Types

Skill Files

Format

Directory Structure

Frontmatter Fields

name (required)

description (required)

license (optional)

compatibility (optional)

metadata (optional)

Progressive Disclosure

Selector Filtering

File Location

Validation

Special Behaviors

Multiple Tasks with Same Filename

Rules Without Frontmatter

Resume Mode Special Handling

Validation

See Also

`id` (optional, standard field)

`name` (optional, standard field)

`description` (optional, standard field)

`task_name` (optional)

`languages` (optional, standard field)

`single_shot` (optional, standard field)

`timeout` (optional, standard field)

`agent` (optional, standard field)

`model` (optional, standard field)

`selectors` (optional)

`expand` (optional)

`id` (optional, standard field)

`name` (optional, standard field)

`description` (optional, standard field)

`expand` (optional)

`selectors` (optional)

`id` (optional, standard field)

`name` (optional, standard field)

`description` (optional, standard field)

`task_names` (rule selector)

`language` or `languages` (rule selector)

`agent` (rule selector)

`mcp_server` (rule metadata)

`expand` (optional)

`name` (required)

`description` (required)

`license` (optional)

`compatibility` (optional)

`metadata` (optional)