These skills capture repository-specific knowledge about copper-rs. They are only useful if they stay accurate, so the bar for edits is: does this match the current code?
-
Authority order when sources disagree: code > rustdoc/API > wiki/book narrative. Verify a claim against the source before writing it down; cite concrete paths (
core/cu29_runtime/src/cutask.rs) andjusttargets rather than vague guidance. -
One concern per skill. Keep the split clean:
copper-arch— architecture & task authoringcopper-coding-style— code style & conventionscopper-workflow— build, test & debugging commandscopper-api-flavor— taste rules for new user-facing traitscopper-macro-debug—#[copper_runtime]compile-time issuescopper-ron-config— RON schema referencecopper-component-design— source/task/sink/bridge implementation recipescopper-debug-replay— runtime debug/replay/remote-debug deep dive
If something fits two, put it in the most specific one and cross-reference by skill name.
-
Each skill is a directory with a
SKILL.md. The YAML frontmatter needs aname(must equal the directory name) and adescriptionwritten so an agent can decide relevance from it alone — lead with what the skill is and the concrete triggers ("Use when …"). -
Keep it tight. Prefer the smallest set of high-signal, repo-specific facts. Drop generic Rust advice an agent already knows; keep the things that are surprising here (e.g. the
{}-only logging macros, RON formatted byfmtron, no_std discipline).
- Edit the relevant
SKILL.md. If you move content between skills, fix the cross-references in both. - Re-read the affected skill end to end — it should make sense standalone.
- Bump
versionin.claude-plugin/plugin.jsonfor a notable change. - Open a PR describing what changed in the codebase that prompted the skill update.
Create copper-<topic>/SKILL.md, set matching name/description, link it from the
README's overview table, and from sibling skills where relevant. No change to the plugin
manifests is needed — skills are discovered from the repo root ("skills": "./").