Kiss Srs

User Input

$ARGUMENTS

Consider the user input before proceeding (if not empty).

Audience and tone (interactive mode)

When KISS_AGENT_MODE=interactive (the default), assume the user has limited technical background and limited domain knowledge — they may know basics but lack deep expertise in this skill's area. Run this skill as a guided questionnaire:

• One question at a time. No walls of questions.
• Yes / no first. Phrase so yes, no, not sure, or skip is a valid answer.
• Translate jargon, don't strip it. Use the technical term but always pair it with a plain-English gloss the first time it appears.
• Choices, not blank fields. When yes/no isn't enough, offer 2-4 lettered options (A/B/C/D) with one-line plain-language descriptions. Always include "Not sure — pick a sensible default".
• Always recommend. State the option you would pick and why in one sentence so the user can reply "yes" / "ok" to accept.
• Show, don't ask. When upstream artefacts already imply an answer, propose it as a pre-filled finding and ask for confirmation.
• not sure / skip triggers a sensible default, marked "(default applied — confirm later)" in the artefact, and a debt entry in srs-debts.md.

When KISS_AGENT_MODE=auto (or --auto), skip the questionnaire entirely: apply sensible defaults from upstream artefacts and log decisions to the parent agent's decision log.

Inputs

• .kiss/context.yml
• {context.paths.specs}/**/spec.md — all feature specifications; if none exist, prompt the user to run kiss-specify first
• {context.paths.docs}/project/project-plan.md — WBS / scope statement (optional but recommended)
• {context.paths.docs}/architecture/intake.md — quality attributes, constraints, NFRs captured during architecture intake (optional)

Outputs

• {context.paths.docs}/analysis/srs.md — the consolidated SRS (primary artefact)
• {context.paths.docs}/analysis/srs.extract — companion KEY=VALUE ledger consumed by downstream skills (SRS_REVISION, LAST_FR_ID, LAST_NFR_ID, BASELINE_DATE)
• {context.paths.docs}/analysis/srs-debts.md — open items the project team must resolve before the SRS is baselined (SRSDEBT-NN: …)

Context Update

Does not mutate .kiss/context.yml.

Handoffs

• kiss-traceability-matrix uses FR-NNN / NFR-NNN identifiers from srs.extract as the requirement column of the RTM.
• kiss-phase-gate reads srs.md as the Requirements gate deliverable.
• kiss-arch-intake may be run before this skill to populate NFRs.
• kiss-test-strategy reads NFRs (performance, security, reliability) from srs.md to determine test tiers.
• kiss-baseline can snapshot srs.md as the requirements baseline.

AI authoring scope

Does:

• Read every spec.md under {context.paths.specs}/.
• Extract and number all functional requirements (FR-NNN) and non-functional requirements (NFR-NNN) in sequential order, preserving the source feature reference.
• Produce a document that conforms to the structure and terminology of IEEE 29148:2018 (formerly IEEE 830).
• Flag missing or ambiguous requirements as SRSDEBT entries.
• Insert a sign-off table (Author, Reviewer, Approver) for the user to populate.

Does not:

• Approve, accept, or baseline the SRS on the user's behalf.
• Invent requirements not traceable to a spec.md source.
• Run any tools, modify code, or touch files outside the output directory without explicit user confirmation.

Outline

1. Gather specs — scan {context.paths.specs}/**/spec.md and list the features found. If none, stop and instruct the user to run /kiss.specify for each feature first.

2. Interactive questionnaire (interactive mode only) — ask: a. SRS document title and project name (default: project name from project-plan.md or context, else ask). b. Intended audience: A) internal team, B) external customer / auditor, C) regulatory body, D) all — affects formality level. c. Revision number (default: 1.0). d. Whether to include a traceability stub section (default: yes). e. Confirm the feature list detected above is complete.

3. Requirement extraction — for each spec:

   • Map each "Functional Requirement" line to a sequentially numbered FR-NNN entry in the SRS.
   • Map each NFR (performance, security, reliability, usability, maintainability, portability, legal/compliance) to NFR-NNN.
   • Record the source spec slug alongside every identifier.

4. Draft SRS — fill templates/srs-template.md with:

   • Cover page: title, project, revision, date, sign-off table.
   • Sections 1–6 per IEEE 29148:2018:
     1. Introduction (purpose, scope, definitions, overview)
     2. Overall description (product perspective, assumptions, dependencies, constraints)
     3. Functional requirements (FR-001 … FR-NNN), each with: priority (MoSCoW), rationale, source spec reference, and acceptance criterion stub.
     4. Non-functional requirements (NFR-001 … NFR-NNN), each with measurable acceptance criterion, rationale, and source spec reference.
     5. External interfaces (UI, API, hardware, communication) sourced from spec "User Scenarios" and architecture intake.
     6. Constraints and assumptions.
   • Appendix: open SRSDEBT entries.

5. Quality check — after drafting, verify:

   • Every FR / NFR has a measurable acceptance criterion.
   • No orphaned requirements (traceable back to a spec).
   • No duplicate IDs.
   • Log any violations as SRSDEBT entries.

6. Write outputs — write srs.md, srs.extract, and srs-debts.md (or append to existing).

7. Summary — print a one-page summary:

   • Total FRs and NFRs.
   • Number of open SRSDEBT entries.
   • Which features have the most requirements (top 3).
   • Next suggested action: run /kiss.traceability-matrix or /kiss.phase-gate.

Usage

<SKILL_DIR> = the integration's skills root (e.g. .claude/skills/ for Claude Code, .agents/skills/ for other agents).

SRS_TITLE="Acme Payments Platform SRS" \
SRS_REVISION="1.0" \
SRS_AUDIENCE="internal" \
  bash <SKILL_DIR>/kiss-srs/scripts/bash/draft-srs.sh --auto

Answer keys