StaticEng

Don't just code with AI. Build enterprise-grade software.

StaticEng is an OpenCode plugin that installs the StaticEng Collective: an AI-native software development team composed of specialized agents with distinct roles, handoff rules, and verification gates.

Instead of giving you a single generic assistant flow, StaticEng gives you a small software company inside OpenCode. The collective includes product, architecture, development, QA, review, and design roles that collaborate through explicit artifacts such as SCRs, task files, evidence packets, and documentation updates.

Install

Add the plugin to your OpenCode config:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["@staticeng/opencode-staticeng"]
}

Then restart OpenCode, open the target repository, and start talking to the product_manager agent (PMA).

PMA will guide the repository setup flow and, when needed, initialize StaticEng inside the repo for you. The user does not need to manually run StaticEng commands to get started.

Configure

During setup, PMA can initialize the repository and create .staticeng/.config/staticeng.yaml. StaticEng reads this file for repository-local defaults, feature flags, policy extraction settings, and per-agent config overrides.

Repository-local policy overrides live in .staticeng/policies/. If a policy file is not present there, StaticEng falls back to the bundled plugin default automatically.

Repository-local full agent definitions can live in .staticeng/agents/. Use this folder to override a bundled agent's base prompt or define a brand new custom repository agent.

Repository-specific additive agent instructions can live in .staticeng/agent-additions/.

Repository Customization

• .staticeng/policies/*.md: shared repository policy overrides used by multiple agents
• .staticeng/agents/<agent>.md: full repository-local agent definition that overrides a bundled agent or defines a new custom agent
• .staticeng/agent-additions/<agent>.md: additive repository-specific instructions appended to a bundled or custom agent prompt
• .staticeng/.config/generated/agents/: generated final prompt dumps for inspection when features.debug_dumps is enabled
• .staticeng/.config/generated/policies/: generated reference copies of bundled default policies when policies.extract_defaults is set to all

staticeng_init also creates README placeholders in these folders so repositories can discover what each folder is for without those README files being treated as agents.

The scaffolded README files in .staticeng/agents/ and .staticeng/agent-additions/ also list the common available plugin: and policy: includes that custom agents can reuse.

Runtime prompt resolution prefers repository-local policies, agent definitions, and agent additions when present, while keeping the plugin-owned workflow and role model intact by default.

StaticEng supports two team presets:

• mini: PMA + BA + Tech Lead for simple repositories and tiny / standard tasks
• full: the complete collective, including advanced specialists for PMA-led direct delegation

If team_mode is not set in an existing repository, StaticEng treats it as full by default.

Quick links:

• Installation
• Configuration
• Releasing
• Workflow Agents
• Workflow Model
• Plugin Tools
• Mini Team Mode
• Full Team Mode
• Documentation Structure

Release

StaticEng ships for this fork as the npm package @staticeng/opencode-staticeng.

• Local verification: npm run release:check
• Push to dev: auto-publish prerelease (rc)
• Push to main: auto-publish stable release

For the full release setup, required secrets, and branch-based versioning behavior, see Releasing.

Team Modes

| Team Mode | Available Agents | Supported Task Complexity | Flow Guide | | :--- | :--- | :--- | :--- | | mini | product_manager, business_analyst, tech_lead | tiny, standard | Mini Team Mode | | full | Full StaticEng Collective, including technical_architect, developer, qa_engineer, and ui_ux_designer | tiny, standard, complex | Full Team Mode |

Workflow Agents

The StaticEng Collective operates like a role-based software development team:

• product_manager (Product Manager Agent, PMA): Default orchestrator and routing agent.
• business_analyst (Business Analyst, BA): Requirements and product-truth steward.
• technical_architect (Technical Architect): Architecture, interfaces, and impact mapping.
• tech_lead (Tech Lead): Behavioral verification and technical sign-off.
• developer (Developer): Implementation and test authoring.
• qa_engineer (QA Engineer): Verification and test coverage.
• ui_ux_designer (UI/UX Designer): Visual and interaction review.

Together, these agents act as a coordinated delivery team rather than a loose set of tools. PMA manages the work, specialists own their disciplines, and the workflow enforces that major changes are specified, verified, and documented before closure.

Host Sanitize CLI

StaticEng also ships a packaged CLI for host-wide cleanup outside the agent tool surface:

npm run sanitize:host -- --dry-run
npm run sanitize:host --
npm run sanitize:host -- --opencode-db-path ~/.local/share/opencode/opencode.db
npm run sanitize:host -- --host my-server --dry-run

From an installed package, the npm bin is also available when your environment links package binaries:

staticeng-sanitize-host --dry-run

staticeng-sanitize-host scans the OpenCode SQLite database for every distinct opened worktree path, runs the shared StaticEng repair/migration logic for each existing directory, validates the result, and removes repository-local .staticeng/agents/*.md and .staticeng/policies/*.md override files except README.md.

Important safety notes:

• Default mode applies changes; run --dry-run first to preview migrations, repairs, validations, and override deletions.
• The default local database is ~/.local/share/opencode/opencode.db; --opencode-db-path may point to either the OpenCode data directory or the database file.
• Apply mode creates one host-level backup zip at ~/.staticeng_sanitize_backup/<datetime>.zip before deleting override files. It does not create per-repository backups.
• The sanitizer processes paths with .nomadwork/.nomadworks, root StaticEng artifacts (tasks/, evidences/, docs/scrs/, codemap.yml, codemap.yaml), or removable local overrides under .staticeng/agents/*.md / .staticeng/policies/*.md. It runs full repair for legacy .nomadwork/.nomadworks, migrates root StaticEng artifacts into .staticeng, and otherwise only backs up/removes overrides.
• Remote mode uses SSH and executes staticeng-sanitize-host on the target host, so ~, default DB paths, backups, and permissions are those of the remote account.
• Missing or inaccessible repositories are reported and do not stop the run.

Plugin Tools

StaticEng provides these plugin tools:

• staticeng_init
• staticeng_validate
• staticeng_repair

For arguments, behavior, and team-mode availability, see Plugin Tools.

Task Model

• Complexity: tiny, standard, complex
• Track: implementation, investigation, spec
• Slice: foundation, core, logic, ui, polish, qa, docs

Use complex for work that needs an approved SCR, slice-based decomposition, and direct specialist delegation by PMA. Keep tiny and standard tasks direct and bounded.

What Is An SCR?

SCR stands for Spec Change Request.

An SCR is the workflow artifact used to define and approve a meaningful change before implementation starts. It records:

• the problem being solved
• the proposed specification change
• the intended implementation direction
• acceptance criteria
• review and approval state

StaticEng uses SCRs so the team does not jump straight from a vague request into code. The SCR gives the Product Manager Agent, Business Analyst, Tech Lead, and other specialists a shared source of truth for what the change is supposed to achieve before delivery work begins.

In practice, SCRs help:

• reduce missed requirements and hidden assumptions
• separate proposed change from implemented truth
• make complex work reviewable before coding starts
• provide a stable anchor for decomposition into tasks

Task Flow

StaticEng uses different operating flows depending on the configured team mode.

• For the lightweight operating path, see Mini Team Mode
• For the complete collective path, see Full Team Mode

Parallelism

Until dedicated git worktree support lands, StaticEng supports limited parallelism:

• one shared-worktree implementation task at a time
• parallel investigation and spec tasks when they avoid conflicting edits

For deeper workflow details, use the linked docs above.