chelch5/opencode-team-bootstrap

OpenCode Team Bootstrap

Use this skill to design the agent team for the project. This is creative work — you analyze the project and customize the agents, tools, and plugins to match.

Context

The repo-scaffold-factory generates a BASE set of generic agent templates. These are a starting structure, not the final output. Your job is to read the canonical brief and customize these agents to be project-specific.

Procedure

1. Read the canonical brief

Read the project brief to understand:

• What kind of project this is (web app, API, MCP server, CLI tool, library, etc.)
• What stack/framework is being used
• What domains the project spans (UI, backend, database, infrastructure, etc.)
• What the acceptance criteria are

2. Plan the agent team

Decide which agents this project needs. Start from the baseline and add/modify based on project type.

Baseline agents (always present):

| Agent | Role | Permissions | |-------|------|------------| | Team Leader / Orchestrator | Visible orchestrator, delegates to specialists | Read + delegate | | Planner | Turns tickets into implementation plans | Read only | | Plan Reviewer | Approves/rejects plans before implementation | Read only | | Implementer (1+) | Implements the approved plan | Read + write + execute | | Code Reviewer | Reviews for correctness and regressions | Read only | | Security Reviewer | Reviews for trust boundaries and secrets | Read only | | QA / Tester | Validates and checks closeout readiness | Read only | | Docs / Handoff | Closeout artifact synchronization | Read + write |

Project-specific agents (add based on project type):

| Project Type | Additional Agents | |-------------|------------------| | UI / Frontend | Component implementer, accessibility reviewer | | API | API implementer with schema awareness, contract validator | | MCP Server | Protocol implementer, tool definition specialist | | Database-heavy | Migration specialist, schema reviewer | | CLI / Library | API surface reviewer, documentation specialist | | Full-stack | Separate frontend + backend + infra implementers |

You may create MULTIPLE implementer-type agents for different domains. Default to one visible team leader with explicit safe parallel lanes. Only add a hierarchy when the project has strong non-overlapping domains.

Utility agents (include based on need):

• Repo evidence gathering, GitHub research, read-only shell inspection
• Evidence compression, ticket/state consistency, external research

Omit utility agents that aren't useful for the project.

3. Customize agent prompts

For EVERY agent, rewrite the generic prompt to be project-specific:

What to customize:

• Description: mention the actual project and what the agent does for it
• First instruction: state the agent's role in the context of THIS project
• Tool permissions: adjust based on what the agent actually needs
• Skill references: reference project-specific skills
• Delegation targets: reference the actual agents that exist

What NOT to change:

• Model assignments (use provided model strings)
• Hidden/visible settings (only the orchestrator should be visible)
• The fundamental stage-gate workflow (planning → review → implement → review → QA → handoff)

Example customization for a React web app:

Generic: "You produce decision-complete plans for a single ticket."

Customized: "You produce decision-complete plans for a single ticket in the Example App React frontend. Plans must specify which components are affected, what state management changes are needed, and what test scenarios to cover."

4. Write agent files

Write each agent definition to the appropriate config directory. Verify:

• Every agent has description, model, permissions
• Tool permissions are explicit (deny by default, allow specifically)
• Skill references point to skills that exist
• Delegation targets reference agents that exist
• Read-only agents have NO write permissions
• Only implementer and docs agents have write access

5. Review project-specific tools

Keep standard workflow tools (artifact write, ticket lookup, ticket update, workflow state, etc.). Consider adding project-specific tools only when genuinely needed:

• Database projects might need a migration status tool
• API projects might need a schema validation tool
• Component projects might need a component scaffolding tool

6. Review plugins and commands

Keep standard enforcement plugins (stage-gate enforcer, tool guard, invocation tracker). Customize commands (kickoff, resume) to reference project-specific agents and skills.

Team design principles

• One visible orchestrator, all specialists hidden
• No ask permissions — agents don't prompt the user during autonomous work
• Explicit delegation allowlists — agents can only delegate to named agents
• Commands are for humans; tools/plugins handle autonomous internal flow
• Workflow tools for stage control, not raw file edits

Output contract

<agent-config-dir>/
├── agents/           # One file per agent with project-specific prompts
├── skills/           # Project-local skills (populated by project-skill-bootstrap)
├── tools/            # Standard + project-specific tools
├── plugins/          # Standard enforcement plugins
├── commands/         # Human-facing commands (kickoff, resume)
└── config/           # Stage-gate and workflow configuration

Failure handling

• No canonical brief: Generate generic agents, flag for customization later
• Stack not supported: Create generic implementer/reviewer, note stack-specific gaps
• Agent client not installed: Generate files anyway — they're valid for future use
• Conflicting agent names: Use project prefix (e.g., myproj-implementer)

References

• This is step 4 of the scaffold-kickoff flow — continue to ../ticket-pack-builder/SKILL.md
• Apply ../agent-prompt-engineering/SKILL.md rules when hardening prompts