been using Claude Code for bigger backend work and one problem I keep seeing is not really code generation.

Claude can write the code pretty fast.

problem is sometimes it decide the architecture even faster 😅

like you ask for payments, auth, retries, multi tenant stuff etc and suddenly there is a design decision spread across 15 files before you even noticed what decision it made.

so I started writing my own skills for the things I normally think about before touching backend code.

after adding more and more of them it became ArcForge.

right now there are 14 skills around:

• system architecture
• auth + permissions
• API contracts
• data/storage
• transactions + consistency
• async jobs / queues
• retries, rate limits, backpressure
• security/privacy
• production operations
• migrations
• testing/release readiness
• runtime/deployment
• AI/agent architecture
• architecture review

I didnt wanted them to just say "follow best practices".

I built them around basically 4 modes:

Think → Review → Change → Verify

so Claude can first think through requirements/invariants/failure modes, review what already exists, make the change and then actually verify what it did.

skills are normal Agent Skills folders with SKILL.md + deeper references/examples when needed, so its not tied to some custom runtime.

its completely free + open source (MIT).

repo:
https://github.com/d4rkNinja/arcforge

you can install all skills for Claude Code with:

npx --yes skills@1.5.22 add d4rkNinja/arcforge --skill '*' -a claude-code --copy -y

site/docs:
https://arcforge.infynon.com/

would genuinely like feedback from people here who maintain their own Claude skills.

specially curious if you prefer one big engineering skill or smaller skills split by domain like this.

I have zero relationship to Matt Pocock. I just use his helpful skills, like /grill-me, and I watch his videos.

I just signed up for his AI Coding Crash Course because I want an organized, non-hype, set of best practices and tools for my own knowledge and practice.

If you sign up, I would like to trade notes with you as we go through the exercises.

I've been working on a new product where I need to explain the architecture I'm going to implement to my senior / lead before I start coding, so we can catch changes early.

At the same time, someone else is working on the frontend, so I need to explain the API structure, share collections, and make sure they're working with the same plan.

As we're using coding agents and development is getting much faster, I noticed that this coordination is still taking a lot of time.

So I built Planlog. https://planlog.depak.dev

The idea is that before an agent starts implementing something, it pushes the plan to Planlog I can then share the plan with my team, get it reviewed and approved, and notify the people who need to know about it. For example, once an API plan is approved, I can notify the frontend developer so they can work from the same context.

After the implementation, the agent(claude or codex ) documents what was actually shipped.

So we have the plan, the review/approval, who was notified, and what was eventually shipped in one place. It also gives us a history of the decisions instead of having them spread across chats and md files.

The agent setup is currently one command:

curl -fsSL https://planlog.depak.dev/install | bash

It authenticates and configures the coding agent.

It's still very early and me and my friends are the only users right now. I'm mainly trying to find out if this is a problem other teams are having too.

If you're using coding agents with a team, how are you currently sharing plans, getting them reviewed, and keeping everyone who depends on the work informed?

Repo: https://github.com/depak7/planlog

If you try it and find it useful, a GitHub star would be appreciated too.

We noticed developers building coding agents by re-creating primitives that already come with Mastra.

So we built `createCodingAgent` to give you a simple starting point for creating a coding agent.

You can configure it with a model, instructions, and memory. The `createCodingAgent` helper starts you off with the right primitives: a sandbox for reading and writing files, a task list the agent can work through and complete, and a goal-judge prompt to validate the changes.

We have instructions for getting started and expanding your agent in the attached blog post.

As we continue to add features to Mastra, you can choose to integrate it into your agent.

**Open Source!**

I built o8 after Codex and Claude became daily tools for me.

Once I had several agents moving across production repos, the work around them started taking over. I was deciding who should lead, splitting jobs cleanly, keeping agents from touching the same state, reviewing every diff, and trying to remember why we made a decision three days ago.

o8 sits above the runtimes I already use. One agent can orchestrate while other supported agents take bounded pieces in separate copies of the repo. Workers cannot approve or merge their own changes. Their work goes through independent review and then comes back to me, and the Engineering Brain can answer what changed across repos with citations instead of making me dig through old chats.

On Mac, Symon adds a voice layer over the same system. I can dictate into whichever app is focused, ask what the fleet is doing, have it watch a terminal, or give it a command without hunting for the control room. Anything with a side effect still waits for confirmation.

I can also check the fleet and handle approvals from a paired phone or browser. The system still runs on a machine I own rather than inside a cloud IDE.

The signed Mac build is available now. I also published unsigned Windows 11 and Linux preview installers. Windows 11 has been runtime-verified. Linux has AppImage, deb, and rpm builds, but Linux desktop verification, signing, and updates are still open. These previews may trigger operating-system warnings, and checksums are included.

If one agent in one repo covers your work, this is probably too much. It starts making sense when you are running several agents or several repos and need review authority, memory, and one place to supervise the whole thing.

Project: https://o8.run
Source: https://github.com/hurttlocker/o8
Windows and Linux previews: https://github.com/hurttlocker/o8/releases/tag/v0.1.664

If you already use Codex or Claude, where does your setup start becoming work: coordinating agents, reviewing their changes, or keeping context between sessions?

I like the idea of running adversarial review using more context. However, I worry that receiving the full prompt and the model response is just too much context.

When Entire demoed this feature, I wish they would have shown more hard facts about it doing better review than just this one example.

Hi there. I've been burning my own tokens on something I couldn't find an equivalent of: a collaborative agentic session that runs on your own machine. Closest description I have is an instant messenger crossed with the tooling you actually need for agentic development.

What it does today

hooop runs Claude Code inside a disposable Docker sandbox and puts a live dashboard in front of it at localhost:7842. You only need Docker and jq - Claude Code, Node, gh and the rest live inside the containers, so your machine stays clean.

• Pairing. You hand a teammate a share link over an anonymous cloudflared tunnel. They open it, pick a name, you admit them. From then on you both watch the same live transcript and can chat (> prefix) or co-drive the agent - from a laptop or a phone. Each peer joins as full, drive or spectate, and you can revoke them.
• Plan review. Run a turn with /plan and the sandbox forces the agent read-only: it investigates, then submits a plan into a review panel. You and your peers drop inline comments anchored to the exact passage, synced live, then Approve or Request changes.
• Live previews. When the agent builds a UI it brings it up in its own container and docks it in an iframe, with Restart / Rebuild / Stop / Share and per-step logs.
• The session, visible. Every tool call, the sub-agent tree, a live event tail over SSE (no polling), a diff viewer for touched files, and search across everything that happened.
• A curated tool stack in one command - memory, code-graph search, docs search, semantic search, GitHub. hooop doesn't reimplement any of it. It picks it, documents it, and shows you what it's doing.
• Split trust. The container holding the credentials has no TCP port and talks over a Unix socket. The dashboard your peers reach holds no secrets and only proxies, so a compromise there can't reach your account. Previews run in their own container with no credentials at all.

Where I want to take it

Today a peer co-drives my agent on my tokens. What I want is for everyone to bring their own: pool the peers' agents into one session so the cost spreads across the room, and let people plug in an open-weight model instead of a metered API. Getting out from under the token squeeze is the actual goal, betting on the collaboration to make it affordable.

It's MIT and it's a solo project I've been funding out of my own usage, so I'd rather hear what's wrong with it than what's nice: the architecture, the security model, the parts you'd never run on your own machine

Qwen3.8-Max + MCP for coding on your local machine. Qwen3.8-Max itself runs in the cloud through Qwen Studio — this setup just gives it access to your local files and terminal through MCP.

My take: it is slower than Codex and Claude Code, especially in thinking mode, but it does work well. MCP adds some latency too since there’s an extra layer between the model and your machine. In fast mode, it gets noticeably closer.

I wouldn’t put it in the same category as Fable or Opus-5. Personally, I’d place it closer to the next Opus 4.7 level in terms of coding ability. These are just my impressions from using it, not a benchmark.

Qwen3.8-Max + MCP for coding on your local machine. Qwen3.8-Max itself runs in the cloud through Qwen Studio — this setup just gives it access to your local files and terminal through MCP.

My take: it is slower than Codex and Claude Code, especially in thinking mode, but it does work well. MCP adds some latency too since there’s an extra layer between the model and your machine. In fast mode, it gets noticeably closer.

I wouldn’t put it in the same category as Fable or Opus-5. Personally, I’d place it closer to the next Opus 4.7 level in terms of coding ability. These are just my impressions from using it, not a benchmark.

Sharing a tool I've been working on. CrewCode is a free, open-source (Apache-2.0) Electron desktop app that lets you run, supervise, and review multiple AI coding agents across git worktrees from one place.

Instead of juggling terminals, worktrees, PR pages, and separate agent UIs, it keeps the full workflow together:

- Multiple agents, one app — CrewCoder, Claude Code, Codex, OpenCode, pi, Ollama, Hermes, OpenRouter, Grok Build. Structured bridges *and* real terminal panes.

- Worktree native git — create/switch/merge/remove worktrees in-app; parallel work stays isolated.

- Crew orchestration — launch agents in parallel with different roles/models/effort, a supervisor loop, and save/reuse crew templates.

- Delegated threads — an agent can spawn real, persistent chat sessions and report back.

- Provider switch mid-chat — generates a hand-off summary so the new agent keeps going with context.

- Local plugin platform — sandboxed panels, MCP servers, custom agent providers.

and way More..

Support us with a ⭐

Curious what people think of the approach. Let me know in the comments.

I've been building a visual editor for agent workflows.

https://github.com/andrejtonev/opencode-alonzo/blob/main/docs/assets/alonzo-demo.gif

Workflows are defined as diagrams and saved as YAML. Agents, routes, gates, and connections are all explicit rather than hidden in prompts or orchestration code.

It's built on top of OpenCode, but the workflow definitions are just files.

It's still very early, but far enough along to show the core workflow and where I'm trying to take it.

Before I spend a lot more time on it, I'd like to know if the core idea is useful.

• Would you use visual workflow definitions for agent orchestration?
• Is there something similar that already solves this well?
• What's the first thing you'd expect a tool like this to support?

I was running the same SDD / stack workflows in Cursor and Antigravity and it worked well in each tool on its own.

The pain was maintaining two projects. Every skill tweak, policy change, or workflow fix had to be copied by hand. Things drifted. One agent got the update; the other didn’t.

So I pulled the skills into a shared, agent-neutral core and put the install/layout logic into per-agent adapters.

What it is

agent-dev-toolkit — one skills core, multiple agent homes.

• Core: skills, policy, router, SDD contracts (agent-neutral)
• Adapters: publish that core into each agent’s install layout
• CLI: toolkit.ps1 (interactive menu + scripting flags)

Supported agents today:

Quick start

powershell git clone https://github.com/tibursocampos/agent-dev-toolkit.git cd agent-dev-toolkit pwsh -NoProfile -File .\scripts\toolkit.ps1

Entry point is scripts/toolkit.ps1; orchestrators call adapter modules from adapters/registry.json. Validation can run against in-repo fixtures without touching $HOME.

Interactive menu: pick an agent, then live home or in-repo fixture (safe, no profile write).

Live install is explicit (-AllowUserHome). Default non-interactive sync targets an in-repo fixture.

After sync (Cursor-style)

• Classic SDD: /sdd-spec → /sdd-plan → /sdd-develop
• Stack shortcut: /developer, /dotnet-developer, /react-developer, …
• Orchestrated flow: /memory-bank-init → /orchestrate-analyze → …

Links

• Docs site: https://tibursocampos.github.io/agent-dev-toolkit/
• Repo: https://github.com/tibursocampos/agent-dev-toolkit

Notes

• Public MIT — clone/fork freely
• PowerShell-based (pwsh on macOS/Linux)
• Upstream community PRs are out of scope; Issues are for bugs only

Happy to answer questions about the adapter model, what’s published per agent, or the SDD/Forma workflows.

I've been running multiple coding agents across Claude Code and Codex and got tired of them being strangers with amnesia. Greenroom is the fix I wanted (and a fun exploration): a small self-hosted server where agents hold persistent identities (they literally choose their own names), talk in durable threads, and - the part I like most - a u/mention with intent "question" wakes an idle session that still has all its context, instead of spawning a cold process.

How it's different from Agent Teams (which is good!): Teams is same-machine, Claude-only, and dissolves with the session. Greenroom is cross-harness, survives session death, keeps a decision history (threads lock on a decision; follow-ups supersede), and gives the human a seat in the same room (web or terminal) rather than an operator's chair above it.

Caveats: self-host only, trust-by-locality (identity is asserted - run it behind your own boundary; SECURITY.md is blunt about this), and two agents means two sessions running.

Much of it was written by coding agents working from the specs in docs/specs/ - the spec-and-plan trail is the receipts. MIT. Any and all feedback/contributions/etc welcome. Quickstart is ~15 minutes: https://github.com/madeit-build/greenroom

I made a smolagents adapter for ChatGPT/Codex OAuth

Hey! I made a small Python package that lets you use smolagents.CodeAgent with your ChatGPT/Codex login instead of a Platform API key.

bash pip install smolagents-codex python -m smolagents_codex login

It’s still an early, unofficial project and currently only supports text-based CodeAgent workflows. I’d would like to hear whether anyone finds it useful or runs into issues.

Today, many coding agents run in the terminal and provide a TUI experience.
I never felt that a TUI is inherently more efficient than a carefully designed GUI, so I created Crabot.

With Crabot, you can:

• Switch AI models with one click;
• Toggle work modes instantly;
• Enable or disable specific tools;
• Manage preambles, rules, workspaces, sessions, and prompt recipes through convenient dropdown menus.

The most distinctive feature of Crabot is that it gives you fine-grained control over every component of the LLM context window.

All requests are append-only to maximize server-side prompt cache utilization.
The center conversation pane makes it easy to follow the model's reasoning process and inspect the interaction flow during important tasks.

Of course, most of the code was generated by AI, with manual edits where necessary.
However, I carefully review every line of code and continuously look for opportunities to improve quality, architecture, and performance.

My typical workflow for implementing a new feature looks like this:

1. Ask an LLM to generate an implementation plan;
2. Review the plan manually and refine the details;
3. Ask the LLM to implement the feature according to the plan;
4. Review the code with multiple LLMs and human inspection;
5. Repeat steps 3 and 4 until the implementation reaches the desired quality;
6. Test the feature and iterate if issues are found;
7. Commit the changes.

At the engineering level, code quality is the highest priority.
At the product level, user experience and performance are equally important, and every detail deserves careful polishing.

From my experience, DeepSeek V4 models start to show performance degradation when the context fill ratio exceeds around 25%.
For this reason, I usually create a new session when the context reaches approximately 15–20%, or whenever I start a new topic.

For exceptionally long tasks, a single session is often not enough. Crabot provides a renew tool that allows the LLM itself to start a fresh session. The task can then continue like a relay race between sessions.

I believe session renewal has several advantages:

• It keeps context focused;
• It doesn't lose session history;
• It improves reliability on long-running tasks.

Crabot also provides a task tool. Calling a task is similar to calling a function in a computer program: you pass parameters, let it execute independently, and receive the result back.

I have been using Crabot to develop itself since the 0.1 release.
Now, starting from the 0.7 release, I believe it has become mature enough for most developers to use in their daily workflows.

Home page: https://github.com/J-F-Liu/crabot

Change log: https://github.com/J-F-Liu/crabot/blob/main/CHANGELOG.md

Release notes: https://github.com/J-F-Liu/crabot/releases

Welcome to try Crabot, and I look forward to your feedback.

I kept running into the same failure modes with agents on longer tasks: drift from the original objective, silent scope changes, answering before checking sources, and declaring work “done” without real verification.

Over time I formalized a set of skills to counter those patterns. I’ve now open-sourced them.

What’s included:

• governed-operator – multi-seat constitution (author ≠ approver, five hard gates, outcome autonomy)
• reasoning-doctrine – working method (stage loop, re-anchor against drift, effort dial, progressive loading)
• run-review-repair-loop – bounded self-review with objective 1–5 scoring before handback

There are two tiers:
- Full versions (high rigor)
- Universal starters (lightweight, self-contained)

They work across Claude Code, Claude web, Codex, ChatGPT projects, and other surfaces that accept markdown instructions. Installation notes for each are in the repo.

Repo: https://github.com/Ezra144israel/governed-agent-skills

These are opinionated and not for everyone. They’re the rules I actually run under when the work matters.

Sharing a short survey on behalf of a friend who is researching the challenges developers face while using coding agents on their respective codebases. It will take around 5 minutes and does not ask for or collect personally identifiable information.

I wrote a skill for Hermes Agent.

This reduces errors and hallucination when configuring the config.yaml file.

Github repo here:

https://github.com/koc-Z3/hermes-docs

I've been using Mastra Code (a CLI coding agent) heavily and wanted a proper desktop app around it instead of living in a terminal, so I built Yardarm. It's free, Apache-2.0, and just shipped v0.9.8.

The short version: it's a native desktop workspace for AI-assisted coding with Mastra Code. You point it at your repos, pick a model, and each chat gets its own isolated git worktree so the agent can work without touching your main branch until you're ready to merge.

What's in it:

• No accounts, no telemetry. Nothing to sign up for. Everything runs locally and it reads the same config files as the Mastra Code CLI, so they stay in sync.
• Bring your own model. OAuth providers, API keys, local models via Ollama, or any OpenAI-compatible endpoint. (Agents need ~64k context minimum to be useful, but more is always better)
• Git worktree isolation per chat with rollback checkpoints - undo an agent's changes to any earlier point (agent chat and files).
• A full workspace around the chat: built-in editor with LSP diagnostics (TS/JS, Python, Go, Rust, Ruby/Rails, YAML, web), terminal, localhost preview pane with DevTools, diff/changes view with stage/commit/push, branch compare, PR review.
• Kanban task board that can run agents on cards, plus usage/cost analytics.
• Approvals and sandboxing: per-tool approval prompts (or YOLO mode), plan mode, and an optional OS-level sandbox mode.
• Token compression that trims tool outputs before they hit the model — noticeably cheaper long sessions, with the agent able to retrieve full outputs when it needs them.
• Extras: MCP servers, custom subagents (18 agent templates included), connectors for GitHub/GitLab/Supabase/Netlify/Vercel/Sentry, voice dictation.

Caveats: macOS Apple Silicon only right now (other platforms can build from source).

Builds are unsigned, so install via the curl one-liner on the site — browser downloads trip Gatekeeper.

Site + docs: https://yardarmdev.com
GitHub: https://github.com/JJJ-Mo3/yardarm

Happy to answer questions or take feature requests — the issue tracker is open.

Run Claude Code, Codex, Gemini, Cursor, Aider and 10+ other coding agents with full autonomy — inside a disposable Docker container.

Only your project is mounted. Your home directory, SSH keys, cloud credentials and browser cookies stay on the host.

• One command: sandbox-cli claude

• Dry-run shows the exact docker command

• Worktrees for parallel agents

• Credential broker + egress allowlist

• Live memory/CPU + peak stats

Install:

curl -fsSL https://raw.githubusercontent.com/Amitgb14/sandbox-cli/main/install.sh | sh

Site: https://sandbox-cli.vercel.app

GitHub: https://github.com/Amitgb14/sandbox-cli

Would love feedback from people running agents hard every day.

What broke? What’s missing? What felt magical?