OpenPipe

OpenPipe AI

OpenPipe AI

OpenPipe AI

OpenPipe AI

OpenPipe AI

OpenPipe AI

OpenPipe AI

OpenPipe AI

OpenPipe AI

OpenPipe AI

I had Claude Opus 4.6 write an air guitar you can play in your browser — ~2,900 lines of vanilla JS, no framework, no build step

I learned guitar on and off during childhood and still consider myself a beginner. I also took computer vision classes in grad school and have been an OpenCV hobbyist. I finally found an excuse to combine the two — and Claude wrote the entire thing. Try it: https://air-instrument.pages.dev It's an air guitar that runs in your browser. No app, no hardware — just your webcam and your hand. It plays chords, shows a strum pattern, you play along, and it scores your timing. ~2,900 lines of vanilla JS, all client-side, no framework, no build step. Claude Opus 4.6 wrote the code end to end. What Claude built: Hand tracking with MediaPipe — raw tracking data is jittery enough to trigger false strums at 60fps. Claude implemented two layers of smoothing (5-frame moving average + exponential smoothing) to get it from twitchy to feeling like you're actually moving something physical across the strings. Karplus-Strong string synthesis — no audio files anywhere. Every guitar tone is generated mathematically: white noise through a tuned delay line that simulates a vibrating string. Three tone presets (Warm, Clean, Bright). Claude nailed this on the first pass — the algorithm is elegant and the result sounds surprisingly real. Velocity-sensitive strum cascading — hand speed maps to both loudness and string-to-string delay. Fast sweeps cascade tightly (~3ms between strings), slow sweeps spread out (~18ms). This was Claude's idea and it's what makes it feel like actual strumming rather than triggering a chord sample. Real-time scoring — judges timing (Perfect/Great/Good/Miss) with streak multipliers and a 65ms latency compensation offset to account for the smoothing pipeline. Serverless backend — Cloudflare Workers + KV caching for a Songsterr API proxy. Search any song, load its chords, play along. The hardest unsolved problem (where I'd love community input): On a real guitar, your hand hits the strings going down and lifts away coming back up. That lift is depth — a webcam can't see it. So every hand movement was triggering sound in both directions. Claude's current fix: the guitar body has two zones. Left side only registers downstrokes. Right side registers both. Beginners stay left, move right when ready. It works surprisingly well, but I'd love a better solution. If anyone has experience extracting usable depth from monocular hand tracking, I'm all ears. What surprised me about working with Claude: Most guitar apps teach what to play. Few teach how to strum — and it's the more tractable CV problem. I described that framing to Claude and it ran with it. The velocity-to-cascade mapping, the calibration UI, the strum pattern engine — I described what I wanted at a high level and Claude handled the implementation. The Karplus-Strong synthesis in particular was something I wouldn't have reached for on my own. Strum patterns were the one thing Claude couldn't help with. Chord progressions are everywhere online, but strum patterns almost never exist in structured form. Most live as hand-drawn arrows in YouTube tutorials. I ended up transcribing them manually, listening to each song, mapping the down-up pattern beat by beat. Still a work in progress. Building this has taught me more about guitar rhythm than years of picking one up occasionally ever did. submitted by /u/Ex1stentialDr3ad [link] [comments]

I benchmarked "Plan with Opus, Execute with Codex" — here's the actual cost data

There's been discussion about using Opus to plan and Codex to execute (example). Everyone agrees it "feels" more efficient, but nobody had numbers. So I ran a controlled benchmark. Setup: Claude Opus 4.6 + OpenAI Codex CLI, using the opus-codex skill. 3 real tasks at increasing scale, each in isolated git worktrees. Results: Task Pure Opus Opus+Codex 80 LOC (CLI flag + 3 tests) $0.33 $0.53 400 LOC (HTML report + 10 tests) $0.68 $0.74 1060 LOC (REST API + 46 tests) $0.86 $0.78 Crossover is ~600 LOC. Below that, the planning/handoff overhead costs more than just letting Opus write the code. Above that, Opus+Codex wins because it cuts output tokens by ~50%. The hidden cost driver: cache reads. Everyone optimizes output tokens, but every API turn re-sends your full conversation as cached context. Extra turns from planning + review add up. We found 600 lines of Codex stdout landing in the conversation was the single biggest cost inflator — piping it to a file saved ~$0.15/run. Practical advice: 800 LOC: Opus+Codex saves money and the gap grows with scale. Codex free trial makes it even more attractive for large tasks. Burning Opus tokens fast? Check cache reads in /cost. If they're 5-10x your output tokens, your context is bloated. submitted by /u/Least-Sink-7222 [link] [comments]

I built a security scanner that runs inside Claude Code — 5,000+ rules, one command

I got tired of switching between my editor and separate security tools, so I built Shieldbot — an open-source security scanner that runs directly inside Claude Code as a plugin. You install it with: /plugin marketplace add BalaSriharsha/shieldbot /plugin install shieldbot /shieldbot . It runs 6 scanners in parallel: Semgrep (5,000+ community rules — OWASP Top 10, CWE Top 25, injection, XSS, SSRF) Bandit (Python security) Ruff (Python quality/security) detect-secrets (API keys, tokens, passwords in source code) pip-audit (Python dependency CVEs) npm audit (Node.js CVEs) Findings get deduplicated across scanners (same bug reported by Semgrep and Bandit shows up once, not twice), then Claude synthesizes everything into a prioritized report — risk score, executive summary, specific code fixes, and which findings are likely false positives. The first thing I did was run it on itself. It caught a Jinja2 XSS vulnerability in the HTML reporter that I'd missed. One real finding, zero false positives on secrets. You can also just talk to it naturally — "scan this repo for security issues" or "check my dependencies for CVEs" — and the agent kicks in. It also works as a GitHub Action if you want it in CI: - uses: BalaSriharsha/shieldbot@main Findings show up in GitHub's Security tab via SARIF. Everything runs locally. No code leaves your machine. The MCP server just pipes scanner results to Claude Code over stdio. GitHub: https://github.com/BalaSriharsha/shieldbot MIT licensed. Would appreciate feedback — especially on what scanners or report features you'd want added. submitted by /u/ILoveCrispyNoodles [link] [comments]

I built a complete vision system for humanoid robots

I'm excited to an open-source vision system I've been building for humanoid robots. It runs entirely on NVIDIA Jetson Orin Nano with full ROS2 integration. The Problem Every day, millions of robots are deployed to help humans. But most of them are blind. Or dependent on cloud services that fail. Or so expensive only big companies can afford them. I wanted to change that. What OpenEyes Does The robot looks at a room and understands: - "There's a cup on the table, 40cm away" - "A person is standing to my left" - "They're waving at me - that's a greeting" - "The person is sitting down - they might need help" - Object Detection (YOLO11n) - Depth Estimation (MiDaS) - Face Detection (MediaPipe) - Gesture Recognition (MediaPipe Hands) - Pose Estimation (MediaPipe Pose) - Object Tracking - Person Following (show open palm to become owner) Performance - All models: 10-15 FPS - Minimal: 25-30 FPS - Optimized (INT8): 30-40 FPS Philosophy - Edge First - All processing on the robot - Privacy First - No data leaves the device - Real-time - 30 FPS target - Open - Built by community, for community Quick Start git clone https://github.com/mandarwagh9/openeyes.git cd openeyes pip install -r requirements.txt python src/main.py --debug python src/main.py --follow (Person following!) python src/main.py --ros2 (ROS2 integration) The Journey Started with a simple question: Why can't robots see like we do? Been iterating for months fixing issues like: - MediaPipe detection at high resolution - Person following using bbox height ratio - Gesture-based owner selection Would love feedback from the community! GitHub: github.com/mandarwagh9/openeyes submitted by /u/Straight_Stable_6095 [link] [comments]

Solo dev + Claude: From side project to press coverage in under 2 months - here's what I learned"

Hey everyone, I wanted to share my experience building NV-UV, a free companion app for undervolting NVIDIA RTX 50-series GPUs, almost entirely with Claude over the past ~2 months and 100+ sessions. I started in early February as a small side project for my own RTX 5090, and it kind of snowballed from there. What NV-UV does It's a WPF/C#/.NET 9.0 desktop app that makes GPU undervolting accessible - lower power draw, lower temps, same performance. It integrates with MSI Afterburner and includes features like automatic per-game UV profiles (587 games in the database), a built-in stress test scanner, crash detection that automatically adjusts your settings, and full DE/EN localization. It's currently in Open Alpha. Press coverage The project got picked up by several major tech outlets, which I honestly did not expect: VideoCardz (2 articles) https://videocardz.com/newz/nv-uv-brings-one-click-undervolting-to-geforce-rtx-50-gpus https://videocardz.com/newz/nv-uv-enters-open-alpha-for-geforce-rtx-50-series-rtx-5060-and-laptop-support-planned PCGH (Germany's biggest PC hardware magazine) https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/NV-UV-Undervolting-Tool-fuer-Geforce-RTX-5000-1521437/ https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/Specials/NV-UV-Untervolting-Tool-startet-Alpha-Test-1523449/ KitGuru https://www.kitguru.net/components/graphic-cards/joao-silva/new-nv-uv-utility-aims-to-simplify-undervolting-for-rtx-50-series-gpus/ Hardwareluxx https://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/68478-nv-uv-undervolting-der-geforce-rtx-50-karten-per-mausklick.html PCGH even gave NV-UV its own dedicated subforum for the Open Alpha How Claude was involved - it wasn't just code This is what I think makes this interesting for this community. Yes, Claude wrote and refactored most of the C# code with me. But it went way beyond that: Documentation - I had never used GitBook before. Claude walked me through the setup, told me "do this, then that", I asked 2-3 questions, and it just worked. I didn't even need to read the docs first - that came later naturally as I started working with it. It was literally like having a buddy who knows the tool and just tells you what to click. Same thing for the full user guide (DE + EN), tester guides, and a detailed handbook. Discord community - Claude helped me set up and grow a Discord community by summarizing the technical details of each build into announcements and changelogs that testers could actually understand. 86+ members now. Community posts - I write all my forum posts and support answers myself, but Claude helps me polish them, especially the English ones. My native language is German, so having Claude correct and refine my English texts while keeping my voice is a huge help. The posts are mine, Claude just makes sure my English doesn't suck. Architecture decisions - We discussed approaches together - sacrificial process architecture, encryption strategies, pipe protocols - Claude would lay out options, I'd pick the direction. Debugging - I'd paste logs, we'd discuss what went wrong, I'd come back with "that doesn't work, let's try it this way" - and often that's what cracked it. It was a real back and forth, not just Claude spitting out answers. I'm not a professional developer, but I do have some coding background from my job - enough to read code, understand logs, and know when something smells off. I review everything, I dig through logs myself, I make the calls. One thing I want to be clear about: every single feature in NV-UV - the UV-Pilot, Game Replay, the stress test scanner, the preset system, the OCS import - those are all 100% my ideas. Claude can't come up with stuff like that because it doesn't know what GPU users actually need. But it wasn't just "build me this". I'd define features in detail, Claude would come back with options, and then I'd think it through - "if we do it this way, this and that could go wrong", "we need to optimize this", "isn't there another approach?", "let's analyze this deeper before we commit". Sometimes we'd go back and forth for an entire session before landing on the right architecture. The vision and the decisions are mine, the implementation is teamwork. But let's be real: Claude is basically that one friend who happens to have a CS degree and somehow always has time to help. I work in Visual Studio as my editor, no AI agent or copilot, just the Claude chat window. It’s basically the manual version of what people call “vibe coding” , in reality it’s a mix of both. Sometimes he does a lot on his own, sometimes I go through it more carefully and review things. Sometimes with bug fixing he’s almost too fast, so I have to pull him back a bit. Every now and then he fixes something just to make it compile, and I only catch that later, but most of the time it works really well. Claude also handles a lot of the heavy lifting. He fixes compiler errors on its own, help

[P] Unix philosophy for ML pipelines: modular, swappable stages with typed contracts

We built an open-source prototype that applies Unix philosophy to retrieval pipelines. Each stage (PII redaction, chunking, dedup, embeddings, eval) is its own plugin with a typed contract, like pipes between Unix tools. The motivation: we swapped a chunker and retrieval got worse, but could not isolate whether it was the chunking or something breaking downstream. With each stage independently swappable, you change one option, re-run eval, and compare precision/recall directly. ```python Feature("docs__pii_redacted__chunked__deduped__embedded__evaluated", options={ "redaction_method": "presidio", "chunking_method": "sentence", "embedding_method": "tfidf", }) ``` Each `__` is a stage boundary. Swap any piece, the rest stays the same. Still a prototype, not production. Looking for feedback on whether the design assumptions hold up. Repo: [https://github.com/mloda-ai/rag_integration](https://github.com/mloda-ai/rag_integration) submitted by /u/coldoven [link] [comments]

I built a physical Tamagotchi that feeds on my Claude Code activity

Claudigotchi A tiny desktop creature running on an ESP32 with an LCD screen. A Claude Code plugin hooks into session events and sends state updates over serial — every tool call, prompt, and notification feeds the creature and lowers its hunger. Leave Claude idle and it starts getting restless, looking around, and eventually screaming at you with R2-D2-style buzzer sounds until you get back to work. How it works Claude Code hooks → shell script → named pipe → Python daemon → USB serial → ESP32 Hunger system goes from 0 (full) to 100 (starving), with five visual states and escalating sound effects The case is 3D-printed as a pixel-art character The whole thing is open source (firmware, plugin, and STL files): github.com/jsprpalm/claudigotchi submitted by /u/zwtswe [link] [comments]

CLI for Google AI Search (gai.google) — run AI-powered code/tech searches headlessly from your terminal

Google AI (gai.google) gives Gemini-powered answers for technical queries — think AI-enhanced search with code understanding. I built a CLI for it using headless Playwright since the site is fully browser-rendered. cli-web-gai search "how does Redis persistence work" cli-web-gai search "Python asyncio vs threading" --json cli-web-gai search "Rust ownership model explained" --format markdown Because the site renders in-browser (no public API), the CLI spins up a headless Chromium session, runs the query, and extracts the structured response. No auth needed — fully public. Output includes the AI answer, any code blocks, and source citations. --json gives structured output for piping into other tools or agents. Open source: https://github.com/ItamarZand88/CLI-Anything-WEB/tree/main/gai Full project (13 CLIs): https://github.com/ItamarZand88/CLI-Anything-WEB submitted by /u/zanditamar [link] [comments]

Hubcap Bridge: persistent two-way messaging between CLI and browser JavaScript via CDP

I've been building Claude Code skills that integrate deeply with web apps, and ran into a gap: many apps have no public API, and even when one exists you might not have access. But most have rich client-side JavaScript APIs powering their own UI. Today I shipped bridge as part of Hubcap (a Go CLI wrapping the Chrome DevTools Protocol, available as a Claude Code plugin). Bridge keeps a persistent two-way message channel open between a local process and JS running in the page: hubcap bridge --target "$TAB" ' for await (const msg of messages) { const result = await window.appAPI.query(msg.sql); send({rows: result}); } ' stdin/stdout carry LDJSON. Heartbeats detect disconnection. Multiple bridges can run in the same tab. This makes it possible to build Claude Code skills that include a local server kept in sync with a web page through its own internal APIs. The server uses bridge to push and pull data through the page's JS layer, and Claude talks to the server. No scraping HTML, no waiting for someone to build an MCP server. If you can call it from the browser console, you can pipe it through bridge. Because CDP-injected code runs in the page's own context, there's no CORS, CSP, or mixed content to fight. (Make sure you're staying within the terms of service of whatever you're integrating with.) Also in this release: eval now supports top-level await. Blog post: https://tomyandell.dev/blog/hubcap-bridge Hubcap plugin: https://github.com/tomyan/claude-skill-hubcap Docs: https://hubcap.tomyandell.dev Source: https://github.com/tomyan/hubcap submitted by /u/tomyandell [link] [comments]

Made an MCP that keeps Claude Code up to date on new tools, updates and best practices

Been using Claude Code heavily and kept running into the same problem — I'd ask about MCP servers or new tools and it would either hallucinate something outdated or start doing web searches that took forever and burned tokens. I was already spending way too much time on Twitter and newsletters trying to keep up with what's new, so I figured, why not just pipe all that into Claude Code directly? Built an MCP server that monitors ~1,000 sources (GitHub repos, RSS feeds, Reddit, HN, npm, etc.) and makes it all searchable through a single tool call. Now, when I ask "what MCP servers exist for databases?" it just knows, with star counts and quality signals, so it doesn't recommend some random 2-star repo. It's been useful for me, so I figured I'd share. Open source, free: www.inteloverdrive.com GitHub if you want to poke around: https://github.com/Looney-tic/intel-overdrive submitted by /u/No-Assignment-956 [link] [comments]

How to solve (almost) any problem with Claude Code

I've been using Claude Code to build a 668K line codebase. Along the way I developed a methodology for solving problems with it that I think transfers to anyone's workflow, regardless of what tools you're using. The short version: I kept building elaborate workarounds for things that needed five-line structural fixes. Once I started separating symptoms from actual problems, everything changed. Here's how I separate the two. What is the actual problem? This is where I used to lose. Not on the solution. On the diagnosis. You see a symptom, you start fixing the symptom, and three hours later you've built an elaborate workaround for something that needed a five-line structural fix. Real example. Alex Ellis (founder of OpenFaaS) posted about AI models failing at ASCII diagram alignment. The thread had 2.8K views and a pile of replies. Every single reply was a workaround: take screenshots of the output, use vim to manually fix it, pipe it through a python validator, switch to Excalidraw, use mermaid instead. https://preview.redd.it/jz9pivvbherg1.png?width=592&format=png&auto=webp&s=f17987c789fcdc9d386615a1c7e0785c5dd19f7b Nobody solved the problem. Everyone solved a different, easier problem. The workaround people were answering "how do I fix bad ASCII output?" The actual problem was: models can't verify visual alignment. They generate characters left to right, line by line. They have zero spatial awareness of what they just drew. No amount of prompting fixes that. It's structural. The diagnostic question I use: "Is this a problem with the output, or a problem with the process that created the output?" If it's the process, fixing the output is a treadmill. Research before you build I looked at every reply in that thread. Not to find the answer (there wasn't one). To categorize what existed: workaround, tool switch, or actual solution. The breakdown: Workarounds (screenshots, manual fixes): address symptoms, break on every new diagram Tool switches (mermaid, Excalidraw): solve a different problem entirely, lose the text-based constraint Closest real attempt (Aryaman's python checker): turning visual verification into code verification. Right instinct. Still post-hoc. When smart people are all working around a problem instead of solving it, that's your signal. The problem is real, it's unsolved, and the solution space is clear because you can see where everyone stopped. This applies to any codebase investigation. Before you start building a fix, research what's been tried. Read the issue threads. Read the closed PRs. Read the workarounds people are using. Categorize them. The gap between "workaround" and "solution" is where the real work lives. Build the structural fix The solution I built: don't let the model align visually at all. Generate diagrams on a character grid with exact coordinates, then verify programmatically before outputting. Three files: A protocol file (tells Claude Code how to use the tool) A grid engine (auto-layout and manual coordinate API, four box styles, nested containers, sequence diagrams, bidirectional arrows) A verifier (checks every corner connection, arrow shaft, box boundary after render) 31 test cases. Zero false positives on valid diagrams. The verifier catches what the model literally cannot see: corners with missing connections, arrow heads with no shaft, gaps in arrow runs. The model never has to "see" the alignment. The code proves it. That's the structural fix: take the thing the model is bad at (visual spatial reasoning) and replace it with something the model is good at (following a coordinate API and running verification code). Make the system verify itself This is the part that changes everything. Not "trust but verify." Not "review the output." Build verification into the process itself so bad output can't ship. The ASCII verifier runs automatically after every diagram render. If corners don't connect, it fails before the model ever shows you the result. The model sees the failure, regenerates on the grid, and tries again. You never see the broken version. Same pattern works everywhere: Post-edit typechecks that run after every file change (catch errors in the file you just touched, not 200 project-wide warnings) Quality gates before task completion (did the agent actually verify what it built?) Test suites that the agent runs against its own output before calling the task done That's the difference between CLAUDE.md getting longer and your process getting better. Rules degrade as context grows. Infrastructure doesn't. The full loop Every problem I solve with Claude Code follows this pattern: Identify the real problem (not the symptom, not the workaround target) Research what exists (categorize: workaround, tool switch, or actual solution) Build the structural fix (attack the process, not the output) Make the system verify itself (verification as infrastructure, not as a prompt) The ASCII alignment skill took one ses

I built Scalpel — it scans your codebase across 12 dimensions, then assembles a custom AI surgical team. Open source, MIT.

I built the entire Scalpel v2.0 in a single Claude Code session using agent teams with worktree isolation. Claude Code spawned parallel subagents — one built the 850-line bash scanner, another built the test suite with 36 assertions across 3 fixture projects, others built the 6 agent adapters simultaneously. The anti-regression system, the verification protocol, the scoring algorithm — all designed and implemented by Claude Code agents working in parallel git worktrees. Claude Code wasn't just used to write code — it architected the system, reviewed its own work, caught quality regressions, and ran the full test suite before shipping. The whole v2 (scanner + agent brain + 6 adapters + GitHub Action + config schema + tests + docs) was built and pushed in one session. Scalpel is also **built specifically for Claude Code** — it's a Claude Code agent that lives in `.claude/agents/` and activates when you say "Hi Scalpel." It also works with 6 other AI agents. The Problem: AI agents are powerful but context-blind. They don't know your architecture, your tech debt, your git history, or your conventions. So they guess. Guessing at scale = bugs at scale. What Scalpel does: Scans 12 dimensions — stack, architecture, git forensics, database, auth, infrastructure, tests, security, integrations, code quality, performance, documentation Produces a Codebase Vitals report with a health score out of 100 Assembles a custom surgical team where each AI agent owns specific files and gets scored on quality Runs in parallel with worktree isolation — no merge conflicts The standalone scanner runs in pure bash — zero AI, zero tokens, zero subscription: ### ./scanner.sh # Health score in 30 seconds ### ./scanner.sh --json # Pipe into CI I scanned some popular repos for fun: Cal.com (35K stars): 62/100 — 467 TODOs, 9 security issues shadcn/ui (82K stars): 65/100 — 1,216 'use client' directives Excalidraw (93K stars): 77/100 — 95 TODOs, 2 security issues create-t3-app (26K stars): 70/100 — zero test files (CRITICAL) Hono (22K stars): 76/100 — 9 security issues Works with Claude Code, Codex, Gemini, Cursor, Windsurf, Aider, and OpenCode. Auto-detects your agent on install. Also ships as a GitHub Action — block unhealthy PRs from merging: - uses: anupmaster/scalpel@v2 with: ### fail-below: 60 ### comment: true GitHub: Click Here to visit Scalpel Free to use. MIT licensed. No paid tiers. Clone and run. Feedback welcome. submitted by /u/anupkaranjkar08 [link] [comments]

How to build CLI tool + skill to work longer without compacting

I work with AI agents daily and try really hard to minimise context switching and enable agent to use all the tools I'd normally use during development, which goes really well nowadays as agents are good into finding those tools themselves. But as my work requires ClickUp, I got tired of alt-tabbing to it for every status update, comment, or task description I just wanted to feed that into context, so I prompted a CLI for it, along with a skill, so agent would pick it up automatically. The whole project was built with Claude Opus 4, set to High mode via OpenCode (😉) Not a single line written by hand. I want to share the build process, as I think the pattern is reusable for anyone who wants to vibe-code their own CLI tools, which I'd recommend as massive AI productivity boost The philosophy: CLI + SKILL.md My biggest takeaway from working with agents is that CLI tools paired with a skill file use way fewer tokens than MCP servers or browser-based workflows. The agent runs a shell command, gets structured output, pipes it if needed, then moves on - no protocol overhead, no server process, no massive context dumps, just straight data This matters because it means less compacting. I can work through longer sessions without the agent losing track of what it's doing. The skill file is small (a few hundred lines of markdown), the CLI output is compact (markdown when piped, JSON as alternative), and the agent doesn't need to hold much state. I think this pattern - build a CLI, write a SKILL.md, hand it to your agent - could work for pretty much any service that has an API but no good agent integration. Your company's internal tools, your CRM, your deployment pipeline. If you can write a REST client and a markdown file describing how to use it, an agent can learn it. The build process I use obra superpowers for my agent workflow. It's a set of skills that teach Claude how to plan, implement, review, and ship code in a structured way. I'd say it's a nice sweet spot between writing simple prompts and running full looping frameworks like Ralph. You get structured planning and parallel execution without the complexity of a whole orchestration system. After the initial setup (repo, npm, Homebrew, CI, tag-based releases, also done by agent), every new feature uses more or less the same prompt, relying heavy on superpowers skillset: ``` Use brainstorming skill to prepare for implementing , // 1 ask as many questions as needed Let's go with Approach // 2 Use writing-plan skill to prepare complete plan as .md file for Use subagent-driven-development and executing-plans skills to implement complete plan and confirm it with tests Do not make development yourself, act as orchestrator for subagents, by using dispatching-parallel-agents. If you have further questions, make decisions on your own and document them in DECISIONS.md Keep PROGRESS.md to track progress and carry on this to your next agents. Point subagents to those files and link to them in compacting summary. ``` I sometimes omit // 1 or // 1 + 2, depending whether I already cleared up with agent what to build What this does in practice: the agent brainstorms approaches, picks one, writes a detailed plan, then spawns sub-agents to implement each part of the plan in parallel. It tracks progress in markdown files so when context gets long, the summary links back to the plan and decisions. Each sub-agent writes tests, the orchestrator reviews. I mostly just approve or redirect. I hardly ever need to answer some questions after brainstorming, mostly when I just sloped request ("let's add comments functionality") The AGENTS.md in the repo instructs the agent to handle the release at the end of new features too - version bump, tag, push. So the whole cycle from "I want feature X" to "it's published on npm" requires almost no oversight from me. I trust the tests, and tests are honestly the only code I look at sometimes. But not really even that. One feature (time tracking - 6 commands, fully tested, documented) took about ~10-15 minutes of my time. Most of that was reviewing the plan and confirming the approach, agent did everything else. But frankly at this point I trust it enough to not review smaller features What the tool actually does cup is a ClickUp CLI. Three output modes: In your terminal: interactive tables with a task picker, colored output Piped (what agents see): clean Markdown, sized for context windows --json: structured data for scripts ```bash Morning standup cup summary Agent reads a task, does the work, updates it cup task PROJ-123 cup update PROJ-123 -s "in progress" ...does the work... cup comment PROJ-123 -m "Fixed in commit abc1234" cup update PROJ-123 -s "in review" ``` 40+ commands covering tasks, comments, sprints, checklists, time tracking, custom fields, tags, dependencies, attachments. Each feature is fully tested. The repo includes a ready-to-use skill file for Claude Code, OpenCode, Codex (these are some

Interclaude - Connecting 2 separate Claude Sessions (master-slave logic)

Github: https://github.com/anoop-titus/Interclaude You have Claude Code on your laptop. You also have a beefy remote server — maybe a VPS, a GPU box, or a dev machine in the cloud. Wouldn't it be great to send tasks to Claude on that remote machine and watch the response stream back in real-time, all from your local terminal? Interclaude makes that possible. It's a terminal bridge that connects two machines over SSH, lets you fire prompts to a remote Claude Code instance, and streams the response back to your screen as it's being generated. No web UI. No port forwarding. No Docker. Just SSH and a single binary. TUI pages: Setup, Access, Bridge Features: Streaming Responses — Watch Claude think in real-time. Responses appear line-by-line as they're generated on the remote machine, not after a 10-second wait Multi-Transport Messaging — Three transport backends: rsync (file-based, always works), MCP (Model Context Protocol), and Redis pub/sub. Rsync is the backbone; others are overlay accelerators Beautiful Terminal UI — Built with ratatui. Four-page guided flow, delivery pipeline visualization, transport health indicators, ping RTT display, and animated status updates Error Resolution Engine (ERE) — Automatic error analysis powered by the Anthropic API. When something breaks, Interclaude diagnoses the issue and suggests fixes through a 3-stage pipeline Encrypted Credentials — API keys are encrypted at rest using machine-specific key derivation (ring/HKDF). Never stored in plaintext Auto Session Cleanup — All message files are wiped from both local and remote machines on exit. Every session starts fresh with clean directories Connection Resilience — Supports both SSH and MOSH, autossh tunnels for persistent connections, automatic reconnection, and health monitoring Quick Start Prerequisites Dependency Required Purpose ssh Yes Remote connection rsync Yes File-based transport claude CLI Yes (remote) Runs prompts on the remote machine mosh No UDP-based resilient connection redis-server No Redis pub/sub transport autossh No Persistent SSH tunnels Install git clone https://github.com/anoop-titus/Interclaude.git cd Interclaude cargo build --release # Copy to your PATH cp target/release/interclaude ~/.local/bin/ Run # Launch the TUI (master mode) interclaude # The setup wizard will guide you through: # 1. Remote host / SSH configuration # 2. Transport selection # 3. API credentials (optional, for ERE) # 4. One-click activation: Test → Push → Bridge How It Works LOCAL MACHINE REMOTE MACHINE ┌─────────────────────┐ SSH pipe ┌─────────────────────┐ │ │ │ │ │ ┌───────────────┐ │ streaming │ ┌───────────────┐ │ │ │ Interclaude │──┼───────────────►│ │ claude -p │ │ │ │ TUI (master) │◄─┼───────────────┤ │ (remote CLI) │ │ │ └───────────────┘ │ line-by-line │ └───────────────┘ │ │ │ │ │ │ │ ┌────┴────┐ │ rsync / │ ┌──────────┐ │ │ │Transport│◄─────┼── Redis/MCP ──►│ │ Inbox / │ │ │ │ Layer │ │ │ │ Outbox │ │ │ └─────────┘ │ │ └──────────┘ │ └─────────────────────┘ └─────────────────────┘ You type a prompt in the Bridge page input bar Interclaude SSHs to the remote and runs claude -p ' ' Output streams back line-by-line through the SSH pipe into your inbox panel Pipeline status updates in real-time: SENT → READ → RUNNING → STREAMING → COMPLETE On exit, all message files are cleaned up on both machines Keyboard Shortcuts Bridge Page Key Action Enter Send task to remote Claude Tab Cycle focus: Outbox → Inbox → Input Up/Down Scroll focused message list 1 / 2 / 3 Switch transport: rsync / MCP / Redis F5 Toggle status panel Ctrl+L Launch slave on remote Ctrl+H Toggle help overlay Esc Back to Setup / dismiss overlay Ctrl+Q Quit (cleans up session) Global Key Action Ctrl+Q / Ctrl+C Quit application Ctrl+S Save configuration (Setup page) Mouse scroll Scroll message panels Architecture src/ ├── main.rs # Entry point, CLI args (--slave mode) ├── app.rs # Application state, page management ├── logging.rs # File-based debug logging ├── tui/ │ ├── welcome.rs # Dependency checking page │ ├── setup.rs # SSH/transport configuration │ ├── access_portal.rs # API credential management │ ├── bridge.rs # Main bridge interface │ ├── status_bar.rs # Global status bar with ERE indicator │ └── error_overlay.rs # Error analysis popup ├── bridge/ │ ├── engine.rs # Core bridge engine, event system │ ├── session.rs # SSH session + streaming exec │ ├── connection.rs # Connection testing, dir setup, cleanup │ ├── message.rs # Message protocol (Command, Response, Ping...) │ ├── handshake.rs # Role negotiation protocol │ ├── sync.rs # rsync push/pull operations │ └── watcher.rs # File system change detection ├── transport/ │ ├── rsync_transport.rs # File-based transport over SSH │ ├── mcp_transport.rs # Model Context Protocol transport │ ├── redis_transport.rs # Redis pub/sub transport │ ├── dedup.rs # Message deduplication ledger │ └── s

@charles_irl @DecagonAI Don't get us started!

@charles_irl @DecagonAI Don't get us started!