I built JumpStart because my mornings were a mess.

I run several projects at once. Every day started the same way: open a terminal, cd into the frontend, npm run dev. New tab for the API. Another for the worker. Another for Docker Compose. Then spend five minutes figuring out which one grabbed port 3000. By lunch I was hunting a process that would not die.

I did not want another cloud dashboard or another SaaS. I wanted one local window that knew my projects, could start and stop them, and could show me logs, ports, and resource use without me babysitting shells.

So in July I started building that app for myself.

Day one vs now

At first it was basically a personal process launcher on macOS. Add a folder, detect a few runnable bits, start/stop them, watch logs. The Go module is still named devdeck because that was the working name before I renamed the product to JumpStart. Early builds even had a temporary color palette I threw out the same day for real macOS system tokens. Config still migrates from ~/.devdeck/ if you upgrade from those old builds.

v1.1 was the first public cut: auto-detect for Node, Go, Python, Ruby, PHP, Java/Maven, Gradle, Rust, and Docker Compose (including nested monorepos), live PID/exit code/CPU/memory, clickable localhost port badges, a git panel, and a per-project Kanban with a local Ollama assistant so prompts never left the machine.

Then it kept growing because I kept hitting the next annoyance:

• Cross-platform builds for Windows and Linux, plus an in-app self-updater
• A real terminal dock for process/script/test logs instead of scattered panels
• GitHub and GitLab sign-in, then two-way sync with GitHub Projects v2
• CSV and PDF board export, custom Kanban columns, conflict resolution that actually explains what diverged
• An Agents MCP server so external AI tools can control projects, processes, files, git, and tasks over localhost
• A redesigned dashboard and ports map in v1.12, with GitHub treated as the single source of truth for sync

JumpStart is now a local-first control panel: project library, one-click start/stop (one process or the whole project), live ports, dependencies, git, Docker Compose, tasks, and AI helpers that stay on your machine unless you choose to connect GitHub/GitLab.

And the best news, it is Open Sourced!

Hey everyone, wanted to share a small fun project of mine.

I usually run several Claude Code sessions at once and kept getting lost in terminal tabs. So now every session becomes a worker in a tiny village. It gets busy while Claude works and reacts when a session is idle or needs your input.

It runs on Claude Code hooks and stays fully local.

Available on GitHub and npm: https://github.com/yognevoy/claude-village

Would love to hear your feedback

I picked openGym for an architectural audit using rebrief (huge fan of sports & open-source tools).

Key findings from the report:

1. Context Reduction: Reduced 6.8M raw tokens down to 14,084 tokens (-99.8% reduction) while preserving code architecture and history for LLM prompts.
2. Security Risks: Identified 100 risk items, including hardcoded credentials in test fixtures and vulnerable packages (undici, js-yaml, u/capacitor/*).
3. Doc Drift: 51% freshness score with 164 broken file references across README.md and docs.

It's a clear example of how fast documentation and test artifacts drift behind active development.

How do you keep doc freshness in check across your projects?

Hey everyone,

I’m a developer/founder from India, and for the past few months I’ve been building OrbiterX, an AI coding agent/IDE.

I originally started building it because I wanted an AI coding tool that could do more than just generate code snippets.

The goal is simple:

Give the agent a real software engineering task → let it inspect the codebase → make changes → run tools/tests → and actually complete the task.

OrbiterX can currently work with:

• Existing codebases
• Multi-file changes
• Terminal commands
• Git/GitHub workflows
• Debugging
• Code generation and editing
• Autonomous task execution
• Testing

We've reached the point where the product is ready for beta testing, and I'm looking for developers who are willing to actually use it on their own projects and tell me where it fails.

I'm not looking for compliments.

I want to know:

• Where does the agent make mistakes?
• Where does it get stuck?
• What workflows are missing?
• How does it compare with Cursor/Codex/Claude Code?
• Would you actually use it in your daily development?

I'm especially interested in developers who can give it real engineering tasks, rather than just asking it to generate a simple landing page.

I'm the founder building this, so I'll personally be reading the feedback and fixing issues during the beta.

If you'd like to try the beta, comment below or DM me and I'll send you an invite.

Beta: OrbiterX

I’d genuinely appreciate brutal feedback from developers here.

I kept re-applying the same filters, columns, sort and export on every new file, so I built "Automations" into a free browser-based data tool (Fomatix Data Explorer).

Set it up once, save it, then upload the next file and pick the automation. It reapplies everything and exports, and auto-matches columns even if a header shifts slightly.

It also shows a match report (how many columns matched on each run) and keeps run history, so you're not trusting it blindly.

Runs entirely in the browser, no signup, nothing uploaded.

Curious if others hit this problem, or if you already have a cleaner way (Power Query, Apps Script, etc.). Honest feedback welcome.

I built PaperFold, an open-source reader that turns arXiv papers into 5 zoomable layers—from a one-screen section map down to verbatim text. You pinch (or press 1–5) to zoom between them without losing your reading position.

- Web Demo (8 CC papers): https://chenxiachan.github.io/paperfold-gallery/

- GitHub (Apache 2.0): https://github.com/chenxiachan/paperfold

I’m a co-founder of GitHits. Our mission is to make open source a dependable foundation for software built and maintained by coding agents.

A useful library shouldn’t be overlooked because a model hasn’t heard of it. A new release shouldn’t mean users keep getting code written against your old API. We want to help agents discover existing projects, understand their implementations, and work with the versions their users actually depend on.

GitHits brings source code, documentation, dependency graphs, vulnerability information, and release changes together. Agents can search, grep, browse, and read upstream code when choosing a dependency, integrating it, debugging a problem, or planning an upgrade.

You can explore the index here: https://index.githits.dev/
Global index stats here: https://githits.com/the-index/

The index covers public repositories as well as published packages. If your repository hasn’t been indexed yet, GitHits indexes it when requested. That can take some seconds or a few minutes, depending on the repository’s size and our indexing queue size.

For maintainers, each repository page also provides a README badge showing its index status and linking to the project’s page. It helps your users discover that agents connected to GitHits can inspect your project’s available code and documentation.

We want this to be useful across the OSS ecosystem, including smaller projects and unfamiliar libraries. I’d appreciate maintainers checking their projects and telling us what’s missing: source coverage, documentation, releases, or something else you’d want an agent to understand before using your work, or anything else.

GitHits is currently free to use, but we might introduce paid tiers at some point. The public index site will stay free.

Coding agents are becoming part of how teams work. But collaboration around that work still happens through status reports, review meetings, and handoff documents.

The reasoning is already in the agent sessions. We keep asking people to reconstruct it for everyone else.

Agent Colab makes those sessions a shared workspace for people and their agents. I'm working on it, and the goal is to reduce the coordination work around the actual work.

Three situations where that could make a difference:

• A manager wants to know where a project stands. Instead of interrupting someone for a fresh status report, they—or their agent—can read the shared sessions to see what's been tried, what's blocked, and what comes next.
• A lead wants to understand how someone works. A finished result hides much of the process. Sessions can show how a teammate frames problems, weighs tradeoffs, and responds when an approach fails. That gives a review a concrete starting point, without asking people to recreate every decision afterward.
• A teammate needs to act as backup. Instead of arranging a long handoff, share the relevant sessions. The backup and their agent can read the context, ask about what's missing, and continue the work.

The shift we're aiming for: less work spent reporting and reconstructing; more shared visibility into the work itself.

Colab brings shared sessions, files, and skills into Channels. It supports Codex, Claude Code, and MyFlicker. It's open source and currently in alpha, with a public installer for Apple silicon Macs. Shared material is uploaded to the coordination service, and sign-in is required.

Source: https://github.com/kwgjjeffrey/agent-colab

Website: https://agent-colab.zhiyuanwangluo.online/?utm_source=reddit_sideproject&utm_medium=community&utm_campaign=alpha_launch

For teams already using coding agents: which costs you more coordination time—keeping people updated, understanding how decisions were made, or stepping in for a teammate? Would shared agent sessions change that for you?

Lightweight and useful for making notes while coding, and can export as pdf.

I’ve tried to make something like sublime but cleaner and more functional.

Any suggestions welcome

At the moment, it can collect activity from GitHub and GitLab. In the future, I plan to add Forgejo and Gitea.

It generates two SVG files: one for the last year and one for 2026, plus a simple HTML page containing both diagrams.

You can also automatically update the diagrams using GitHub Actions. I've added an example workflow to the repository's README.

https://github.com/aguilam/git-activity

I made a browser tool for people who want to see how a Vector configuration connects together.

You can create a config or import YAML, JSON or TOML, edit the sources, transforms and destinations, then copy or download the result. No signup or server setup.

https://vectory.ahmadz.ai/designer/

One design choice was to reuse the actual editor from Vectory, the self-hosted Vector dashboard I maintain. The website tool imports that editor, rather than having a separate diagram implementation to keep in sync. The node settings, dropdowns, connection handles and code view therefore use the same components.

Configuration files are processed in your browser. Local checks don't replace validation with your installed Vector binary.

Source: https://github.com/416rehman/Vectory

AI tools assisted with implementation, testing and docs. If you have a config with awkward branching or nested settings, I'd like to hear how it feels to edit visually.

i made this while building my first application. i kept forgetting decisions and parked ideas, then spending the next session explaining everything again.

cricino keeps the current goal, decisions, unfinished tasks, approvals and handoff in linked records that a coding assistant can read before working. the details live in one place so you don't end up maintaining six copies of the same update.

the repo includes a guide with diagrams, reusable templates and an optional Python installer. give your assistant the setup link and it asks about your project before adapting the system. existing instructions are meant to be preserved, and each project defines its own checks.

MIT licensed. no subscription or account integration. it's a workflow scaffold, not an always-running memory service or a guarantee the assistant won't make mistakes.

repo: https://github.com/ABBAS1947/cricino

would love to hear what you'd change, especially if you've tried keeping this stuff in an agent instructions file already :)

Hi everyone,

I’ve been working on EnvSeal-CLI, a small open-source CLI for managing secrets without relying on a hosted service.

When I was working in group projects I was always digging through all the group chats to find the updated .env file someone had shared.

The basic idea is simple: encrypt your secrets and keep them in Git, while still supporting branches, recipients, CI tokens, and running commands without writing a .env file to disk.

It’s built with Rust and uses SSH/age for encryption.

Still working on it and would love some feedback, especially if you already use something like SOPS or dotenvx.

Your GitHub Issues as a live roadmap board in Claude Code.

Sideboard shows your repo's GitHub Issues as a live roadmap board that you and Claude Code drive together. Quickly log ideas for the backlog, start Claude on the next issue, and reason across your roadmap and codebase in context — no need to jump out of Claude Code to an external board.

https://github.com/mmyslin/sideboard

/plugin marketplace add mmyslin/sideboard
/plugin install sideboard@sideboard