[FEATURE]: Evidence based refurbishment of openCode's System Prompt (Architecture) #14398

Activity

1. micuintus

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Feb 20, 2026
2. github-actions

   assigned

   rekram1-node

   on Feb 20, 2026
3. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on Feb 20, 2026
4. github-actions commented on Feb 20, 2026

   

   github-actionsBot

   on Feb 20, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: Evidence based refurbishment of openCode's System Prompt (Architecture) #14395: This appears to be an exact duplicate of your own previously submitted (and closed) issue with the same title and content.
   • [FEATURE]: Unify provider system prompts #13605: Related feature request about unifying and improving provider system prompts.

   If #14398 is meant to replace #14395, please clarify what differs or reference the prior issue in the description.
5. micuintus commented on Feb 20, 2026

   

   micuintus

   on Feb 20, 2026

   Author

   More actions

   A summary of the master plan:

   OpenCode_IMPROVEMENT_PLAN.md

   P0 - Foundation

   PR	Score	Description
   1	9.6	Overspecification Audit - Reduce to 5-7 constraints/category, <1500 tokens
   2	8.8	Prompt Builder Pattern - Modular assembly with env var control
   3	9.4	Tool Format Detection - Auto-select XML/JSON/native by model family
   4	8.4	Turn Budget Configuration - 25th-75th percentile limits, prevent cost overruns
   5	8.6	Turn Reminder System - Inject warnings at 10 and 5 turns remaining
   6	8.3	Verification Checkpoints - 3-5 steps before completion

   P1 - Infrastructure

   PR	Score	Description
   7	8.2	Context Compression - LLMLingua-style 5-20x compression
   8	7.7	Variant Registry - Model matchers for 8+ variants, mode-based tools
   9	7.8	Anti-Training-Data - Override verbose comments, sequential calls, questions
   10	7.9	Workspace Reconstruction - O(1) complexity, evolving report pattern
   11	7.5	Output Formats - Markdown blocks, JSON formatting, completion markers
   12	7.5	Forceful Language - "should" → "MUST/NEVER" for critical only
   13	7.2	Security Section - 5-7 rules prioritized by rejection rates

   P2 - Targeted Improvements

   PR	Score	Description
   14	8.0	KISS Principle - Simple solutions over clever abstractions
   15	7.8	Test Requirements - Mandate tests before completion
   16	7.0	Plan-Code Validation - Bridge gap causing 75% multi-agent failures
   17	6.8	Customization API - User template overrides without code changes

   P3 - Advanced/Exploratory

   PR	Score	Description
   18	6.2	Chain of Code - LMulator reasoning for mixed semantic/numeric tasks
   19	5.0	Documentation - Variant mapping and developer guide
   20	4.5	Activation Steering - Pre-computed vectors for format control (exploratory)
6. micuintus commented on Feb 20, 2026

   

   micuintus

   on Feb 20, 2026

   Last edited by micuintus

   Author

   More actions

   Transparency: How did I create this master plan?

   By a multitude of iterations (GLM-5 and Kimi K2.5) -- roughly along the lines of the following prompts:

   All the prompts were handwritten

   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   
   1. Conduct an in-depth research on the science of system promoting -- specifically for coding agents like openCode, Crush, Claude Code etc, and download the relevant papers you found to @papers/. Focus on RCT / meta studies / studies in well-renowned magazines. Important objectives a) High quality coding results b) Avoid token waste / context littering c) LLM steering 
   
   2. Study the downloaded papers very carefully and extract/synthesize a comprehensive and detailed report of guidelines and best practices for system promoting that later we are going to use to a) asses the system prompting of FOSS coding agents and b) improve the system prompts and system prompting architecture of an open source agent
   
   Make sure our report is comprehensive, contains all the relevant science and covers everything and is perfect we need for the next steps. 
   
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   
   EXECUTIVE SUMMARY
   =================
   
   After extensive research under @papers/ on the science of system prompting and extracting the findings into an comprehensive guide book to @papers/SYSTEM_PROMPTING_COMPREHENSIVE_REPORT.md, it is now our plan to craft a detailed and evidence based plan now on how to improve the system prompting architecture and implementation of @opencode/.  
   
   1. As a first step, we want to a) analyze and b) assess the system prompts and system prompting architecture of the leading FOSS coding agents based on our research
   2. If we stumble across well formulated system prompts or a stellar system prompting architecture (according to our research), we want to note this down as leading examples and input for our endeavor to improve opencodes system prompting
   
   TASK
   ====
    
   In this directory, I downloaded a list of leading free and open source coding agents:
   
   * cline
   * crush
   * goose
   * kimi-cli
   * opencode
   * Roo-Code
   * continue
   * gemini-cli
   * kilocode
   * mistral-vibe
   * qwen-code
   
   For each of the agents
   
   1. Please dive deep into the code base and create an exhaustive understanding of a) the way the agent creates system prompts b) how these system prompts end up looking like and c) the system prompting code architecture 
   
   2. Based on our extensive research in @papers/SYSTEM_PROMPTING_COMPREHENSIVE_REPORT.md asses the a) quality of the system prompts and b) system prompting architecture
   
   3. When analyzing the FOSS agent of a model vendor ( @gemini-cli/ for the Google Models, @kimi-cli/ for the Kimi models, @qwen-code/ for the Qwen models and @mistral-vibe/ for the Mistral models), watch out for specifics we can learn that may be relevant for the model family or individual models of that vendor
   
   
   Create an extensive report with our finding!
   
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   
   Now create and indepth and detailed while iterative plan to incorporate the findings of our research a) @papers/SYSTEM_PROMPTING_COMPREHENSIVE_REPORT.md @papers/ as well as our open source code analysis @FOSS_CODING_AGENTS_SYSTEM_PROMPT_ANALYSIS.md into @opencode/: Each step should be a PRable (aka encapsulated and reviewable) increment
   
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   
   Can you please deep dive through the plan @OpenCode_IMPROVEMENT_PLAN.md and restructure it according to priority.
   
   How to define priority:
   
   1. How much impact will a mechanism have based on evidence of the science in @papers/SYSTEM_PROMPTING_COMPREHENSIVE_REPORT.md @papers/ 
   2. How widely is this objective backed by the science  - aka not just a result from based one paper, but can be found several papers in a similar form - and our findings in @FOSS_CODING_AGENTS_SYSTEM_PROMPT_ANALYSIS.md 
   3. What is the effort and how much churn will it cause in the code base?
   
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   ---------------------------------------------------------------------------------
   
   Skim @OpenCode_IMPROVEMENT_PLAN.md and the science in @papers/ for over specifying. Also conduct another science web research. It has been proven that over specification hurts LLM (coding) performance
   
7. micuintus commented on Feb 20, 2026

   

   micuintus

   on Feb 20, 2026

   Author

   More actions

   FOSS_CODING_AGENTS_SYSTEM_PROMPT_ANALYSIS.md
8. github-actions commented on Apr 22, 2026

   

   github-actionsBot

   on Apr 22, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
9. github-actions

   closed this as completedon Apr 22, 2026