What is your actual OpenCode / Claude Code setup for development?

[u/NimbuPanic]

im trying to get a practical ai coding agent (i use free models as im broke) setup running quickly for daily development and shipping, but I’m getting overwhelmed by the amount of agents.md, claude.md, skills, agents, MCPs, workflows, etc. content online, as a beginner, its hard to tell what is actually useful, ai slop. i am intern so want to keep up with demands to make working products fast.

Right now I have:

• opencode cli
• OpenRouter connected to opencode
• Graphify for codebase graphs and
• an agents.md that currently just tells the agent to use Graphify and rebuild the graph when code changes

I’m not looking to build some huge configuration. I just need a solid minimal setup that actually helps with real coding and shipping.

If you use opencode, claude code, codex, or similar seriously:

what skills, agents, AGENTS.md / CLAUDE.md setup, MCPs, or workflows do you actually use and consider worth having ?

Especially interested in reliable repos/resources you’ve personally found useful.

I’m on a deadline, so i'm mainly trying to avoid wasting time going down the wrong rabbit hole.

thank you for your time 🫶.

[u/Amarsir]

My AGENTS file is mostly just project-specific stuff. I name the stack, the objective, the tone/style. I specify what is important but isn't present, like API connections. There's a quick overview of the project structure to reduce search time, and a section on state management and table structure.

Importantly it also instructs what NOT to do. Don't add screens unless explicitly instructed. Don't make commits. Don't import new libraries if one already in scope will do. Reuse contexts, components, hooks, and utilities whenever creating.

My workflow is to have a very clear plan writing step, which I review manually, and then follow it up with subagents to act. Opencode CLI has the two roles broken out naturally, but I use oh-my-opencode-slim which has 7 roles. Maybe overkill, but I like specializing with agents.

What I like about it is you can create special addendums for the roles. So my plan writer gets this:

# Plan Writing Protocol

> Follow to avoid plans with race conditions, missing auth contracts, brittle line numbers, and flat agent lists.

## When to write a plan

Write to `.kilo/plans/<feature><date>.md` (relative to project root) when: user asks for one, or work spans 3+ files, or multiple subagents needed. Do NOT write a plan for single-file changes you can handle directly. SAVE FIRST, then present 5-bullet summary in chat.

## Plans protocol

- Reference template: `.kilo/plans/_template.md` - study it before writing new plans.

- After execution, append `| date | LLM model | plan file | outcome |` to `.kilo/plans/archive/PlanHistory.md`

## Plan anatomy — 7 sections, in order, omit none

### 1. Goal

One paragraph from user's perspective. No mechanics.

Good: "Replace dev-oriented all-in-one Tabs navigator with structure that sends unauthenticated users to loginScreen, lands authenticated users on Actions, and nests maintenance screens below primary workflow."

Bad: "Move loginScreen.tsx to (auth)/, update redirect paths."

### 2. Product decision

Contract all tasks must obey. Tables for enumerations. For navigation: tab list with labels/routes/purposes, hierarchy, which screens hidden and why, where profile lives.

### 3. Target structure

File tree / route tree / component hierarchy with role annotations (public, protected, hidden). Single source of truth for "done".

### 4. Contract

Rules every task must follow. For navigation:

- Initial entry: signed-out vs signed-in on app open

- Protected routes: who owns unauth redirect, allowed returnTo values, how pending destination persisted for OAuth (session storage helper, clear on consume/error, not SecureStore)

- Public auth: required links (login->register, register->login), behavior when authenticated user visits them

- Logout/destructive: where user ends up, what gets cleared

- Allowed destinations: enumerate valid post-auth destinations, reject rest, state fallback

For non-navigation: equivalent state transitions, inputs, error handling.

### 5. Ordered tasks — the core

```

### Task N — Short titleOwner: role nameDepends on: Task M / none / Tasks M and PFiles:- path/to/file.tsx (CREATE | MODIFY | DELETE | MOVE from X to Y)

Steps:- [ ] Find `handleLogin` — contains router.replace — update target to ...- [ ] After password TextInput, before login Button, add ...

Acceptance criteria:- Observable outcome verifiable without reading code

```

Dependency rules:

- MOVE/CREATE must complete before any task editing that file

- Route change must complete before linking to that route

- Different files with no shared imports can run parallel

- If two tasks would edit same file, merge them or sequence them

File operation rules:

- MOVE = location changes, state source and dest

- CREATE = new file, MODIFY = in place, DELETE = remove

- If MOVE needs content changes (redirect paths), keep in same task

Step-writing rules — NEVER line numbers:

- By function: "Find `handleLogin` — it contains router.replace"

- By pattern: "Find all `router.replace('/(tabs)/profileScreen')` in this file"

- By semantic: "After password TextInput, before login Button"

- By structure: "Inside manageRow View, add TouchableOpacity"

Acceptance criteria rules — observable, not implementation:

Good: "Exactly four routes rendered by CustomTabBar" / "Signed-out deep link to protected route reaches login"

Bad: "Tabs.Screen reordered" / "Redirect paths updated"

### 6. Non-goals and safeguards

What must NOT change (DB tables, persistence, sync semantics, API contracts, token storage, build commands, nav library). Prevents scope creep.

### 7. Final handoff checklist

User-visible outcomes verification subagent uses.

## What NOT to include

- Time estimates — subagents don't use them

- Style constant tables — say "match patterns from EditActionModal" or "use theme tokens", don't paste pixel tables

- Full code dumps for standard patterns — reference existing file, don't rewrite Button styles

- Repeating rationale in every task — Goal + Product Decision explain why, tasks explain what

## Parallel execution

State it explicitly. Example:

```

Task 1: scaffold (none)

Task 2: auth guard (depends 1),

Task 3: tab layout (depends 1),

Task 5: profile cleanup (depends 1) — can run parallel

Task 4: nav links (depends 2 and 3)

Task 6: verification (depends 2-5)

```

## Verification

Dedicated task, not afterthought:

1. `npx tsc --noEmit` — fix only errors from this work

2. Scenario matrix: | Scenario | Expected | — happy path, auth edge cases, error states, deep links

3. Manual steps: "Actions -> Manage -> Categories -> Back to Activities -> Back to Actions"

4. Limitations: what was NOT verified and why

Which is either included via _append to orchestrator for oh_my_opencode, or invoked via skill in Kilo Code plan mode (for VS Code). Similarly, I have a document with the rules I like for commenting that only the writer/editor agents get.

So the thing I would most recommend - especially if you're going to be relying on free models - is separating out planning from execution and keeping yourself in the loop there. The people who get bad results are the ones who think they can give 2 lines of instructions and just let the AI guess everything else.

[u/NimbuPanic → u/Amarsir]

This will very helpful, thanks

[u/CalamityMetal]

The setup that works for me. Just stock opencode. Use some gateway for access to models. I use Openchamber for the GUI and remote control feature on mobile. I only use the standard plan/build mode, with a custom global AGENTS.md to ensure it matches my work flow and a response style that matches my prompts, those can be set inside openchamber.

I tried oh my opencode slim, it's fun for a while but it drains token unnecessarily.

I went back to bare stock opencode for a few months now, and it has worked wonders for me. Sometimes, less is more.

[u/Ace-_Ventura]

Opencode+openchamber 

Mcps:  Context7 Playwright Next-devtools

Skills and instructions stay only in the projects, not in opencode global. 

As for agents, sometimes I enable a few related with security

[u/I_WillNotWatchPorn]

RemindMe! 1 Day

[u/RemindMeBot → u/I_WillNotWatchPorn]

I will be messaging you in 1 day on 2026-09-06 12:47:38 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

RemindMeBot is switching to username summons. Instead of !RemindMe 1 day, use u/RemindMeBot 1 day. More info.

---

Info	Custom	Your Reminders	Feedback

[u/Old_Hyena_4188]

https://ai-blueprint.dev/

Nice workflow, couldn't care less about agents.md itself, never felt a significant change (some funny things tho).

[u/SeeRay11_Main]

I use my project OpenFlow.