Separate task modes
Study the division of agent responsibilities when deciding which workflow stages should inspect, plan, or change a repository.
OpenCode
Study OpenCode’s coding-agent workflow to improve how your own tasks move from investigation to changes and review. Use its interaction and extension design as references for development work organized in Floatboat.
Separate code exploration from implementation
Describe the repository investigation or code change you want to make reviewable. Use the request to separate discovery, editing, and acceptance, then assess whether OpenCode's task modes or extension surfaces offer a useful pattern for your existing tools.
Provide the feature, repository area, acceptance rules, and tools that may write files.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatYour request for Floatboat
Preview and copy the request. It is not sent automatically from this page.
Reference: OpenCode https://github.com/anomalyco/opencode Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Use OpenCode’s plan/build workflow as a reference for adding search to my application. First define a read-only investigation of the data and routes, then a separate implementation phase. List the evidence I should review before allowing edits. Expected deliverable: An exploration brief and an implementation handoff with distinct permissions and acceptance checks.
About OpenCode
OpenCode is an open-source AI coding agent published by Anomaly. It connects task conversations with repository tools. The model service supplies reasoning and generation, the execution environment handles files and commands, and the application coordinates the workflow.
For workflow design, OpenCode is a concrete implementation to study rather than a requirement to switch products. Its agent modes and interactive feedback can inform how you separate investigation from implementation, expose a change for review, and add task-specific integrations to your own environment.
The project source is MIT licensed. Model-provider accounts, subscription access, remote services, and community additions have separate requirements. The source can be inspected and adapted without implying that all associated hosted services are free or included.
Workflow Mechanisms to Learn From
OpenCode's modes, tool feedback, and extension interfaces address different parts of coding work. Compare how they separate investigation from modification, make results inspectable, and expose project-specific integrations without confusing the agent application with its model service.
Expose useful feedback
Use the interactive workflow as a reference for showing progress and tool results where a person can make an informed decision.
Evaluate integrations by task
Inspect an integration’s tools and maintainer before adapting the pattern to the development workflow you actually need.
Use Cases for OpenCode
Repository investigation, code review, and development-tool connections require different permissions and outputs. Explore how OpenCode's workflow can inform a read-only discovery stage, an inspectable change pipeline, and bounded extension tests for your own project.
A repository investigation stage
Before implementing a repository feature, define what the agent must learn about the relevant files, routes, and data entry points. Keep the investigation read-only while collecting constraints and unresolved decisions. Its findings should tell the implementation stage where to work and which questions still need an answer.
A reviewable change pipeline
A proposed code change should remain distinct from its acceptance. Present the diff with relevant test results and the context the responsible reviewer needs, then make acceptance an explicit step. This gives the workflow an inspectable change pipeline rather than treating generated code as finished work.
A task-specific development tool
A project's existing checks or external development systems may need a task-specific extension. Compare the documented interfaces with the available commands, API requirements, and permitted access. Assess compatibility first, then run one bounded tool-call test to establish what the proposed connection can actually do.
Separate model access from tool permissions
Choosing a model provider and granting an agent access to repository tools solve different problems. Compare OpenCode's model-service boundary with the environment where commands and edits occur, using your task's actual access requirements. Prepare a plan that states both sets of prerequisites so an authenticated model connection is not treated as approval for every available tool action.
Build a reviewable OpenCode handoff
A reviewable OpenCode-inspired workflow needs a clear result from each stage. Define the investigation handoff and tool boundaries before implementation, then use diffs and verification evidence to decide whether the proposed change should be accepted in your repository.
Describe the desired handoff
Write down what investigation must deliver before planning or implementation can safely continue.
Limit available actions
Match tool access and the active mode to each stage rather than giving every step the same ability to change files.
Check the result and feedback
Evaluate whether the workflow makes errors visible and gives the user enough evidence to accept or revise the change.
Related Software Projects
Compare the workflows, operating requirements, and source licenses of these projects.
OpenCode FAQ
Is OpenCode a model provider?
OpenCode is a coding-agent application that provides the interface and execution workflow. The model used by a session depends on its provider configuration; the application and model service have different responsibilities.
Should OpenCode be called a Skill?
No. It is an independent coding-agent project. Skills or other instructions can form part of an agent workflow, but they do not replace the application that runs the workflow.
Who publishes the official repository?
The repository is anomalyco/opencode, under Anomaly’s GitHub organization. Community integrations and similarly named projects should be checked separately rather than attributed to Anomaly automatically.
Are planning and building the same mode?
The official project documents different agent modes for different responsibilities. Read the selected mode’s behavior and permissions before assuming a planning session can or should make changes.
Does MIT include a free model subscription?
No. It covers the application source. Provider accounts, model usage, commercial subscriptions, and external integrations have their own conditions and costs.
Must I switch products to use these workflow ideas?
No. You can first use OpenCode as a reference for task structure, tool boundaries, and result review in your existing workflow. Reusing software is a separate choice that requires compatibility, permissions, and license checks; applying the design ideas does not automatically connect the software to Floatboat.