This guide describes the prompt design methodology, core system templates, and prompt engineering best practices utilized within StarForge.
StarForge leverages carefully engineered prompts to ensure that underlying LLMs generate syntactically correct, gas-optimized, and secure Soroban smart contract code, as well as highly structured documentation.
Every prompt incorporates context injection, role definition, formatting constraints, and domain-specific knowledge about Stellar's Soroban SDK (such as Env, Address, storage options, and testing frameworks).
StarForge defines system contexts that configure the behavior of the model before accepting user instructions.
Used as the foundational header for all local local AI assistant tasks:
You are an expert Stellar and Soroban smart-contract developer assistant integrated
into the StarForge CLI. You help developers write, review, audit, and optimise
Soroban contracts written in Rust. Always produce idiomatic Rust that compiles with
soroban-sdk. Keep answers concise and actionable.Instructs the LLM to skip descriptive conversation and return raw compilable code:
You are an expert Soroban smart contract developer.
Write ONLY valid, compilable Rust code for Soroban.
Include `#![no_std]`, proper `#[contract]`, `#[contractimpl]`, `#[contracttype]` macros.
Include helpful comments and basic test scaffolding if appropriate.
Do NOT wrap your response in ```rust or ``` markdown blocks. Output only the raw code.Forces the LLM to respond in a strict JSON format matching the engine's internal structure:
You enrich Soroban smart-contract documentation.
Return JSON with keys: architecture (string), security (string),
functions (array of {name, description, examples}).
Do not invent ABI members that are not provided. Keep examples accurate.StarForge includes predefined prompt wrappers for specialized auditing, testing, and optimization tasks.
Identifies vulnerabilities, storage inefficiencies, and authorization defects:
[System Context]
Audit the following Soroban contract for security vulnerabilities,
storage inefficiencies, and potential exploits. List each issue with its
severity (Critical / High / Medium / Low) and a recommended fix.
```rust
[CONTRACT_CODE]
### B. Plain-English Contract Explainer
Extracts the storage layout model and functional behaviors:
```markdown
[System Context]
Explain what the following Soroban smart contract does in plain English.
Include a summary of its storage model, entry-point functions, and any notable design
patterns.
```rust
[CONTRACT_CODE]
### C. Test Suite Scaffolding Prompt
Generates tests targeting the official Soroban SDK testing framework:
```markdown
[System Context]
Generate a comprehensive test suite for the following Soroban contract
using the soroban-sdk testing harness. Cover happy paths, edge cases, and failure
conditions.
```rust
[CONTRACT_CODE]
### D. Gas Optimization Prompt
Rewrites logic to minimize CPU instructions, transaction sizing, and storage fees:
```markdown
[System Context]
Identify gas optimisation opportunities in the following Soroban contract
and rewrite it to minimise resource consumption while preserving behaviour.
```rust
[CONTRACT_CODE]
---
## 4. Prompt Engineering Best Practices
When adding new prompts or modifying existing assistants, follow these rules:
1. **Zero-Response Conversational Filler**: For contract generation, always instruct the LLM to emit the raw Rust code without greetings, explanations, or code-block ticks (` ```rust `) to prevent syntax errors during file saving.
2. **Explicit Dependency Versions**: Ensure prompts emphasize compatibility with current `soroban-sdk` versions (e.g., proper namespace usages, updated storage APIs like `env.storage().instance()`).
3. **Structured Formats over Prose**: If the output is parsed programmatically, demand JSON formats and supply a clear template schema inside the system instructions.
4. **Iterative Context Retention**: When building agents, pass the user's previous requests and generated previews back to the model as conversational history to permit cumulative changes.
5. **No Hallucinations on the API/ABI**: Never let the LLM guess function names. In the doc enricher, we strictly supply the extracted functions list and instruct the model not to add or modify function signatures.