GitHub AI Daily · 2026-11-07 (Saturday)

1. Today's picks (5)

1. nicobailon/skill-diet: putting an agent's skill pack on a diet — 70–80% of the tokens can be cut with no drop in test results, and it turns "does this still work on other models?" into a recomputable table

URL: https://github.com/nicobailon/skill-diet ｜ ★237 ｜ MIT ｜ Python ｜ A skill that puts other agent skills on a diet, plus a cross-model re-check skill called skill-model-gap

What happened

3 commits in the window (11-06 04:31Z ~ 11-06 06:18Z), centred on shipping v0.2.0, which upgrades "skill slimming" from a one-off action into a sustainable maintenance contract.

• ⭐ The core observation is stated as a hard fact: "an agent reads a skill's entire SKILL.md every time it uses the skill." Every extra line in a skill is therefore a tax paid on every call. The README names four kinds of bloat: detail only some tasks use, things the model already knows, notes written for people rather than agents, and lists that one idea could replace. A subtler kind: skills that teach a tool copy that tool's reference into their own body, and that copy goes stale as the tool changes.
• ⭐ The result of a diet is recomputable, not a feeling: the README states plainly that on real skills, a diet cut 70–80% of the tokens with no drop in test results, and found commands the skill documented that no longer worked. Dieting is therefore not only about token savings — it doubles as drift detection between a skill and the tool it teaches.
• ⭐ The "diet" comes with a five-level placement method that puts every fact on the lowest level that still reaches the agent: ① the skill's description (one trigger per case, read every session) ② SKILL.md (what every task needs, read when the skill is used) ③ reference files (what only some tasks need, read when that case comes up) ④ the tool's own help (flags, allowed values, examples, read when the agent picks that command) ⑤ the tool's own replies, errors and checkers (the right name, the fix, the next step, read when the agent calls the tool or a guess is wrong). The lower the level, the less context it costs — this ladder is effectively an explicit context-cost ledger.
• ⭐ v0.2.0 adds skill-model-gap, which solves a problem I had barely registered: most skills are written and tested on one top model, but many people run them on other models, where they can quietly do worse. It runs the same tasks on each model you pick, finds why the weaker one fails, and keeps only a fix that helps that model without hurting the others. The first trial is recorded in the release notes: one change to a skill's description took Kimi from 78% to 98% of runs passed and Haiku from 85% to 100%, with no drop on GPT or GLM.
• ⭐ Scoring was tightened so a diet cannot pass or fail for the wrong reason: v0.2.0 makes running a banned command fail that run outright, and makes comparisons with missing runs fail instead of giving a misleading result. That last rule matters more than the numbers before it — it closes the path by which the evaluation itself lies.
• ⭐ The threshold for keeping a diet is a three-way comparison plus blind judging: run the same tasks with the old skill, the new one, and no skill at all, and keep the new one unless it does worse; disputed answers are settled by a fresh session that has not seen which version wrote them; and the scorer fails the diet if the new skill does worse than chance would explain, or if the new skill never passes a task the old one always passed. The task set is written before anything is cut.
• ⭐ For skills that teach a tool there are three extra steps: prove each mismatch between skill and tool (either by running it or by pointing at the source line); read session logs to find the calls agents make most, and spell out only those in full; and check how often agents actually open the skill, and move rules they need into the tool's replies and errors when they rarely do. The README admits one counter-intuitive fact — "asking an agent to update a skill usually makes it longer, since agents tend to add more than they cut."

Why it matters

• ⭐ This hits my single most painful problem head-on: I use WorkBuddy's expert-manager skill to mass-produce expert packages, and every one of them is a SKILL.md that gets read in full into context on every call. As of this issue I have nineteen daily-report issues, dozens of expert packages and multiple public-account content templates — and I have never measured how many tokens any single skill burns per call. skill-diet's method is measure first, then place, then compare old / new / none — that whole process can be lifted into my expert-package QA flow as its first fixed step: before an expert package ships, it must report three numbers — tokens before slimming, tokens after slimming, and the change in test results.
• ⭐ The skill-model-gap numbers (one line of description moved Kimi from 78% to 98% and Haiku from 85% to 100%) land precisely on my one-person-company niche C, "certification hook + nutrition-AI kernel, lightweight assistant." My target users will not all run the strongest model, and my skill packages have so far been developed once on the strongest model and never checked for whether they still work on weaker ones. More importantly it reveals a lever I had completely missed: one line of description can be worth more than body edits — and my current habit when maintaining an expert package is "fix the body, ignore the description." That belongs in the expert-package iteration spec: try the description first, then the body.
• ⭐ "Only keep a fix that helps the weaker model and does not hurt the others" is the cleanest non-regression criterion I have seen. When I produce GRPM reports and public-account content, the effect of a prompt change is almost never validated across models — and my WorkBuddy setup already reaches several overseas models through a single OpenRouter key, so I have the raw material to run that comparison and have simply never done it.
• ⭐ "Running a banned command fails the run, and a comparison with a missing run fails too" closes off the "the evaluation is lying" route. The hermes-fledge "score from observable facts" idea I noted last issue supplies the evaluation side; this supplies the other half: not just how to score, but when a score must not be trusted. Together they make a complete trustworthy evaluation.
• ⭐ "Read session logs, find the calls agents make most, spell out only those in full" is a near-zero-cost optimisation with immediate returns. My expert packages and content templates spend a lot of space on "what values can this field take" — but the agent typically only ever needs one of them.
• MIT licensed, readable, modifiable and commercially usable, and it is itself a working example of how to write a skill — I can use it as a linter for skill authoring.
• It also carries a warning worth keeping: the README states that asking an agent to update a skill usually makes the skill longer. That means that if I hand expert-package iteration to an agent automatically, the token cost of my expert packages will rise monotonically — a hidden expense I had not been accounting for at all.

2. qf-studio/navigator: moving context management out of the prompt and into the runtime — it blocks the exit signal when a task isn't finished, blocks hand-written task files, and logs one line for every rejection

URL: https://github.com/qf-studio/navigator ｜ ★355 ｜ MIT ｜ Python ｜ A Claude Code plugin that uses context engineering to keep long sessions alive and moves workflow discipline from a config file into the runtime

What happened

15 commits in the window (11-06 11:31Z ~ 11-06 16:47Z), centred on turning workflow discipline from prose into enforceable hooks.

• ⭐ The central commit of this issue is: feat(hooks): stop_completion refuses the exit signal while marker_created is unmet after a task doc — as long as the completion marker required by the task document has not been created, it refuses to emit the exit signal. This is "commitments written into code" appearing again, but in an evolved form: it does not refuse the output content, it refuses to let the agent end its turn. Alongside docs: require_marker_after_task_doc in the configuration reference, the rule is written into the configuration reference.
• ⭐ A second hard gate of the same family: feat(hooks): task_doc_guard — a PreToolUse gate blocks a hand-written .agent/tasks/TASK-*.md unless … — hand-written task files are blocked outright by a pre-tool hook. That means "bypass the workflow and write the conclusion directly" is refused at the tool layer, rather than depending on the agent's good intentions.
• ⭐ A third element: every rejection leaves one line of log. The README is explicit: from v8 the workflow is enforced by a runtime that runs inside Claude Code, not by prose in a config file; it gates task-shaped prompts, guards fan-out reads, records what each turn finished, and writes one line to a reject log every time it says no. The reject log is what I value most here — it turns "what did the gate refuse?" into an auditable fact rather than a message that vanishes into the console.
• ⭐ The remaining commits in this window all harden the reliability of that chain: build(test): scrub session variables before every suite — make test is hermetic in-session and in the … (session variables are cleared before every suite so tests are hermetic both in-session and across threads); build(test): run the suites in parallel (TEST_JOBS, default 4); build(test): make test writes everything to stderr (all test output goes to stderr, because Pilot's gate tail captures stderr only); build(test): make test ends with a FAILED SUITES block naming each red suite and its FAIL/ERROR line (a failed test run must end with a FAILED SUITES block naming each failing suite and its failing line); test(hooks): p95 timing budget scales with measured host slowdown (the p95 time budget scales with measured host slowdown, because the Pilot box failed under load); fix(nav-task): local task IDs come from origin/main and the archive, not only the working tree; and ci(tests): pin the Python 3.9 leg to ubuntu-24.04 (setup-python has no 3.9 build for Ubuntu 26.04).
• ⭐ The core metrics are quantifiable: the README's comparison table gives tokens loaded dropping from 150,000 to 12,000 (92% saved), session length rising from 5–7 exchanges to 20+, and end-of-session context occupancy falling from 95% (crashed) to 35% (comfortable). That turns "context engineering" from mysticism into a comparable engineering metric.
• ⭐ It also has a mechanism aimed at collaboration quality, nav-diagnose: the same correction appearing twice triggers a quality check ("You're not getting this" → a re-anchoring prompt); nav-profile remembers preferences across sessions and auto-learns from corrections; and the v6.0 knowledge graph unifies retrieval across tasks, SOPs and system docs, surfacing relevant context automatically at session start.
• ⭐ Loop Mode v5.1 exits on dual conditions: "run until done" is decided jointly by heuristics and an explicit signal (dual-condition exit), with stagnation detection preventing infinite loops. The README also states an honest boundary — "you can say it looks good, but the agent's answer was actually wrong and you did not react, and such a run looks clean."

Why it matters

• ⭐ "Refusing the exit signal" treats exactly the kind of silent failure I hit most in public-account content production: I hand WorkBuddy "write an evidence-based article" and it returns something that looks finished — but the references are missing, or only 18 of the 24 risk dimensions were written. My current approach is manual checking afterwards. navigator's approach is to intercept the agent at the moment it wants to end, and require a completion marker first. The equivalent for my stack: an intervention report must land an "evidence ids complete" marker before it is allowed to return success — a rule that is far cheaper to enforce than checking afterwards.
• ⭐ "task_doc_guard blocking hand-written task files" is the one I most want to copy, because it closes off "bypass the workflow and write the conclusion directly." In my public-account workflow the AI sometimes hands me a piece of finished-looking prose, and only on inspection do I find the references were invented. If the generation layer has a PreToolUse gate saying "a draft that has not passed evidence-id validation may not be written to disk," the AI has no way to deliver by circumventing the process.
• ⭐ "One log line per rejection" is the cheapest thing I saw this issue and the one I should do first. None of my current AI flows keep a rejection log — so when an AI refuses to do something, I never know how often it refused or under what conditions. With a reject log, "how many times did the AI refuse this week, and under what conditions" becomes a table you can look at, which is the same family of idea as Calibrate's "grade reminders by value" I noted last issue: turn reminders into a graded list rather than equal-weight noise.
• ⭐ "A failed test run must end with a FAILED SUITES block naming each failing suite and its failing line" should become a fixed closing format in my expert-package CI. Today a failing run often mixes one real error into a pile of red text; a final naming block turns "which test went red, and on which line" from an archaeology exercise into something visible at a glance.
• ⭐ "The p95 time budget scales with measured host slowdown" is a design I had never considered and immediately understood: the same gate takes different time on an idle machine and a loaded one, so a fixed threshold produces false kills under load. For my stack: if I add an "evidence complete" gate to the lab-report OCR pipeline, its timeout threshold cannot be hard-coded — Gordon's Mac performs several times slower during bulk imports than when idle.
• ⭐ Its honest self-description should go into my checklist: "the answer was wrong and you didn't react, so the run looks clean." That sentence pinpoints the fundamental flaw of "clean run rate" as a quality metric. If my platform counts "task completion rate," it will systematically overstate reliability in exactly the same way.
• MIT licensed and commercially usable. Its context-budget thinking is the same cost awareness as the oh-my-pi "measure bytes on the real wire" note from the previous issue — context is money, and it has to be measured.

3. Mason-Levyy/myfitnesspal-mcp: letting AI write straight into your food diary — but every write must be verified by reading the diary back, the simplest and most reliable anti-hallucination technique I have seen

URL: https://github.com/Mason-Levyy/myfitnesspal-mcp ｜ ★30 ｜ MIT ｜ Python ｜ An MCP server for MyFitnessPal that turns "log your meals by talking" into a searchable, trackable and exportable real diary

What happened

3 commits in the window (11-06 05:21Z ~ 11-06 05:32Z), centred on adding read-back verification to a write-capable tool, plus a complete single-day lifecycle.

• ⭐ The title of the most important commit this issue is the answer itself: Verify food adds by reading the diary back (#54) — after adding a food, read the diary back and check. That is eleven words, and it closes the entire "AI writes data" credibility problem. The README states the overall stance just as plainly: "Writes, not just reads: log, modify, and delete real diary entries."
• ⭐ The next two commits complete the semantics of a single day: Add day goals and remaining macros to day records (#55 — day records carry goals and remaining macros) and Add fitness_complete_day to report, complete, or reopen a diary day (#56 — a day can be marked complete, and can also be reopened, meaning a day's state is mutable rather than written once and frozen).
• ⭐ The authentication problem it solves is genuinely technical: MyFitnessPal moved behind Cloudflare + NextAuth, breaking the username/password login that most existing integrations rely on. Its approach is to carry the browser session cookie over a real Chrome TLS fingerprint (curl_cffi) to pass Cloudflare, with an optional headless-browser profile that rotates the expired token, and automatic retries on failed calls.
• ⭐ It states its own usage boundary explicitly: "Unofficial. MyFitnessPal has no public API; this reverse-engineers the web app's own endpoints. It can break whenever MFP changes their site. Use at your own risk, with your own account." — the fact that it is reverse-engineering, the risk that it may break at any time, and the responsibility split of "use your own account", each in one sentence.
• ⭐ The interaction design is search-then-log: get candidates with macros first, then log the exact item — not letting the AI write a food name and its calories from memory. The README's demo shows a breakfast smoothie being logged ingredient by ingredient.
• ⭐ The tool surface covers the real diary's whole lifecycle: logging a meal, searching the food database with macros, tracking trends, exporting nutrition history, editing and deleting — plus the new day-goal / complete / reopen semantics.

Why it matters

• ⭐ "Read back after writing" is the cheapest and most directly portable anti-hallucination technique I saw this issue, and it belongs to exactly the same family as OpenAdapt's "read-back verification four checks" from the previous issue. My 4P platform, GRPM reports and public-account content all involve "AI writes structured data, then it gets stored or published" — but I have never done a read-back check. myfitnesspal-mcp closes the loop with a single diary read. One tool call, near-zero cost, and "the AI invented a food that does not exist" becomes detectable. This should become a uniform step in my platform's write path: write → read back by primary key → compare → flag and block downstream on mismatch.
• ⭐ "Search-then-log" fixes a real pain point in my platform. My supplement formulation engine generates food combinations and nutrient estimates today by having the AI produce "food + content" pairs directly — and AI-invented nutrient values often do not exist in any public database. The shape used here is you must first pull candidates from a real food database, with that food's macros attached, and only then decide which item to log. Applied to my stack: nutrient estimation should query USDA or the Chinese food composition tables first, and the AI should only choose which items to use and explain why — not invent a content value.
• ⭐ "A day can be marked complete, and can also be reopened" has direct value for my supplement-plan design. My GLP-1 nutrition companion today has a "morning / evening double-cup plan" plus "lab trends trigger re-optimisation", but there is no state for "this day's plan was actually executed". I cannot currently distinguish "this day's plan hasn't started" from "this day's plan was completed and worked". Adding a completable / reopenable state to "daily plan execution" is the same modelling exercise as the improve / unchanged / worsen triad I already use for lab markers — and I haven't done the former.
• ⭐ The way it discloses the risk of unofficial interfaces is worth copying. The README leads with "this is reverse-engineering, it may break at any time, use your own account." Whenever I design a third-party data integration for the 4P platform (WeChat, public accounts, food databases, wearables), it should carry an explicit "this may break at any time" declaration, and the business must be able to degrade gracefully when it does.
• MIT licensed and commercially usable, and it has already implemented "authentication + automatic renewal + retry on failure + search + write + read-back verification" as a whole. If I build food or nutrition data ingestion, this is a ready reference implementation rather than a from-scratch design.

4. wilbert-MD-PhD/medical-illustration: a medical-illustration skill for AI agents — every anatomical structure used for teaching must have a credible source matched to its region, viewing angle and depth, and the evidence is logged per image

URL: https://github.com/wilbert-MD-PhD/medical-illustration ｜ ★174 ｜ MIT (core Skill and scripts) / CC BY 4.0 (original documentation and comics) ｜ Python ｜ A medical-illustration Skill for Codex, Claude Code and other AI agents, producing science-communication comics, teaching illustrations and research diagrams

What happened

1 commit in the window (11-06 14:19Z), plus the v1.3.7 release (11-06 14:21Z), centred on fixing relation-type validation in mechanism graphs.

• ⭐ The release notes are strikingly restrained: "Fix mechanism graph validation to report invalid relation types without stopping validation of the remaining edges" — when relation is mistakenly filled in as an array or an object, the checker now reports the field error and keeps checking the remaining relations — plus new regression tests for invalid types and for valid data. The key half of that sentence is "keeps checking the remaining relations": one bad edge must not make it abandon the whole diagram.
• ⭐ Its core commitment is mandatory, not advisory: the README states that "this Skill requires that every anatomical structure used for medical teaching in the work has a credible source matched to its region, viewing angle and depth"; during production it must verify atlases, textbooks, primary studies or traceable models, actually look at the reference, and then record which specific structures it supports, whether it was attached as a generation-time reference, and the result of comparing against the final image.
• ⭐ Evidence is logged per image, not cited in aggregate. The README walks through an example wrist-and-joint comic: it contains 5 anatomical base images used a total of 6 times, and then breaks it down image by image — page 1 base image B01 uses Gray219 plus Wrist and Hand Fig.4.18, book page 52, with the verification content spelled out as "the partition and adjacency of phalanges, metacarpals and carpal bones; BodyParts3D M01 provides right-hand geometry", and noting that "the textbook only supplements the wrist relationship"; pages 4–5 base image B05 uses Gray336 plus Fig.4.19a, book page 53, noting that "M06 is an explanatory coronal line drawing, B02 is used only as a colour reference."
• ⭐ It has an explicit discipline for narrowing a source's scope of applicability: "the use of textbook Fig.4.18 is limited to the wrist; a wrist image is not used to prove every detail of the whole hand" (for page 1); for B04 it notes that "the two textbook figures belong to the same source."
• ⭐ Deliverables are editable, and text and imagery are separated: the text, speech bubbles, medical labels and later-added arrows can all be edited independently, so changing wording, moving annotations and partial rework are all convenient; delivery includes a Markdown script, colour artwork, layout source files and a PDF.
• ⭐ The license layering is the most transferable thing about this repository (the API reports NOASSERTION; the file text is authoritative): author-owned core Skill (SKILL.md, references/, agents/, scripts/, CI and install configuration) = MIT; author-owned original repository documentation, tutorials, comics, characters, showcase images and layout contributions = CC BY 4.0; third-party images, fonts, models, software and their derivatives keep their original licenses, with a separate third-party inventory and unresolved-items audit. The README states that "MIT and CC BY 4.0 both permit commercial use", gives a sample attribution format, and warns that "new works created with the Skill do not automatically inherit the above licenses."
• ⭐ Its topic-selection capability is written into the capability table: science-communication comics start from a life situation; teaching illustrations express anatomical layers, injury location and repair process against real references; and research diagrams "distinguish established relationships from hypotheses."

Why it matters

• ⭐ The whole "log evidence per image plus state the reference's scope of applicability" apparatus is precisely what my public accounts (4P Precision Nutrition Watch / Health 100 Observation) lack most. Today I list references at the end of an article, but there is no registration structure for "which concrete conclusion does this image support, which book and page is the basis, and what part of the claim does this basis actually cover." medical-illustration's "expand image by image" format can be lifted directly as an "evidence registry" for my public accounts — every image and every mechanism statement mapped to one row: claim / source / page or figure number / scope of support / hypothesis or not.
• ⭐ "A wrist image is not used to prove every detail of the whole hand" is the mistake I most easily make in precision-nutrition science writing. An article about "a certain nutrient pathway" often uses one generic diagram to support three or four claims at different levels — while that diagram only covers one of them. Writing out the scope of applicability explicitly kills the most common form of over-extension in my articles.
• ⭐ "Distinguish established relationships from hypotheses" written into the capability table rather than offered as an optional note lines up exactly with the explicit association caps a sentence at associative rule (evidence supporting association must not have its wording upgraded to causation) I noted last issue. The same principle, in two languages, one discipline.
• ⭐ "One bad relation no longer stops validation of the remaining edges" corresponds to my GRPM: if one of the 40 SNP decision rules fails to parse, the report must not stall there — and the other 39 must not be marked "not evaluated" either.
• ⭐ License layering matters enormously for a one-person company, and this one points the right way: "MIT for code + CC BY 4.0 for original content + third-party assets keep their own terms" is the cleanest licensing structure for "I want to turn this content into a commercial product" — the code is freely commercially usable, the original content needs only attribution and a note of changes, and third-party assets just need to be used per their own terms. That is far more precise than "one license for the whole repository", and far friendlier than the AGPL/PolyForm all-or-nothing cases I ran into last issue.
• ⭐ It also flagged a point I had never registered: "new works created with the Skill do not automatically inherit the above licenses." In other words, for a comic I produce with it, copyright ownership and asset provenance need checking again myself — I cannot assume "the material came from a CC BY 4.0 repository, therefore my output is CC BY 4.0."

5. archestra-ai/archestra: pulling "which model does the agent use, what does it cost, whose permissions does it carry" into one platform — and making secure defaults an architectural property rather than a toggle

URL: https://github.com/archestra-ai/archestra ｜ ★4,433 ｜ AGPL-3.0-only (default) / LicenseRef-Archestra-Enterprise (regions marked Enterprise) ｜ TypeScript ｜ An enterprise AI platform: LLM gateway + MCP gateway + A2A gateway + private MCP registry + agent runtime + guardrails

What happened

40 commits in the window (11-06 17:28Z ~ 11-07 02:46Z), plus the platform-v1.4.22 and platform-v1.5.0-rc.24 releases (both 11-06), centred on pushing agent runtime boundaries (isolation level, credential ownership, cost ceilings) down into the infrastructure layer.

• ⭐ The hardest commit this issue productises runtime isolation itself: feat(agent-runtime): run unprivileged Agent Runtime pods under a configurable RuntimeClass (gVisor o…) — agent runtime pods run unprivileged under a configurable RuntimeClass (gVisor and similar). In other words the sandbox isolation level of the agent has become a product configuration option rather than an ops parameter.
• ⭐ Guardrails are not optional; they are stated on the README's first screen: "Built on a strong security and observability foundation: SSO and RBAC, sandboxed code execution, Lethal-Trifecta guardrails, OpenTelemetry traces, and Prometheus metrics — first-class, not bolted on." — the phrase "not bolted on" is itself a product standard.
• ⭐ The gateway layer's shape is "one URL for four jobs": the LLM gateway (any provider plus cost limits, virtual API keys and dynamic model routing), the MCP gateway (OAuth + On-Behalf-Of, so tools run as the user rather than under a shared service account), the A2A gateway (agent-to-agent triggers), a private MCP registry (teams ship their own tools) and an MCP orchestrator (a Kubernetes operator plus self-serve promotion across environments).
• ⭐ MCP tools executing under the user's own identity is the design detail worth noting: On-Behalf-Of means audit logs can distinguish "a person did this" from "the agent did that" — which directly addresses the shared-service-account ambiguity in credential ownership that I flagged in the previous issue's notes on the governance layer above the gateway.
• ⭐ The rest of this window's commits are almost entirely "move credentials out of the code": ci(deploy): read staging and demo credentials from synced Kubernetes Secrets; ci: read benchmark and alerting secrets from GCP Secret Manager; ci: scope publish credentials to GitHub Environments; ci: request least-privilege permissions for releaser App tokens; ci: run Release Please through the shared App-authenticated workflow; fix(ci): pass environment secrets to reusable workflows by name; fix(helm): connect to Cloud SQL through the Auth Proxy with IAM login; fix(helm): optional hook ServiceAccount for the migration Job; fix(ci): move remaining CI images and dev caches to GHCR. This is a real sample of agent supply-chain governance — every single commit is a question about "who could see this credential before".
• ⭐ The license routing rules themselves are worth reading: AGPL-3.0-only by default; files marked Enterprise fall under LicenseRef-Archestra-Enterprise; the order of determination is file-top SPDX header → in-file REUSE snippet regions → path convention (*.ee.* or an ee/ directory) → the vendored Dagger SDK keeps its upstream MIT → default AGPL. That is far more granular than a single LICENSE file.

Why it matters

• ⭐ "MCP tools run under the user's identity (On-Behalf-Of) rather than a shared service account" solves a concrete architectural problem in my 4P platform. All my MCP tool calls today go through one connector identity, so the audit log cannot distinguish "the user queried their supplements" from "the agent initiated a fetch on its own." Once tools execute under the user's identity, I can answer "who actually proposed this intervention?" — which goes straight to the compliance story of the 4P platform.
• ⭐ "Cost limits plus virtual API keys" are the two gateway features I need most as a one-person company, and the market's gateways basically only do "can it connect". The previous issue already recorded this judgement: "the competitive point in the infrastructure line has shifted from 'can it connect' to 'what else will it eat once connected' (budget, format, credential ownership)" — this issue productises all three (budget, credential ownership, isolation level) at once, which is a clear node on that thread.
• ⭐ "Sandbox isolation level as a configurable RuntimeClass" is a shape that helps me understand agent security boundaries. When I run batch AI tasks (OCR, report generation) today, isolation basically rests on the informal convention of "I don't turn on the network." Making the isolation level a configurable, tightenable option is "writing compliance boundaries into code" in another form.
• ⭐ That run of "move credentials out of the code" commits is a ready-made self-audit checklist for my own repositories. My 4P platform, GRPM and content pipeline all involve API keys and model credentials; walking the ten commits one by one (deploy credentials, benchmark and alerting credentials, scoped publish credentials, least-privilege App tokens, shared-workflow authentication, images and caches moved to a private registry, IAM-based database login) will immediately surface gaps in my own setup.
• ⭐ "first-class, not bolted on" is a standard I can hold my own platform components to. Much of my "compliance" today is written in documentation rather than in architecture — and if a security claim is bolted on beside the thing it protects, it is the first thing to fall off under pressure.
• ⚠️ But the licensing needs care: AGPL-3.0-only by default, with Enterprise regions under a separate commercial license. For a one-person company, AGPL means read-only, not copy; deploying it as the base of a commercial service would require negotiating a commercial license. What can be copied is the design thinking, not the code.

2. Category roundup

① AI Coding / programming agents and skill ecosystems

② Medical / clinical research AI and agent skill libraries

③ Health management / nutrition and food AI

④ Model foundations and agent infrastructure

3. Trends today

The most visible thread this issue is that constraints are moving from "requirements written in a prompt" to "gates that cannot be bypassed at runtime" — and the gates now carry their own evidence. skill-diet guarantees that slimming introduces no regression via "old / new / none three-way comparison plus blind judging plus a scorer that can itself fail"; navigator has stop_completion refuse to let the agent end its turn while the completion marker is missing, and log every rejection; archestra runs agent runtime pods unprivileged under a configurable gVisor RuntimeClass and writes "which identity runs the tool" into the auth protocol; myfitnesspal-mcp does the plainest thing of all — after writing, it reads the diary back and checks. These four lines are unrelated to each other, yet all answer the same question: not "what should the AI do" but "when the AI cannot do it, how does the system stop it, and is there a record afterwards." That is the fourth stage of the thread I have been tracking across recent issues (aureproof's three-state gate, Calibrate's 2×2 dependency matrix, AdelIA's answer contract, Gaskin's locked items): the previous stage pushed constraints down into code; this stage pushes them down into the runtime, and makes the runtime leave auditable traces.

The second thread is that the unit of cost is shifting from token to token × model × scenario. When skill-diet reports "cut 70–80% of tokens with no drop in test results", it also reports something far more counterintuitive: changing one line of the description took Kimi from 78% to 98% and Haiku from 85% to 100%. The same slimming action yields wildly different gains on different models. navigator reports "tokens loaded from 150,000 down to 12,000, end-of-session context from 95% down to 35%" — also as comparable quantitative metrics rather than "it feels better". Together these two mean: evaluating the cost-effectiveness of an AI artifact or skill can no longer look only at "how smart is it" — it must be the triple of "which model, how many tokens, how many tasks passed." That is precisely the measurement I have been missing when producing expert packages and one-person-company products.

The third thread: local-first and traceable-evidence are becoming default assumptions for health and medical work, not personal preferences. syntropy-health runs on a computer you control, and everything it does with your records is read-only and logged; medical-illustration mandates that "every anatomical structure used for medical teaching has a credible source matched to region, viewing angle and depth" and logs per image which part that source actually supports; myfitnesspal-mcp reverse-engineers MyFitnessPal's private API but states "this is reverse-engineering, it may break at any time, use your own account" in its opening paragraph. All three share the same shape: making "the data is on my machine" and "the conclusion has a basis" simultaneously checkable facts. This extends the trend I noted in earlier issues (cairn binding HTTP to 127.0.0.1, DataNyx's value-less schema plus schema-diff in CI) — local-first is now the default architectural assumption for this class of product, and traceable evidence is filling in the second half.

The fourth thread: licensing forms are upgrading from "one LICENSE file" to "layered + routed + three separately declared layers." medical-illustration puts its author-owned core Skill and scripts under MIT, its author-owned original documentation and comics under CC BY 4.0, and third-party assets under their own terms, stating outright that "new works created with the Skill do not automatically inherit the above licenses"; archestra uses a first-match-wins router with AGPL-3.0-only as default and a commercial license for Enterprise-marked regions, laying out SPDX headers, REUSE snippets, path conventions (*.ee.* / ee/) and vendored dependencies layer by layer; ClawBio's "three-part license" from the previous issue (code / model / data, take the strictest) is the same family. The direct implication for a one-person company is that you can no longer read the license badge on a repository's front page and stop there — you have to ask two questions: which part of this am I using, and who owns that part. This round confirmed 5 entries genuinely have no LICENSE file (dromlakhani/MD2SKILL, ImHangLi/maru, anbeime/skill, linhay/harmony-next.skills, anthropics/skills), and anthropics/skills carries this issue's commit "Move Office skills to the Apache 2.0 license" — even the most upstream official skill repository is shifting toward the more permissive side, which is itself a signal.

The fifth thread, and a direct note to Gordon: the three "read-back verifications" I saw this issue come from three different tech stacks, but all solve the same error. myfitnesspal-mcp solves "the AI invented a food that does not exist" with one diary read; navigator solves "the agent handed back a finished-looking incomplete draft" with a completion marker plus a reject log; medical-illustration solves "this image does not actually support this sentence" with per-image evidence logging. My three projects — the 4P platform, GRPM reports and public-account content — all do "AI generates a structured conclusion, then it is stored or published", and none of them does a read-back check. This is a near-zero-cost improvement: write → read back by primary key → compare → flag red and block downstream on mismatch. What I should be more worried about is skill-diet's warning that "asking an agent to update a skill usually makes it longer" — meaning that if I let agent automation iterate my expert packages, their token cost will rise monotonically.

4. Repo index

https://github.com/nicobailon/skill-diet
https://github.com/qf-studio/navigator
https://github.com/Mason-Levyy/myfitnesspal-mcp
https://github.com/wilbert-MD-PhD/medical-illustration
https://github.com/archestra-ai/archestra
https://github.com/vastsa/PI-Desktop
https://github.com/getpaseo/paseo
https://github.com/langwatch/langwatch
https://github.com/earendil-works/pi
https://github.com/windmill-labs/windmill
https://github.com/repoprompt/repoprompt-ce
https://github.com/genspark-ai/genoffice
https://github.com/generalaction/emdash
https://github.com/open-gsd/gsd-pi
https://github.com/ParadevAI/Paradev
https://github.com/davila7/claude-code-templates
https://github.com/homarr-labs/dashboard-icons
https://github.com/coreyhaines31/marketingskills
https://github.com/wonderwhy-er/DesktopCommanderMCP
https://github.com/anbeime/skill
https://github.com/mjmirza/app-store-compliance
https://github.com/InsForge/InsForge
https://github.com/cobusgreyling/loop-engineering
https://github.com/vercel-labs/deepsec
https://github.com/ValueCell-ai/ClawX
https://github.com/rpamis/comet
https://github.com/kaankiziltug/logo-design-skill
https://github.com/Jakubantalik/transitions.dev
https://github.com/EgoAlpha/prompt-in-context-learning
https://github.com/linhay/harmony-next.skills
https://github.com/DiffoHQ/diffo
https://github.com/pavanbadempet/AI-Healthcare-System
https://github.com/melvinmathew9991/multi-agent-food-concierge-mcp
https://github.com/cfu288/mere-medical
https://github.com/peter-fusek/oncofiles
https://github.com/hapifhir/hapi-fhir
https://github.com/nitrain/nitrain
https://github.com/ohcnetwork/care_fe
https://github.com/earthians/marley
https://github.com/dromlakhani/MD2SKILL
https://github.com/Mayank-cyber-cell/MedGuide-PillTracker
https://github.com/SongyuQi-Francisco/Watch2Whoop
https://github.com/fliptheweb/yazio-mcp
https://github.com/siddsachar/row-bot
https://github.com/GeiserX/OwnGenome
https://github.com/health-assistant-io/health-assistant
https://github.com/sayed0am/unstrap
https://github.com/ArtLogicIKE/frixos
https://github.com/EnriqueNeyra/syntropy-health
https://github.com/ImHangLi/maru
https://github.com/ohuc/CaffeineHealth
https://github.com/pedroberaldo87/daily-screen
https://github.com/CherryHQ/cherry-studio
https://github.com/kestra-io/kestra
https://github.com/topoteretes/cognee
https://github.com/perplexityai/SPACE
https://github.com/smg-project/smg
https://github.com/langfuse/langfuse
https://github.com/pydantic/pydantic-ai
https://github.com/yc-software/qm
https://github.com/zeroclaw-labs/zeroclaw
https://github.com/microsoft/agent-framework
https://github.com/deepset-ai/haystack
https://github.com/pipecat-ai/pipecat
https://github.com/a2ui-project/a2ui
https://github.com/google/adk-go
https://github.com/google/adk-python
https://github.com/strands-agents/harness-sdk
https://github.com/multica-ai/multica
https://github.com/THU-MAIC/OpenMAIC
https://github.com/mastra-ai/mastra
https://github.com/boxlite-ai/boxlite
https://github.com/aklivity/zilla
https://github.com/mozilla-ai/otari
https://github.com/matthiasn/lotti
https://github.com/crewAIInc/crewAI
https://github.com/codescene-oss/codescene-mcp-server
https://github.com/firecrawl/firecrawl
https://github.com/awslabs/mcp
https://github.com/TanStack/ai
https://github.com/dataelement/dsh-desktop
https://github.com/TencentCloud/CubeSandbox
https://github.com/higress-group/higress
https://github.com/vercel/eve
https://github.com/apple/coreai-models
https://github.com/EverMind-AI/EverOS
https://github.com/VoltAgent/voltagent
https://github.com/agentscope-ai/agentscope-java
https://github.com/IBM/mcp-context-forge
https://github.com/hatchet-dev/hatchet
https://github.com/oomol-lab/open-connector
https://github.com/spiceai/spiceai
https://github.com/ysr666/dsh-vision-router
https://github.com/Mintplex-Labs/anything-llm
https://github.com/langchain-ai/deepagents
https://github.com/apache/apisix
https://github.com/casdoor/casdoor
https://github.com/langchain4j/langchain4j
https://github.com/xerrors/Yuxi
https://github.com/truefoundry/trueforge
https://github.com/RLinf/RLinf
https://github.com/0xSteph/patient-zero
https://github.com/googleapis/mcp-toolbox
https://github.com/harbor-framework/harbor
https://github.com/rivet-dev/rivet
https://github.com/mem0ai/mem0
https://github.com/wasmerio/wasmer
https://github.com/TokenRhythm/opensquilla
https://github.com/theagentrouter/agent-router
https://github.com/trpc-group/trpc-agent-go