lcs-tosrs

LCS ToSRS Skill

Shared Coding Contract

• Refer to Shared Coding Workflow Contract in ../lcs-shared/contract.md for folder conventions, Handoff format, and token optimization.

Purpose

• Transform prd-enhanced.md when present, otherwise prd.md, into deterministic Lean SRS artifacts optimized for AI implementation and QA.
• Reduce ambiguity, hallucination, and inconsistent implementation.
• Keep output lightweight, markdown-first, traceable, and implementation-ready.

Trigger

• Activate when user requests PRD-to-SRS transformation, implementation specification, requirement traceability, acceptance criteria normalization, or deterministic engineering contract.

Do not overlap with other skills

• Do not generate granular execution files task/task-###.md.
• If user asks to slice execution tasks, handoff to lcs-task-slicer.
• lcs-tosrs owns: srs.md, tests.md, optional api.md, optional db.md.

Input and output location

• Work item folder: .lcs/work-items/{timestamp}-{slug-work-item}/
• Preserve existing prd.md.
• Generate or overwrite:
  • srs.md (required)
  • tests.md (required)
  • api.md (optional, only when API changes are relevant)
  • db.md (optional, only when DB changes are relevant)

OKF Frontmatter & Writing Safety

• All 5 output types (srs.md, api.md, db.md, tests.md, traceability.md) MUST include YAML frontmatter following the schema in ../lcs-shared/contract.md.
• Follow the Artifact Writing Safety rules in contract.md.
• One-file-per-step write strategy: After generating all SRS content, write one file per step in this order: srs.md → api.md → db.md → tests.md → traceability.md. Do not write more than one file per response.
• Generate the complete content for all artifacts in planning, then write exactly one file per subsequent response.

Trigger

Activate when user requests related to this skill's purpose. See description field in YAML frontmatter for trigger phrases.

Behavior checklist

1. Read .lcs/state.md first when continuing existing work.

2. Read source bundle in order:

   1. .lcs/state.md
   2. prd-enhanced.md if present
   3. prd.md as baseline (fallback if no prd-enhanced exists)

   If prd-enhanced.md exists but not read, stop and report source conflict. Do not generate SRS from prd.md alone when enhanced PRD exists.

3. Extract from the authoritative PRD and Source Requirement Ledger:

   • features
   • business goals
   • user roles
   • business rules
   • SRC-### source IDs and priorities

4. Generate deterministic requirement sets:

   • functional requirements
   • validation rules
   • edge cases
   • acceptance criteria

5. Draft API contract details when API behavior exists.

6. Draft DB impact details when schema/persistence changes exist.

7. Build traceability mapping across source IDs, requirement families, acceptance criteria, and tests.

8. Generate traceability.md mapping SRC-* -> REQ/FR/BR/VR/EC -> AC-* -> TEST-*.

9. Update .lcs/state.md with:

   • current_phase: srs
   • work_items[state.current_work].phase = srs
   • work_items[state.current_work].updated_at = <current-ISO-timestamp>
   • timestamp: <current-ISO-timestamp>
   • last_session_note: Generated SRS artifacts for <work-name>

10. Produce stable markdown output with repeated structure.

Requirement design rules

• Every requirement must be atomic, deterministic, testable, and implementation-oriented.
• Avoid vague words like "properly", "fast enough", "secure enough".
• Use measurable and verifiable statements.

ID policy (mandatory)

• Use 3-digit sequential IDs per category:
  • FR-001
  • BR-001
  • VR-001
  • EC-001
  • API-001
  • DB-001
  • AC-001
  • TEST-001
• Keep numbering stable and deterministic in regeneration.

Deterministic regeneration rules

• Overwrite target file content, do not append ad-hoc sections.
• Keep heading order fixed.
• Keep template shape fixed.
• Keep wording concise and implementation-focused.

SRS.md required structure

Work Item Overview System Overview User Roles Functional Requirements Business Rules Validation Rules Edge Cases Non Functional Requirements API Contracts User Stories

(Preserved from prd.md if present)

Testing Seams

(Preserved from prd-enhanced.md if present — test seams indicate where to inject test doubles for isolated unit testing)

Acceptance Criteria Requirement Traceability

Functional requirement template (exact)

## FR-001 <Requirement Name>

### Description
Short deterministic description.

### Inputs
- input_1
- input_2

### Process
1. Step one
2. Step two
3. Step three

### Outputs
- output_1
- output_2

### Validation
- rule_1
- rule_2

### Edge Cases
- edge_case_1
- edge_case_2

### Acceptance Criteria
- AC-001
- AC-002

Business rule template

## BR-001 <Rule Name>

Description:
Explicit business constraint.

Impact:
Affected features/modules.

Validation rule template

## VR-001 <Validation Name>

Condition:
Validation condition.

Error Response:
Expected rejection behavior.

Edge case template

## EC-001 <Edge Case Name>

Scenario:
Failure or unexpected scenario.

Expected Behavior:
How system must respond.

Acceptance criteria template

## AC-001 <Acceptance Name>

Given:
<precondition>

When:
<action>

Then:
<expected result>

NFR template

## Performance
- API response under 300ms for P95 baseline.
- Support defined concurrent load target from PRD.

## Security
- Authentication and authorization constraints are explicit.
- Sensitive endpoints have abuse controls (for example rate limiting).

## Reliability
- Error handling path defined for all critical flows.
- Retries/idempotency rules defined where relevant.

## Scalability
- Scale constraints and bottleneck assumptions are explicit.
- Horizontal/vertical scaling expectation is stated.

API contract template (for srs.md and/or api.md)

## API-001 <Endpoint Name>

Method:
POST

Route:
/api/example

Request:
```json
{
  "field": "string"
}
```

Response:
```json
{
  "result": "string"
}
```

Errors:
- error_code_1
- error_code_2

DB impact template (for srs.md and/or db.md)

## DB-001 <Table Name>

| field | type | notes |
|---|---|---|
| id | bigint | primary key |
| created_at | timestamp | |

tests.md required content

• Test scenarios grouped by feature/module.
• Coverage matrix mapping TEST-### to related IDs.
• Each test must include:
  • Covers
  • Type
  • Preconditions
  • Steps
  • Expected

tests.md template

# Test Plan

## Coverage Matrix

| Test ID | Covers | Type | Priority |
|---|---|---|---|
| TEST-001 | AC-001, FR-001 | integration | P0 |

## <Feature Name>

### TEST-001 <Test Name>

Covers:
- AC-001
- FR-001

Type:
- integration

Preconditions:
- precondition_1

Steps:
1. step_1
2. step_2

Expected:
- expected_1
- expected_2

Traceability rules

• Every SRC-### from the Source Requirement Ledger must map to at least one downstream ID or appear under unresolved sources with reason.
• Every FR must map to at least one AC.
• Every AC must map to at least one TEST.
• Requirement Traceability section must include cross-reference matrix:
  • SRC -> FR/BR/VR/EC/API/DB/AC/TEST

traceability.md required content

# Traceability Matrix

| SRC ID | FR | BR | VR | EC | API | DB | AC | TEST | Status |
|---|---|---|---|---|---|---|---|---|---|
| SRC-001 | FR-001 | - | - | - | - | - | AC-001 | TEST-001 | covered |
| SRC-002 | FR-002 | BR-001 | - | - | - | - | AC-002 | TEST-002 | covered |

## Unresolved Sources

- SRC-003: <reason not yet decomposed>

Writing style

• Concise.
• Structured.
• Technical.
• Repetitive section pattern.
• Minimal prose.
• Markdown-only.

Handoff (mandatory footer in every generated artifact)

## Chain of Truth Report
### Level
Strict

### Sources Checked
- `.lcs/state.md`
- `.lcs/work-items/{timestamp}-{slug-work-item}/prd.md`
- <additional references with line numbers>

### Assumptions
- <label each [verified] or [unverified]>

### Plan
<Enumerated steps>

### Actions Taken
<Per-step record>

### Verification
<Automated checks attempted; document every failure>

### Report
<Explicit pass/fail per acceptance criterion>

## Handoff

Next recommended skill: lcs-task-slicer
Next file to read: .lcs/work-items/{timestamp}-{slug-work-item}/srs.md
Current phase: srs
Current confidence: <low/medium/high>
Blocking questions: <list or None>
Risks to carry forward: <short>
Source of Truth Bundle: .lcs/state.md, prd-enhanced.md if present, prd.md, srs.md, tests.md, traceability.md
Must Preserve IDs: SRC-001, SRC-002, FR-001, AC-001, TEST-001, ...
Unresolved IDs: <list or None>
Suggested next command: Slice srs.md into task/task-###.md with strict requirement references

Chain of Truth Level

Level: Strict

This skill follows the LCS Chain of Truth protocol at the declared level.