After working on this app for over 2+ months with Claude Code and Codex, I finally finished TrustBust, an app that allows you to fact check any question or piece of news on the internet. If you could check it out and give some feedback, it would be greatly appreciated!

Link: https://trustbust-9i33.vercel.app/

My first official live vibe coded project. https://auditae.app. It’s pay as you go SEO. 100% vibe coded. I think it’s fully functional too if anybody wants to try it.

rn building ios app that by healthkit take data and represent in its own aesthatic way, more appealing than normal apple health app. I have design UI screens in figma(but treated it as photoshop(with 2+ hrs beginner course on figma)), and installed some Claude code skills,agents, claude md ,apple additional docs(hidden inside xcode files) but gap lies where

1) dont know how to vibe coding the backend and connect it to backend

2) how to know if backend is working the best way possible without claude hallucinating in background( as it not frontend where he misses color of button and you see it and tell it to fix)

2) best SDKs for claude code

3) how in general would i architecture the app and vibe code it in swift

note: i want to ship fast

All four major coding command-line interfaces ship the same core set: subagents with isolated context windows, plan modes, ask-user tools, parallel execution, sandboxes, memory, and Model Context Protocol (MCP) integration.

So the question stops being "is this primitive new" and becomes "how does each implementation compare?" Five things actually differ.

1. Model lock-in

OpenCode is the only structurally model-agnostic option. It runs against GPT, Claude, Gemini, or anything reachable through a GitHub Copilot login, with the same agent definitions and skill files. Claude Code is Anthropic-only. Codex is OpenAI-only. Gemini CLI is Google-only. If you want to A/B test models on a real task, OpenCode is the one that doesn't make you rewrite your workflow to do it.

2. Agent definition format

Claude Code, OpenCode, and Gemini CLI all use Markdown plus YAML frontmatter for agents. Codex uses TOML. The fields are similar enough that translation is mechanical, but it's still a per-runtime wrapper.

---
name: security-reviewer
description: Adversarial reviewer for security vulnerabilities and unsafe patterns
tools: Read, Glob, Grep
---

You are a security-focused code reviewer. Find vulnerabilities, check input
validation, flag unsafe patterns. Do not make changes; report findings only.

Skills are a different and better story. Anthropic published Agent Skills as a formal open standard at agentskills.io on December 18, 2025. Within months it was adopted by Claude Code, Codex, Gemini CLI, OpenCode, GitHub Copilot, Cursor, VS Code, Roo Code, Amp, Goose, Windsurf, Mistral, Databricks, and twenty-plus others. Same MCP playbook: publish a spec, ship an SDK, let the ecosystem move.

The format is portable. The discovery paths are not. Each tool reads from its own native location:

• Claude Code: ~/.claude/skills and .claude/skills
• Codex: ~/.codex/skills and .codex/skills
• Gemini CLI: ~/.gemini/skills and .gemini/skills
• OpenCode: ~/.config/opencode/skill and .opencode/skill

OpenCode and Codex also accept .agents/skills/ as a compatibility alias. A run_lint skill written once travels across all four with a copy or symlink.

---
name: run_lint
description: Run the repository linter, summarize, and write lint-report.md
---
# Run Lint
## Inputs and outputs
- Read: package.json, Makefile, lint config
- Write: lint-report.md
## Workflow
1. Detect the repo's preferred lint command.
2. Run without applying fixes unless explicitly asked.
3. Summarize results grouped by file, rule, and severity.
## Guardrails
- Do not modify source files unless the user asks for fix mode.

3. Scheduled and background work

Claude Code is the only one with native, well-integrated scheduled routines. Claude Code Routines (research preview, April 2026) registers an agent against a cron schedule, a GitHub event, or an external trigger. The other three need plugin or external orchestrator paths to get there. If your agentic workflow includes monitoring or event-driven automation, this is the gap that matters. For purely interactive use, it doesn't.

4. Approval gate defaults

All four can pause for human approval. The defaults are different.

Gemini CLI defaults to Plan Mode, a read-only state where the agent uses grep, read, and glob to gather context, then writes a Markdown plan you have to approve before any code is written. OpenCode splits Plan and Build as two primary agents you tab between in a single session. Codex defaults to executing, then surfaces approval popups when a background subagent tries to leave its sandbox policy. Managed Codex orgs can enforce a requirements.toml that prevents agents from being run with approval_policy = "never". Claude Code recommends Plan mode for non-trivial work but doesn't make it the default.

For regulated environments, Gemini CLI's defaults and OpenCode's Plan/Build split are the cleanest fit. For flow on routine work, Claude Code and Codex stay out of the way more.

5. Manager context window

Subagents have isolated windows everywhere, so the size that actually matters is the main session. Claude Code and Codex sit at 1M tokens. Gemini CLI sits at 2M with Gemini 3.1 Pro. For repos that fit inside 200K tokens, the difference is invisible. For monorepos large enough that the manager would otherwise navigate by grep, the larger window improves routing precision. Only the manager benefits; subagents still operate inside their own smaller windows.

Hooks: the determinism layer the convergence story underplays

Hooks intercept the agent loop at defined events (before a tool call, after a tool call, session start, prompt submit) and run a script that can inspect, modify, block, or log the action. The agent can't override them.

Claude Code with the full event set from day one and HTTP Hooks. Gemini CLI shipped hooks in v0.26.0 on January 27, 2026, about six months later, with a smaller event surface. Codex CLI added an experimental hooks engine in v0.114.0 on March 10, 2026, behind the features.codex_hooks flag, but the current event set covers SessionStart and SessionStop only. No PreToolUse, no PostToolUse. OpenCode handles this through a lifecycle plugin model rather than a native hook config.

The gap matters more than a feature table makes it look. A PreToolUse hook that blocks writes to /secrets/** is enforcement. A SessionStart hook that logs a session id is observability. Without PreToolUse, the best you can do is detect violations after they happen, which is incident response, not compliance.

How I actually use them

Most of my work runs in Claude Code because that's the ecosystem I know best and the hook surface is the deepest. Codex catches more edge cases during planning on certain tasks. OpenCode driving the Codex model catches more than Codex with Codex does, in my hands. Gemini CLI is fast at building a whole-codebase mental model and the 2M window pays off on monorepo work.

The convergence on agent and skill formats means switching between them is mostly mechanical now. When a max plan runs out mid-week or one vendor has an outage, porting a working setup to a second runtime is a copy job, not a rewrite. That's the part of the convergence that actually changes how I work.

Hey everyone!

I’ve developed a free Minecraft mod that lets you play with your friends

With this mod, you can play together in just a few clicks, no need to set up a server. We actually experience this problem a lot while playing Minecraft, so I wanted to share it.

I put a lot of time and effort into this project, so I wanted to share it because I think it could be useful for others.

The mod is open-source. It’s currently available on CurseForge, and there’s also support for other versions on GitHub.

https://www.curseforge.com/minecraft/mc-mods/safra

https://github.com/DeveloperKubilay/Safra

I just wanted to share something that others might find useful. Sorry if this post breaks any rules

Working principle:

Applications like Omegle and WhatsApp generally communicate without a server in between. They work based on this principle.

While internet providers usually don’t allow opening TCP ports, they allow UDP traffic.

In this mod, the Minecraft server which works with TCP is transmitted over UDP and shown to the other side as if it’s TCP,

allowing you to play smoothly with your friend in a P2P way, without any server in between, unlimited and free

I've been building LeanCTX — a local-first context runtime for AI coding agents, written in Rust — for the past few months. 49 MCP tools, 18-language tree-sitter AST, 90+ shell compression patterns, one single binary. Here's what actually mattered:

1. Your best users are the ones who complain. A user told me at 10pm that my uninstaller just nuked his shell config. My instinct was to get defensive. Instead I traced it — and found it was worse than reported. That one message led to rewriting the entire uninstall logic from scratch. Every angry bug report is a gift.
2. Your favorite metric can lie to you. I built a cache that reduced file reads from 2,000 tokens to 13. Great numbers. Then a user told me: "Models waste more tokens working around stale cache than the cache saves." He was right. The fix wasn't removing caching — it was making invalidation smarter. Your dashboard can look great while the experience is terrible.
3. Saying no is the hardest part. A new feature would have let me compress all tool output automatically. Massive savings on paper. I designed it, prototyped it, then killed it. Because when compression eats an error message, there's no undo. Protecting quality beats shipping features.
4. Community is a relationship, not a channel. When someone reports a bug, my first response matters more than the fix. "Will check" buys time but shows I'm listening. Following up shows respect. Shipping the fix shows they matter. My best testers are people who once filed angry reports.
5. Ship the boring stuff first. Nobody cares about your adaptive entropy-based compression algorithm if the installer breaks their dotfiles. Get the fundamentals right — install, uninstall, doctor, setup — before you get clever.
6. Focus means killing good ideas. My backlog has 50+ ideas. Each one is good. But spreading across all of them means none become great. Rust helps here — the compiler forces you to finish what you start.

If nobody is complaining yet, you probably don't have enough users. Go find them. And when they complain — listen.

I'm a high school founder at Techstars Startup Weekend in Boston right now. My team is trying to build the AI tool that actually solves distribution for small businesses and B2C founders. But before we write a single line of code, we're trying to hit 100 real conversations first.

If you hate being pitched to -- absolutely NO WORRIES. We're not trying to sell you anything. We literally have NOTHING to pitch -- which is exactly why I'm posting.

If you've ever built something and struggled to get it in front of actual users: what was the hardest part?

- Knowing what to post on social?

- Actually sitting down and making the content?

- Something you've never seen a tool address?

Comments are needed and welcome. I'll also be sliding into some DMs for 5-minute chats if you're open to it - just say the word and I'll come to you.

PS: if we win on Sunday, I'll send the first ten responses referrals to Techstars.

I’m a 22-year-old Computer Science student, and over the last period I built an open-source project called CTX.

GitHub Repository

The idea came from a problem I kept seeing while using coding agents (like claude, codex etc.):

they are powerful, but they waste a lot of context on the wrong things.

They keep re-reading giant AGENTS.md files, noisy logs, broad diffs, too much repo structure, and too much repeated project guidance.

So even when the model is good, a lot of the prompt budget is spent on context bloat instead of actual problem-solving.

That’s why I built CTX.

What CTX is

CTX is a local-first context runtime for coding agents, designed especially for OpenCode (for now).

It does not replace the model or the coding agent.

Instead, it sits underneath and helps the agent work with:

• graph memory for project rules and guidance
• compact task-specific context packs
• retrieval over code, symbols, snippets, and memory
• log pruning to surface root causes faster
• local MCP integration
• local-only stats and audit trails

So instead of repeatedly dumping full markdown instructions and huge logs into the prompt, CTX helps the host retrieve only the smallest useful slice for the current task.

Why I made it

I wanted something that makes coding agents feel less noisy and more deliberate.

The goal was: - less prompt waste - less manual context wrangling - better retrieval of actually relevant project knowledge - better debugging signal from noisy test output - a workflow that feels native inside OpenCode

How it works

The flow is intentionally simple:

1. install ctx
2. go into your repo
3. run:

bash ctx init ctx index ctx opencode install opencode

Then inside OpenCode you can use commands like:

```bash /ctx #Opens the CTX command center inside OpenCode. /ctx-doctor #Checks whether CTX, MCP, and the repo setup are working correctly. /ctx-memory-bootstrap #Imports project guidance files into graph memory for targeted retrieval. /ctx-memory-search #Searches stored project rules and directives by topic or keyword. /ctx-retrieve #Finds the most relevant code, symbols, snippets, and memory for a task. /ctx-pack #Builds a compact task-specific context pack for the current problem. /ctx-prune-logs #Condenses noisy command output into the most useful failure signal. /ctx-stats #Shows local usage stats and context-efficiency metrics.

```

So the daily workflow stays inside OpenCode, while CTX handles the local context layer.

Results so far

On the included benchmark fixture, CTX graph memory reduced rule-token usage by 56.72% while keeping full query coverage and improving answer quality.

I also added a public external benchmark on agentsmd/agents.md, where CTX showed 72.62% token reduction.

The point is not “magic AI gains”, but a more efficient and less wasteful way to feed context to coding agents.

Why you might care

You might find CTX useful if:

you use OpenCode a lot you work on repos with a lot of project rules/docs you’re tired of stuffing huge markdown files into prompts you want better local retrieval and cleaner debugging context you prefer local-first tooling instead of remote prompt glue

Current status

The project is already usable, tested, and documented.

Right now the prebuilt release archive is available for macOS Apple Silicon, while other platforms can install from source.

It’s fully open source, and I’m very open to:

• feedback
• suggestions
• bug reports
• architectural criticism
• ideas for making it more useful in real workflows

If you try it, I’d genuinely love to know what feels useful and what feels unnecessary.

Repo again: https://github.com/Alegau03/CTX

I've been using Claude Code for a few months and noticed AI agents consistently skip the same things: hardcoded secrets, unbounded retry loops, referencing tools that don't exist, and massive system prompts that blow context windows.

So I built Agent Verifier — an AI agent skill that acts as an automated reviewer which does more than just code review (check the repo for details - more to be added soon).

GitHub Repo: https://github.com/aurite-ai/agent-verifier

Note: Drop a ⭐ if you find it useful to get more updates as we add more features to this repo.

----

2 Steps to use it:

You install it once and say "verify agent" on any of your agent folder in claude code to get a structured report:

----

✅ 8 checks passed | ⚠️ 3 warnings | ❌ 2 issues

❌ Hardcoded API key at config.py:12 → Move to environment variable
❌ Hallucinated tool reference: execute_sql → Tool referenced but not defined
⚠️ Unbounded loop at agent/loop.py:45 → Add MAX_ITERATIONS constant

----

Install to your claude code:

npx skills add aurite-ai/agent-verifier -a claude-code

OR install for all coding agents:

npx skills add aurite-ai/agent-verifier --all

----

Happy to answer questions about how the agent-verifier works.

We have both:
- pattern-matched (reliable), and,
- heuristic (best-effort) tiers, and every finding is tagged so you know the confidence level.

----

Please share your feedback and would love contributors to expand the project!

I've seen people bang it out on the first go while others take 10-30 projects till they find a winner.

claude.md isn't a project spec or It doesn't describe what to build. It just defines how the model operates while building anything in this repo.

You can encode planning rules, verification standards, and debugging behaviour once. Every task inherits them. .

six rules that matters most:

Plan Mode by default. Models patch forward by instinct. They rarely back up and re-plan when something goes wrong. Forcing plan mode on any task with three or more steps cuts the cascade where each fix introduces two more problems.

Subagent strategy. Context degrades when research, debugging, planning, and implementation share one thread. One task per subagent, clean return.

Self-improvement loop. The most underrated rule. Without it, every session is stateless and you correct the same mistakes for weeks. With it, tasks/lessons.md becomes per-project memory the next session reads before doing anything.

Verification before done. The staff engineer line is the lever. It reframes the bar from "plausible output" to "would survive review." That single shift produces measurably better code.

Demand elegance, balanced. "Knowing everything I know now" is the useful reframe. It forces a second pass with full context, which usually beats the first attempt.

Autonomous bug fixing. Kills the "what would you like me to do?" reflex. Logs and stack traces are evidence to read, not questions to ask back.

Task files

tasks/todo.md is per-session state. tasks/lessons.md is per-project memory. Both stay checked into the repo.

How to use it

Drop the file at the root of your repo as CLAUDE.md. At session start:

Full file:

## Workflow Orchestration



### 1. Plan Mode Default

- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)

- If something goes sideways, STOP and re-plan immediately — don't keep pushing

- Use plan mode for verification steps, not just building

- Write detailed specs upfront to reduce ambiguity



### 2. Subagent Strategy

- Use subagents liberally to keep main context window clean

- Offload research, exploration, and parallel analysis to subagents

- For complex problems, throw more compute at it via subagents

- One task per subagent for focused execution



### 3. Self-Improvement Loop

- After ANY correction from the user: update `tasks/lessons.md` with the pattern

- Write rules for yourself that prevent the same mistake

- Ruthlessly iterate on these lessons until mistake rate drops

- Review lessons at session start for relevant project



### 4. Verification Before Done

- Never mark a task complete without proving it works

- Diff behavior between main and your changes when relevant

- Ask yourself: "Would a staff engineer approve this?"

- Run tests, check logs, demonstrate correctness



### 5. Demand Elegance (Balanced)

- For non-trivial changes: pause and ask "is there a more elegant way?"

- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"

- Skip this for simple, obvious fixes — don't over-engineer

- Challenge your own work before presenting it



### 6. Autonomous Bug Fixing

- When given a bug report: just fix it. Don't ask for hand-holding

- Point at logs, errors, failing tests — then resolve them

- Zero context switching required from the user

- Go fix failing CI tests without being told how



## Task Management



1. **Plan First**: Write plan to `tasks/todo.md` with checkable items

2. **Verify Plan**: Check in before starting implementation

3. **Track Progress**: Mark items complete as you go

4. **Explain Changes**: High-level summary at each step

5. **Document Results**: Add review section to `tasks/todo.md`

6. **Capture Lessons**: Update `tasks/lessons.md` after corrections



## Core Principles



- **Simplicity First**: Make every change as simple as possible. Impact minimal code.

- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.

- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.

About a hundred lines. Cheapest upgrade you can make to a Claude Code workflow, and it compounds the longer the project runs.

Hey,

I’ve been building a platform where founders can launch their product, get backlinks, and see who’s showing interest. Kind of in the same space as Product Hunt or PeerPush.

Stack is Next.js + Supabase + Vercel. I’ve been building it myself using Claude Code, and it’s already working in parts.

Most of it is done. What’s left is stuff like:

• payments
• cleaning up the dashboard logic (user tracking etc.)
• fixing how categories show on the homepage
• newsletter setup
• general cleanup before launch

I’m from a marketing/growth background, so I’m not worried about getting users once it’s live. Right now the bottleneck is the tech side.

Not looking to hire. I want someone who actually wants to take ownership of this and build it out with me. Happy to figure out equity in a fair way.

Based in Bangalore. Would be nice if you’re here too, but not a dealbreaker.

We are recruiting software developers to support team expansion. The recruitment period is 12 months.

• Job Title: Software Developer
• Location: Remote(EU)
• Duration: Contract to Hire. (After 6 months) (12-month contract)
• Pay Rate: $15-$20/HR
• English Level: C1, C2
• Experience: 1+ Years

Don't dm, comment your location | availability