Gone by the next restart
A prototyping rule edited straight into an installed third-party skill file looked shipped, until a devcontainer restart quietly reverted it, for two reasons the agent had missed.
Prototypes kept hand-rolling markup, icons, and styling for things the component library already had. The clearest case was the PvP connection-status treatment: three corrective rounds before it landed on a design that reused what already existed, a mock surrounding page swapped for the real production components, then bespoke SVG icons swapped for the existing icon catalog. The rule that should have caught that drift the first time didn’t exist yet, so the agent set out to write it.
The first attempt edited the globally installed prototyping skill’s own UI-variant file directly: a new survey step, scan the component directory and its Storybook catalog before drafting; a sharper reuse rule, everything in a variant has to be a real, already-existing component except the smallest new surface the prototype’s question is actually about; a note that throwaway pages with no real surrounding UI drift into this fastest, so they need the survey step most; and a one-line reuse manifest at handoff, so a violation is visible in the same review round instead of surfacing two rounds later as “redo this with the real component.” The edit read clean, the issue closed as resolved.
It had to be reopened. The devcontainer reinstalls that skill directory from scratch on every start, not just a rebuild:
rm -rf /home/vscode/.claude/skills/* 2>/dev/null || true
npx -y skills add mattpocock/skills --skill '*' -a claude-code -y --copy -gAny local edit under that path is gone the moment the container restarts. The second problem sat underneath the first: that file was never this project’s to begin with, it’s installed from a third-party package, so editing the local copy in place hadn’t shipped anything durable even setting the restart aside. Both were caught after the close, not before it, and the edit was reverted.
Two real paths were left. Send the rule upstream as a pull request against the third-party package, which only makes sense with an existing relationship to that repository. Or override it locally, which raised its own unanswered question: whether a project-scoped skill with the same name actually takes precedence over an identically named global one, or just creates an ambiguous duplicate that needed verifying before anyone could call it the answer. The design that shipped sidesteps that question rather than resolving it, a plain markdown supplement living in the project’s own docs, not a same-named skill at all, pointed to from the agent instructions every session reads first and followed alongside the global skill rather than replacing or duplicating it.
Nothing about a markdown file’s survival depends on how any particular agent tool resolves a naming collision. The next prototype in this repo is the actual test of whether pointing at a supplement doc, instead of baking the rule into the tool doing the prototyping, is enough for the rule to actually get followed.