chore(skills): sync skills to miden v0.15

[Keinberger]

Overview

This PR brings the six .claude/skills files that overlap with 0xMiden/agent-tools up to their Miden v0.15 state, so the template's skill guidance matches the code that #51 already migrated to v0.15. It ports the v0.15 substance from the agent-tools skills (source-grounded, Codex-audited) while keeping every example, path, and cross-link that is specific to this template. Doc-only: no code, config, or test changes.

Note on base: the sync was originally planned to stack on migrate-protocol-v015, but #51 has since merged, so this targets main directly. The skill files are identical on both, so the diff is the same either way.

Key Changes

Six skills updated to v0.15, each keeping the template's own worked examples (the counter contract + increment note, the contracts/ and integration/ paths), rather than agent-tools' bank-account examples:

Skill	Ported (v0.15 substance)	Preserved (template-specific)	Dropped
miden-concepts	Note NoteStorage (Vec<Felt>); fallible Felt::new; standard components (BasicWallet, FungibleFaucet::builder(), NoAuth, AuthSingleSig/Falcon512Poseidon2)	Section structure; rust-sdk-pitfalls cross-link	JS/React SDK asides and their non-existent frontend-pitfalls link
rust-sdk-pitfalls	16-felt call boundary; three-part component macro; v0.15 slot-name derivation; two-word Asset; note::build_recipient; NoteType 1-bit encoding; active_note::get_storage()	Felt-arithmetic and as_canonical_u64 security rules; counter examples; contracts/ links	"old / removed / gone" migration framing
rust-sdk-source-guide	Repo map + tags (protocol v0.15.3, client v0.15.2, compiler v0.9.0, miden 0.13, cargo-miden 0.9); error-translation table	Template test command cargo test -p integration --release; repo-exploration workflow	multi-repo make test / nextest guidance not relevant here
local-node-validation	Split node topology (validator / sequencer / ntx-builder / prover); scripts/start-test-node.sh; .sqlite_store extension-trait footgun; connect-time version negotiation	integration/src paths; setup_local_client; counter / increment_count example; port 57291; miden-client-cli cross-link	pre-v0.15 accept-header / genesis-cache item
rust-sdk-patterns	Three-part component macro; #[account(...)] wrapper for notes and tx-scripts; slot-name derivation; corrected native-function signatures; Asset::new; fallible Felt::new; two-place cross-component deps	Counter contract + increment note as the sole worked example; all namespaces and paths; the p2id-note compiler example	all miden-bank example links; the crate::bindings::Account example
rust-sdk-testing-patterns	v0.15 slot naming; faucet setup; PartialNoteMetadata / Note::new; tx-script from_parts; InitStorageData seeding footgun; NoteScript::root() newtype	counter_test.rs flow verbatim (MockChain builder, insert_map_entry, add_account_from_builder, prove_next_block, get_map_item); helpers.rs / increment_count.rs references	migration framing

Rationale

• The skills still described the pre-v0.15 SDK while the code (via feat: migrate to next compiler SDK (protocol v0.15) #51) had already moved to v0.15, so guidance and code were out of sync.
• agent-tools teaches these patterns with its miden-bank tutorial; this template teaches with its counter contract. I re-expressed every v0.15 point using the counter example instead of importing bank code, so the snippets match the contracts actually in this repo. Counter references stay high in the two counter-centric skills (rust-sdk-patterns: 21, rust-sdk-testing-patterns: 29) with zero bank code in either.
• rust-sdk-source-guide still points at the external tutorials/examples/miden-bank app, because mapping external repos for advanced patterns is that skill's whole purpose and those pointers were already present in the template (this is not the counter being clobbered by bank code).

Notes

• Every counter and test snippet was checked against the actual v0.15 source in contracts/ and integration/; version pins are the v0.15 set (miden = "0.13", cargo-miden = "0.9", the 0.15 client stack, protocol v0.15.3, compiler v0.9.0), with no stray 0.14 literals.
• Scope is exactly the six SKILL.md files. miden-client-cli and every other skill are untouched.

Follows #51 (now merged into main).

[greenhat]

The project template lives in the compiler repo now at https://github.com/0xMiden/compiler/tree/next/extra/templates/project. Please move this PR over to the compiler repo.

[Keinberger]

Thanks for the info. Will mirror the PR there.

Is the template code at the compiler repo migrated for v16? The packaging seems to be migrated, has the code been migrated too?

Regarding how to structure given that this repo is currently used as a submodule for the agentic-template, and the agentic-template depends on it: I think it could make sense to create a script that pulls the template from the release file and records the version. Using a github submodule won't anymore since submodules cannot point at subdirectories of repos.

Do you think that will work fine or do you have another idea?

[greenhat]

Thanks for the info. Will mirror the PR there.

Is the template code at the compiler repo migrated for v16? The packaging seems to be migrated, has the code been migrated too?

Regarding how to structure given that this repo is currently used as a submodule for the agentic-template, and the agentic-template depends on it: I think it could make sense to create a script that pulls the template from the release file and records the version. Using a github submodule won't anymore since submodules cannot point at subdirectories of repos.

Do you think that will work fine or do you have another idea?

It seems that agent skills from the new project template should be extracted into a separate toolchain component and managed (installed, updated, etc.) accordingly. Then, cargo miden new will create the workspace and install the agent skills component. The agent skills could be added to any existing user Miden project and not only to a new project. Plus, this way the agent skills could be updated in existing user projects.
@bitwalker What do you think?

[bitwalker]

We can easily make them a separate component. Only real question is what should happen when the component is installed - they would just be assets installed in the toolchain directory, so either that's a fine location for them, or something will have to then copy them into your project.

[greenhat]

We can easily make them a separate component. Only real question is what should happen when the component is installed - they would just be assets installed in the toolchain directory, so either that's a fine location for them, or something will have to then copy them into your project.

Good question! I think the user would most likely want to symlink .claude from the installed agent-skills component to ALL their projects. This way, after the agent-skill component update, all user projects would have it fresh. We can do symlinking in cargo miden new and maybe provide cargo miden symlink-agent-skills command that would do only symlinking as an escape hatch for those that create their project manually.