Menu
Use to write focused implementation SPEC slices for UI, API, data, admin, permissions, directory, observability, or release.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use only when the user explicitly invokes this skill to map unresolved product, domain, repository, or delivery unknowns before choosing a path.
Use only when the user explicitly invokes this skill to create or resume a persistent file-based goal tracker across sessions.
Use only when the user explicitly invokes this skill to stress-test an existing plan or design through one load-bearing question at a time.
Use only when the user explicitly invokes this skill to evaluate a skill with representative cases, isolated runs, independent judging, and evidence-driven edits.
Use for a concrete defect or regression that needs reproduction, root-cause diagnosis, a fix, and regression validation. Do not trigger for routine localized edits or primarily performance-focused work.
Use when the requested feature genuinely spans at least two delivery layers such as frontend, backend, API, data, scripts, or tests. Do not expand a single-layer change into a full-stack workflow.
| name | sdlc-spec-slice-writer |
| description | Use to write focused implementation SPEC slices for UI, API, data, admin, permissions, directory, observability, or release. |
| metadata | {"version":"0.5","updated":"2026-07-26"} |
Use this workflow when a requirement must be turned into one or more implementation-facing specification slices.
A SPEC slice is a narrow contract for one technical or product surface. It should be precise enough for dev agents to implement and validate, while remaining owned by the SDLC manager as a requirements artifact.
sdlc-nfr-spec.sdlc-hld-workflow.sdlc-lld-workflow.$codex-next:sdlc-solution-spec-workflow.sdlc-dev-handoff-planning.Use the strongest available inputs:
If inputs conflict, record the conflict and identify the controlling source.
Choose only the slices required by the delivery profile and risk.
| Slice | Use for |
|---|---|
| UI SPEC | screens, components, states, copy, interactions, accessibility, responsive behavior |
| API SPEC | endpoints, payloads, auth, errors, idempotency, compatibility, rate limits |
| Data SPEC | fields, schema, lifecycle, retention, migration, import/export, data quality |
| Admin SPEC | admin workflows, support actions, moderation, operational controls |
| Permission SPEC | roles, visibility, access rules, ownership, tenant boundaries |
| Directory SPEC | module boundaries, file organization, package layout, naming constraints |
| Observability SPEC | events, logs, metrics, traces, alerts, audit events, dashboards |
| Release SPEC | rollout, feature flags, migration, rollback, app store or deployment notes |
| Copy SPEC | product copy, empty/loading/error/success/warning states, localization notes |
| Integration SPEC | external services, webhooks, partner APIs, sync behavior, failure modes |
Create a slice routing table:
| Requirement / source | Required slice | Reason | Priority | Blocks dev? |
|---|
Do not create slices that are not needed. Each slice should have an implementation or validation purpose.
Use stable IDs:
| Prefix | Slice |
|---|---|
UI | UI SPEC |
API | API SPEC |
DATA | Data SPEC |
ADMIN | Admin SPEC |
PERM | Permission SPEC |
DIR | Directory SPEC |
OBS | Observability SPEC |
REL | Release SPEC |
COPY | Copy SPEC |
INT | Integration SPEC |
Example:
UI-001
API-001
DATA-001
PERM-001
Use this structure:
## UI-001: <Screen / flow / component>
- Source REQ / VAL IDs:
- User goal:
- Entry points:
- Exit points:
- Screens / components:
- Primary flow:
- Alternate flows:
- State requirements:
- Field requirements:
- Copy requirements:
- Accessibility requirements:
- Responsive / platform behavior:
- Analytics / events:
- Acceptance criteria:
- Open questions:
State coverage table:
| State | Trigger | UI behavior | Copy | User action | System action |
|---|
Required UI states when relevant:
initial
empty
loading
success
failure
validation error
permission denied
offline / timeout
conflict / duplicate
disabled / unavailable
Use this structure:
## API-001: <API contract>
- Source REQ / VAL IDs:
- Related HLD / domain owner:
- Purpose:
- Actor / client:
- Method and path:
- Authentication:
- Authorization:
- Request headers:
- Request body:
- Response body:
- Error responses:
- Idempotency:
- Rate limits:
- Compatibility:
- Observability:
- Acceptance criteria:
- Open questions:
Request / response table:
| Field | Type | Required | Validation | Notes |
|---|
Error table:
| Code | Condition | User/system meaning | Retryable? | Logging |
|---|
Do not define implementation framework or internal storage unless required by an approved constraint. Do not invent API ownership or cross-module dependency direction when HLD or Domain Boundary Map is missing; mark the owner or boundary as a decision-needed gap.
Use this structure:
## DATA-001: <Data object / dataset / event>
- Source REQ / VAL IDs:
- Related Domain Boundary / data owner:
- Related NFR / migration constraint:
- Data owner:
- Entity / table / document / event:
- Fields:
- Lifecycle:
- Retention:
- Privacy classification:
- Migration needs:
- Import/export:
- Data quality rules:
- Backfill or reconciliation:
- Acceptance criteria:
- Open questions:
Field table:
| Field | Type | Required | Default | Constraints | Retention | Privacy note |
|---|
Data lifecycle table:
| Event | State before | State after | Actor/system | Audit/log note |
|---|
Use this structure:
## ADMIN-001: <Admin workflow>
- Source REQ / VAL IDs:
- Admin roles:
- User/customer impact:
- Admin actions:
- Required confirmation:
- Audit log:
- Error handling:
- Abuse prevention:
- Support escalation:
- Acceptance criteria:
- Open questions:
Admin actions table:
| Action | Role | Preconditions | Result | Audit event | Reversible? |
|---|
Use this structure:
## PERM-001: <Permission area>
- Source REQ / VAL IDs:
- Related Domain Boundary:
- Related Security / Privacy NFR:
- Role model:
- Resource ownership:
- Visibility rules:
- Action rules:
- Tenant/account boundaries:
- Delegation rules:
- Audit requirements:
- Acceptance criteria:
- Open questions:
Permission matrix:
| Role / actor | View | Create | Edit | Delete | Export | Admin | Notes |
|---|
Use this structure:
## DIR-001: <Directory / module boundary>
- Source REQ / VAL IDs:
- Related HLD:
- Related LLD:
- Related Domain Boundary:
- Related ADR:
- Target repository or package:
- Existing convention:
- Proposed module boundary:
- Files or directories in scope:
- Files or directories out of scope:
- Naming constraints:
- Import / dependency constraints:
- Allowed dependencies:
- Forbidden dependencies:
- Migration notes:
- Acceptance criteria:
- Open questions:
Directory SPEC should constrain organization only when it reduces implementation ambiguity or protects existing architecture. It must reference HLD, LLD, Domain Boundary Map, ADR, modular-monolith guidance, or repository evidence when those materials exist. Do not invent a repository structure, module ownership, or dependency direction without evidence.
Use this structure:
## OBS-001: <Observability area>
- Source REQ / NFR / VAL IDs:
- User or business risk:
- Events:
- Logs:
- Metrics:
- Traces:
- Alerts:
- Dashboard:
- Audit trail:
- Retention:
- Acceptance criteria:
- Open questions:
Event table:
| Event | Trigger | Properties | Purpose | Privacy note |
|---|
Metric table:
| Metric | Type | Target / threshold | Dimension | Owner |
|---|
Use this structure:
## REL-001: <Release / rollout>
- Source REQ / NFR / VAL IDs:
- Release target:
- Feature flag:
- Migration requirement:
- Rollout stages:
- Beta / dogfood:
- Monitoring:
- Rollback:
- Support readiness:
- App store / platform notes:
- Acceptance criteria:
- Open questions:
Rollout table:
| Stage | Audience | Entry criteria | Exit criteria | Rollback condition |
|---|
For each slice, add:
| Slice ID | Source REQ IDs | NFR / ARCH / DOM IDs | VAL IDs | Task candidate |
|---|
If two slices conflict, do not resolve silently. Record the conflict and the owner or decision needed.
When slices depend on architecture or domain ownership, cross-link them to related HLD, LLD, ADR, Domain Boundary Map, or Directory SPEC IDs.
Return or write one or more SPEC slices.
Recommended file names:
ui-spec.md
api-spec.md
data-spec.md
admin-spec.md
permission-spec.md
directory-spec.md
observability-spec.md
release-spec.md
copy-spec.md
integration-spec.md
When writing a combined document, use:
# SPEC Slices: <Feature / System>
## 1. Slice Routing
## 2. UI SPEC
## 3. API SPEC
## 4. Data SPEC
## 5. Admin SPEC
## 6. Permission SPEC
## 7. Directory SPEC
## 8. Observability SPEC
## 9. Release SPEC
## 10. Cross-slice Traceability
## 11. Open Questions
Before calling slices ready:
sdlc-dev-handoff-planning.Recommend the smallest next step. For an explicit-control workflow, return its
exact $codex-next:<skill-name> command and stop; do not begin it here.
Route downstream:
| Need | Next skill |
|---|---|
| software requirement normalization | sdlc-srs-workflow |
| measurable quality constraints | sdlc-nfr-spec |
| standalone HLD | sdlc-hld-workflow |
| standalone LLD | sdlc-lld-workflow |
| domain ownership or boundary map | sdlc-domain-boundary-modeling |
| modular monolith directory/dependency structure | sdlc-modular-monolith-architecture |
| solution package coordination | $codex-next:sdlc-solution-spec-workflow |
| implementation task package | sdlc-dev-handoff-planning |
| traceability matrix | sdlc-requirements-traceability |
| readiness judgment | $codex-next:sdlc-readiness-review |
For dev handoff, provide: