SkillSign Roadmap Context
Domain knowledge for managing the SkillSign product roadmap.
Project Overview
SkillSign is a cryptographic signing and verification system for Claude Code SKILL.md files using Sigstore keyless signing. The spec is at docs/spec.md (v0.1 draft).
Roadmap Structure
The roadmap lives at docs/roadmap.md and maps to GitHub Milestones + Issues.
Phases
- v0.1-mvp (Phase 1): End-to-end sign and verify. 15 deliverables. Exit criteria: one developer signs, another verifies.
- v0.1-hardening (Phase 2): Security, error handling, all verification result codes. 11 deliverables. Exit criteria: all error paths tested.
- v0.1-adoption (Phase 3): Policy engine, CI integration, distribution. 11 deliverables. Exit criteria: org CI pipeline with policy file.
- v0.2-planning (Phase 4): Ecosystem features requiring spec changes. 8 deliverables. Exit criteria: v0.2 spec draft.
Prioritization Criteria
- Who's blocked without this? Everyone = P0, some users = P1, edge cases = P2
- Can we add it later without breaking changes? If yes, defer
- Blast radius of getting it wrong? Crypto/identity = hard to change, CLI flags = moderate, output format = easy
- Does the spec already define it? Section 12 known limitations are pre-triaged
Issue Labels
- Phase:
mvp, hardening, adoption, ecosystem
- Area:
cli, crypto, policy, infra, docs
- Effort:
good-first-issue, needs-design, needs-spec-change
Spec Sections → Deliverables Mapping
| Spec Section |
Phase |
Key Deliverables |
| Section 4 (Identity/OIDC) |
MVP |
Auth flow, Fulcio integration |
| Section 5 (Canonical Form) |
MVP |
Normalizer, digest computation |
| Section 6 (Sidecar) |
MVP |
Reader, writer, strict YAML parsing |
| Section 7 (Signing) |
MVP |
Signing engine, manifest reader |
| Section 8 (Verification) |
MVP + Hardening |
Verification engine, all result codes, SKILL_ID_MISMATCH |
| Section 9 (CLI) |
MVP + Hardening |
Commands, flags, exit codes, multi-file |
| Section 10 (Policies) |
Adoption |
Policy engine, signer_org, max_age_days |
| Section 11 (Security) |
Hardening + Adoption |
--strict, --offline, --emit-canonical, --policy-digest |
| Section 12 (Limitations) |
Ecosystem |
Co-signing, TOFU, registry, NFC normalization |
Known Limitations (from Spec Section 12)
These are pre-triaged by the spec author and deferred to v0.2+:
- M1: Version downgrade attacks → registry-level solution
- M2: Sidecar rollback → registry "latest sidecar" concept
- M3: TOFU / signer pinning → automated trust-on-first-use
- M4: npm distribution → tool integration enforcement points
- M5: GitHub account rename/transfer → timestamp-bounded mitigation
- M11: ASCII lookalike homoglyphs → inherent namespace limitation
- M12: Unicode normalization (NFC/NFD) → v0.2 preprocessing step
1---2name: skillsign-roadmap-context3description: SkillSign Roadmap Context4---5# SkillSign Roadmap Context67Domain knowledge for managing the SkillSign product roadmap.89## Project Overview1011SkillSign is a cryptographic signing and verification system for Claude Code SKILL.md files using Sigstore keyless signing. The spec is at `docs/spec.md` (v0.1 draft).1213## Roadmap Structure1415The roadmap lives at `docs/roadmap.md` and maps to GitHub Milestones + Issues.1617### Phases18191. **v0.1-mvp** (Phase 1): End-to-end sign and verify. 15 deliverables. Exit criteria: one developer signs, another verifies.202. **v0.1-hardening** (Phase 2): Security, error handling, all verification result codes. 11 deliverables. Exit criteria: all error paths tested.213. **v0.1-adoption** (Phase 3): Policy engine, CI integration, distribution. 11 deliverables. Exit criteria: org CI pipeline with policy file.224. **v0.2-planning** (Phase 4): Ecosystem features requiring spec changes. 8 deliverables. Exit criteria: v0.2 spec draft.2324### Prioritization Criteria2526- **Who's blocked without this?** Everyone = P0, some users = P1, edge cases = P227- **Can we add it later without breaking changes?** If yes, defer28- **Blast radius of getting it wrong?** Crypto/identity = hard to change, CLI flags = moderate, output format = easy29- **Does the spec already define it?** Section 12 known limitations are pre-triaged3031### Issue Labels3233- Phase: `mvp`, `hardening`, `adoption`, `ecosystem`34- Area: `cli`, `crypto`, `policy`, `infra`, `docs`35- Effort: `good-first-issue`, `needs-design`, `needs-spec-change`3637## Spec Sections → Deliverables Mapping3839| Spec Section | Phase | Key Deliverables |40|---|---|---|41| Section 4 (Identity/OIDC) | MVP | Auth flow, Fulcio integration |42| Section 5 (Canonical Form) | MVP | Normalizer, digest computation |43| Section 6 (Sidecar) | MVP | Reader, writer, strict YAML parsing |44| Section 7 (Signing) | MVP | Signing engine, manifest reader |45| Section 8 (Verification) | MVP + Hardening | Verification engine, all result codes, SKILL_ID_MISMATCH |46| Section 9 (CLI) | MVP + Hardening | Commands, flags, exit codes, multi-file |47| Section 10 (Policies) | Adoption | Policy engine, signer_org, max_age_days |48| Section 11 (Security) | Hardening + Adoption | --strict, --offline, --emit-canonical, --policy-digest |49| Section 12 (Limitations) | Ecosystem | Co-signing, TOFU, registry, NFC normalization |5051## Known Limitations (from Spec Section 12)5253These are pre-triaged by the spec author and deferred to v0.2+:5455- M1: Version downgrade attacks → registry-level solution56- M2: Sidecar rollback → registry "latest sidecar" concept57- M3: TOFU / signer pinning → automated trust-on-first-use58- M4: npm distribution → tool integration enforcement points59- M5: GitHub account rename/transfer → timestamp-bounded mitigation60- M11: ASCII lookalike homoglyphs → inherent namespace limitation61- M12: Unicode normalization (NFC/NFD) → v0.2 preprocessing step
bruk-io