u/CriteriumA

Skills.md are one of the biggest advances in the use of AI.

But I feel they are a very dangerous mechanism.

All definitions of installed skills are sent to the beginning of each API call, in the system prompt. This is the most important part when you start working with a tool in a new session or after context compaction.

With just 3 or 4 skills, these definitions will likely already occupy as much space as the rest of the system prompt (custom prompt - AGENTS.md files).

And on top of that, we install them without properly reviewing their YAML front matter.

They not only burden you with tokens, but they can also clutter and influence the model's response without you even realizing it.

They shouldn't be discarded; they remain a very valuable tool. However, the self-charging feature of this model doesn't justify their regular installation.

The solution is very simple; we just need to specify something like this in the custom prompt we send at the beginning of the session and in each subsequent message:

Skills loading: manual with read. Location: ~/.agents/skills/. Available: one, two, three, opencode-customize, opencode-database, find-skills, skill-creator, xlsx, xlsx-manipulation, frontend-design.

And set:

OPENCODE_DISABLE_EXTERNAL_SKILLS=1

Ideally, we should know better than the model which skills might be useful before we start programming in "our" projects—not the typical ts+react+vercel projects of the model.

The model already knows which skills are available; it wouldn't even need to use `ls` on the directory and knows where to find them to load them into the context. We just need to ask it to do it. It's quite simple and requires little effort on our part.

And there's no problem with the model, he already knows they exist, and without so much context contaminating his answers.

https://preview.redd.it/eybtywb50x0h1.png?width=1963&format=png&auto=webp&s=9ea6937094b2753166e6e7f443f7c6e132cd5a51

Am I missing something with this solution?

I am investigating the OpenCode system prompt.

I'm investigating the OpenCode system prompt and have found some things we should be aware of.

AGENTS.md/CLAUDE.md is great, but only if you know how to use it correctly.

Its contents are automatically passed at the beginning of each API call, making it very important for the model and significantly impacting its functionality.

There are two problems.

For those with disorganized data: if the content is excessive or outdated, this significantly affects the model's behavior. And you may not even be aware of it.

For the disciplined ones who keep it constantly updated. Each time the model's API is called, it is regenerated, just like what happens with AGENTS.md globally. In models with KV cache management with longer expiration times (such as DS V4 which even dumps to disk), this reduces cache hits and increases cache misses.

Luckily exists:

OPENCODE_DISABLE_PROJECT_CONFIG=true
OPENCODE_DISABLE_CLAUDE_CODE_PROMPT=true

You just need to be less lazy and think about when it would be good for your model to read it and update it beforehand.

It will also help a lot not to use AGENTS.md globally, as it is read and rebuilt on every call to the model. Instead, it is better to use a custom prompt that is only read in new o resume session.

Fine-tune and set it for your model, for your mode:
"prompt": "{file:/route/opencode/prompt-custom/custom.txt}",

This overwrite de default prompt for system prompt:
https://github.com/anomalyco/opencode/blob/dev/packages/opencode/src/session/prompt/default.txt

Edit: I use DeepSeek, review other default prompt for order models: https://github.com/anomalyco/opencode/tree/dev/packages/opencode/src/session/prompt

Don't complain about OpenCode's results; just adapt it to your preferences. Something I think would be much more complicated in Claude Code and others.

I love OpenCode, long glory to OpenCode 😄

I just discovered that ES Flash is in free mode on OpenCode Zen 😳

Hi.

When working with OpenCode and DeepSeek V4 Flash (though this may happen with others), editing source code files often leads to errors. It makes incorrect text substitutions, causing ghost code to appear or entire lines of text to be deleted.

Is anyone else experiencing this?

Do you have any options or solutions for this problem?

I'm fine-tuning a global md, CLAUDE global inherited from CC, which loads well in OpenCode.

Errors are still appearing, and I ask DS about them and how to avoid them in the future.
They slow down editing, but deleting a line of code in the wrong place can be a much bigger problem than that lost time.
For now, I'm finding all those mistakes with the help of Git, but it still makes me very insecure that I might miss some catastrophic editing error.

DS has summarized this for me:

1. Reread before editing — always read the file again before each edit. Don't trust your memory. DFMs change with every UI tweak, PAS files with every refactor. (Learned this the hard way today.)

2. One oldString = one logical unit — don't group multiple unrelated blocks in a single replacement. If you need to change two adjacent CSS rules, do two separate edits.

3. Include intermediate lines — when doing batch replacements, include ALL lines between first and last change in the oldString. Skipping lines can cause false positives in fuzzy matching.

4. Verify uniqueness with grep -c — before any edit, check that your oldString appears exactly once. Zero matches = wrong context. Multiple matches = ambiguous target. Don't edit until you fix the match.

5. Exact oldString — whitespace, indentation, line endings must match exactly. Include at least 2 lines of surrounding context to disambiguate.

6. Duplicate block hazard — when two sections look nearly identical, the matcher only replaces the first occurrence. The second stays untouched, creating inconsistent code. Add unique context (e.g. the line before) to differentiate.

7. Prefer small changes — individual line edits are safer than replacing large blocks. DFM component blocks are especially dangerous: only change the object name and event bindings, never touch positional/visual properties (Left, Top, Width, images, fonts — those are IDE-managed design data).