Open-Manus
Open-Manus models and system prompts
Browser
Browser automation agent responding in JSON format with goal evaluation, memory tracking, and sequential action execution (clicking, typing, scrolling, navigation) supporting multi-page workflows.
Manus
OpenManus all-capable AI agent with tools for programming, research, file processing, web browsing, and human interaction — uses proactive tool selection and step-by-step task breakdown.
Mcp
Model Context Protocol (MCP) agent with access to dynamically-exposed MCP server tools — emphasizes proper parameter formatting, error handling, and sequential tool calling with clear user communication.
Planning
Task planning agent that creates structured multi-step plans with logical outcomes, adaptive progress tracking, and a finish action for concluding completed tasks.
Swe
Autonomous software engineer operating in a 5-file-window editor interface — requires proper indentation for all edits, single tool call per turn, and documented thought process before each command.
Toolcall
Minimal toolcall executor agent with a terminate function for stopping interactions when tasks are complete.
Visualization
Data analysis and visualization agent for complex requests — uses step-by-step tool selection within a workspace directory and outputs an analysis conclusion report as the final deliverable.
About the Open-Manus system prompts
This collection holds 7 Open-Manus system prompts, covering Browser, Manus and Mcp. Each entry is the instruction text that sits above the conversation and shapes how the model answers — its role, its tone, the tools it may reach for, and the things it must refuse. Reading them is the fastest way to understand why a Open-Manus model behaves the way it does, and the fastest way to borrow patterns that already work.
Every prompt on this page is reproduced in full, with no truncation or paraphrase, so you can copy the exact wording into your own build and compare it line by line against the prompts other providers ship.
How to use them
Treat a Open-Manus prompt as a starting structure, not a script to paste unchanged. The parts worth keeping are the scaffolding: how the role is stated up front, how tool use is gated, how refusals are worded, and how output format is pinned down. The parts worth replacing are the product-specific details — feature names, brand voice, and any capability your own model does not have.
A prompt tuned for one model rarely transfers cleanly to another. Context windows, tool-calling conventions, and refusal behaviour all differ, so run a short evaluation set through your target model before you rely on a borrowed prompt in production.
What is a system prompt?
A system prompt is the hidden first message in a conversation. The user never sees it, but the model reads it before every reply, which makes it the single strongest lever over an assistant’s behaviour — stronger than few-shot examples and, in most cases, stronger than anything the user types afterwards. That is why published and leaked system prompts are studied so closely: they are the clearest available record of how a production assistant was actually built.
How to read one critically
A system prompt is a snapshot, not a specification. Providers revise them continuously, sometimes weekly, and a prompt captured in one release may already be out of date — so treat the date on an entry as part of the evidence. Length is not quality either: some of the most effective prompts here are a few hundred words, while others run to tens of thousands because they carry an entire tool schema inline.
The most transferable material is usually the negative space — the explicit “do not” rules and the tie-breakers that tell the model what to do when two instructions conflict. Those are the parts written after something went wrong in production, which makes them the parts worth copying.