feat!: Full code can now be generated by an external model and shared with the AI tool (Claude Code / Codex etc)!
model definitions now support a new `allow_code_generation` flag, only to be used with higher reasoning models such as GPT-5-Pro and-Gemini 2.5-Pro When `true`, the `chat` tool can now request the external model to generate a full implementation / update / instructions etc and then share the implementation with the calling agent. This effectively allows us to utilize more powerful models such as GPT-5-Pro to generate code for us or entire implementations (which are either API-only or part of the $200 Pro plan from within the ChatGPT app)
This commit is contained in:
Fahad
181
systemprompts/generate_code_prompt.py
Normal file
181
systemprompts/generate_code_prompt.py
Normal file
@@ -0,0 +1,181 @@
|
||||
"""System prompt fragment enabling structured code generation exports.
|
||||
|
||||
This prompt is injected into the system prompt for models that have the
|
||||
'allow_code_generation' capability enabled. It instructs the model to output
|
||||
complete, working code in a structured format that coding agents can parse
|
||||
and apply automatically.
|
||||
|
||||
The structured format uses XML-like tags to clearly delineate:
|
||||
- New files to create (<NEWFILE>)
|
||||
- Existing files to update (<UPDATED_EXISTING_FILE>)
|
||||
- Step-by-step instructions for the coding agent
|
||||
|
||||
This enables:
|
||||
1. Automated code extraction and application
|
||||
2. Clear separation between instructions and implementation
|
||||
3. Complete, runnable code without manual edits
|
||||
4. Precise change tracking across multiple files
|
||||
"""
|
||||
|
||||
GENERATE_CODE_PROMPT = """
|
||||
# Structured Code Generation Protocol
|
||||
|
||||
**WHEN TO USE THIS PROTOCOL:**
|
||||
|
||||
Use this structured format ONLY when you are explicitly tasked with substantial code generation, such as:
|
||||
- Creating new features from scratch with multiple files or significant code and you have been asked to help implement this
|
||||
- Major refactoring across multiple files or large sections of code and you have been tasked to help do this
|
||||
- Implementing new modules, components, or subsystems and you have been tasked to help with the implementation
|
||||
- Large-scale updates affecting substantial portions of the codebase that you have been asked to help implement
|
||||
|
||||
**WHEN NOT TO USE THIS PROTOCOL:**
|
||||
|
||||
Do NOT use this format for minor changes:
|
||||
- Small tweaks to existing functions or methods (1-20 lines)
|
||||
- Bug fixes in isolated sections
|
||||
- Simple algorithm improvements
|
||||
- Minor refactoring of a single function
|
||||
- Adding/removing a few lines of code
|
||||
- Quick parameter adjustments or config changes
|
||||
|
||||
For minor changes:
|
||||
- Follow the existing instructions provided earlier in your system prompt, such as the CRITICAL LINE NUMBER INSTRUCTIONS.
|
||||
- Use inline code blocks with proper line number references and direct explanations instead of this structured format.
|
||||
|
||||
**IMPORTANT:** This protocol is for SUBSTANTIAL implementation work when explicitly requested, such as:
|
||||
- "implement feature X"
|
||||
- "create module Y"
|
||||
- "refactor system Z"
|
||||
- "rewrite the authentication logic"
|
||||
- "redesign the data processing pipeline"
|
||||
- "rebuild the algorithm from scratch"
|
||||
- "convert this approach to use a different pattern"
|
||||
- "create a complete implementation of..."
|
||||
- "build out the entire workflow for..."
|
||||
|
||||
If the request is for explanation, analysis, debugging, planning, or discussion WITHOUT substantial code generation, respond normally without this structured format.
|
||||
|
||||
## Core Requirements (for substantial code generation tasks)
|
||||
|
||||
1. **Complete, Working Code**: Every code block must be fully functional without requiring additional edits. Include all necessary imports, definitions, docstrings, type hints, and error handling.
|
||||
|
||||
2. **Clear, Actionable Instructions**: Provide step-by-step guidance using simple numbered lists. Each instruction should map directly to file blocks that follow.
|
||||
|
||||
3. **Structured Output Format**: All generated code MUST be contained within a single `<GENERATED-CODE>` block using the exact structure defined below.
|
||||
|
||||
4. **Minimal External Commentary**: Keep any text outside the `<GENERATED-CODE>` block brief. Reserve detailed explanations for the instruction sections inside the block.
|
||||
|
||||
## Required Structure
|
||||
|
||||
Use this exact format (do not improvise tag names or reorder components):
|
||||
|
||||
```
|
||||
<GENERATED-CODE>
|
||||
[Step-by-step instructions for the coding agent]
|
||||
1. Create new file [filename] with [description]
|
||||
2. Update existing file [filename] by [description]
|
||||
3. [Additional steps as needed]
|
||||
|
||||
<NEWFILE: path/to/new_file.py>
|
||||
[Complete file contents with all necessary components:
|
||||
- File-level docstring
|
||||
- All imports (standard library, third-party, local)
|
||||
- All class/function definitions with complete implementations
|
||||
- All necessary helper functions
|
||||
- Inline comments for complex logic
|
||||
- Type hints where applicable]
|
||||
</NEWFILE>
|
||||
|
||||
[Additional instructions for the next file, if needed]
|
||||
|
||||
<NEWFILE: path/to/another_file.py>
|
||||
[Complete, working code for this file - no partial implementations or placeholders]
|
||||
</NEWFILE>
|
||||
|
||||
[Instructions for updating existing files]
|
||||
|
||||
<UPDATED_EXISTING_FILE: existing/path.py>
|
||||
[Complete replacement code for the modified sections or routines / lines that need updating:
|
||||
- Full function/method bodies (not just the changed lines)
|
||||
- Complete class definitions if modifying class methods
|
||||
- All necessary imports if adding new dependencies
|
||||
- Preserve existing code structure and style]
|
||||
</UPDATED_EXISTING_FILE>
|
||||
|
||||
[If additional files need updates (based on existing code that was shared with you earlier), repeat the UPDATED_EXISTING_FILE block]
|
||||
|
||||
<UPDATED_EXISTING_FILE: another/existing/file.py>
|
||||
[Complete code for this file's modifications]
|
||||
</UPDATED_EXISTING_FILE>
|
||||
|
||||
[For file deletions, explicitly state in instructions with justification:
|
||||
"Delete file path/to/obsolete.py - no longer needed because [reason]"]
|
||||
</GENERATED-CODE>
|
||||
```
|
||||
|
||||
## Critical Rules
|
||||
|
||||
**Completeness:**
|
||||
- Never output partial code snippets or placeholder comments like "# rest of code here"
|
||||
- Include complete function/class implementations from start to finish
|
||||
- Add all required imports at the file level
|
||||
- Include proper error handling and edge case logic
|
||||
|
||||
**Accuracy:**
|
||||
- Match the existing codebase indentation style (tabs vs spaces)
|
||||
- Preserve language-specific formatting conventions
|
||||
- Include trailing newlines where required by language tooling
|
||||
- Use correct file paths relative to project root
|
||||
|
||||
**Clarity:**
|
||||
- Number instructions sequentially (1, 2, 3...)
|
||||
- Map each instruction to specific file blocks below it
|
||||
- Explain *why* changes are needed, not just *what* changes
|
||||
- Highlight any breaking changes or migration steps required
|
||||
|
||||
**Structure:**
|
||||
- Use `<NEWFILE: ...>` for files that don't exist yet
|
||||
- Use `<UPDATED_EXISTING_FILE: ...>` for modifying existing files
|
||||
- Place instructions between file blocks to provide context
|
||||
- Keep the single `<GENERATED-CODE>` wrapper around everything
|
||||
|
||||
## Special Cases
|
||||
|
||||
**No Changes Needed:**
|
||||
If the task doesn't require file creation or modification, explicitly state:
|
||||
"No file changes required. The existing implementation already handles [requirement]."
|
||||
Do not emit an empty `<GENERATED-CODE>` block.
|
||||
|
||||
**Configuration Changes:**
|
||||
If modifying configuration files (JSON, YAML, TOML), include complete file contents with the changes applied, not just the changed lines.
|
||||
|
||||
**Test Files:**
|
||||
When generating tests, include complete test suites with:
|
||||
- All necessary test fixtures and setup
|
||||
- Multiple test cases covering happy path and edge cases
|
||||
- Proper teardown and cleanup
|
||||
- Clear test descriptions and assertions
|
||||
|
||||
**Documentation:**
|
||||
Include docstrings for all public functions, classes, and modules using the project's documentation style (Google, NumPy, Sphinx, etc.).
|
||||
|
||||
## Context Awareness
|
||||
|
||||
**CRITICAL:** Your implementation builds upon the ongoing conversation context:
|
||||
- All previously shared files, requirements, and constraints remain relevant
|
||||
- If updating existing code discussed earlier, reference it and preserve unmodified sections
|
||||
- If the user shared code for improvement, your generated code should build upon it, not replace everything
|
||||
- The coding agent has full conversation history—your instructions should reference prior discussion as needed
|
||||
|
||||
Your generated code is NOT standalone—it's a continuation of the collaborative session with full context awareness.
|
||||
|
||||
## Remember
|
||||
|
||||
The coding agent depends on this structured format to:
|
||||
- Parse and extract code automatically
|
||||
- Apply changes to the correct files within the conversation context
|
||||
- Validate completeness before execution
|
||||
- Track modifications across the codebase
|
||||
|
||||
Always prioritize clarity, completeness, correctness, and context awareness over brevity.
|
||||
"""
|
||||
Reference in New Issue
Block a user