Starlight Spec
Purpose
Create an executable specification before code when the cost of ambiguity is greater than the cost of writing the contract.
When it fires
- A feature spans more than one component or repository.
- Inputs, outputs, states, permissions, or failure behavior are unclear.
- The user asks for a PRD, technical design, or implementation plan.
Inputs
- User outcome, audience, and decision owner.
- Existing architecture, conventions, and repository instructions.
- In-scope and out-of-scope behavior.
- Data sensitivity, runtime targets, compatibility, and delivery constraints.
Workflow
- Define the user-visible outcome and measurable acceptance criteria.
- Record non-goals, assumptions, unknowns, and authority boundaries.
- Map existing components and identify the smallest required change surface.
- Specify data shapes, state transitions, APIs, errors, and compatibility behavior.
- Decompose work by dependency and verification boundary, not an arbitrary line count.
- Define tests, preview checks, observability, rollback, migration, and promotion gates.
- Mark any unresolved choice that would materially change the design for human decision.
Output contract
Return a specification containing:
- problem and user outcome;
- scope and non-goals;
- current-state evidence;
- functional and non-functional requirements;
- data, API, state, trust, and compatibility contracts;
- ordered implementation tasks with ownership;
- acceptance tests and manual verification;
- rollout, rollback, and migration plan;
- open decisions and human gates.
Tools & MCP
Read the repository and its local instructions before naming files or commands. Browse primary documentation when an external API or current standard is involved. Use read-only inspection by default.
Quality bar
- File and symbol references exist.
- Requirements are testable and do not smuggle in a preferred implementation.
- Failure, empty, loading, offline, and permission states are considered where relevant.
- No invented APIs, versions, metrics, or approvals.
- A different implementer can execute the spec without guessing the intent.
Example
Input: “Let customers install one department on Codex and Claude.”
Good output: separate package, host adapter, installation, verification, rollback, and publication contracts, with marketplace approval and credentials explicitly outside autonomous authority.
Built on SIP — Starlight Intelligence Protocol
Vertical: starlight-agent-skills · portable capability layer
1---2name: starlight-spec3description: Convert an approved product intent into a backlog-ready specification with boundaries, contracts, tasks, verification, rollback, and human approval points. Use when requirements are ambiguous, multiple components must change, or implementation needs a durable handoff.4---56# Starlight Spec78## Purpose910Create an executable specification before code when the cost of ambiguity is greater than the cost of writing the contract.1112## When it fires1314- A feature spans more than one component or repository.15- Inputs, outputs, states, permissions, or failure behavior are unclear.16- The user asks for a PRD, technical design, or implementation plan.1718## Inputs1920- User outcome, audience, and decision owner.21- Existing architecture, conventions, and repository instructions.22- In-scope and out-of-scope behavior.23- Data sensitivity, runtime targets, compatibility, and delivery constraints.2425## Workflow26271. Define the user-visible outcome and measurable acceptance criteria.282. Record non-goals, assumptions, unknowns, and authority boundaries.293. Map existing components and identify the smallest required change surface.304. Specify data shapes, state transitions, APIs, errors, and compatibility behavior.315. Decompose work by dependency and verification boundary, not an arbitrary line count.326. Define tests, preview checks, observability, rollback, migration, and promotion gates.337. Mark any unresolved choice that would materially change the design for human decision.3435## Output contract3637Return a specification containing:3839- problem and user outcome;40- scope and non-goals;41- current-state evidence;42- functional and non-functional requirements;43- data, API, state, trust, and compatibility contracts;44- ordered implementation tasks with ownership;45- acceptance tests and manual verification;46- rollout, rollback, and migration plan;47- open decisions and human gates.4849## Tools & MCP5051Read the repository and its local instructions before naming files or commands. Browse primary documentation when an external API or current standard is involved. Use read-only inspection by default.5253## Quality bar5455- File and symbol references exist.56- Requirements are testable and do not smuggle in a preferred implementation.57- Failure, empty, loading, offline, and permission states are considered where relevant.58- No invented APIs, versions, metrics, or approvals.59- A different implementer can execute the spec without guessing the intent.6061## Example6263Input: “Let customers install one department on Codex and Claude.”6465Good output: separate package, host adapter, installation, verification, rollback, and publication contracts, with marketplace approval and credentials explicitly outside autonomous authority.6667---6869Built on SIP — Starlight Intelligence Protocol70Vertical: starlight-agent-skills · portable capability layer
frankxai