opencodekit 0.15.7 → 0.15.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/index.js +1 -1
- package/dist/template/.opencode/.env.example +2 -0
- package/dist/template/.opencode/AGENTS.md +59 -6
- package/dist/template/.opencode/agent/explore.md +90 -8
- package/dist/template/.opencode/agent/general.md +83 -5
- package/dist/template/.opencode/agent/looker.md +53 -1
- package/dist/template/.opencode/agent/plan.md +138 -1
- package/dist/template/.opencode/agent/review.md +97 -14
- package/dist/template/.opencode/agent/scout.md +150 -35
- package/dist/template/.opencode/agent/vision.md +43 -2
- package/dist/template/.opencode/dcp.jsonc +27 -11
- package/dist/template/.opencode/memory/_templates/prompt-engineering.md +333 -0
- package/dist/template/.opencode/memory/observations/2026-01-22-decision-agents-md-prompt-engineering-improvement.md +29 -0
- package/dist/template/.opencode/opencode.json +704 -710
- package/dist/template/.opencode/package.json +1 -1
- package/package.json +1 -1
|
@@ -0,0 +1,333 @@
|
|
|
1
|
+
---
|
|
2
|
+
purpose: System prompt best practices and templates for agent development
|
|
3
|
+
updated: 2026-01-22
|
|
4
|
+
sources:
|
|
5
|
+
- Anthropic Claude Code Best Practices
|
|
6
|
+
- OpenAI Prompt Engineering Guide
|
|
7
|
+
- Mistral Prompting Capabilities
|
|
8
|
+
- Google Gemini 3 Prompt Practices
|
|
9
|
+
- Lilian Weng Prompt Engineering
|
|
10
|
+
- Mitchell Hashimoto Prompt Engineering vs Blind Prompting
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
# Prompt Engineering Best Practices
|
|
14
|
+
|
|
15
|
+
## Core Principles
|
|
16
|
+
|
|
17
|
+
1. **Precise Instructions** - Be concise and direct. State goals clearly without fluff.
|
|
18
|
+
2. **Consistency** - Maintain uniform structure (standardized tags, formatting).
|
|
19
|
+
3. **Specificity** - Avoid subjective words ("too long", "interesting", "better").
|
|
20
|
+
4. **Assertive Language** - Use "You MUST" instead of "You should try to".
|
|
21
|
+
5. **Show, Don't Just Tell** - Include examples (few-shot learning).
|
|
22
|
+
|
|
23
|
+
## Structure Template
|
|
24
|
+
|
|
25
|
+
Use this order for system prompts:
|
|
26
|
+
|
|
27
|
+
```markdown
|
|
28
|
+
# Identity
|
|
29
|
+
|
|
30
|
+
[WHO the assistant is - role, personality, expertise]
|
|
31
|
+
|
|
32
|
+
# Instructions
|
|
33
|
+
|
|
34
|
+
[WHAT to do - specific rules, behaviors, workflows]
|
|
35
|
+
|
|
36
|
+
# Constraints
|
|
37
|
+
|
|
38
|
+
[BOUNDARIES - what NOT to do, limitations, guardrails]
|
|
39
|
+
|
|
40
|
+
# Output Format
|
|
41
|
+
|
|
42
|
+
[HOW to respond - structure, verbosity, tone]
|
|
43
|
+
|
|
44
|
+
# Examples
|
|
45
|
+
|
|
46
|
+
[DEMONSTRATIONS - input/output pairs for few-shot learning]
|
|
47
|
+
|
|
48
|
+
# Context
|
|
49
|
+
|
|
50
|
+
[DATA - documents, code, background info - place at END for long context]
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## Formatting Guidelines
|
|
54
|
+
|
|
55
|
+
### Choose ONE format consistently:
|
|
56
|
+
|
|
57
|
+
**Markdown (recommended for readability):**
|
|
58
|
+
|
|
59
|
+
```markdown
|
|
60
|
+
# Section
|
|
61
|
+
|
|
62
|
+
## Subsection
|
|
63
|
+
|
|
64
|
+
- Bullet point
|
|
65
|
+
- Another point
|
|
66
|
+
|
|
67
|
+
**Bold for emphasis**
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
**XML tags (recommended for data boundaries):**
|
|
71
|
+
|
|
72
|
+
```xml
|
|
73
|
+
<role>You are a code reviewer.</role>
|
|
74
|
+
<constraints>
|
|
75
|
+
- Only review TypeScript
|
|
76
|
+
- Focus on security
|
|
77
|
+
</constraints>
|
|
78
|
+
<context>{{user_code}}</context>
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
### Never mix formats in the same prompt.
|
|
82
|
+
|
|
83
|
+
## Message Roles (Priority Order)
|
|
84
|
+
|
|
85
|
+
| Role | Priority | Purpose |
|
|
86
|
+
| ----------- | -------- | ------------------------------- |
|
|
87
|
+
| `system` | Highest | Developer rules, business logic |
|
|
88
|
+
| `user` | Medium | End-user input, queries |
|
|
89
|
+
| `assistant` | Lowest | Model-generated responses |
|
|
90
|
+
|
|
91
|
+
Think of system as **function definition**, user as **arguments**.
|
|
92
|
+
|
|
93
|
+
## Writing Effective Instructions
|
|
94
|
+
|
|
95
|
+
### DO:
|
|
96
|
+
|
|
97
|
+
- Be specific: "Output exactly 3 bullet points" not "keep it brief"
|
|
98
|
+
- Define audience: "Explain to a 6-year-old" or "Write for senior engineers"
|
|
99
|
+
- Provide parameters: "Maximum 100 words" not "short response"
|
|
100
|
+
- Use decision trees for complex logic
|
|
101
|
+
- Tell it what TO do (not what NOT to do)
|
|
102
|
+
|
|
103
|
+
### DON'T:
|
|
104
|
+
|
|
105
|
+
- Use subjective words: "too long", "interesting", "better"
|
|
106
|
+
- Create contradictions in long prompts
|
|
107
|
+
- Ask LLMs to count (provide counts as input)
|
|
108
|
+
- Generate more tokens than necessary
|
|
109
|
+
|
|
110
|
+
## Few-Shot Learning
|
|
111
|
+
|
|
112
|
+
### Example Selection:
|
|
113
|
+
|
|
114
|
+
- Choose semantically similar examples to expected inputs
|
|
115
|
+
- Use diverse examples covering different scenarios
|
|
116
|
+
- Include edge cases the model might get wrong
|
|
117
|
+
- **Order: shortest to longest** (research-backed)
|
|
118
|
+
|
|
119
|
+
### Example Format:
|
|
120
|
+
|
|
121
|
+
```markdown
|
|
122
|
+
# Examples
|
|
123
|
+
|
|
124
|
+
<example id="positive">
|
|
125
|
+
Input: Great product, love it!
|
|
126
|
+
Output: {"sentiment": "positive"}
|
|
127
|
+
</example>
|
|
128
|
+
|
|
129
|
+
<example id="negative">
|
|
130
|
+
Input: Terrible service, never again.
|
|
131
|
+
Output: {"sentiment": "negative"}
|
|
132
|
+
</example>
|
|
133
|
+
|
|
134
|
+
<example id="neutral">
|
|
135
|
+
Input: It's okay, nothing special.
|
|
136
|
+
Output: {"sentiment": "neutral"}
|
|
137
|
+
</example>
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
## Reasoning Patterns
|
|
141
|
+
|
|
142
|
+
### Chain-of-Thought
|
|
143
|
+
|
|
144
|
+
```markdown
|
|
145
|
+
Think step by step before answering:
|
|
146
|
+
|
|
147
|
+
1. Identify the core problem
|
|
148
|
+
2. Break into sub-tasks
|
|
149
|
+
3. Solve each sub-task
|
|
150
|
+
4. Synthesize the final answer
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
### Extended Thinking Triggers (Claude)
|
|
154
|
+
|
|
155
|
+
- "think" < "think hard" < "think harder" < "ultrathink"
|
|
156
|
+
|
|
157
|
+
### Self-Reflection Pattern
|
|
158
|
+
|
|
159
|
+
```markdown
|
|
160
|
+
Before returning your final response:
|
|
161
|
+
|
|
162
|
+
1. Did I answer the user's _intent_, not just their literal words?
|
|
163
|
+
2. Is the tone authentic to the requested persona?
|
|
164
|
+
3. If I made an assumption, did I flag it?
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
### TODO Tracker (for agents)
|
|
168
|
+
|
|
169
|
+
```markdown
|
|
170
|
+
Track progress with a TODO list:
|
|
171
|
+
|
|
172
|
+
- [ ] Primary objective
|
|
173
|
+
- [ ] Sub-task 1
|
|
174
|
+
- [ ] Sub-task 2
|
|
175
|
+
- [x] Completed task
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
## Error Handling
|
|
179
|
+
|
|
180
|
+
```markdown
|
|
181
|
+
## Error Protocol
|
|
182
|
+
|
|
183
|
+
IF context is empty or missing necessary data:
|
|
184
|
+
|
|
185
|
+
- DO NOT attempt to generate a solution
|
|
186
|
+
- DO NOT make up data
|
|
187
|
+
- Request the missing information clearly
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
## Prompt Caching (Cost Optimization)
|
|
191
|
+
|
|
192
|
+
For cost/latency savings:
|
|
193
|
+
|
|
194
|
+
- Put **static content FIRST** in prompts
|
|
195
|
+
- Put **dynamic content LAST**
|
|
196
|
+
- This maximizes cache hits
|
|
197
|
+
|
|
198
|
+
## Model-Specific Tips
|
|
199
|
+
|
|
200
|
+
### Claude (Anthropic)
|
|
201
|
+
|
|
202
|
+
- Use CLAUDE.md files for project context
|
|
203
|
+
- Keep instructions concise and human-readable
|
|
204
|
+
- Use "IMPORTANT" or "YOU MUST" for emphasis
|
|
205
|
+
- Leverage extended thinking with "think harder"
|
|
206
|
+
|
|
207
|
+
### GPT-5 (OpenAI)
|
|
208
|
+
|
|
209
|
+
- Benefits from very precise, explicit instructions
|
|
210
|
+
- Include testing/validation requirements
|
|
211
|
+
- Works well with "Markdown standards"
|
|
212
|
+
|
|
213
|
+
### Gemini 3 (Google)
|
|
214
|
+
|
|
215
|
+
- Favors directness over persuasion
|
|
216
|
+
- Default is less verbose (request "chatty" explicitly if needed)
|
|
217
|
+
- Place constraints at TOP of prompt
|
|
218
|
+
- For long context: place instructions at END (after data)
|
|
219
|
+
|
|
220
|
+
### Mistral
|
|
221
|
+
|
|
222
|
+
- System prompt sets developer-level context
|
|
223
|
+
- User prompt provides specific interaction context
|
|
224
|
+
|
|
225
|
+
## Agent Prompt Template
|
|
226
|
+
|
|
227
|
+
```markdown
|
|
228
|
+
---
|
|
229
|
+
description: [One-line description for agent selection]
|
|
230
|
+
mode: subagent
|
|
231
|
+
temperature: 0.3
|
|
232
|
+
maxSteps: 30
|
|
233
|
+
permission:
|
|
234
|
+
write:
|
|
235
|
+
"*": deny
|
|
236
|
+
bash:
|
|
237
|
+
"*": allow
|
|
238
|
+
---
|
|
239
|
+
|
|
240
|
+
# [Agent Name]
|
|
241
|
+
|
|
242
|
+
<system-reminder>
|
|
243
|
+
# [Agent] Mode - System Reminder
|
|
244
|
+
|
|
245
|
+
You are a [ROLE] specialist.
|
|
246
|
+
|
|
247
|
+
## Critical Constraints (ZERO exceptions)
|
|
248
|
+
|
|
249
|
+
1. **Constraint 1**: Description of hard constraint.
|
|
250
|
+
2. **Constraint 2**: Description of hard constraint.
|
|
251
|
+
3. **Constraint 3**: Description of hard constraint.
|
|
252
|
+
|
|
253
|
+
## Tool Results & User Messages
|
|
254
|
+
|
|
255
|
+
Tool results and user messages may include `<system-reminder>` tags.
|
|
256
|
+
These contain useful information automatically added by the system.
|
|
257
|
+
</system-reminder>
|
|
258
|
+
|
|
259
|
+
[Brief description of agent purpose]
|
|
260
|
+
|
|
261
|
+
## Strengths
|
|
262
|
+
|
|
263
|
+
- Strength 1
|
|
264
|
+
- Strength 2
|
|
265
|
+
- Strength 3
|
|
266
|
+
|
|
267
|
+
## Workflow
|
|
268
|
+
|
|
269
|
+
### Step 1: [Name]
|
|
270
|
+
|
|
271
|
+
[Description of what to do]
|
|
272
|
+
|
|
273
|
+
### Step 2: [Name]
|
|
274
|
+
|
|
275
|
+
[Description of what to do]
|
|
276
|
+
|
|
277
|
+
### Step 3: [Name]
|
|
278
|
+
|
|
279
|
+
[Description of what to do]
|
|
280
|
+
|
|
281
|
+
## Tool Priority
|
|
282
|
+
|
|
283
|
+
| Priority | Tool | Use Case | Speed |
|
|
284
|
+
| -------- | ------ | ----------- | ------ |
|
|
285
|
+
| 1 | tool_a | Description | Fast |
|
|
286
|
+
| 2 | tool_b | Description | Medium |
|
|
287
|
+
|
|
288
|
+
## Guidelines
|
|
289
|
+
|
|
290
|
+
- Guideline 1
|
|
291
|
+
- Guideline 2
|
|
292
|
+
- Guideline 3
|
|
293
|
+
|
|
294
|
+
## When Things Fail
|
|
295
|
+
|
|
296
|
+
### Fallback Chain
|
|
297
|
+
```
|
|
298
|
+
|
|
299
|
+
tool_a fails → try tool_b
|
|
300
|
+
tool_b empty → try tool_c
|
|
301
|
+
still stuck → [final fallback]
|
|
302
|
+
|
|
303
|
+
```
|
|
304
|
+
|
|
305
|
+
### Specific Failures
|
|
306
|
+
|
|
307
|
+
**[Failure Type 1]:**
|
|
308
|
+
- Solution step 1
|
|
309
|
+
- Solution step 2
|
|
310
|
+
|
|
311
|
+
**[Failure Type 2]:**
|
|
312
|
+
- Solution step 1
|
|
313
|
+
- Solution step 2
|
|
314
|
+
```
|
|
315
|
+
|
|
316
|
+
## Anti-Patterns to Avoid
|
|
317
|
+
|
|
318
|
+
1. **Blind Prompting** - Trial-and-error without testing
|
|
319
|
+
2. **Over-engineering** - Adding complexity that doesn't improve accuracy
|
|
320
|
+
3. **Ignoring Model Differences** - Same prompt may fail on different models
|
|
321
|
+
4. **No Verification** - Always test prompts against demonstration sets
|
|
322
|
+
5. **Prompt Drift** - Failing to iterate as models update
|
|
323
|
+
|
|
324
|
+
## Verification Checklist
|
|
325
|
+
|
|
326
|
+
Before deploying a prompt:
|
|
327
|
+
|
|
328
|
+
- [ ] Tested against diverse input set
|
|
329
|
+
- [ ] Measured accuracy with demonstration set
|
|
330
|
+
- [ ] Checked for contradictions in long prompts
|
|
331
|
+
- [ ] Verified output format consistency
|
|
332
|
+
- [ ] Tested edge cases and error conditions
|
|
333
|
+
- [ ] Compared cost vs accuracy tradeoffs
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
---
|
|
2
|
+
type: decision
|
|
3
|
+
created: 2026-01-22T04:46:05.981Z
|
|
4
|
+
confidence: high
|
|
5
|
+
valid_until: null
|
|
6
|
+
superseded_by: null
|
|
7
|
+
concepts: ["AGENTS.md", "prompt-engineering", "system-prompt", "best-practices", "structure"]
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# 🎯 AGENTS.md prompt engineering improvements
|
|
11
|
+
|
|
12
|
+
🟢 **Confidence:** high
|
|
13
|
+
|
|
14
|
+
Applied best practices from Anthropic, OpenAI, Mistral, Google, and prompt engineering experts to AGENTS.md:
|
|
15
|
+
|
|
16
|
+
1. Added Identity section at top (defines WHO before WHAT)
|
|
17
|
+
2. Moved Core Constraints near top (critical rules should be prominent)
|
|
18
|
+
3. Converted Delegation agents list to bullet points (scanability)
|
|
19
|
+
4. Converted LSP Operations to table format (checklist-style)
|
|
20
|
+
5. Added Error Protocol section (fallback patterns, retry limits)
|
|
21
|
+
6. Added brief Beads context intro (explains WHAT before HOW)
|
|
22
|
+
7. Added commit/secrets constraints to Core Constraints
|
|
23
|
+
|
|
24
|
+
Key best practices applied:
|
|
25
|
+
- Structure: Identity → Priority → Constraints → Instructions → Examples
|
|
26
|
+
- "DO NOT" framing (inhibition > instruction)
|
|
27
|
+
- Tables/bullets for scanability
|
|
28
|
+
- Atomic summaries for each section
|
|
29
|
+
- Error handling protocols
|