@MindfulReturn: yetone’s Magpie operations setup looks simple. The approach boils down to this: Claude Code + official Opus, with three /loop processes running in parallel—one monitors GitHub issues/PRs and Discord (PRs have to be pulled down and actually run before merging), another monitors feedback on X…

yetone’s Magpie operations setup looks plain and simple. Here’s the approach in a nutshell: Claude Code + official Opus, with three parallel /loop runs—one monitoring GitHub issues/PRs and Discord (PRs must be pulled down and actually run before merging), one monitoring feedback on X (with the cheap Jev model doing an initial filtering pass to save tokens), and one periodically cleaning up shitty code, documenting lessons, and blacklisting low-quality contributions. The human only spends time at night cleaning up UI/UX.

Reproduce issues on three actual environments (Mac + Windows + a Linux VM inside Windows, with the agent installed on only one and SSH used across machines); decisions rely on Claude Code’s memory + design docs in the repo; all external actions use browser use. When someone asked what advantage /loop has over scheduled tasks, he said outright, “No advantage—as long as it can monitor things.”

I’m also using Magpie for local routing for Claude. The more I look at it, the more I feel that for an OPC, clearly defining “what counts as done” first, then giving the agent an evolving notebook of past mistakes, works better than piling on another orchestration layer.

Comparison: similar philosophy, different methods. Both are “event-driven, filter first, minimize interruptions to humans, and continuously watch the repo”; yetone runs a handcrafted workshop of 3×/loop in Claude Code, while DeepSeek SuperAgent is a research prototype plugin for a productized ticket engine on DSH.

Side-by-side:

1. Continuous operations: neither is about writing code in a one-off session—yetone tends to Magpie all night; SuperAgent continuously monitors GitHub (optionally Feishu), and the panel only surfaces items “awaiting human action.”
2. Parallelism: yetone = 3 independent /loop runs; DeepSeek = 1 Router + multiple Worker Tickets (subscriptions can go directly to workers, bypassing the Router).
3. Cheap filtering: yetone uses Jev to filter X; DeepSeek uses a code-based Gate + model-based Eval (the long-form article calls these Fast/Slow, and the Router can use a lighter model).
4. Memory/past mistakes: yetone has LESSONS.md → code-standards; SuperAgent has a SQLite ticket ledger + versioned prompts, with no publicly available pipeline for updating a notebook of past mistakes.
5. Human-agent boundaries: both elevate humans to acceptance and decision-making roles; DeepSeek defaults to observe mode, with Mandate/allowlists enforced by the host, while yetone relies more on prompts and human habits.
6. Product roles: Magpie = gateway; SuperAgent = the agent plugin itself. Don’t confuse it with the other dsh-super-agent on Plugin Hub (which uses the preset protocol).

yetone (@yetone): A lot of people have asked me to share my workflow. I’ve never figured out how to share it, because I really don’t have any magic tricks—it’s actually quite rudimentary, and I always feel there’s no point in sharing it. All I do is use Claude Code, then run loops with the official Opus 5.5 model.

I run the 3 loops shown in the image in parallel, then spend a little time each evening shoveling shit (mainly UI/UX