What task are you trying to do?

We want PawWork to provide one consistent product behavior across providers and model families such as Kimi, GLM, Qwen, Gemini, Claude, and GPT.

PawWork should not maintain long model-family behavior prompts. The model may differ, but PawWork's instructions about when to act, how to use tools, how cautious to be, how to communicate, and how to respect user control should stay the same.

What do you do today?

The session system prompt path currently selects a behavior prompt based on model.api.id in packages/opencode/src/session/system.ts. Each run gets the PawWork persona plus one selected base prompt, not every model prompt at once. The issue is therefore not that all prompt files always inflate the same context window. The issue is that PawWork's behavior changes based on model-family string matching.

Current examples include GPT, Codex, Gemini, Claude, Trinity, Kimi, and older GPT-4/o-series routing. GLM and Qwen do not currently have their own prompt files, and they should not get one as a fix for model-specific failures.

Several of these prompt files are not narrow protocol adapters. They define broad behavior: default action mode, tool-use habits, file access boundaries, planning style, output style, todo or subagent usage, and product identity. That makes PawWork harder to reason about and risks stale or contradictory behavior as providers and models change.

What would a good result look like?

PawWork has one PawWork-owned base behavior prompt used across model families in the default provider system prompt path. The base behavior prompt is identical across model families. Model differences are represented through capability metadata, tool exposure, provider settings, and runtime behavior rather than long model-family behavior prompt branches.

A narrow provider protocol note is allowed only when it describes a non-behavior protocol requirement, for example a provider message-shape constraint or tool-result ordering requirement. Protocol notes must be separately named, explicitly allowlisted, selected through an explicit allowlist table or metadata path, and covered by focused tests. They must not encode product behavior such as "Kimi should be more proactive", "Gemini should plan more", or "Claude should use todos more". They also must not be selected through ad hoc model.api.id.includes(...) behavior-routing logic.

The new base prompt should be PawWork-owned, not a renamed OpenCode CLI prompt. It should not send users to OpenCode help, OpenCode docs, or OpenCode issue trackers as PawWork's product identity. This is limited to the prompt surface touched by this issue, not a broad repository-wide branding cleanup.

Which audience does this matter to most?

Both

Decision

Use one unified PawWork product behavior prompt plus optional narrow non-behavior provider protocol notes.

Do not tune failures by adding or expanding model-family behavior prompts. If a model behaves poorly, first look at tool descriptions, permissions, provider metadata, model capability flags, provider options, runtime guards, or the unified base prompt.

The unified base prompt should encode PawWork's default interaction mode: understand first, and only write files, mutate GitHub state, or make other persistent changes when the user clearly asks to execute.

Scope

In scope:

• Replace model-family behavior prompt routing in packages/opencode/src/session/system.ts with a unified PawWork base behavior prompt.
• Create or reorganize the base prompt so PawWork has one clear source of truth for product behavior.
• Remove model-family behavior prompt files formerly or currently used by session prompt routing, plus any already-unreferenced model-family behavior files found by reference search.
• Inventory every packages/opencode/src/session/prompt/*.txt file as keep or delete, so unrelated non-behavior snippets are preserved and stale model-family behavior prompts are not left behind.
• Remove OpenCode CLI product identity from the new PawWork base prompt where this issue directly touches it.
• Add tests that prove representative model-family IDs route to the same PawWork base behavior prompt.
• Add a guard or focused assertions that prevent reintroducing model-family behavior prompt routing.

Out of scope:

• Agent-specific custom prompts that bypass SystemPrompt.provider() are out of scope unless they are model-family behavior prompts. This issue does not require changing the agent prompt composition contract.
• No manual cross-model smoke matrix for this issue.
• No new model regression harness.
• No broad repository-wide OpenCode branding cleanup.
• No provider runtime rewrite.
• No special GLM, Qwen, Kimi, Gemini, Claude, GPT, Codex, or Trinity behavior prompt tuning.
• No artificial fallback switch that keeps old behavior prompts alive only for emergency rollback.

Acceptance criteria

• The default session system prompt path uses one PawWork-owned base behavior prompt across model families.
• The selected base behavior prompt no longer depends on model-family string matching such as gpt, gemini, claude, kimi, trinity, or similar model-name branches.
• The composed behavior prompt output is identical across representative model-family IDs except for separately named and allowlisted non-behavior protocol notes.
• Any provider protocol note is separately named, explicitly allowlisted, selected through an explicit allowlist table or metadata path, limited to non-behavior protocol requirements, includes a short explanation of why it cannot live in metadata or runtime code, and is covered by focused tests.
• No provider protocol note is selected through ad hoc model-family substring checks in the behavior prompt path.
• Model-family behavior prompt files formerly or currently used by session prompt routing are deleted once they are no longer referenced; unrelated prompt snippets such as plan or max-step reminders are not deleted just because they are .txt files.
• Every packages/opencode/src/session/prompt/*.txt file has an explicit keep/delete classification in the PR body or implementation notes.
• The new unified base prompt encodes PawWork's default interaction mode: understand first, execute only after a clear user request.
• The composed SystemPrompt.provider() output does not direct users to OpenCode product help, OpenCode docs, OpenCode issue trackers, or OpenCode support surfaces as PawWork's own support surface.
• GLM, Qwen, Kimi, Gemini, Claude, GPT, Codex, Trinity, and future model families do not need their own custom behavior prompts.
• Unit tests cover representative model IDs and assert that they receive the same PawWork base behavior prompt.
• Tests or static assertions fail if a new model-family behavior branch is added to the session system prompt path.

Verification

Required:

• Unit or focused integration tests for SystemPrompt.provider() covering representative IDs for GPT, Codex, Gemini, Claude, Kimi, Trinity, GLM, Qwen, and an unknown model.
• A composed-output assertion that SystemPrompt.provider() output does not include OpenCode support or product-identity strings such as opencode.ai, anomalyco/opencode, or OpenCode-specific help and feedback wording.
• Static search or test coverage showing deleted prompt files are no longer imported or referenced.
• Static search or test coverage showing no model-family behavior branch remains in the session system prompt path.
• A prompt-file inventory covering every packages/opencode/src/session/prompt/*.txt file with keep/delete rationale.
• Existing relevant prompt/session tests continue to pass.

Not required:

• Manual smoke testing across every provider.
• Live API calls with real provider credentials.
• A formal model-quality benchmark.

Rollout and risk handling

This change should be verified structurally in CI and then observed after release through normal user feedback and follow-up issues. Without an existing model evaluation harness, a manual cross-model smoke matrix would add process complexity without giving strong evidence.

The main risk is that a weaker model previously benefited from a custom behavior prompt. If that happens, handle the follow-up by first checking whether the unified base prompt, tool descriptions, provider metadata, permissions, or runtime behavior need adjustment. Reintroducing model-specific prompt content should require a specific non-behavior protocol reason, an allowlist entry, and focused test coverage, not a general quality claim.