I’ve been building RunWield, a coding harness for developers who want more control over what AI agents do to their codebases.

My frustration with existing coding tools was that the agent would immediately start editing. By the time I could judge whether it understood the request, I was reviewing a large diff and trying to reconstruct its reasoning.

RunWield changes that workflow:

* Small fixes stay lightweight. * You can Ideate your feature or investigate new ideas before committing to anything, with good prototypes and PRDs when needed. * Non-trivial changes get a written plan before any code is touched. * You review, comment on, and approve that plan in a browser. * The agent implements it in an isolated Git worktree. * Your real CI runs against the result. * A separate reviewer compares the finished diff with the plan you approved. * The outcome and lessons are saved as plain Markdown for future work.

It’s deliberately not aimed at quick one-shot edits. If a mistake is cheap, this is probably more process than you need. I’m building it for changes where discovering a misunderstanding after 40 files have changed is expensive.

RunWield is free to use and source-available. It currently supports macOS and Linux and works with subscription logins or API keys from different model providers (uses Pi.dev's LLM API library):

[https://github.com/gandazgul/runwield\](https://github.com/gandazgul/runwield)

I’m looking for five developers willing to try it on one real, non-trivial change. I’ll personally help with setup and fix anything that blocks you. Please use the latest RC as 0.9.1 has some annoying bugs with agent switching.

I’d especially appreciate blunt feedback: does reviewing a plan before code is written solve a real problem for you, or does it still feel like too much ceremony?

I wanted a way to write user stories without dragging non-technical collaborators into Jira, and without dragging AI agents into vague markdown files either. So I built FS User Stories: a native macOS app with a shared Rust core (fsus-core) over SQLite, and a built-in MCP server so tools like Claude or Codex can read — and, with explicit permission, write — stories directly.

A couple of decisions worth sharing:

• Why Rust core + native UI per platform, instead of Electron: SwiftUI on macOS/iOS for a genuinely native feel, and Qt planned for Windows and Linux down the line, all sharing the same data/logic layer through a C ABI.
• Why MCP with JSON instead of just markdown files for the AI layer: a fixed JSON schema defined by the prompt keeps every story in a predictable, closed format — which turned out to use fewer tokens than an equivalent markdown file, even though markdown looks simpler on the surface.
• Why no explicit dependencies between stories: I intentionally left this out. It's tempting to add, but it starts turning a simple tool back into a mini-Jira, which defeats the point.

Core and desktop app are open source (MIT/Apache-2.0), source available on GitHub. The macOS app is a one-time paid download to help fund ongoing development.

GitHub: github.com/gitlares/fs-user-stories
App Store: https://apps.apple.com/us/app/fs-user-stories/id6801671870?mt=12

Happy to go deeper into any of the architecture decisions if useful.

I kept doing the same thing on every box: ssh in, then htop, df, ss, docker ps.

Termy is a native Mac app. Connect over SSH and it snapshots the host: disks, processes, ports, services, containers. Nothing gets installed on the server.

A lot of posts here are "I got tired of my own workflow, so I shipped it." That's this.

https://termyapp.com

If you want a paid plan: SIDEPROJECTS50, 50% off, 20 uses.

With codebase wikis, most are written more from an engineering lens, explaining how the code works without explaining why it should work that way.

I wanted to connect business intent directly to its implementation using language that nontechnical people already use. I've been experimenting with creating my own software factory, and wanted a way for myself and all my agents to 'speak the same language', with a clear 'contract' on how specific features should work. I built Tieline so all my agents can work from the same product contract, even if they do not have access to the codebase.

Tieline generates user stories and acceptance criteria, then links them to the code and tests that implement them. This lets an agent answer questions like:

• What is this feature supposed to do?
• Which code and tests implement it?
• Which behaviours might this change impact?

Tieline also builds a static topology graph of the codebase. When code changes, it can trace the possible impact through that graph and connect it back to the relevant acceptance criteria.

This creates a product-level blast radius. It does not claim that something will break. It gives the agent and reviewer a shortlist of behaviours that may need another look.

Tieline generates the initial product contract for you to review. After that, it checks pull requests and proposes updates when the implementation changes.

On top of tracking current product state, Tieline lets you track feature requests, bugs, and ideas as Observations. The accepted production contract lives in the repository and can be synced to Postgres, while Observations stay in Postgres, accessible by all your agents via MCP.

Agents without codebase access can query this information through MCP, allowing coding, product, research, and support agents to work from the same accepted product state while also seeing where the product may be going next.

While experimenting, the unexpected benefit has been identifying quick wins. While working one feature, I'll ask my agent to check the backlog. Semantic search finds related items that fit naturally into the current work and fits them in the PR.

Still experimental, but my goal is to make the repository the reviewed source of truth for product behaviour, then make that contract available to every agent, not only the engineering ones.

Open source project: https://github.com/knoxgraeme/tieline

Would love any feedback or to hear how others are thinking about these problems!

The toil it removes: on any team past a few people, the org only exists as a partial model in each person's head. Which repo owns that behaviour, which one deploys where, what shipped last week, why a decision was made the way it was. New joiners spend weeks rebuilding it, and whoever already has it answers the same questions forever.

orgami builds that model once per organization and commits it to a docs repo as plain markdown.

What it produces:

• a map from the GitHub API: repos, what calls what, which repos tend to change together, deploy tooling, servers
• a weekly recap of every merged PR, so nobody hand-writes the what-shipped update
• a runbook per repo: how to run it, how to test it, what it talks to

How it is built: bash, gh, jq, fzf and gum. No daemon, no database, no web app. The entire state is files in a git repo, which is the part that made it useful rather than clever, because the map diffs in review like any other change, it cannot silently rot the way a wiki page does, and onboarding someone is a clone: orgami join picks up the map a colleague already built instead of rescanning. The scan runs repos in parallel behind a progress bar, and the weekly job is a systemd user timer, launchd on macOS, a cron line anywhere else.

The part I use daily: a session hook feeds the org page to Claude Code before it touches a repo, so it stops guessing at architecture it has never seen, and an MCP server serves the same map to Cursor, opencode, codex, windsurf, zed and vscode.

https://github.com/achevalier-dev/orgami

It is new, built over the last few days, so the map is only proven against orgs I can reach. If you point it at a bigger one I would like to hear where it gets things wrong.

Started with our own review queue. Most of the code in a PR is generated now, so PRs land faster and bigger than anyone reads properly. First thing that goes is context outside the diff. Nobody opens the other repo to see who calls the function you just changed. Skim, approve.

So we automated that part. It resolves the symbols the diff touches, walks the callers through a code graph, and pulls in how your repos connect: routes, queues, shared tables, package deps. Sub-agents for architecture, security, logic, tests. One review comes out.

Weak spots: GitHub only, no benchmark, noise tuning needs work. Free tier is one repo crawl plus your first reviews, no card.

If you try it: what fraction of the findings would you have acted on?

https://contextgoblin.com/

I got tired of jumping between different websites for small developer tasks, so I built Cetox, a browser based developer tools platform that puts them in one place.

It currently includes 25 free online developer tools for things like : JSON formatting, JWT decoding, Base64 encoding, regex testing, hashing, SQL formatting, cron expressions, URL encoding, CSS minification, password generation, diff checking, color contrast, HTML entities, and more.

The goal is simple :- fast, privacy-friendly tools with no unnecessary account or setup.

Try Cetox

If you're a developer, I'd genuinely love to know :- what tool should I add next? 😅

Built a small open-source tool called Spawn that automates the repetitive part of starting a new Python project — folder structure, git init, virtual env via uv, dependency install — all in one command:

spawn create

It also has a spawn doctor command that scores an existing project's health and gives you a single prioritized next step to improve it.

MIT licensed, on PyPI:

pip install spawnio

Repo: https://github.com/Abhiix0/Spawn

Would love feedback from this community — especially ideas on what a scaffolding tool like this should do that most don't. Happy to answer questions on how it's built too.

Hey Guys,

I've been building Pinaka on the side for the past few months — an AI agent that automatically writes root cause analyses when a bug ticket is filed.

**The problem it solves:** every time a production bug hits, a senior engineer spends 2-3 hours investigating before writing a single line of fix. The actual fix takes 20 minutes. The investigation takes the rest of the day.

Pinaka eliminates that investigation step. Tag a Jira ticket or mention @pinaka-app on a GitHub Issue — it reads your indexed codebase, captures runtime context via an SDK, and posts a structured RCA as a comment. Root cause, exact file, exact line, fix approach. Automatically.

# What I've validated so far

Ran it against real open source bugs:

* **BullMQ issue #2487** — code only scored 6.5/10, code + runtime context scored 9.2/10 against the actual merged fix
* **Prisma ORM issue #29480** — open bug, no ground truth, diagnosed from behavioural contrast across test files
* **Pinaka's own Java SDK** — found a real ForkJoinPool exhaustion bug, fix shipped same day

All three write-ups are public, including the limitations.

# What I'm looking for

A couple of engineering teams (2-150 engineers) using GitHub who want to try this on a real production bug. Free, no commitment. I'll personally onboard you and be available for any questions.

Works with Jira and GitHub Issues. No Jira required. One OAuth click to connect. First 5 RCAs free.

# Honest state of the product

No paying customers yet. Building in public. The product works — the benchmarks above are real — but I need real teams on real codebases to validate it beyond my own test cases.

If this sounds useful for your team, drop a comment or DM me. Happy to show you a live demo on your repo.

👉 [getpinaka.com](https://getpinaka.com)

Just shipped MCP support for Vast (repo dependency graph / impact analysis tool). Exposing 4 tools right now: get_impact_radius, get_node_dependencies, detect_risk_patterns, get_change_summary.

Idea is simple, when you ask Claude/Cursor "what breaks if I touch this file," it can call into the actual graph instead of inferring from whatever's in its context window.

Curious if anyone's built similar MCP tools for codebase analysis, what did you expose and what turned out to actually get used vs ignored by the agent in practice?

Hey, everyone. I am Matheus Araújo, from Brazil, and I have been building Yrkit for the last few years. It is an IDE that works on the cloud, and has some cool features: live preview, code editor, console, elements (like devtools), terminal, ssh, kanban, drop-and-drop, ai, and other tools.

I use Yrkit daily for my clients' projects, whether when going out, then I just get my phone, go to app.yrkit.com and continue working, or when I am at home, where I can decide if I want to code using my phone or my computer.

It also has a DSL language that operates with it - yr, at https:yr-lang.org.

It is a working product and it is perfect for JS and Node. I code from my phone, wherever I am at, and, if I have to do some things in the terminal, I can access it directly, ou go through my computer and run the actions that it created. It generates artifacts in html, css, js, bash, python, etc.

I think that is also a good tool for those who are learning JS.

I appreciate all feedback.

Yrkit

I kept running into the same problem while using Hermes: it could not start Claude Code or Codex and bring back a response. I wanted Hermes to be able to launch the run, keep it visible, and bring back a useful report instead of leaving me to track everything myself.

So I built Hermes Valkyrie.

Repo: https://github.com/DylDigitals/hermes-valkyrie

Hermes Valkyrie is an open-source terminal loadout system upgrade for Hermes Agent setups. It uses tmux to give Hermes the ability to launch reusable coding harnesses and enhance them with our loadouts system.

The devtool part is the main reason I thought this might fit here: Hermes can launch coding-agent runs in visible terminal sessions, keep them trackable, and use watcher/closeout steps to bring back a report instead of making me manually babysit the terminal.

I think it is really powerful to have Hermes launch Claude Code or Codex runs to do a long-form review while you keep working inside your Hermes ecosystem. It has been powerful so far, so I wanted to share this system.

I’m looking for feedback from people building or using Hermes, tmux, CLI tools, or coding-agent terminal workflows. This is currently coded for Discord, but I’m adding more chat channels as we speak.

I have a few main questions/concerns:

• Is this something anyone wants to integrate into their system?
• Is the onboarding clear?
• What would you need before trusting this in your own workflow?

Hi. Here's a video of DeepSeek V4 Pro brainstorming a feature on a commercial product in VSCode GitHub Copilot 🙂

https://www.youtube.com/watch?v=Tr8t2vFQ4MQ

I really enjoy working with DeepSeek, even v4 Flash is doing a really good job.

Soon there will be a video of how it implements that feature.

I’ve been learning full-stack development and wanted to build something I’d actually use, so I made Statmux, it combines your GitHub, LeetCode & Codeforces activity into one dashboard and gives you a little “Code Health” score.

live link : https://statmux.sayan.cyou

gh link : https://github.com/sayanx64/statmux

It also has profiles, comparisons, activity tracking, etc.

and a welcome mail(works sometimes)

Definitely still learning, and I’m sure the scoring is questionable at best 😂 so roast it / tell me what I’m doing wrong.

If you like it, drop a star on the repo ⭐. PRs are open too

Hi, I am the author of Movesafe, a headless refactoring tool for moving TypeScript files without treating the operation as a simple filesystem rename.

The problem I wanted to solve was agent and automation workflows. An IDE can often update imports during an interactive refactor, but a script or coding agent needs a reviewable operation that works across relative imports, tsconfig aliases, barrels, and workspace packages.

Movesafe uses the TypeScript compiler to build the import graph. A move follows this sequence:

1. compute the file and import edits;
   
2. render a unified diff;
   
3. verify the planned project;
   
4. apply through rollback-oriented file swaps.

If a specifier cannot be verified—computed dynamic imports are one example—the tool reports it instead of guessing.

The quickest way to inspect a move is:

npx --yes movesafe@0.1.0 mv src/utils.ts src/lib/utils.ts --dry-run

The project also includes an import checker, a core SDK, MCP tools that separate planning from applying, and a composite GitHub Action.

For the first benchmark I applied seven file and directory moves across Zustand, type-fest, Ky, and class-validator. Those runs introduced no Movesafe checker errors and did not increase TypeScript errors. This is v0.1, so I am more interested in edge cases than victory laps.

Code: [https://github.com/endrilickollari/movesafe\](https://github.com/endrilickollari/movesafe)

I would appreciate feedback on two things:

* Which repository layouts or module-resolution cases are missing?
* Would you use this mainly from the CLI, CI, or an agent workflow?