NanoClaw

NanoClaw replaces bundled skill patches with host-owned seams

NanoClaw proposes host interfaces for skill-owned capabilities after two bundled Qodo skills intercepted ordinary coding requests and depended on setup that did not exist. A companion patch removes those skills while preserving broader hardening changes.

← Back to homeOriginal source ↗

nanocoai/nanoclaw PR #3186 is the inspected primary source: “refactor: add host seams for skill-owned capabilities.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- nanocoai/nanoclaw PR #3186 was created 2026-08-04T14:21:53Z and was open at inspection; its title is “refactor: add host seams for skill-owned capabilities.” - nanocoai/nanoclaw issue #3171 was created 2026-08-01T18:50:41Z and was open at inspection; its title is “The two qodo skills depend on an integration nothing sets up and intercept normal coding requests.” - nanocoai/nanoclaw PR #3172 was created 2026-08-01T18:50:42Z and was open at inspection; its title is “chore(skills): remove the two qodo skills.” - The repository reported 30432 stars, 866 open issues, default branch main, and last push 2026-08-04T13:56:07Z. - The latest tagged-release baseline checked was v2.1.54 published 2026-08-01T20:46:31Z.

What changed

nanocoai/nanoclaw PR #3186 reports: Type of Change [ ] **Feature skill** - adds a channel or integration (source code changes + SKILL.md) [ ] **Utility skill** - adds a standalone tool (code files in.claude/skills/ /, no source changes) [ ] **Operational/container skill** - adds a workflow or agent skill (SKILL.md only, no source changes) [ ] **Fix** - bug fix or security fix to source code [x] **Simplification** - reduces or simplifies source code [ ] **Documentation** - docs, README, or CONTRIBUTING changes only Description Add small, typed host extension seams so an optional TypeScript module can own one responsibility and integrate through explicit registration instead of spreading implementation across core files. Logical changes | Area | Change | Compatibility | |---|---|---| | Skill authoring | Document single responsibility, the Open/Closed Principle, skill-owned files, and minimal integration through the owning typed seam. | Guidance only. Existing skills are unchanged. | | Database migrations

nanocoai/nanoclaw issue #3171 reports: What happens** Two bundled skills, get-qodo-rules and qodo-pr-resolver, depend on a Qodo SaaS account that nothing in the repo sets up. Both read an API key from ~/.qodo/config.json (get-qodo-rules/SKILL.md:55), and no skill, doc, or setup step ever creates that file. The worse part is that get-qodo-rules is not inert. Its description says "Use before any code generation or modification task" and its trigger list includes implement, write.?code, fix.*bug, build.*feature, and refactor (SKILL.md:3-27). So an agent handling an ordinary "fix this bug" request picks the skill up first and goes hunting for a Qodo config that does not exist before doing the actual work. We saw exactly this during a debugging session: the agent kept looking for a qodo install nobody had asked about. Why removal instead of a fix** Zero references anywhere in the repo. A repo-wide grep for qodo finds only a historical CHANGELOG line. No tests, no REMOVE.md,

nanocoai/nanoclaw PR #3172 reports: Type of Change [ ] **Feature skill** - adds a channel or integration (source code changes + SKILL.md) [ ] **Utility skill** - adds a standalone tool (code files in.claude/skills/ /, no source changes) [ ] **Operational/container skill** - adds a workflow or agent skill (SKILL.md only, no source changes) [ ] **Fix** - bug fix or security fix to source code [x] **Simplification** - reduces or simplifies source code [ ] **Documentation** - docs, README, or CONTRIBUTING changes only Description Closes #3171. Removes.claude/skills/get-qodo-rules/ and.claude/skills/qodo-pr-resolver/. Both depend on a Qodo SaaS account that nothing in the repo sets up (API key expected in ~/.qodo/config.json, which no skill, doc, or setup step ever creates), have zero references outside their own directories, no tests, and no REMOVE.md. get-qodo-rules also triggers on generic coding phrases (implement, fix.*bug, refactor), so agents intercept ordinary coding requests and hunt for a Qodo config

Why it matters

A skill should not patch core files or seize normal requests merely because it is bundled. Host-owned seams make capabilities removable, testable and less likely to survive as hidden installation drift. The operator test is whether persisted state, execution authority and the visible outcome describe the same event after retries, restarts or delegation.

Current

The primary record was open when captured on 2026-08-05. The release baseline was v2.1.54 published 2026-08-01T20:46:31Z. Repository metadata, pull requests, issues, release records, Google News discovery, Hacker News discovery, Lobsters, Metamesh and the rendered ClawCharts row were checked. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/nanocoai/nanoclaw/pull/3186. Supporting records are https://github.com/nanocoai/nanoclaw/issues/3171 and https://github.com/nanocoai/nanoclaw/pull/3172. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts, reproductions and deployment observations remain attributed to their authors unless explicitly identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Land capability interfaces before deleting legacy patches, test the no-skill baseline, and make every optional integration prove its setup path before routing user work. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently after intervention.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.