opencode-config

Use when converting files to Markdown format for LLM consumption, document analysis, or text extraction. Supports PDF, Office documents, images, audio, HTML, and more via Microsoft's markitdown. Don't use for simple text file reads, existing Markdown files, or when the file is in a usable format.

Use when creating or modifying custom opencode commands in the `commands/` directory. Covers markdown command files, frontmatter options (description, agent, model, subtask), prompt templates with $ARGUMENTS, shell output injection, and file references.

Use when rendering mermaid diagrams to PNG, SVG, or PDF images. Handles both .mmd files and inline mermaid code blocks in markdown files. Don't use for creating mermaid syntax or GraphViz/DOT diagrams.

Use when creating a comprehensive architecture document for a codebase. First explores the codebase using the exploring-code skill, then writes a detailed architecture document. Don't use for quick documentation lookups or single-file questions: only use when asked to create or update architectural documents.

Use to do a thorough exploration of an existing codebase. Always use this when asked to explore a codebase/repo/project. Always use it when starting a task that requires deep knowledge of the codebase. Don't use for quick lookups or single-file questions.

You MUST use when creating, modifying, or reviewing GitHub Actions workflow files. For security reasons it is VITAL that you use this skill when working with third party actions (including `actions/checkout` and other official actions).

Use when parsing, querying, transforming, or extracting data from JSON files, API responses, or JSON streams. Always use the `jq` CLI for all JSON operations. Do not use for YAML, XML, CSV, or plain-text parsing. Never build JSON from scratch in Python, Node, or other languages when `jq` can handle it.

Use when designing software architecture or new features: producing technical design documents with model definitions, service code, API contracts, migration strategies, and testing plans. Works alongside OpenSpec proposals or stands alone for feature design. This is NOT the `design.md` UI design system format (colors, typography, components) — this is purely for engineering architecture documentation.

Use when implementing, extending, or adapting Rob's Style Guide design system in any framework (vanilla HTML, Svelte, React, etc.). Covers theming, colors, typography, components, Prism.js syntax highlighting, and Tabler Icons. Don't use for generic styling, Tailwind projects, or unrelated design systems.

Use when bootstrapping the design of a brand new project — producing a plan.md through iterative exploration. Don't use for modifying existing plans, implementing features, or working with established codebases.

Use when creating a new Python project from Rob's Awesome Python Template (cookiecutter). Don't use for adding Python to existing projects, installing packages, or working with established codebases.

Use when asked to create, generate, or scaffold a new Agent Skill. Don't use for modifying existing skills or writing general documentation.

All actions on GitHub must use this skill. Covers pull requests, issues, repositories, releases, GitHub Actions, searches, and API requests via the `gh` CLI.

Use when initializing or setting up OpenSpec in a project that doesn't have it yet. Don't use for creating, applying, exploring, or tinkering with OpenSpec proposals.

Use when creating a pull request, preparing changes for review, or pushing work to GitHub. Handles quality checks, branch management, conventional commits, openspec archival, and PR creation end-to-end.

Use when asked to "fix things", "qa", "run tests and fix things", "test until clean", or similar requests to iteratively run quality checks and fix failures until everything passes. Don't use for single-purpose tasks like running only tests or only linting without fixes.