Common Software RequirementsSAFE

A collection of Agent Skills Standard and Best Practice for Programming Languages, Frameworks that help our AI Agent follow best practies on frameworks and programming laguages

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: common-software-requirements
description: Standardize SRS and FRS specifications for technical behavior, interfaces, data contracts, quality constraints, and verification mapping. Use when writing SRS, functional specification, system behavior requirements, API/data contracts, or non-functional thresholds.
metadata:
  triggers:
    files:
      - "SRS.md"
      - "docs/srs/srs-*.md"
      - "specs/*.md"
    keywords:
      - create srs
      - software requirements
      - functional specification
      - system behavior spec
      - technical requirements
      - non-functional requirements
---

# Software Requirements Expert

## **Priority: P0 (CRITICAL)**

Define the technical "How" with verifiable requirements.

## 1. SRS/FRS Discovery

- Confirm linked PRD requirements (`REQ-*`) and AC IDs.
- Preserve trace: `BRD-OBJ-* -> REQ-* -> AC-* -> SRS-* -> test evidence`.
- Missing behavioral acceptance criteria, accountable owner, consequential design approval, or verification prerequisites route EVERY affected slice back to requirements/planning regardless of new or existing scope. Bounded low-risk equivalence (approved ticket with behavioral AC, owner, scope fence, approval, verification lane) may replace separate SRS files and formal IDs, but never waives behavioral prerequisites; do not infer product scope from code.
- Define functional flows: trigger, inputs, validations, outputs, errors.
- For complex flows, use one actor, one goal, one session; split normal, alternate, and exception courses.
- Define interface contracts: API, events, storage, external integrations.
- Define NFRs: numeric thresholds where appropriate (latency, availability, scalability) and categorical verifiable invariants where appropriate (security, access control, integrity); never fabricate numbers.
- Define constraints: migration, compatibility, compliance, rollout.

## 2. Drafting Workflow

- Load `references/srs-template.md`.
- **Slug Alignment**: Use the same `[slug]` from the source `docs/prd/prd-[slug].md` to maintain filename-level traceability.
- Write one requirement card per statement with stable `SRS-*` IDs.
- Map each `SRS-*` to source PRD `REQ-*` and verification lane.
- Map every technical behavior to PRD ACs, test lane, and evidence target; one observable behavior per AC with necessary preconditions.
- Include statement, priority, status, input/output/error behavior, NFR impact, measurement method, and evidence target.
- Add outcome report: `feature_status`, requirement trace, completed/missing evidence, decision needed, and recommended next workflow.
- Write to `docs/srs/srs-[slug].md`.

## 3. Verification Mapping

- Each `SRS-*` has test evidence plan (unit/integration/E2E/manual).
- Failure modes and fallback behavior are explicit.
- Permissions and privacy controls mapped to requirements as verifiable categorical invariants.
- Measurement or verification method exists for each NFR.

## Anti-Patterns

- No mixed requirements and implementation tasks in same statement.
- No NFR claims without verifiable criteria: use numeric thresholds where appropriate, categorical invariants for security/access; never fabricate numbers.
- No interface contract without input/output/error schema.
- No requirement without trace link to source and verification.
- No implementation handoff without behavioral ACs and verification lanes mapped to each slice; formal PRD/SRS IDs and separate documents may be replaced only by approved low-risk ticket equivalence (carrying behavioral AC, owner, approval, scope fence, verification lane).
- No happy-path-only flow for complex user/system interactions.

## References

- [SRS Template](references/srs-template.md)
- [FRS Checklist](references/frs-checklist.md)
- [Requirements Baseline](references/standards-baseline.md)

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.