Launch Registry
Track launch stages, dates, embargoes, submissions, and outcomes with provenance.
The skill explicitly requires user authorization, the current revision, host capability, append-only events, source evidence, and provenance; it forbids deletion, truncation, stream editing, and placing capabilities in request data or logs. README.md and SECURITY.md additionally describe bound authority, fail-closed behavior, auditing, and non-persistence of keys. Four points are deducted because the registry runtime, schema, protocol implementation, and recovery path were not supplied for independent verification; publisher identity is unverified.
The workflow is internally coherent and specifies runtime/schema/catalog checks, optimistic revision control, verify launches, and a pending-only fallback when runtime capability is unavailable. Two points are deducted because the key scripts, event protocol, and projection implementation were not provided and nothing was executed; under static calibration the score cannot exceed 10.
Triggers, read/write scope, excluded planning and RAMP responsibilities, input types, and handoff skills are clearly stated; Chinese naming is present and Claude Code-compatible hosts are named. Four points are deducted because standalone installs cannot claim canonical state, host-capability requirements are not fully operationally described, and actual Chinese interaction plus mainland-China reachability are not established.
Front matter, version 18.0.0, Apache-2.0 licensing, Quick Start, Skill Contract, Data Sources, Instructions, Handoff Summary, and Next Best Skill are well structured, with linked reference and repository security/test material. Five points are deducted because this material does not show skill-specific FAQs, changelog detail, a named maintenance owner, or a clear update path; author and homepage metadata exist, but publisher provenance is unverified.
The objective and done conditions are explicit and cover registration, querying, stage transitions, date/embargo conflicts, submission proposals, manifests, and outcomes, with revision, event IDs, provenance, and projection status as outputs. One point is deducted because no runtime or representative registration/query flow was executed, so directly usable final dossier/calendar output cannot be confirmed; static calibration limits this dimension to 7.
The skill requires event IDs, provenance, revisions, and projection verification, and repository tests demonstrate some architecture and audit validation. Two points are deducted because the supplied tests do not cover launch-registry write paths, state transitions, conflict handling, or projection rebuilds, and no third-party execution evidence is present; the conclusion therefore relies mainly on author documentation.
- Do not treat request actor fields as authorization; canonical accept, reject, upsert, and transition operations require a verifiable host capability.
- The registry runtime, event schema, and referenced materials were not supplied; confirm the root, scripts, catalog, locking, and projection checks before use.
- A standalone single-folder install cannot claim canonical launch state; without capability or verified runtime, proposals should remain pending and the skill must not report readiness.
- No tests were executed in this review; date/embargo conflicts, state transitions, projection rebuilds, and recovery behavior still require controlled validation.
What does this skill do, and when should you use it?
Launch Registry is a structured record-keeping skill for marketing launches. It maintains stage, date, embargo, submission, manifest-version, and outcome facts for a launch aggregate. Facts are stored in an append-only launches event stream, with optimistic revisions and regenerated dossier and calendar views. It does not plan launches or issue RAMP readiness verdicts.
Reads the launches event stream, live projection, decision evidence, and approved source records; answers factual queries with the current revision, state, dates, sources, and history; appends authorized owner events through registry-events.py for upserts, stage transitions, submissions, manifests, and outcomes; reviews pending launch-day submission proposals; regenerates per-launch dossiers and calendar.md from the accepted projection; and runs verify launches.
- A marketing lead needs the current stage and evidence for a product launch.
- A team must record a beta-to-general-availability transition at an expected revision.
- A launch team needs to register an authoritative date, embargo commitment, or channel submission.
- An operations owner must review launch-day submission proposals without deleting their history.
- A team needs to record the asset-manifest version and a post-lag outcome snapshot after launch.
What are this skill's strengths and limitations?
- Preserves launch facts and history in an append-only event stream.
- Captures event IDs, provenance, and revisions for traceable dates, embargoes, and stage changes.
- Separates canonical projections from replaceable dossier and calendar views.
- Clearly separates factual registration from launch planning and RAMP auditing.
- Depends on a verified repository root, event schema, system catalog, and registry-events.py runtime.
- Requires an authorized launch-registry host capability to accept, reject, or upsert events.
- A standalone one-folder installation cannot append or project canonical launch state.
- The source identifies Claude Code and compatible hosts but provides no independent test report for this skill.
How do you install this skill?
Install the repository on an Agent Skills-compatible host. In Claude Code, run /plugin marketplace add aaron-he-zhu/aaron-marketing-skills, then /plugin install aaron-marketing@aaron. On a generic compatible host, run npx skills add aaron-he-zhu/aaron-marketing-skills. This skill is located at protocol/launch-registry/SKILL.md.
How do you use this skill?
Provide a launch aggregate ID and an operation, such as Register launch widget-2 with tier/type/stage/date/access model and source evidence., Transition widget-2 from beta to general-availability at revision 4., or a request to review pending launch-day submission proposals. Persistent writes require explicit authorization, the current revision, and the host capability; if the verified root, script, event schema, or system catalog is unavailable, proposals remain pending.