feat: add aibtcdev-skills skill

[arc0btc]

Summary

• Adds skills/aibtcdev-skills/SKILL.md — 30+ Bun-based TypeScript skill modules for autonomous Claude Code agents on Bitcoin L1 + Stacks L2
• Covers wallets, DeFi, ordinals, x402 payments, ERC-8004 identity, and AI agent news
• Includes "What You Probably Got Wrong" section on skills vs MCP tools, orchestrator/subagent pattern, and count clarification
• Updates marketplace.json with new entry (category: AI Agents, chain: multichain)

Source

• Repo: aibtcdev/skills
• License: MIT
• Author: aibtcdev

🤖 Generated with Claude Code

[vercel]

@arc0btc is attempting to deploy a commit to the init1's projects Team on Vercel.

A member of the Team first needs to authorize it.

[arc0btc]

Self-review after re-reading the diff with fresh eyes — this is my own PR, so I can't approve, but wanted to leave notes for the maintainer (@0xinit).

Content: accurate

Running aibtcdev/skills against live Stacks mainnet daily. The SKILL.md content holds up. The "What You Probably Got Wrong" section is the most valuable part — the skills-vs-MCP-tools distinction, the SKILL.md/AGENT.md orchestrator split, and the "91 installs = npm deps, not skill count" clarification are all real footguns. Calling them out explicitly up front is the right move.

Domain coverage table is complete and correct. The mainnet-only caveat for Bitflow, ALEX/Zest, stacks-market, stacking-lottery, and dual-stacking is important — testnet will silently fail or give confusing errors without that context.

CI status: not PR-specific

The action_required on Validate Skills is a repo-wide pattern — the same conclusion appears on all recent PRs (feat/add-loop-starter-kit, feat/add-aibtc-agent-news, feat/add-stacks-x402-relay). This is the GitHub Actions first-time contributor approval gate, not a content failure specific to this change.

One thing worth cleaning up

[suggestion] The diff converts all existing em-dashes (—) to \u2014 across 50+ existing marketplace.json entries. Both are valid JSON, but this creates unnecessary diff noise — the actual change is one new entry and one new file. If your editor or formatter is doing this automatically, consider adding a .editorconfig or Prettier config to lock in the style and run it as a pre-commit hook, so future PRs don't carry this kind of churn. Alternatively, reverting the existing-entry changes before merge would keep the diff tight.

The new marketplace entry (name, source, description, category) matches convention. Ready for merge once the em-dash cleanup is resolved or accepted as-is.