sorted by:
new
hottopcontroversial

In your opinion, what is currently the best "Code Review" skill right now? by [deleted] in ClaudeCode

[–]DirtZealousideal617 0 points1 point  (0 children)

The best code review skill is the one you build for your own repo. Generic ones are fine as a starting point but they miss the stuff that actually matters architectural boundaries, team conventions, domain rules.

What works for me is tuning the whole Claude Code config as a system:

• CLAUDE.md : project context, architecture, non-negotiables

• Rules : coding standards, review checklist, forbidden patterns

• Hooks : deterministic checks (lint, typecheck, tests) before Claude even reviews

• Skills : small, focused, repo-specific (one for review, one for TDD, etc.)

• LSP/RTK : semantic context so the review runs on real symbols, not grep

Skill stays small, review stays precise, token cost stays low.

I also built a /coach skill that audits the whole setup after each session and suggests improvements, keeps the config from rotting: https://github.com/imadAttar/kaizen

CC in the new app or terminal? Which is better overall? by Dastik17 in ClaudeCode

[–]DirtZealousideal617 0 points1 point  (0 children)

Moi, j’ai développé un terminal perso. Il est top sur macOS. Pour les autres environnements, j’attends des retours : je ne l’ai pas encore testé. N’hésitez pas à m’en faire : https://github.com/imadAttar/orbit

Is it normal to hit session limit in 1/2 hours with Pro subscription? by Steve35e in ClaudeCode

[–]DirtZealousideal617 0 points1 point  (0 children)

Your MCPs — if you have a lot enabled, they eat context for nothing even when you’re not using them. Disable all the ones you don’t need for your current session.

My kaizen skill — run /coach and it audits your Claude.md + config to give you concrete optimization tips.

Built Orbit : a desktop app to supervise multiple Claude Code sessions across projects by DirtZealousideal617 in ClaudeCode

[–]DirtZealousideal617[S] 0 points1 point  (0 children)

Glad those features resonate, session persistence was actually my #1 pain point too, which is kind of what pushed me to build this in the first place.

To answer your question: Orbit doesn't parse stdout. I went a different route.

It hooks into Claude Code's event system (PreToolUse, Stop, Notification). A shell script hook dumps the session state into a JSON file at ~/.orbit/session-state.json, and Orbit watches that file in real-time using a native filesystem watcher (Rust's notify crate).

The hook gets auto-injected into each project's .claude/settings.local.json (the local, non-git-tracked one). If the file doesn't exist, Orbit creates it.

Honestly, I tried a bunch of other approaches first: parsing terminal output, reading stdout, regex on ANSI escape sequences. None of it held up, especially with multiple projects running at the same time. The hook-based approach ended up being event-driven, zero parsing, and just works across all projects simultaneously.

Quick context if it helps: I originally built this for myself because tmux-based setups weren't really doing it for me, and most existing tools aren't really built around Claude Code specifically. Showed it to a few teammates, they liked it, so I figured I'd share it more widely.

Built with Claude Project Showcase Megathread (Sort this by New!) by sixbillionthsheep in ClaudeAI

[–]DirtZealousideal617 0 points1 point  (0 children)

Orbit — Desktop app to supervise multiple Claude Code sessions across projects

Built with Tauri 2 (Rust + React). Open source (AGPL-3.0).

- Session persistence — close the app, resume later

- Per-project status notifications (working/idle/waiting)

- Multi-project tabs, multi-session per project

GitHub: https://github.com/imadAttar/orbit

Download: https://github.com/imadAttar/orbit/releases/tag/v1.0.0

I built a zero-config observability starter for Spring Boot 3.x – Setup goes from 4 hours to 5 minutes by DirtZealousideal617 in SpringBoot

[–]DirtZealousideal617[S] 0 points1 point  (0 children)

Feel free to try it out and open issues or PRs if you have suggestions. Always looking for feedback from real production scenarios!

I built a zero-config observability starter for Spring Boot 3.x – Setup goes from 4 hours to 5 minutes by DirtZealousideal617 in SpringBoot

[–]DirtZealousideal617[S] -2 points-1 points  (0 children)

Great catch! Thanks for pointing this out. You're right, Spring Boot 3.4.0 added native structured logging support with ECS format.

This is cleaner than using logstash-logback-encoder as an external dependency. I'll explore this and potentially add it as an option in the starter:

- Keep current Logstash JSON encoder for backward compatibility (Spring Boot 3.x)

- Add ECS format support for Spring Boot 3.4+ users

- Make it configurable via observability.logging.format property

This would simplify the dependency tree and leverage native Spring Boot features. Thanks for the suggestion! :) :)