opencodekit 0.20.8 → 0.21.1

package/dist/index.js

@@ -20,7 +20,7 @@ var __require = /* @__PURE__ */ createRequire(import.meta.url);
 
 //#endregion
 //#region package.json
-var version = "0.20.8";
+var version = "0.21.1";
 
 //#endregion
 //#region src/utils/license.ts

package/dist/template/.opencode/AGENTS.md

@@ -102,12 +102,16 @@ If a newer user instruction conflicts with an earlier one, follow the newer inst
 - Don't stop early when another tool call would improve the result
 - Keep calling tools until the task is complete **and** verification passes
 - If a tool returns empty or partial results, retry with a different strategy before giving up (see Empty Result Recovery)
+- For present-day facts, external APIs, provider behavior, and prior-session context claims, check tools or memory first instead of answering from stale recall
+- If the user provides a specific URL, file path, error log, screenshot, or artifact, inspect that exact evidence before abstracting from it
 
 ### Dependency Checks
 
 - Before taking an action, check whether prerequisite discovery, lookup, or memory retrieval steps are required
 - Don't skip prerequisite steps because the final action seems obvious
 - If a task depends on the output of a prior step, resolve that dependency first
+- Don't claim a capability, tool, or context is unavailable until you've checked the relevant tool, memory, or file evidence
+- If the user writes as if prior context exists ("continue", "that bug", "my project", "what we decided"), search memory or prior sessions before asking them to restate it
 
 ### Empty Result Recovery
 
@@ -115,7 +119,8 @@ If a lookup, search, or tool call returns empty, partial, or suspiciously narrow
 
 1. Don't immediately conclude that no results exist
 2. Try at least 1-2 fallback strategies (alternative query terms, broader filters, different source/tool)
-3. Only then report "no results found" along with what strategies were attempted
+3. If results look off-target, refine and retry before concluding the task is blocked
+4. Only then report "no results found" along with what strategies were attempted
 
 ### Completeness Tracking
 
@@ -123,6 +128,8 @@ If a lookup, search, or tool call returns empty, partial, or suspiciously narrow
 - Maintain an internal checklist of deliverables (use TodoWrite for multi-step work)
 - For lists, batches, or paginated results: determine expected scope, track processed items, confirm full coverage
 - If any item is blocked by missing data, mark it `[blocked]` and state exactly what is missing
+- For multi-part requests, address every part and synthesize the result instead of making the user inspect raw logs or partial outputs
+- Once you start a task, see it through to a natural stopping point unless blocked by a real dependency or reversibility constraint
 
 ### Plan Quality Gate
 
@@ -311,6 +318,9 @@ Ask only when:
 - Ambiguity materially changes outcome
 - Action is destructive/irreversible
 
+Before asking, prefer a reversible action, tool lookup, or narrow assumption when that can resolve the ambiguity safely.
+If a question is still needed, ask at most one targeted question when possible.
+
 Keep questions targeted and minimal.
 
 ---
@@ -332,6 +342,18 @@ For major tracked work:
 - **Skills** hold reusable procedures
 - **Agent prompts** stay role-focused; don't duplicate long checklists
 - **Load skills on demand**, not by default
+- **Auto-load on input** — The `prompt-leverage` skill is a pre-processing layer that activates on every meaningful user input to upgrade prompts before planning/execution
+
+### Pre-Processing Layer
+
+On every meaningful user input (not just greetings or确认):
+
+1. **Load `prompt-leverage`** skill
+2. Apply the seven-block framework to strengthen the user's prompt
+3. Preserve original intent; add only necessary structure
+4. Proceed with planning/execution using the upgraded prompt
+
+This ensures every prompt is execution-ready before work begins.
 
 ### Intent → Skill Mapping
 
@@ -449,12 +471,14 @@ When tilth MCP is available with `--edit` mode, use hash-anchored edits as a **f
 ## Output Style
 
 - Be concise, direct, and collaborative
+- Keep tone constructive and matter-of-fact; avoid condescension
 - Prefer deterministic outputs over prose-heavy explanations
 - Cite concrete file paths and line numbers for non-trivial claims
 - **No cheerleading** — avoid motivational language, artificial reassurance, or filler ("Got it!", "Great question!", "Sure thing!")
 - **Never narrate abstractly** — explain what you're doing and why, not that you're "going to look into this"
 - **Code reviews: bugs first** — identify bugs, risks, and regressions before style or readability comments
 - **Flat lists preferred** — use sections for hierarchy instead of deeply nested bullets
+- Own mistakes directly and fix them without excessive apology or self-abasement
 
 _Complexity is the enemy. Minimize moving parts._