// 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.
| name | bootstrapping-plan |
| description | 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. |
| license | MIT |
| metadata | {"author":"Robert Hafner","source":"https://github.com/tedivm/opencode-config"} |
When a user wants to design a new project from scratch, guide them through an iterative exploration that produces a plan.md in ./tmp/. The plan captures vision, architecture, feature requirements, data model, technology stack, implementation phases, and open questions.
Read the existing codebase skeleton — Understand existing structure, dependencies, Docker setup, and template conventions. This grounds the plan in reality.
Initial exploration — Read the user's requirements (bullet points, feature list). Identify vague areas that need clarification.
Think through architecture — Visualize the system. Identify tension points, unclear requirements, and key design decisions. Present an ASCII/mermaid diagram.
Ask focused questions — Surface ambiguities. Group related questions. Present options where relevant. Wait for answers before proceeding.
Draft the plan — Create ./tmp/plan.md with all sections (see template below).
Iterate — As the user corrects, refines, or adds to the plan, update it in place. Each iteration should improve accuracy without losing previous work.
The plan.md must contain these sections in order:
One paragraph describing what the project is and what it does.
Mermaid diagram showing all interfaces, service layers, and data stores. Rules:
graph LR with subgraph groupings for External, Application, Compute, DataNumbered sections for each major feature area. Each section:
Mermaid ER diagram with:
erDiagram syntaxBullet list of technologies with their roles. Mark TBD items clearly.
Numbered phases in logical order. Each phase: name + brief description.
Unresolved decisions that need answers before implementation begins.
As the user refines the plan, expect these common corrections:
Each correction is a surgical edit to the plan — don't rewrite sections that haven't changed.
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 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.
Use when doing a thorough exploration of an existing codebase. Guides a subagent through reading documentation, reviewing tests, analyzing architecture, and producing a comprehensive overview. Don't use for quick lookups or single-file questions.
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 creating, modifying, or reviewing GitHub Actions workflow files. Covers workflow syntax, action selection, dependabot configuration, and CI/CD best practices.