yetone magpie agent workflow

yetone magpie agent workflow

One-liner

magpie (yetone/magpie, Go, MIT) is a menu-bar app plus a local gateway (127.0.0.1:3425) that picks the model for 45+ coding agents, so you can run Codex on DeepSeek or Claude Code on Kimi. The main thing about how it gets built: the repo says outright that “magpie’s code is written, reviewed, merged and released by agents” (LESSONS.md). That works because of a written loop: a nightly review of the day’s commits adds rules to LESSONS.md, and a rule found on 3 separate days moves into docs/code-standards.md. On top of that sit strict acceptance criteria (“say what was run, at which head; a check not run is listed as not run”). The agent config is plain markdown. There are no .claude/, .cursor/ or skills folders and no AI review bots in CI.

Repo check (step 1): search_repositories user:yetone magpie returned exactly two repos: yetone/magpie (the product, the one this digest is about) and yetone/magpie-releases, which holds the signed builds. A v* tag in magpie triggers a repository_dispatch there. The match is exact, so no guessing was needed.

Pinned 2026-10-08 ~21:50 (UTC+8). Main was at ddb6f806 (committed 21:21), last push 21:29, tag v0.1.1120.

Related: 2026-09-28 CC Switch (the closest competitor, which magpie imports from) · 2026-09-28 LLM project failure modes and slop patterns · 2026-09-28 DeepSeek harness dsh system prompt (dsh is one of the agents magpie wires).

---

1. The repo

What	Desktop app (tray, panel, magpie web, TUI, CLI, Docker) that rewrites each agent’s own config file to point at one local gateway. The gateway translates between OpenAI Chat, OpenAI Responses, Anthropic Messages and Gemini, and routes over keys and subscriptions (smart / order / rotate / usage / pace). It also has a Library that writes instructions, MCP servers and skills into every agent in that agent’s own format (library.md), plus plugins (OpenCode auth plugins and pi packages on Bun).
Stack	Go 1.26 (go.mod): Wails v3 webview GUI, bubbletea TUI, modernc sqlite. Vanilla-JS GUI in internal/gui/assets with Playwright tests (*.test.cjs). Bun plugin host. Static site in site/.
Size	4,011 tree entries. internal/ holds 3,041 of them.
Activity	Repo created 2026-09-24 00:22 (UTC+8), but local history starts 2026-09-22 21:47 (first commit: “dial: one dial for every coding agent’s model”). 2,296 commits in about 16 days. By day: 88 → 128 → … → 206 (10-01) → 221 (10-05) → 196 → 94 → 150 (10-08 so far). 1,121 tags, with a peak of 170 tags on 10-05.
Popularity	6,617★ and 466 forks at pin time. 306 open issues+PRs. 562 PRs all-time (GitHub search).
People	1,917 of 2,296 commits are authored by yetone. The next authors are far behind: TryWorld 36, forever/waitingsnow 28, Snowyy 20. 0 merge commits. 370 commits are committed by GitHub web-flow, i.e. squash-merged PRs.
Cadence	yetone-authored commits by hour (UTC+8): no hour of the day has zero. The minimum is 23 commits at 08:00, the maximum 139 at 17:00, and there are 104 each at 00:00 and 01:00. That fits agents running around the clock.

---

2. In-repo agent setup

What exists (and what doesn’t)

From a recursive get_git_tree on main:

• ✅ AGENTS.md (5 KB): a router, not a manual.
• ✅ CLAUDE.md (23 bytes). The whole file is:

  @AGENTS.md
  @LESSONS.md

• ✅ LESSONS.md (15.7 KB): output of the nightly review. Header: <!-- reviewed-through: 8b14afea (2026-10-07 22:09 +0800) -->.
• ✅ docs/code-standards.md: rules, acceptance criteria, review patterns, commit format.
• ✅ docs/subsystems/: 8 design references (gateway routing, agent wiring, providers/accounts, library, GUI shell, plugins, middleware, Claude bridge), each with a Verification command block.
• ✅ docs/contributors.md: harm-first PR triage and a block list.
• ❌ No .cursor/, .claude/ (commands/agents/settings/skills), .agents/, .codex/, .github/copilot-instructions.md, GEMINI.md, skills/, prompts/, .windsurf, .opencode, or .mcp.json. git log --diff-filter=D shows none of these were ever added and then deleted.
• ❌ No PR or issue templates under .github/. No husky, lefthook or pre-commit config. No justfile and no root package.json.
• Skills live outside the repo. magpie ships an official skill, magpie-quota, in magpie-community/plugins. It teaches agents to call magpie quota --json and magpie quota wait.

AGENTS.md: a thin router with four “before you…” pointers

Subsystem design and review. Before changing a documented subsystem, read its design reference and verify the linked source… Code standards. Write and review changes against the code standards. Community PRs. Before reviewing a community PR, read contributors: what stops a review for possible harm, what is closed unreviewed, and the authors whose PRs are closed on sight. Lessons. Before changing code, read LESSONS.md: what recent merged work got wrong and the rule that would have caught it.

The only domain content left inline is a “which code actually runs” map. Built-in subscriptions are moving to community OpenCode plugins, and a fix made only in the built-in “does nothing for moved users.” The map gives a 4-step fix order: fix the plugin → publish → raise the mover’s min → change the built-in only if needed. It also names TestMovedBuiltinsSayTheirPlugin, a test that fails when a mover’s code lacks a PLUGIN-SERVED notice. In other words, the agent instruction is enforced by a test.

It also mentions a local checkout path (~/workspace/projects/magpie-commuity-plugins). That suggests the agents run on yetone’s own machine with sibling repos checked out.

LESSONS.md: the nightly review ledger

magpie’s code is written, reviewed, merged and released by agents. Each night the day’s commits are reviewed for what had to be fixed again, what shouldn’t have merged and what was verified too thinly… Each lesson is a rule, then why, then the evidence. “Seen” counts the days a review found it. A lesson seen on 3 or more separate days moves into docs/code-standards.md.

How it’s organized: each lesson is a bold rule, then bullets of evidence that cite commit SHAs and issue numbers, then “Done right on 10-07: …” with positive examples, then Seen N× (dates). Sections:

• Reading the report: reproduce the reporter’s exact case on their surface; build fixtures from the reporter’s literal bytes; when a vendor refuses magpie but serves its own client, diff every header against the official client before adding retries.
• Fix the class, not the sample: scope vendor rules to that vendor; a restriction covers every route to the guarded thing.
• User’s files: never let a default override a user value; a failed read/parse/hash means “unknown”, never “empty” or “equal”; find every record matching a credential before deleting it.
• Verification: “Not tried with the real thing” means don’t build more on it, and don’t tell users it works; a platform report is checked on that platform (“ssh to the box. A GOOS build is not a test”); GUI changes run in Chromium and WebKit, at narrow widths, in every language.
• Concurrency/tests: no blocking send while holding a lock the receiver needs; fake child processes end with the test.
• Red tests and releases: find a flake’s cause; don’t tag until a CI Test run on that commit has finished green; a cancelled run is not a pass; batch fixes (“294 tags in 51 hours left no run to finish”).
• Merging and closing: never merge with the PR’s own new test failing; keep the issue open until the reporter’s case works; one commit, one goal.
• Moved to the code standards (on 10-07): fix every sibling; re-derive everything built on a change; red-on-main is a bug now; merge only the reviewed head and record what was run.

History of LESSONS.md: 4 commits so far (10-06 03:10, 10-06 03:49, 10-07 00:23, 10-07 23:46, all UTC+8). Each one is titled like “docs: LESSONS.md gets the review of 10-07’s commits — … seen a third day move into the code standards”. The founding commit 303819c carries Co-Authored-By: Claude Opus 5.5. The first review covered 10-05: 220 commits and ~170 releases, about 40 of which fixed something released that day or the day before.

There is a measurable effect. The “batch fixes, don’t tag every commit” lesson landed 10-06. Tags per day went 170 (10-05) → 41 (10-06) → 14 (10-07) → 16 (10-08). The Test workflow now says in a comment that it doesn’t cancel runs on main “(LESSONS.md)“.

code-standards.md: acceptance criteria an agent must show

A change is merged or released only when it shows each of the following. Say which ones were run and what they printed. A check that wasn’t run is listed as not run, never left out.

1. A test that fails without the change. Put the old code back; it must fail with a real FAIL naming the behavior (“a compile error or a skipped test doesn’t count”).
2. Tests in a sandbox: a temp HOME with GOPATH/GOMODCACHE/GOCACHE pinned from go env first. Never touch ~/.codex, ~/.claude, ~/.config/magpie.
3. Build and suite: go vet, go build, GOOS=linux … -tags nogui, GOOS=windows, go test -tags nogui ./..., with set -o pipefail.
4. GUI tests in both engines, run locally because CI doesn’t run this suite: zh, en, zh-tw, ja, de.
5. Real use where possible: a real account or key in a sandbox HOME with copies of credentials. “If a real check isn’t possible, say so.”
6. UI rules: t() strings, no native <select>, no scroll-on-click, no colored left-border stripes.

Merge rule: a maintainer pulls the PR, merges it onto current main, runs the checks, then runs gh pr merge --match-head-commit <reviewed sha>. “A push made during the review then stops the merge, rather than shipping code nobody ran.” What was run gets written on the PR before the merge.

Review patterns: Run it, Break it on purpose (revert the fix or break the guarded code several ways, and check the tests catch each break), Check the vendor, not the PR’s account of it, check each platform and arch, follow the whole path, classify narrowly, a preview writes nothing, don’t reverse deliberate decisions (those belong to the maintainer).

Commit format:

gateway: a 429 that says the balance is spent is out of credit, not a rate limit. Give the issue number or the reporter. The body says how it was verified, and which test fails without the change.

subsystems/README.md: one fact, one place

Keep each fact in one reference and link to it from agent instructions… Link to source files and named symbols rather than copying implementation details… Document current behavior separately from proposed changes.

A PR describes semantic changes per subsystem (trigger and before/after behavior). The reviewer then “checks that the cited tests or runtime evidence exercise the claimed behavior. Report checks that were not run.”

contributors.md: harm-first intake, and the agent only proposes

magpie merges community PRs through agents.

• Look for harm first. Stop the review if the PR touches .github/, release scripts, the Dockerfile or site/; adds a network address, telemetry or credential flow; adds a dependency, a go.mod replace, an npm install script, or a binary/minified/encoded blob; or adds a relay/affiliate address. “Don’t run the PR’s code on a machine with real accounts until the maintainer has cleared it.”
• Close unreviewed: PRs that reverse the maintainer’s rulings (for example the Codex prompt files, “kept byte for byte”), resubmissions, and near-identical bursts.
• Blocking: “An agent only proposes. It writes the evidence… the maintainer decides.” One author (lunar-me) is listed under “reviewed with extra care”. Evidence: 3 PRs opened within 12 seconds. Extra care includes “Never merge it in the same tick it was opened”. The word “tick” hints at a scheduled agent loop.

---

3. Dev flow: tooling, CI, AI review, commits, PRs

Tooling

• Makefile targets: build, cli (nogui), test (= go vet && go test), test-ui (node --test over internal/gui/tests/*.test.cjs, concurrency 2), dev (fswatch live reload on its own ports 3426–3429, “so a running magpie keeps serving the agents”), release-*. It refuses to run outside magpie’s own folder (it checks go.mod), and it sanitizes VERSION against $/backticks.
• build/race-shards.sh splits the gateway -race suite across cores (#923).
• Commit bodies show agents running tests in Docker golang:1.26.8 with a temp HOME on the Mac, because “new test binaries hung in dyld while syspolicyd was at 100%”. They also run on a real Windows box and its WSL2 distro.

CI (.github/workflows/)

Workflow	What	AI?
test.yml	Matrix of ubuntu, macOS and Windows. Gofmt gate, added after “unformatted files reached main 8 times from 10-01 to 10-06”. Vet, test, a production plugin flow on Bun, a sharded -race run, targeted native Windows tests. CLI builds for linux/android plus site/installer tests. Main runs aren’t cancelled (so releases can wait for a green run).	No
ui-preview.yml + .github/ui-preview/	On a PR that touches the GUI, it builds the PR’s magpie, seeds a fake home (providers, 30 days of requests, 200+ sessions, two ChatGPT accounts, skills), and gives DeepSeek (deepseek-flash) the diff and page outlines to plan click/hover/type scenes. Playwright then records screenshots and an mp4 with a drawn cursor, and the result is published to GitHub Pages and into a fixed block in the PR body. Security split: pull_request_target; the record job runs the fork’s code with a read-only token and a low-limit key; the publish job, which can write, never runs PR code. If the key ever appears on screen, all output is thrown away.	Yes. The only LLM in CI.
release.yml	A v* tag sends a repository_dispatch to magpie-releases, which signs, notarises and publishes (16 assets).	No
docker.yml	Multi-arch GHCR image with a smoke test (curl /v1/models, a 4xx on an unknown model, provider add).	No

No claude-code-action, Codex, Cursor Bugbot, CodeRabbit or Copilot review workflow. Reviews arrive as comments from the yetone account (see below).

Commits (counts)

Two samples: the last 100 commits on main from list_commits (10-08 12:42–21:20 UTC+8, about 8.6 hours), and the full history of 2,296 commits from a partial clone.

Signal	Last 100	Full history (2,296)
Any AI co-author trailer (noreply@anthropic, amp@ampcode, codex@openai, multica, Instinct)	0 / 100	48 / 2,296 (about 2%)
…of which on yetone-authored commits	0	11 of 1,917 (all Claude/Claude Opus 5.5)
Trailer mix (lines)	—	Claude Opus 5.5 38, Claude Code 12, Claude Sonnet 5.5 5, Amp 13 (+Amp-Thread-ID), Codex 9. Mostly on contributor commits.
area: behavior subject (gateway: …, gui tests: …)	97 / 100	yetone top areas in the last 500: gui 67, gateway 60, provider 51, gui tests 36, agent 34
Conventional-commit prefix (feat:/fix(…))	—	172 total, only 44 by yetone. That style comes from contributors.
Body mentions verification (rough regex: verified/go test/pass/fails without/not tried)	86 / 100	—
Subject quotes the instruction (user: …) / “per the owner”	—	113 yetone commits
Credits a reporter “on Discord” / “on X”	—	338 / 49
Cites an issue #NNN in the subject	—	793
Median subject length (yetone, last 500)	—	242 chars
Median body length (yetone, last 100)	—	16 lines

Trailers undercount agent work here

The repo says agents write, review, merge and release. Yet only 11 of yetone’s 1,917 commits carry an AI trailer, and none of the last 100 do. Better provenance signals: commit subjects that quote the human’s instruction, e.g. (user: 对内置的订阅 provider 在代码层面和文档层面加上注释，防止又有别的 agent 在改…) in fa9daa6. Also 240-character behavior-sentence subjects, bodies with mutation and revert evidence, and commits at every hour of the day. Which harness writes them can’t be determined from git alone. yetone answered “claude code” when asked what he develops his apps with (see §4).

Sample body (ddb6f806): measured RSS before/after in Docker on a copy of a real config, then “TestWarmUpReturnsItsGarbage fails without the FreeOSMemory call (10 of 10…) and passes 10 of 10 with it… Not measured on macOS: a fresh build there hangs at exec behind syspolicyd today.” So “not run” is actually written down.

PRs (counts)

Sample: the 100 most recent PRs, state=all (#1127–#1318, created 10-07 16:18 → 10-08 21:31 UTC+8).

• Outcome: 31 merged, 36 closed unmerged, 33 open; 16 drafts.

• Openers: 0 by yetone (he has opened 1 PR ever, #289, out of 562). He works straight on main. 44 of 100 came from waitingsnow (“forever”): 13 merged, 25 closed, 6 open. Their titles copy yetone’s behavior-sentence style. Seven DST-fix PRs (#1202–#1208) were opened about 6 seconds apart, which looks machine-driven, but that is unconfirmed.

• Bodies: 55/100 have structured headings (Summary / Semantic changes / Reviewer Test Plan / What was run). There is no PR template file; the shape comes from docs/subsystems/README.md and code-standards. 26/100 carry the auto UI-preview block. Example: #1311 (Qwen Code adapter) has a Trigger | Before | After table and a revert check.

• Review comments come from the yetone account and read like the code-standards playbook. #1311:

  Reviewed at head 34849c4…, merged locally onto origin/main 04704111… Harm check: … No .github, release, Dockerfile or site/ change… Checked against the real Qwen Code (npm 0.25.0, read and run in a container; no live ~/.qwen touched)… Mutations in qwen.go, each caught: … Not run: Playwright…; WSL and Windows on a real box; a real vendor behind the gateway.

  Then: “Released in v0.1.1120. Thanks!” #1045 ran 10 -shuffle seeds on main vs head (main failed 9 of 10, head passed all 10) and checked the merge with a sibling PR.

• Merge style: squash. No merge commits in history; 370 commits committed by web-flow.

---

4. What yetone says publicly

X was searched with from:yetone queries (magpie; claude/codex/agent/skill/AGENTS; harness/review terms) plus Exa. The first X call hit a shared-access 429, and retries worked. No blog post, talk or interview about the magpie agent loop turned up, and HN Algolia has 0 stories for “yetone magpie”. His X activity is mostly Chinese-language support replies. The useful bits:

• Tool of choice: asked “are your apps all developed on Alma?”, he answered “claude code” (2026-10-03 16:35).
• Harness opinions: “现在还有 todo list 的 harness 基本上都是上一代产品” (“harnesses that still have a todo list are basically last-generation products”, 09-30 05:59). He also noted Claude Code retired TodoWrite in January (09-30 13:25). And: “you can tell what year someone started building harnesses from how they implement the Edit tool” (09-13 01:40). He says he’s now building “real-world harness evaluation” (10-08 03:01).
• Lineage: he put lessons from building avante.nvim (agentic Neovim, “a year before Claude Code”) into Alma, his desktop agent app (09-13 01:23). Alma also tops the FrontierHarness benchmark in his own run (09-03).
• Skills as product surface: a user asked how their agent could read quotas, and he pointed to magpie quota --json / GET /v1/magpie/quotas: “write either into the agent’s prompt or a skill” (10-07 23:18). A day later the official skill magpie-quota shipped (v0.1.1107), installable via npx skills add magpie-community/plugins --skill magpie-quota (10-08 16:54).
• The reply pattern matches LESSONS: he asks numbered repro questions (agent? subscription/model? symptom? version?) before fixing (example). He replies “fixed in vX, tested with real accounts”. He publicly corrects blame: “补充更正：上一条把原因推给了上游，不对，这里 magpie 自己有责任” (“correction: my last reply blamed upstream, that was wrong, magpie is at fault here”, 10-04 18:29).
• Context-window inspector: magpie now draws each agent’s context (system prompt, tools/MCP, memory, files, tool results) and scores agents on cache hits (10-08 06:56). This is his harness-eval interest showing up in the product.

---

5. Patterns worth stealing for Noa’s bots (ranked)

Checked against the skill library (30 skills). None of them has a lessons ledger, a verification record format or a PR intake gate. The closest are repo-sloppiness/deslop (after-the-fact cleanup), project-doc-maintenance (a daily PM refresh) and current-truth (doc hygiene).

1. Nightly lessons ledger with promotion (LESSONS.md → standards at 3 days). Why: this is the one mechanism that turns agent mistakes into durable rules without a human writing them. Each entry is rule → why → evidence (SHAs/links) → “done right” → Seen N× (dates), and the file carries a reviewed-through: <sha> watermark. Promotion at 3 separate days stops one-off noise from becoming law. The effect is visible (tags 170/day → 16/day). Where: a new skill lessons-ledger, run by a daily routine. For coding projects, hook it into project-doc-maintenance: the PM bot reviews the day’s merged commits and appends to Projects/<x> Lessons.md. For the bots themselves, a vault note per bot (e.g. Researchy’s misses). The promotion target is that bot’s SKILL.md or persona. Follow current-truth when promoting: rewrite the rule, and leave no “was X” residue.

2. Verification record: “what was run, at which head; not-run is listed”. Why: it makes agent claims auditable. Required elements: a revert check (the test fails without the fix, with a real FAIL); “break it on purpose” mutations; a sandbox HOME with copies of credentials; an explicit Not run: line; and merging only the reviewed head (gh pr merge --match-head-commit), with the record posted before the merge. Where: extend deslop’s “clean with proof” with a standard ## Verification block. Add the same block to the Sol/Codex implementer side of critique, redesign and new-design-handoff (AC ticked plus checks run and not run). Any bot that merges PRs should adopt --match-head-commit.

3. Harm-first PR intake; agents propose blocks, the owner decides. Why: once bots review or merge outside PRs, the first pass should be a mechanical scan for scope creep. Stop on .github/, release scripts, new network endpoints, credential reads, new deps or encoded blobs, and don’t run untrusted code where real accounts live. Blocking is proposal-only, with evidence. Where: a new skill pr-intake-gate, run before any review skill. It pairs with repo-sloppiness (audit after merge) as the gate before merge. Relevant to the orchestrator plans in 2026-09-26 Cloud agent orchestrators in the wild.

4. A thin AGENTS.md that routes; CLAUDE.md is just imports. Why: one fact lives in one place. CLAUDE.md = @AGENTS.md @LESSONS.md, and AGENTS.md holds only “before X, read Y” pointers plus the one map agents keep getting wrong. Key instructions are backed by a test (TestMovedBuiltinsSayTheirPlugin). Where: Noa’s own repos. Also the shape for bot personas: a persona links to skills, not copies. obsidian-vault already does this for vault rules.

5. Subsystem references and a “semantic change” table in every PR. Why: reviewers (human or bot) check claimed Trigger | Before | After against the diff. Each reference ends with runnable verification commands. Where: project-map / project-pm. PM bots could keep Projects/<x>/subsystems/*.md and ask implementers for the table in PR bodies.

6. LLM-planned UI preview in CI, with split-trust jobs. Why: a cheap model reads the diff and plans scenes, Playwright records screenshots and mp4 over seeded data, and the result lands in the PR body. The secret is scoped: the record job is read-only with a low-limit key, and the write job never runs PR code. Where: feeds critique (which needs screenshots) automatically. See also 2026-09-28 Agent e2e verification Wayland browser computer-use.

7. Release gating against agent speed. Don’t tag until a CI run on that commit finishes green (a cancelled run isn’t a pass); don’t cancel CI on main; batch fixes. Where: any bot that tags or deploys. Add it as a rule in lessons-ledger’s seed list.

8. Commit format for agents: area: what the user now sees (reporter/#issue) + a body with how it was verified and which test fails without it. Quoting the human’s instruction ((user: …)) gives provenance even without trailers. Where: instructions for Noa’s coding bots. The provenance trick also helps repo-sloppiness tell agent commits from human ones.

9. Ship a skill for your own CLI (magpie-quota): a JSON CLI plus a tiny SKILL.md lets every agent self-serve. Where: when Noa’s tools grow CLIs. Package via pi-agent-package-development / opencode2-plugin-development.

---

6. Gaps / unknowns

• The agent loop itself isn’t in the repo. No harness config, no scheduler and no nightly-review workflow is visible. “Tick”, the round-the-clock commits and the local checkout paths point to a loop running on yetone’s machines (a Mac plus a Windows/WSL box). Which agent runs it, and how it’s triggered, is unknown.
• Who writes the review comments? They come from the yetone account. LESSONS says agents review and merge, so they are probably agent-drafted, but this isn’t confirmed.
• The trailer signal is weak (0 of the last 100 commits). The “Claude Code” attribution rests on one X reply and 11 historical trailers.
• waitingsnow / forever: 75 PRs all-time with yetone-style titles and 6-second bursts. Could be a second agent operator, or a contributor using the same harness. Unverified.
• GUI tests aren’t in CI. Per the standards they run locally only, so local compliance can’t be verified.
• No blog post, talk or interview about this workflow was found (X + Exa + HN). Public statements are scattered replies.
• magpie-community/plugins (where magpie-quota and the plugin fixes live) wasn’t inspected for its own AGENTS.md or skills.
• Counts use regexes over commit messages (the verification-language and area-prefix rows are approximate). PR stats cover only the 100 most recent PRs (about 29 hours).

---

7. Sources

Repo (GitHub, pinned ddb6f806)

• yetone/magpie · magpie-releases · usemagpie.ai
• AGENTS.md · CLAUDE.md · LESSONS.md
• docs/code-standards.md · docs/subsystems/README.md · docs/contributors.md · docs/subsystems/library.md
• Makefile · test.yml · ui-preview.yml · ui-preview README · release.yml · docker.yml
• Commits: 303819c (LESSONS founded) · 8731dd9 (10-07 review) · fa9daa6 ((user: …) quote, AGENTS.md born) · ddb6f806 · 4ed6df80
• PRs: #1311 · #1045 · #1302 (UI preview block) · #1219 (waitingsnow)
• magpie-community/plugins: magpie-quota skill

yetone on X

• “claude code” · todo-list harness = last gen · TodoWrite retired · Edit tool tells harness age · real-world harness eval · avante → Alma lessons · quota via prompt or skill · magpie-quota skill shipped · context inspector · owning a wrong diagnosis

Other

• AICoder news on magpie launch (2026-10-03) · gitnova: yetone/magpie · avante.nvim
• HN Algolia yetone magpie: 0 stories (checked 2026-10-08).