cheatsheet-context-symbols.md 45 KB

OpenCode Context Reference Cheat Sheet

Purpose: Master reference for defining files, agents, and tools in prompts that work seamlessly with OpenCode's automatic tool resolution.


๐ŸŽฏ Quick Reference Table

Type Syntax Auto-Loaded? AI Action Required When to Use
File (Initial) @file.md โœ… Yes โŒ No User's initial prompt
File (Nested) @file.md โŒ No โœ… Yes (read_file) Inside loaded files
Directory @src/components/ โœ… Yes โŒ No Folder context
Sub-Agent (Context) @agent-name โœ… Yes* โŒ No Reference agent info
Sub-Agent (Invoke) task(subagent_type="name") โŒ No โœ… Yes (task tool) Delegate tasks
Shell Command !`command` โœ… Yes โŒ No Inline command output
Config File instructions: [] in opencode.json โœ… Yes โŒ No Always-needed context
Agent (Markdown) .opencode/agent/**/*.md โœ… Auto-registered โŒ No Define agents

๐Ÿ”‘ Key Takeaways

  1. @ in agent markdown = Just informational text
  2. @ in user prompt = OpenCode processes it (loads files/metadata)
  3. To invoke agents = Always use task tool
  4. Agent names = Full path from .opencode/agent/ directory
  5. Don't use @ to list agents in your prompt - it's confusing!

The @ symbol only has special meaning in USER PROMPTS, not in AGENT SYSTEM PROMPTS.


๐Ÿ”ง Shell Commands

Inline Shell Commands (Automatic Execution)

Use the !`command` syntax to execute commands and inline their output into prompts:

# Example: Include git information
Current branch: !`git branch --show-current`
Recent commits: !`git log --oneline -5`

# Example: Include system information  
Node version: !`node --version`
Available memory: !`free -h | grep Mem`

# Example: Include file contents
Database schema: !`cat schema.sql`

# Example: Include directory structure
Project structure:
!`tree -L 2 -I 'node_modules|dist'`

How it works:

  • โœ… Commands execute when prompt is processed
  • โœ… Output is inserted into the prompt text
  • โœ… Great for dynamic context (git status, file lists, system info)
  • โš ๏ธ Commands run in shell with current working directory

Shell Command Patterns

Git Context

## Current Work Context

Branch: !`git branch --show-current`
Modified files: !`git status --short`
Last commit: !`git log -1 --pretty=format:'%h - %s'`
Uncommitted changes:
!`git diff --stat`

Project Structure

## Project Layout

!`find src -type f -name '*.ts' | head -20`

## Component Structure  

!`tree src/components -L 2`

Environment Information

## Environment

Node: !`node --version`
npm: !`npm --version`
OS: !`uname -a`

File Content Snippets

## Configuration

Current eslint rules:
!`cat .eslintrc.json`

Package scripts:
!`cat package.json | jq .scripts`

When to Use Shell Commands vs Tools

Scenario Use Shell ! Syntax Use run_terminal_cmd Tool
Static context in prompt โœ… โŒ
Git information โœ… โŒ
File contents โœ… โŒ
Interactive AI execution โŒ โœ…
Based on AI decisions โŒ โœ…
Build/test commands โŒ โœ…
Requires error handling โŒ โœ…

๐Ÿ“ File References

Initial Prompt (Automatic)

When you type this in your prompt:

Follow guidelines in @GUIDELINES.md
Use patterns from @src/patterns/

OpenCode automatically:

  • โœ… Reads GUIDELINES.md
  • โœ… Lists src/patterns/ directory
  • โœ… Attaches content to AI context
  • โŒ Does NOT read nested @ references inside these files

Nested References (Requires AI Action)

When GUIDELINES.md contains:

Also see @CODE_STYLE.md and @TESTING.md

OpenCode does:

  • โŒ Does NOT automatically read these
  • โœ… AI sees them as plain text

To make AI read them, use explicit instructions:

# GUIDELINES.md

โš ๏ธ **CRITICAL**: Before proceeding, read these files using read_file:

1. @CODE_STYLE.md - Coding standards (READ FIRST)
2. @TESTING.md - Testing patterns (READ FIRST)  
3. @ARCHITECTURE.md - System design (READ FIRST)

[rest of your guidelines...]

Key phrases that work:

  • โœ… READ FIRST
  • โœ… use read_file tool
  • โœ… CRITICAL: Read these files
  • โœ… Load immediately before proceeding

๐Ÿค– Sub-Agent References

โš ๏ธ CRITICAL: Agent Context vs Agent Invocation

IMPORTANT DISTINCTION: Agent Files vs Agent Names

Understanding the Difference

Agent File (Documentation):

  • Path: .opencode/agents/subagents/core/taskmanager.md
  • This is a MARKDOWN FILE describing the agent
  • Use @.opencode/agents/subagents/core/taskmanager.md to load file content
  • Result: Loads documentation/instructions as text

Agent Name (System Registration):

  • Name: taskmanager (registered in OpenCode)
  • This is the actual AGENT that can execute tasks
  • Use task(subagent_type="taskmanager", ...) to invoke
  • Result: Agent runs and performs work

Scenario 1: Using @agent-name (USUALLY NOT RECOMMENDED)

When you use @agent-name in your initial prompt:

Use @reviewer agent for code review

What happens:

  1. โœ… OpenCode checks if it's a file at that path
  2. โŒ File doesn't exist โ†’ Checks if it's a registered agent
  3. โœ… If agent exists: Attaches agent metadata as context (name, description, tools)
  4. โŒ Does NOT invoke/run the agent
  5. โš ๏ธ This loads agent info but doesn't execute anything

Result: AI knows the agent exists but doesn't execute it.

When to use: Rarely needed. Only if you want to reference agent capabilities in context.

Scenario 2: Agent Invocation (RECOMMENDED)

To actually run an agent and execute tasks:

// AI must explicitly call the task tool
task(
  subagent_type="CodeReviewer",
  description="Review code",
  prompt="Review the auth implementation for security issues"
)

Result: Agent executes and returns results.

When to use: Always - this is how you actually invoke agents.

Scenario 3: Loading Agent Documentation Files

If you have agent documentation files:

# Initial prompt
Follow guidelines in @.opencode/agents/subagents/core/taskmanager.md

What happens:

  1. โœ… Loads the file content as context
  2. โŒ Does NOT invoke the agent
  3. โœ… Good for loading agent usage instructions

When to use: When you want to load documentation about how to use agents.


Best Practice: Clear Agent Instructions

โŒ DON'T write this (confusing - uses @ for agents):

Use @reviewer to review code
Review with @taskmanager agent

Problems:

  • Loads agent metadata, doesn't invoke
  • AI might be confused about how to use it
  • Mixing file syntax with agent invocation

โœ… DO write this (clear and explicit):

Option 1: If you have agent documentation files

# Load agent documentation (file)
@.opencode/agents/subagents/core/taskmanager.md

# Then instruct AI how to invoke (not using @)
**Agent: `taskmanager`**
- Purpose: Task planning and breakdown
- Invoke with: task(subagent_type="taskmanager", description="Plan X", prompt="Break down feature Y")

Option 2: Direct invocation instructions (no @ at all)

**Agent: `reviewer`** - Code review agent
- Purpose: Review code for quality and security
- When: After implementing features
- Invoke with: task(subagent_type="CodeReviewer", description="Review X", prompt="Review Y for Z issues")

**DO NOT use @reviewer** - This loads metadata, not invocation
**ALWAYS use task tool** - This actually runs the agent

Listing Sub-Agents

# Available Sub-Agents

โš ๏ธ **IMPORTANT**: These agents are NOT loaded as context. You MUST invoke them using the `task` tool:

## Code Agents

**Agent: `tester`** (DO NOT use @tester as context reference)
- **Purpose**: Test generation and execution
- **When to invoke**: After implementing features, before commits
- **Tool call**: 

javascript task(

subagent_type="TestEngineer",
description="Test auth",
prompt="Write comprehensive tests for auth module with >80% coverage"

)


**Agent: `reviewer`** (DO NOT use @reviewer as context reference)
- **Purpose**: Code review and quality checks  
- **When to invoke**: After completing code changes
- **Tool call**: 

javascript task(

subagent_type="CodeReviewer",
description="Review changes",
prompt="Review the authentication implementation for security vulnerabilities, code quality, and best practices"

)


## Core Agents

**Agent: `planner`** (DO NOT use @planner as context reference)
- **Purpose**: Project planning and task breakdown
- **When to invoke**: Starting large features or projects
- **Tool call**: 

javascript task(

subagent_type="planner",
description="Plan feature",
prompt="Break down the payment system feature into implementable tasks with dependencies"

)

Proactive Sub-Agent Invocation

To make the AI automatically invoke sub-agents at appropriate times:

## Agent Automation Rules

**CRITICAL**: Agents are invoked via `task` tool, NOT by referencing them with @.

**After completing code changes, ALWAYS:**
1. Invoke the `tester` agent using `task` tool to write and run tests
2. Invoke the `reviewer` agent using `task` tool to review code quality
3. Report results back to the user

**Example workflow:**
1. User requests feature
2. You implement the code
3. Automatically call: 

javascript task(subagent_type="TestEngineer", description="Test feature", prompt="Write tests for X")

4. Automatically call: 

javascript task(subagent_type="CodeReviewer", description="Review feature", prompt="Review X for quality")

5. Summarize results for user

**Important**: 
- Sub-agents return results ONLY to you. You must summarize for the user.
- DO NOT use `@agent-name` syntax to invoke agents
- ALWAYS use the `task` tool for agent invocation

๐Ÿ› ๏ธ Tool References

Built-in OpenCode Tools

## Available Tools

**File Operations**
- `read_file` - Read file contents (supports line ranges)
- `write_file` - Create or overwrite files  
- `search_replace` - Edit files with precision
- `list_dir` - List directory contents
- `glob_file_search` - Find files by pattern

**Code Operations**
- `grep` - Search code with ripgrep
- `codebase_search` - Semantic code search

**Execution**
- `run_terminal_cmd` - Execute shell commands
- `task` - Invoke sub-agents

**Planning**
- `todo_write` - Create and manage task lists

When to Reference Tools

# Task Instructions

When you need to find configuration files, use `glob_file_search` to locate them.

When analyzing code patterns, use `codebase_search` for semantic understanding.

When editing code, use `search_replace` for precision rather than rewriting entire files.

๐Ÿ’ก Complete Example: Index File

Here's a production-ready index file that works perfectly with OpenCode:

# Project Context Index

## ๐Ÿ“‹ Quick Start

**CRITICAL INSTRUCTION**: Before proceeding with ANY task:
1. Read the files marked `[READ FIRST]` using the `read_file` tool
2. Review the available sub-agents below
3. Follow the coding standards and patterns defined in these files

---

## ๐Ÿ“š Core Documentation [READ FIRST]

Load these files immediately using `read_file`:

- @docs/CODING_STANDARDS.md - TypeScript/React coding patterns
- @docs/TESTING_STRATEGY.md - Test requirements and patterns
- @docs/ARCHITECTURE.md - System design and component structure
- @.opencode/WORKFLOWS.md - Development workflows and CI/CD

---

## ๐Ÿค– Available Sub-Agents

Use the `task` tool to invoke these specialized agents:

### Development Agents

**@subagents/code/implementer** - Complex feature implementation

javascript task( subagent_type="implementer", description="Implement user auth", prompt="Create complete authentication system with JWT tokens, including login, logout, and session management. Follow patterns in @docs/ARCHITECTURE.md" )


**@TestEngineer** - Test generation and execution

javascript task( subagent_type="TestEngineer", description="Test auth system", prompt="Write comprehensive unit and integration tests for the authentication module. Ensure >80% coverage. Run tests and report results." )


**@CodeReviewer** - Code quality and security review

javascript task( subagent_type="CodeReviewer", description="Review auth code", prompt="Review the authentication implementation for security vulnerabilities, code quality, and adherence to @docs/CODING_STANDARDS.md. Provide specific improvement suggestions." )


### Documentation Agents

**@subagents/docs/technical-writer** - API and code documentation

javascript task( subagent_type="technical-writer", description="Document auth API", prompt="Generate comprehensive API documentation for the authentication endpoints, including request/response examples and error codes." )


### Planning Agents

**@subagents/core/architect** - System design and planning

javascript task( subagent_type="architect", description="Design payment system", prompt="Design a payment processing system architecture that integrates with Stripe. Break down into implementable tasks. Consider scalability and error handling." )


---

## ๐Ÿ”„ Automated Workflows

### After Implementing Code

**ALWAYS execute this workflow:**

1. **Test** - Invoke `@TestEngineer` to validate implementation
2. **Review** - Invoke `@CodeReviewer` for quality check
3. **Document** - Update relevant documentation
4. **Report** - Summarize results to user with:
   - What was implemented
   - Test results and coverage
   - Any issues found in review
   - Next recommended steps

### Before Starting Large Features

**ALWAYS execute this workflow:**

1. **Plan** - Invoke `@subagents/core/architect` for design
2. **Load Context** - Read relevant documentation from @docs/
3. **Break Down** - Create detailed TODO list with `todo_write`
4. **Confirm** - Ask user to confirm approach

---

## ๐Ÿ“– Additional Context Files

### Code Patterns & Examples

For specific implementation patterns, read these on-demand:

- @examples/api-patterns.ts - REST API implementation patterns
- @examples/component-patterns.tsx - React component patterns
- @examples/test-patterns.test.ts - Testing patterns and fixtures
- @examples/error-handling.ts - Error handling strategies

### Configuration Files

Reference these when setting up tools or CI/CD:

- @.github/workflows/ - GitHub Actions workflows
- @tsconfig.json - TypeScript configuration
- @package.json - Project dependencies and scripts

---

## ๐ŸŽฏ Tool Usage Guidelines

### File Search Strategy

1. **Known filename**: Use `read_file` directly
2. **Pattern match**: Use `glob_file_search` (e.g., "*.test.ts")
3. **Semantic search**: Use `codebase_search` (e.g., "authentication logic")
4. **Text search**: Use `grep` for exact text matches

### Editing Strategy

1. **Small changes**: Use `search_replace` for precision
2. **New files**: Use `write_file`
3. **Large refactors**: Consider sub-agent with `task` tool

### Execution Strategy

1. **Simple commands**: Use `run_terminal_cmd`
2. **Complex workflows**: Create shell scripts first
3. **Multistep tasks**: Use sub-agents with `task` tool

---

## โš ๏ธ Common Pitfalls to Avoid

### โŒ DON'T DO THIS:

markdown

Bad: Using @ syntax for agent invocation

Use @tester when needed Review with @reviewer after coding

Bad: Treating agents like files

Read @tester for testing guidelines See @reviewer documentation

Bad: Vague agent reference

Use the tester agent when needed

Bad: Assuming nested files are auto-loaded

See @guidelines.md (which references @other.md)

Bad: Not specifying how to invoke

Available agents: tester, reviewer, planner

Bad: Mixing context and invocation

Use @agent-name to run the agent


### โœ… DO THIS:

markdown

Good: Explicit tool call for agent invocation

Agent: tester - Invoke ONLY via task tool: task(subagent_type="TestEngineer", description="Test feature", prompt="Write comprehensive tests for X")

Good: Clear separation of concerns

File: @docs/testing-guide.md - Load with read_file Agent: tester - Invoke with task tool

Good: Explicit read instruction for nested refs

CRITICAL: Read @guidelines.md, then read all files it references using read_file

Good: Clear tool invocation

Use the codebase_search tool to find authentication logic

Good: Proactive invocation instruction

After implementing code, ALWAYS invoke the tester agent: task(subagent_type="TestEngineer", description="Test X", prompt="Write and run tests for X")


---

## ๐Ÿš€ Quick Start Template

Copy this template to create your own index:

markdown

[Project Name] Context Index

๐ŸŽฏ Before Starting ANY Task

CRITICAL: Load these files first using read_file:

  1. @[PATH_TO_GUIDELINES]
  2. @[PATH_TO_STANDARDS]
  3. @[PATH_TO_ARCHITECTURE]

๐Ÿค– Sub-Agents (MUST use task tool to invoke)

Agent: [AGENT_NAME] (DO NOT use @[AGENT_NAME] as context)

  • Purpose: [Description]
  • When to invoke: [When to invoke]
  • Tool call:

    task(
    subagent_type="[AGENT_NAME]",
    description="[SHORT_DESC]",
    prompt="[DETAILED_TASK_INSTRUCTIONS]"
    )
    

๐Ÿ”„ Standard Workflows

After Code Changes

  1. Invoke tester agent via task tool
  2. Invoke reviewer agent via task tool
  3. Report results to user

Example:

// Step 1: Test
task(subagent_type="[TESTER_AGENT]", description="Test feature", prompt="Write tests for X")

// Step 2: Review
task(subagent_type="[REVIEWER_AGENT]", description="Review feature", prompt="Review X for quality")

// Step 3: Summarize results for user

๐Ÿ“š Reference Files (Load on-demand)

  • @[FILE_PATH] - Description


---

## ๐Ÿ” Verification Checklist

Before sharing your index file, verify:

- [ ] All **file** references use `@` prefix
- [ ] Agent references use `task` tool, NOT `@` syntax
- [ ] Agent names are plain text (e.g., `tester`), not `@tester`
- [ ] Nested file references have explicit "READ FIRST" instructions
- [ ] Sub-agents have complete `task()` tool call examples
- [ ] Sub-agents show when/why to invoke them
- [ ] Clear distinction between files (@file.md) and agents (task tool)
- [ ] Automated workflows use `task` tool for agents
- [ ] Tool usage instructions are specific
- [ ] No ambiguous or vague instructions
- [ ] No mixing of @ syntax for agents

---

## ๐Ÿ“ Quick Reference Notes

- **Files**: Use `@path/to/file.md` in prompts (auto-loaded initially, nested require read_file)
- **Agent Files**: Use `@.opencode/agents/subagents/core/agent.md` to load documentation
- **Agent Invocation**: Use `task` tool, NOT `@agent-name` syntax
- **Agent Names**: Plain text only (e.g., `taskmanager`), never `@taskmanager`
- **Shell**: Use `` !`command` `` for automatic execution in prompts
- **Key Rule**: `@` is for FILES only, `task` tool is for AGENTS
- **Rare Exception**: `@agent-name` loads agent metadata (usually not needed)

---

## ๐ŸŽจ Advanced Patterns

### Combining Multiple Context Types

markdown

Complete Feature Context

Files to Read [READ FIRST]

@docs/auth-spec.md @src/auth/types.ts

Current Implementation

!find src/auth -type f -name '*.ts'

Git Context

Branch: !git branch --show-current Changes: !git diff --name-only

Environment

Node: !node --version Dependencies: !npm list --depth=0 | grep auth

Sub-Agents Available

@subagents/code/implementer - Use for implementation @TestEngineer - Use for testing

Task

Implement the authentication flow following @docs/auth-spec.md


### Dynamic File Loading

markdown

Load All Test Files

Test files in project: !find . -name "*.test.ts" -o -name "*.spec.ts"

INSTRUCTION: Read all test files above using read_file to understand testing patterns.


### Conditional Context

markdown

Database Migration Context

Current Migration Status

!npm run db:status 2>&1

Latest Migration

!ls -t migrations/ | head -1 | xargs cat

If migrations are pending: Read @docs/migration-guide.md If migrations are up-to-date: Proceed with schema changes


### Nested Shell Commands with File References

markdown

Component Analysis

All React Components

!find src -name "*.tsx" | grep -v test

Component Guidelines

@docs/component-patterns.md

CRITICAL:

  1. Review the component list above
  2. Read @docs/component-patterns.md using read_file
  3. Ensure new components follow established patterns

    
    ---
    
    ## ๐Ÿ”— Shell Command Cheat Sheet
    
    ### Git Commands
    
    

    bash

Current branch

!git branch --show-current

Recent commits

!git log --oneline -n 10

Modified files

!git status --short

Diff summary

!git diff --stat

Authors

!git shortlog -sn --all

Current commit hash

!git rev-parse HEAD


### File System Commands

bash

List TypeScript files

!find src -name "*.ts" -type f

Count lines of code

!find src -name "*.ts" | xargs wc -l | tail -1

Recent files

!ls -lt src | head -10

Directory tree

!tree -L 3 -I 'node_modules|dist|.git'

File size summary

!du -sh src/*


### Project Info Commands

bash

Package version

!cat package.json | jq -r .version

Dependencies

!npm list --depth=0

Scripts

!cat package.json | jq .scripts

Node version

!node --version

npm version

!npm --version


### Search Commands

bash

Find TODO comments

!grep -r "TODO" src --include="*.ts"

Find FIXME comments

!grep -r "FIXME" src --include="*.ts"

Find specific function

!grep -rn "function authenticate" src

Count test files

!find . -name "*.test.ts" | wc -l


### System Commands

bash

OS info

!uname -a

Memory usage

!free -h

Disk usage

!df -h .

Process list (filtered)

!ps aux | grep node


---

## ๐ŸŽฏ Complete Real-World Example

markdown

Feature Implementation: User Authentication

Pre-Flight Context Loading

CRITICAL: Read These Files First

  1. @docs/CODING_STANDARDS.md
  2. @docs/AUTH_ARCHITECTURE.md
  3. @src/auth/interfaces.ts
  4. @tests/auth/auth.test.ts

Current State

Branch: !git branch --show-current

Modified Files: !git status --short

Existing Auth Files: !find src/auth -name "*.ts" -type f

Test Coverage: !npm run test:coverage -- src/auth 2>&1 | tail -5

Dependencies

Current Auth Libraries: !npm list | grep -E "(passport|jwt|bcrypt)"

Node Version: !node --version

Sub-Agents Available

@subagents/code/implementer - Feature implementation

  • Use when: Implementing new auth flows
  • Example: task(subagent_type="implementer", description="OAuth flow", prompt="Implement OAuth2 flow with Google, following patterns in @docs/AUTH_ARCHITECTURE.md")

@TestEngineer - Test creation

  • Use when: After implementing auth features
  • Example: task(subagent_type="TestEngineer", description="Test OAuth", prompt="Write integration tests for OAuth2 flow with >90% coverage")

@subagents/security/auditor - Security review

  • Use when: Before deploying auth changes
  • Example: task(subagent_type="auditor", description="Audit auth", prompt="Review auth implementation for security vulnerabilities, SQL injection, XSS, and CSRF")

Implementation Workflow

Step 1: Context Loading

  1. Read all files marked [READ FIRST]
  2. Review current implementation: !cat src/auth/auth.service.ts
  3. Review existing tests: !cat tests/auth/auth.test.ts

Step 2: Implementation

  1. Implement feature following @docs/CODING_STANDARDS.md
  2. Follow patterns from @src/auth/interfaces.ts
  3. Update types in @src/auth/types.ts

Step 3: Testing

  1. Invoke tester agent via task tool for test creation

    task(subagent_type="TestEngineer", description="Test auth", prompt="Write tests for auth module")
    
  2. Run tests: Use run_terminal_cmd for npm test

  3. Verify coverage meets requirements

Step 4: Review

  1. Invoke security auditor agent via task tool

    task(subagent_type="auditor", description="Security audit", prompt="Review auth for vulnerabilities")
    
  2. Address any issues found

  3. Re-run tests after fixes

Step 5: Documentation

  1. Update @docs/AUTH_ARCHITECTURE.md with changes
  2. Add inline code documentation
  3. Update API documentation

Reference Files (Load on-demand)

  • @docs/api/auth-endpoints.md - API documentation
  • @examples/auth-examples.ts - Usage examples
  • @config/auth.config.ts - Configuration options

Additional Context

Database Schema: !cat migrations/latest_auth_schema.sql

Environment Variables: !cat .env.example | grep AUTH


REMEMBER:

  • Files: Use @filename (nested require read_file)
  • Agents: Use task tool, NOT @agent-name
  • Shell: !`cmd` executes automatically in prompt
  • Agent names are plain text (e.g., tester), never @tester

    
    ---
    
    ## ๐Ÿ“ Notes
    
    - **Auto-loaded**: Initial `@` references in YOUR prompt (files only)
    - **Requires tool call**: Nested `@` references in loaded files
    - **Agent as context**: `@agent-name` in initial prompt attaches agent info (not invocation)
    - **Agent invocation**: Always requires `task` tool call - NEVER use `@` syntax
    - **Shell commands**: `` !`command` `` syntax executes automatically in prompt processing
    - **Tool commands**: `run_terminal_cmd` for AI-driven execution during conversation
    - **Key distinction**: Files use `@`, Agents use `task` tool
    
    ---
    
    ## ๐ŸŽฏ Quick Decision Tree
    
    **Need to load a file?**
    - Initial prompt โ†’ Use `@path/to/file.md`
    - Nested reference โ†’ Add "READ FIRST" instruction for AI to use `read_file`
    - Agent docs โ†’ Use `@.opencode/agents/subagents/core/agent.md` (file path)
    
    **Need to invoke an agent?**
    - โŒ **NEVER** use `@agent-name` syntax for invocation
    - โœ… AI must call `task(subagent_type="name", ...)`
    - โœ… Use plain agent names (e.g., `taskmanager`, not `@taskmanager`)
    - โœ… Add clear invocation instructions in your context
    - โš ๏ธ Using `@agent-name` only loads metadata (rarely useful)
    
    **Need to run a command?**
    - Static context โ†’ Use `` !`command` `` in prompt
    - AI-driven execution โ†’ AI uses `run_terminal_cmd` tool
    
    **Structure Example:**
    

Files (use @): Agents (use task): @docs/guide.md task(subagent_type="CodeReviewer", ...) @src/types.ts task(subagent_type="TestEngineer", ...) @.opencode/agents/ [agent name without @] taskmanager.md


---

---

## ๐ŸŽฏ THE PERFECT PROMPT TEMPLATE

Use this template to avoid ALL confusion and work seamlessly with OpenCode:

### Template Structure

markdown

[Task Name]

๐Ÿ“‹ Context Files (Load with read_file tool)

CRITICAL: Read these files FIRST using the read_file tool:

  1. @docs/coding-standards.md
  2. @docs/architecture.md
  3. @src/types/core.ts

๐Ÿ“š Additional Documentation (Auto-loaded)

Current git status: Branch: !git branch --show-current Recent changes: !git status --short

Project structure: !find src -type d -maxdepth 2


๐Ÿค– Available Agents (Invoke via task tool ONLY)

IMPORTANT: DO NOT use @ syntax for agents. Use the task tool to invoke.

Agent: implementer

Purpose: Complex feature implementation When to invoke: When implementing new features or major refactors How to invoke:

task(
  subagent_type="implementer",
  description="Implement feature X",
  prompt="Create complete implementation of X following @docs/architecture.md patterns. Include error handling and validation."
)

Agent: tester

Purpose: Test creation and execution When to invoke: After implementing features, before committing How to invoke:

task(
  subagent_type="TestEngineer",
  description="Test feature X",
  prompt="Write comprehensive tests for X with >80% coverage. Run tests and report results."
)

Agent: reviewer

Purpose: Code review and quality checks When to invoke: After code changes, before finalizing How to invoke:

task(
  subagent_type="CodeReviewer",
  description="Review feature X",
  prompt="Review the implementation of X for code quality, security vulnerabilities, and adherence to @docs/coding-standards.md"
)

๐Ÿ”„ Required Workflow

After implementing ANY code:

  1. Invoke tester agent using task tool
  2. Invoke reviewer agent using task tool
  3. Summarize results to user

๐ŸŽฏ Your Task

[Describe the specific task here]


โš ๏ธ Important Reminders

  • Files: Use @path/to/file.md syntax
  • Agent invocation: Use task(subagent_type="name", ...)
  • NEVER use @agent-name to invoke agents
  • Agent names are plain text: tester, reviewer, NOT @tester

    
    ---
    
    ### Real-World Example: Perfect Prompt
    
    

    markdown

Implement User Authentication System

๐Ÿ“‹ Context Files (Load FIRST)

CRITICAL: Use read_file tool to load these before starting:

  1. @docs/CODING_STANDARDS.md - TypeScript coding patterns
  2. @docs/AUTH_ARCHITECTURE.md - Authentication design patterns
  3. @src/auth/types.ts - Existing auth type definitions
  4. @tests/auth/auth.test.ts - Existing test patterns

๐Ÿ“š Current State (Auto-loaded)

Git Context: Branch: !git branch --show-current Modified: !git status --short

Existing Auth Files: !find src/auth -name "*.ts" -type f

Dependencies: !npm list | grep -E "(jwt|bcrypt|passport)"


๐Ÿค– Available Agents

Agent: implementer

Purpose: Feature implementation Invoke with:

task(
  subagent_type="implementer",
  description="Implement auth flow",
  prompt="Create authentication system with JWT tokens, including login, logout, and session management. Follow patterns in @docs/AUTH_ARCHITECTURE.md. Include middleware, controllers, and services."
)

Agent: tester

Purpose: Test creation Invoke with:

task(
  subagent_type="TestEngineer",
  description="Test auth system",
  prompt="Write unit and integration tests for authentication module. Cover login, logout, token refresh, and session management. Ensure >85% coverage. Run tests and report results."
)

Agent: reviewer

Purpose: Security and quality review Invoke with:

task(
  subagent_type="CodeReviewer",
  description="Review auth implementation",
  prompt="Review authentication implementation for security vulnerabilities (SQL injection, XSS, CSRF), proper token handling, password security, and adherence to @docs/CODING_STANDARDS.md"
)

๐Ÿ”„ Required Workflow

You MUST follow this workflow:

  1. Read Context: Load all files marked [CRITICAL] above
  2. Implement: Create the authentication system
  3. Test: Invoke tester agent via task tool
  4. Review: Invoke reviewer agent via task tool
  5. Report: Summarize implementation, test results, and review findings

๐ŸŽฏ Task Details

Implement a complete authentication system with:

  • JWT-based authentication
  • Login/logout endpoints
  • Token refresh mechanism
  • Session management
  • Password hashing with bcrypt
  • Middleware for protected routes

Requirements:

  • Follow patterns in @docs/AUTH_ARCHITECTURE.md
  • Adhere to @docs/CODING_STANDARDS.md
  • Integrate with existing user model in @src/models/user.ts
  • Add proper error handling
  • Include request validation

โš ๏ธ Important Rules

  • Load files with @ syntax: @docs/file.md
  • Invoke agents with task tool: task(subagent_type="name", ...)
  • NEVER use @agent-name to invoke agents
  • Agent names are plain text: tester, NOT @tester
  • Shell commands auto-execute: !git status

    
    ---
    
    ## ๐Ÿ“ Anti-Pattern Examples (What NOT To Do)
    
    ### โŒ BAD PROMPT (Confusing)
    

    markdown

Use @tester and @reviewer agents to test the code. Follow @guidelines and implement authentication.


**Problems:**
- Uses `@` for agents (only loads metadata, doesn't invoke)
- No clear invocation instructions
- Mixing file and agent syntax
- No explicit workflow

### โœ… GOOD PROMPT (Clear)

markdown

Implement Authentication

Context Files

Read these using read_file tool:

Agents

Agent: tester - Invoke with task tool: task(subagent_type="TestEngineer", description="Test auth", prompt="...")

Agent: reviewer - Invoke with task tool: task(subagent_type="CodeReviewer", description="Review auth", prompt="...")

Workflow

  1. Read @docs/guidelines.md
  2. Implement feature
  3. Invoke tester agent via task tool
  4. Invoke reviewer agent via task tool

    
    ---
    
    ## ๐ŸŽจ Prompt Templates by Use Case
    
    ### Template 1: Simple Feature Implementation
    

    markdown

Implement [Feature Name]

Context

Read: @docs/standards.md

Git status: !git status --short

Task

[Detailed description]

No Agents Needed

(Simple task, no agents required)


### Template 2: Complex Feature with Agents

markdown

Implement [Complex Feature]

Context Files (Read FIRST)

  1. @docs/standards.md
  2. @docs/architecture.md

Current State

!git status --short !find src/[module] -name "*.ts"

Available Agents

Agent: implementer Invoke: task(subagent_type="implementer", description="...", prompt="...")

Agent: tester Invoke: task(subagent_type="TestEngineer", description="...", prompt="...")

Workflow

  1. Read context files
  2. Implement feature
  3. Invoke tester agent
  4. Report results

    
    ### Template 3: Code Review Task
    

    markdown

Review [Feature/Module]

Context

Files to review: !git diff --name-only main...HEAD

Recent changes: !git log --oneline -5

Agent

Agent: reviewer Invoke immediately: task( subagent_type="CodeReviewer", description="Review recent changes", prompt="Review all changes in current branch for code quality, security, and adherence to standards" )

Task

Run code review and report findings.


### Template 4: Documentation Task

markdown

Document [Feature]

Context

Implementation files: !find src/[module] -name "*.ts"

Agent

Agent: documenter Invoke: task(subagent_type="documenter", description="Document X", prompt="...")

Task

Generate comprehensive documentation for [feature].


---

## ๐Ÿ”‘ Golden Rules for Perfect Prompts

1. **Files**: Always use `@path/to/file.md`
2. **Agents**: Always use `task(subagent_type="name", ...)`
3. **Shell**: Always use `` !`command` `` for dynamic context
4. **Clarity**: Separate files, agents, and tasks into clear sections
5. **Workflow**: Always specify the execution order
6. **Agent Names**: Plain text only - `tester`, never `@tester`
7. **Context First**: Load all context before describing the task
8. **Explicit Instructions**: Tell AI exactly when and how to invoke agents

---

## ๐ŸŽฏ REAL-WORLD EXAMPLE: Your Agent Setup

Based on your actual agent configurations (task-manager subagent + orchestration agent):

### Your Agent Files Structure & Naming

**CRITICAL**: Agents are defined in MARKDOWN files. The agent NAME comes from the FILE PATH!

.opencode/ agent/ # All agents as markdown files

subagents/
  core/
    task-manager.md           # Agent name: "TaskManager"
orchestration-agent.md        # Agent name: "orchestration-agent"
code/
  reviewer.md                 # Agent name: "code/reviewer"
  tester.md                   # Agent name: "code/tester"

**Markdown Agent File Format:**

markdown

description: "Brief description of agent" mode: subagent # or "primary" or "all" temperature: 0.2 tools: read: true write: true edit: true bash: true task: true permissions: edit:

"**/*.secret": "deny"

bash:

"rm -rf *": "deny"

Agent Prompt Content Here

Your agent instructions, personality, rules, etc. All the markdown content becomes the agent's system prompt.


**How OpenCode determines agent names (from source code):**
1. Scans `.opencode/agent/**/*.md` files recursively
2. Parses YAML frontmatter (between `---` markers) for config
3. Uses markdown content as the agent's system prompt
4. Agent name = file path from `agent/` directory (minus `.md`)

**Examples:**
- File: `.opencode/agent/task-manager.md` โ†’ Name: `task-manager`
- File: `.opencode/agent/TaskManager.md` โ†’ Name: `TaskManager`
- File: `.opencode/agent/code/reviewer.md` โ†’ Name: `code/reviewer`

**No opencode.json needed!** Everything is in markdown.

### โŒ WRONG: Confusing Prompt

markdown Use @task-manager to break down the feature Have @orchestration-agent coordinate the work


**Problems:**
- Using `@` for agent invocation (only loads metadata)
- AI won't actually invoke the agents
- Wrong agent name - should include full path: `TaskManager`
- Confusing agent files with agent invocation

### โœ… CORRECT: Clear Prompt

markdown

Implement User Dashboard Feature

๐Ÿ“‹ Context Files (Load FIRST)

Agent Documentation (optional - only if you need to understand agent capabilities):

  • @.opencode/agent/orchestration-agent.md - Main agent guidelines
  • @.opencode/agent/TaskManager.md - Task breakdown process

Project Documentation:

Current State: Branch: !git branch --show-current Files: !find src/dashboard -name "*.ts"


๐Ÿค– Available Agents

Agent: TaskManager (Subagent)

IMPORTANT: Agent is defined in a MARKDOWN file. The agent name comes from the file path!

File location: .opencode/agent/TaskManager.md Agent name: TaskManager (path from agent/ directory) Format: Markdown with YAML frontmatter

File structure:

---
description: "Breaks down complex features into subtasks"
mode: subagent
temperature: 0.1
tools: { read: true, write: true, ... }
---

# Task Manager Agent Prompt
[Your agent instructions here...]

Purpose: Break down complex features into atomic subtasks

When to invoke:

  • Feature has 4+ components
  • Need structured task breakdown
  • Complex dependencies exist

How to invoke:

task(
  subagent_type="TaskManager",
  description="Break down dashboard feature",
  prompt="Break down the user dashboard feature into atomic subtasks. Feature includes: profile widget, activity feed, notification center, and settings panel. Create structured task files in /tasks/ directory following your two-phase workflow."
)

What it does:

  1. Analyzes feature and creates subtask plan
  2. Waits for your approval
  3. Creates task files in tasks/subtasks/{feature}/
  4. Returns task sequence and dependencies

๐Ÿ”„ Required Workflow

For complex features (4+ components):

  1. Invoke task-manager to break down the feature

    task(
     subagent_type="TaskManager",
     description="Break down dashboard",
     prompt="Analyze and break down user dashboard feature with profile, activity, notifications, and settings components. Create task files with dependencies and acceptance criteria."
    )
    
  2. Review the task plan (agent will request approval)

  3. Approve and let agent create files

  4. Implement tasks sequentially based on dependencies

  5. Validate each task against acceptance criteria


๐ŸŽฏ Your Task

Implement a user dashboard feature with:

  • Profile widget (avatar, name, stats)
  • Activity feed (recent actions, timestamps)
  • Notification center (alerts, read/unread states)
  • Settings panel (preferences, theme toggle)

Requirements:

  • Follow @docs/architecture.md patterns
  • Responsive design
  • Real-time updates for notifications
  • Accessibility compliant

Since this is complex (4+ components), invoke the task-manager agent first.


โš ๏ธ Important Notes

  • Agent files (.md in .opencode/agents/): Use @ to load as documentation
  • Agent invocation: Use task(subagent_type="name", ...) to actually run the agent
  • Agent names: Plain text - task-manager, NOT @task-manager
  • The orchestration agent is your primary agent (already active)
  • Invoke task-manager when you need feature breakdown

    
    ---
    
    ## ๐ŸŽจ Prompt Templates for Your Specific Agents
    
    ### Template 1: Complex Feature (Needs Task Breakdown)
    
    

    markdown

Implement [Complex Feature Name]

๐Ÿ“‹ Context

Read these files:

Current state: !git status --short !find src/[module] -type f


๐Ÿค– Agent: TaskManager

Invoke immediately for task breakdown:

task(
  subagent_type="TaskManager",
  description="Break down [feature]",
  prompt="Break down [feature description] into atomic subtasks. Include:
  - Component 1: [details]
  - Component 2: [details]
  - Component 3: [details]
  
  Create task files in /tasks/ with dependencies, acceptance criteria, and test requirements. Follow your two-phase workflow (plan โ†’ approve โ†’ create files)."
)

๐ŸŽฏ Task Details

[Detailed feature requirements]


๐Ÿ”„ Workflow

  1. Invoke task-manager for breakdown
  2. Review and approve task plan
  3. Implement tasks in dependency order
  4. Validate against acceptance criteria
  5. Report completion

    
    ### Template 2: Simple Task (Direct Execution)
    
    

    markdown

[Simple Task Name]

๐Ÿ“‹ Context

Read:

  • @docs/coding-standards.md

Current state: !git status --short


๐ŸŽฏ Task

[Task description - simple, 1-3 files]


โš ๏ธ Notes

  • Simple task, no task-manager needed
  • Execute directly
  • Follow coding standards from @docs/coding-standards.md

    
    ### Template 3: Coordination Task (Uses Orchestration Features)
    
    

    markdown

Coordinate [Multi-Step Feature]

๐Ÿ“‹ Context

Read orchestration guidelines:

Current state: !git status --short


๐Ÿ”„ Coordination Workflow

This task requires coordination across multiple steps:

  1. Break down feature using task-manager
  2. Implement core components
  3. Delegate complex subsystems if needed
  4. Validate integration
  5. Report completion

๐Ÿค– Agents Available

Agent: TaskManager - For feature breakdown Invoke: task(subagent_type="TaskManager", description="...", prompt="...")

Agent: general - For delegated complex work (if needed) Invoke: task(subagent_type="general", description="...", prompt="...")


๐ŸŽฏ Task

[Complex coordinated task description]


๐Ÿ“ Orchestration Rules

From @.opencode/agents/orchestration-agent.md:

  • Request approval before execution
  • Stop on failures (don't auto-fix)
  • Report โ†’ Propose โ†’ Approve โ†’ Fix
  • Confirm before cleanup

    
    ---
    
    ## ๐ŸŽฏ Key Insights for Your Setup
    
    ### Your Orchestration Agent (Primary)
    - **Already active** - it's processing your prompts
    - **Has task delegation** capability
    - **Follows approval workflow**
    - **Can invoke task-manager** when needed
    
    ### Your Task-Manager Subagent
    - **Invoked via task tool** when you need breakdown
    - **Two-phase workflow**: Plan โ†’ Approve โ†’ Create
    - **Creates files** in `tasks/subtasks/{feature}/`
    - **Returns structured** task plans
    
    ### Critical Distinctions
    
    | What | File Syntax | Agent Invocation |
    |------|-------------|------------------|
    | Load agent docs | `@.opencode/agent/TaskManager.md` | N/A |
    | Invoke task-manager | N/A | `task(subagent_type="TaskManager", ...)` |
    | Reference in text | "the task-manager agent" or "TaskManager" | N/A |
    | Load project docs | `@docs/standards.md` | N/A |
    
    **KEY INSIGHT**: The agent name comes from the file path structure, NOT just the filename!
    
    ### Decision Flow
    
    

Is it complex (4+ components)? โ†“ YES Invoke task-manager โ†’ Get breakdown โ†’ Implement tasks

โ†“ NO Execute directly (orchestration agent handles it)

Need to understand agents? โ†“ YES Load agent docs: @.opencode/agents/[agent].md

โ†“ NO Skip - just invoke when needed


---

---

## ๐Ÿค” Design Philosophy: Why List Subagents?

**You might ask**: "Why do I need to tell the AI about subagents in my prompt when the `task` tool already lists them?"

**You're right - it's redundant!** Here's the reality:

### The Ideal World (How It Should Work)

markdown

tools:

task: true # AI should figure out the rest

Your Agent

Delegate complex work to specialized subagents.


The AI should:
1. โœ… See the `task` tool
2. โœ… Read the tool's description (which lists agents)
3. โœ… Use it when appropriate

### The Real World (Current AI Limitations)

Current AI models don't always:
- โŒ Read tool descriptions carefully
- โŒ Remember to check available tools
- โŒ Connect "complex task" โ†’ "delegate" โ†’ "use task tool"

So we **compensate** by:
- Explicitly mentioning agents in prompts
- Providing invocation examples
- Repeating instructions

### Two Approaches

**Option 1: Minimal (Trust the Tool)**

markdown For complex work, use the task tool to delegate to specialized subagents. Available agents are documented in the task tool description.

- โœ… Clean, minimal
- โš ๏ธ AI might not delegate when it should

**Option 2: Explicit (Be Redundant)**

markdown Available subagents via task tool:

  • TaskManager - For feature breakdown
  • TestEngineer - For testing

Invoke with: task(subagent_type="...", description="...", prompt="...") ```

  • โš ๏ธ Redundant with tool description
  • โœ… AI consistently delegates appropriately

Recommendation:

Last Updated: 2024-11-21 OpenCode Version: Latest