OpenCode has become an essential part of my development workflow. In this post, I’ll walk you through my custom configuration, including my settings, custom commands, and MCP integration for enhanced documentation lookup.

    Table of Contents

    My opencode.json Configuration

    My configuration file is located at ~/.config/opencode/opencode.json:

    {
  "$schema": "https://opencode.ai/config.json",
  "autoupdate": true,
  "tui": {
    "scroll_speed": 3
  },
  "agent": {
    "code-reviewer": {
      "description": "Reviews code for best practices and potential issues",
      "model": "github-copilot/claude-opus-4.5",
      "prompt": "You are a code reviewer. Focus on security, performance, and maintainability.",
      "tools": {
        "write": false,
        "edit": false
      }
    }
  },
  "mcp": {
    "context7": {
      "type": "remote",
      "url": "https://mcp.context7.com/mcp",
      "enabled": true
    }
  }
}

    Configuration Breakdown

    Auto Updates

    I keep autoupdate: true so OpenCode stays current without manual intervention.

    TUI Settings

    The scroll_speed: 3 makes navigating through long responses faster and more comfortable.

    Custom Agent: Code Reviewer

    I’ve configured a custom code-reviewer agent that:

    This is perfect for getting feedback without risking unwanted file changes.

    MCP Integration: Context7

    I enable the Context7 MCP server for up-to-date documentation and code examples. This gives OpenCode access to comprehensive library documentation when working with various APIs and frameworks.

    Custom Commands

    My custom commands are stored in ~/.config/opencode/command/:

    1. commit

    File: ~/.config/opencode/command/commit.md

    Creates conventional commits based on staged changes:

    ---
description: create a git commit based on current changes
agent: build
model: opencode/kimi-k2.5-free
---

Create a conventional commit for the current staged changes, if there is no staged files, ask users whether they want to stage all changes and create a commit.
DO NOT STAGE FILES by yourselve without users confirmation! Only inspect the staged changes.
Then create a commit with a proper conventional commit message following the conventional commits specification.
Use the same language as the previous commit messages.

    Usage: /commit

    2. update_readme

    File: ~/.config/opencode/command/update_readme.md

    Intelligently updates README files based on the actual codebase:

    ---
description: check and update README files based on related code
agent: build
model: opencode/kimi-k2.5-free
---

# README Update Command

## Instructions

1. **Find all README files** in the repository using glob patterns (`**/README.md`, `**/README`, `**/readme.md`, `**/README.txt`, `**/README.rst`)

2. **If no README files found**: Inform the user and ask if they want to create one.

3. **If README files found**: Present the list to the user and ask if they want to update any of them.

4. **Selection options** (when multiple READMEs exist):
   - Provide a multi-select list of all found README files
   - Include a "Select All" option at the top
   - Allow custom input for the user to specify paths manually
   - Let user select multiple files at once

5. **For each selected README**:
   - Identify the directory where the README resides
   - Analyze the code in that directory and subdirectories to understand:
     - Project structure
     - Main functionality
     - Dependencies
     - Usage patterns
     - Configuration options
     - API endpoints (if applicable)
   - Compare the current README content with the actual codebase
   - Identify sections that are outdated, missing, or incorrect
   - Propose updates to the user before making changes

6. **Before updating each README**:
   - Show the user what changes will be made
   - Ask for confirmation before applying changes
   - Preserve existing formatting style and structure where possible
   - Keep any custom sections the user has added

## Important Rules

- DO NOT update any README without explicit user confirmation
- DO NOT remove existing content unless it's clearly outdated or incorrect
- PRESERVE the original tone and style of the README
- KEEP badges, images, and links intact unless they're broken
- ASK the user if you're unsure about any changes

    Usage: /update_readme

    Directory Structure

    ~/.config/opencode/
├── opencode.json          # Main configuration
└── command/
    ├── commit.md          # Git commit helper
    └── update_readme.md   # README maintenance

    Dotfiles Integration

    Since I manage my dotfiles with GNU Stow, the opencode configuration is symlinked from my dotfiles repository:

    dotfiles/opencode/.config/opencode/ -> ~/.config/opencode/

    This means any changes to my opencode config are version controlled and easily deployed across machines. If you want to learn more about my dotfiles setup, check out my detailed post on Dotfiles Management.

    Conclusion

    This setup streamlines my development workflow by:

    1. Automating commit message creation with conventional commit format
    2. Keeping README files in sync with actual code changes
    3. Getting code reviews without risking unwanted modifications
    4. Accessing up-to-date documentation through MCP integration

    The modular approach makes it easy to add new custom commands as needed. What custom commands have you found most useful?