docs: update README to include jsonc as installation config as well

[paulp-o]

Summary

• Update README installation instructions to support both opencode.json and opencode.jsonc config files
• JSONC (JSON with Comments) allows users to add comments in their OpenCode configuration

Changes

• Added note explaining JSONC support in both English and Korean READMEs
• Updated bash scripts to detect existing .jsonc files before .json
• Updated verification steps to check whichever config file exists

[code-yeongyu]

Great catch!

[paulp-o]

human note: the setup process done by agents would break when my config is in jsonc

[code-yeongyu]

Maybe I just updated README so it is conflicted can you update your branch?

[paulp-o]

항상 생각하고 조금씩 만들어오던 워크플로우 (특히 async agents)가 너무 완벽하게 만들어져있네요.. 좋은 플러그인 감사합니다

[paulp-o]

@code-yeongyu sure will do

[Copilot]

Pull request overview

This PR updates the installation documentation in both English and Korean READMEs to support JSONC (JSON with Comments) configuration files alongside the existing JSON format. The changes enable OpenCode users to add comments to their configuration files for better documentation and maintainability.

Key changes include:

• Modified bash installation scripts to detect and prefer .jsonc files before .json files
• Updated verification commands to check whichever config file format exists
• Minor formatting improvements (whitespace cleanup, table alignment, italics syntax)

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
README.md	Added JSONC support to installation scripts, updated verification steps, and minor formatting improvements
README.ko.md	Korean translation with identical JSONC support changes and formatting improvements

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

According to the PR description, this update adds support for JSONC (JSON with Comments) files. Consider adding a brief note at the beginning of this code block explaining that users can use either opencode.json or opencode.jsonc, and that JSONC allows adding comments to configuration files. This would help users understand the benefit of the new feature.

[code-yeongyu]

항상 생각하고 조금씩 만들어오던 워크플로우 (특히 async agents)가 너무 완벽하게 만들어져있네요.. 좋은 플러그인 감사합니다

🫡 좋은 워크플로우 쓰시는거 있으면 또 소개시켜주시고 제안해주세요. 제일 좋은 에이전트 하니스를 만들어봅시다!

[code-yeongyu]

I'll check that jq's jsonc handling feature as copilot have reviewed and merge

[paulp-o]

oops, jq doesn't seem to support jsonc. I only tested if my agent would manage to do it with the new README, it might have done some workaround as jq would fail

[code-yeongyu]

oops, jq doesn't seem to support jsonc. I only tested if my agent would manage to do it with the new README, it might have done some workaround as jq would fail

If this doesnt mind you what about keeping the current json thing but jsonc handling as a guide?

[paulp-o]

@code-yeongyu you mean guide to human or the agent?

I don't really have a very minimal solution for this in mind yet without making some sort of setup tool - maybe go for pattern matching using sed or guiding the llm do the edit itself (I think this is reliable enough)?

[code-yeongyu]

@code-yeongyu you mean guide to human or the agent?

I don't really have a very minimal solution for this in mind yet without making some sort of setup tool - maybe go for pattern matching using sed or guiding the llm do the edit itself (I think this is reliable enough)?

Trust me reliable enough lool

[paulp-o]

@code-yeongyu you mean guide to human or the agent?
I don't really have a very minimal solution for this in mind yet without making some sort of setup tool - maybe go for pattern matching using sed or guiding the llm do the edit itself (I think this is reliable enough)?

Trust me reliable enough lool

If then, what about removing the part for running code to add plugin entirely and just guide the llm edit both kind of config files by itself? Putting potentially duplicate solution might confuse the model i think

[code-yeongyu]

@code-yeongyu you mean guide to human or the agent?

I don't really have a very minimal solution for this in mind yet without making some sort of setup tool - maybe go for pattern matching using sed or guiding the llm do the edit itself (I think this is reliable enough)?

Trust me reliable enough lool

If then, what about removing the part for running code to add plugin entirely and just guide the llm edit both kind of config files by itself? Putting potentially duplicate solution might confuse the model i think

I think detailed guide on the prompt still matters from my experience. Can I make another PR making you as co author? Thank you for catching the jsonc case btw!

[paulp-o]

@code-yeongyu Sure.

btw, I honestly want to see a cli tool for setting omo up, which could deal with all these and also enable only (modularised) part of the features. (similar to taskmaster or openspec) I plan to do this myself on my own fork of omo soon, but I would like to make PR for that as well if you see the same value as me.

[code-yeongyu]

@code-yeongyu Sure.

btw, I honestly want to see a cli tool for setting omo up, which could deal with all these and also enable only (modularised) part of the features. (similar to taskmaster or openspec) I plan to do this myself on my own fork of omo soon, but I would like to make PR for that as well if you see the same value as me.

That's huge! I was thinking of one but other fancy features got my priority. (Current lack of installation guide is because of this)

Super appreciated if you contribute in a way.

One thing on my mind is that by not building a setup CLI, I'm effectively restricting configuration to a single method—but this stems from a desire to ensure the setup provides strong defaults. Even if we do eventually create a setup CLI, I believe it should only offer an option to launch immediately with recommended settings or, at most, choices within broad categories. Otherwise, running the installation CLI would feel like falling into a black hole.

[paulp-o]

@code-yeongyu Sure.
btw, I honestly want to see a cli tool for setting omo up, which could deal with all these and also enable only (modularised) part of the features. (similar to taskmaster or openspec) I plan to do this myself on my own fork of omo soon, but I would like to make PR for that as well if you see the same value as me.

That's huge! I was thinking of one but other fancy features got my priority. (Current lack of installation guide is because of this)

Super appreciated if you contribute in a way.

One thing on my mind is that by not building a setup CLI, I'm effectively restricting configuration to a single method—but this stems from a desire to ensure the setup provides strong defaults. Even if we do eventually create a setup CLI, I believe it should only offer an option to launch immediately with recommended settings or, at most, choices within broad categories. Otherwise, running the installation CLI would feel like falling into a black hole.

I'll start by respecting your default-first approach. I wholeheartedly wish background agent being separate though because it's too good by itself

[code-yeongyu]

@code-yeongyu Sure.
btw, I honestly want to see a cli tool for setting omo up, which could deal with all these and also enable only (modularised) part of the features. (similar to taskmaster or openspec) I plan to do this myself on my own fork of omo soon, but I would like to make PR for that as well if you see the same value as me.

That's huge! I was thinking of one but other fancy features got my priority. (Current lack of installation guide is because of this)
Super appreciated if you contribute in a way.
One thing on my mind is that by not building a setup CLI, I'm effectively restricting configuration to a single method—but this stems from a desire to ensure the setup provides strong defaults. Even if we do eventually create a setup CLI, I believe it should only offer an option to launch immediately with recommended settings or, at most, choices within broad categories. Otherwise, running the installation CLI would feel like falling into a black hole.

I'll start by respecting your default-first approach. I wholeheartedly wish background agent being separate though because it's too good by itself

That's good to hear. Just a question here: is this 'setup' thing doesn't valuable to you? I thought those curated agents and lsp / ast tools are like basic but missing stuff for other agents so wanna know your opinion

[paulp-o]

@code-yeongyu a CLI matters to me. But it's mostly personal.

I often use (or have to use) different workflows per project, or I’m just experimenting with various setups. In those cases, having to ask an AI to set things up every time feels slow, if not only nondeterministic. (Of course I just comment/uncomment oh-my-opencode in the config json"c")

that said, having a simple, deterministic on/off switch might actually make it easier for more people weird enough like me to try the flow in the first place. I as well doubted about letting an AI do a full install by itself, so I ended up reading the entire 'for agents' section myself anyway. lol.

Also, I suspect that many enthusiastic people who end up here already have some kind of personal workflow (myself included). Some of them also care a lot about on-demand tool definition loading (similar to Claude skills), because they're allergic to context bloat. Which is why I tend to avoid MCP as well.

In many workflows, I only like subparts of a it, and I also see people often end up building frankenagents/frankenworkflow by mixing pieces they like. (like, consider how many people still use things like @https://github.com/VoltAgent/awesome-claude-code-subagents.) To those people, too all-in-one, full-package solutions can feel a bit heavy to try and adopt (taskmaster has this issue in my opinion).

That's why being able to toggle 'modules' on and off via a CLI is needed personally for me (of course, generally, a simple install/uninstall would be so much handy too!). Specifically, I have my own plan subagent, websearch tool (tuned for my taste), etc. so no need for duplicate tools.

In the end, all of this might honestly not really relevant to you- since you’re aiming for strong defaults anyway. I'm just one of the many open source enthusiasts just enjoy putting together pieces from different projects to fit my own needs, and building agentic coding workflows isn’t very different.

tl;dr - it is, but for me. or anyone who wants things to be modular and put things together by themselves.

[paulp-o]

ps I also skipped dinner playing around with omo. good thing.

[code-yeongyu]

@code-yeongyu a CLI matters to me. But it's mostly personal.

I often use (or have to use) different workflows per project, or I’m just experimenting with various setups. In those cases, having to ask an AI to set things up every time feels slow, if not only nondeterministic. (Of course I just comment/uncomment oh-my-opencode in the config json"c")

that said, having a simple, deterministic on/off switch might actually make it easier for more people weird enough like me to try the flow in the first place. I as well doubted about letting an AI do a full install by itself, so I ended up reading the entire 'for agents' section myself anyway. lol.

Also, I suspect that many enthusiastic people who end up here already have some kind of personal workflow (myself included). Some of them also care a lot about on-demand tool definition loading (similar to Claude skills), because they're allergic to context bloat. Which is why I tend to avoid MCP as well.

In many workflows, I only like subparts of a it, and I also see people often end up building frankenagents/frankenworkflow by mixing pieces they like. (like, consider how many people still use things like @VoltAgent/awesome-claude-code-subagents.) To those people, too all-in-one, full-package solutions can feel a bit heavy to try and adopt (taskmaster has this issue in my opinion).

That's why being able to toggle 'modules' on and off via a CLI is needed personally for me (of course, generally, a simple install/uninstall would be so much handy too!). Specifically, I have my own plan subagent, websearch tool (tuned for my taste), etc. so no need for duplicate tools.

In the end, all of this might honestly not really relevant to you- since you’re aiming for strong defaults anyway. I'm just one of the many open source enthusiasts just enjoy putting together pieces from different projects to fit my own needs, and building agentic coding workflows isn’t very different.

tl;dr - it is, but for me. or anyone who wants things to be modular and put things together by themselves.

I will seriously consider making this to be separated modules and let this project to gather them all. Suggesting highly opinionated default setup while making them all configurable. It might be tricky to configure to do so but to make this thing as Omarchy of OpenCode it would fit much better than. Thank you for your good idea.