feat: add skill signature verification

[elliotllliu]

Summary

Implements #617

Adds optional signature verification for installed skills, protecting users from tampered or malicious SKILL.md content.

New Command

# Verify all installed skills
npx skills verify

# Verify specific skills
npx skills verify web-design

# Output example
  ✓ web-design (Verified, signed by skills.sh, 2026-03-14T10:00:00Z)
  ○ my-custom-skill (No signature)
  ✗ suspicious-skill (Content tampered — hash mismatch)

Results: 1 verified, 1 unsigned, 1 failed

Architecture

Signature Block (in SKILL.md frontmatter)

signature:
  algorithm: ed25519-sha256
  signer: skills.sh
  content_hash: sha256:a1b2c3d4...
  signed_at: 2026-03-14T10:00:00Z
  sig: <base64-encoded-signature>
  kid: key-2026-01  # optional, for key rotation

Verification Pipeline

1. Parse signature block from YAML frontmatter
2. Hash content below frontmatter (SHA-256)
3. Compare computed hash against content_hash
4. Fetch signer's public key from https://{signer}/.well-known/skills-pubkey
5. Verify ed25519 signature

Key Management

• Public keys fetched from .well-known/skills-pubkey endpoint (federated trust model)
• Local key cache with 1-hour TTL (~/.agents/.key-cache/)
• Key rotation via kid field matching
• Expired keys automatically skipped

Design Decisions

• Backward compatible — skills without signatures work normally
• Federated trust — any domain can be a signer (skills.sh, skills.mycompany.io, etc.)
• Content-only signing — only content below frontmatter is signed (metadata changes don't break signatures)
• ed25519 — modern, fast, small keys/signatures

Changes

• src/signature.ts — Core verification module (parsing, hashing, key management, verification)
• src/cli.ts — skills verify command with filtering and result display
• tests/signature.test.ts — 13 tests covering parsing, hashing, and formatting

Testing

• pnpm build ✅
• pnpm test ✅ (388/388 tests pass, +13 new)

[fanqi1909]

Thanks for implementing #617 so quickly, @elliotllliu ! 🎉

Great to see the design translated into working code. Skimmed through the PR and the implementation looks solid:

✅ Federated trust model with .well-known/skills-pubkey
✅ kid field for key rotation (good catch from your earlier comment)
✅ Local key cache with TTL
✅ Content-only signing (metadata changes don't break signatures)

A few thoughts for future iterations (not blocking this PR):

1. Revocation endpoint — As you mentioned earlier, a companion .well-known/skills-revoked endpoint would be useful for compromised keys/skills
2. Strict mode — npx skills add --require-signature to reject unsigned skills entirely (for security-conscious users)

Happy to help review or iterate. Let's see what the maintainers think!

[elliotllliu]

Thanks for the thorough review @fanqi1909! Glad the implementation aligns with your RFC vision. The federated model is designed to be extensible — once this lands, adding new registry endpoints should be straightforward.

Looking forward to seeing this move forward!