Sr Improve

sr-improve

Goal: produce a candid improvement report — what was deferred, what carries risk, what should be resolved before development starts. Reference specific FR/NFR IDs.

Step 0 — Identify Project

Ask the user: "Which project? (slug)"

Read from projects/{slug}/:

• spec.md (for deferred features and open items)
• srs/appendix-b-open-issues.md (for all [TBD] items)
• srs/03-03-performance.md (for [TBD] NFRs)
• Validator output if available (WARNs from $sr-validate)

Step 1 — Write improvement-report.md

Write projects/{slug}/improvement-report.md. No word limit.

§1 — Deferred Features (Next Version Candidates)

List every feature marked OUT of scope in spec.md that the user mentioned but deferred. For each:

• Feature name
• Why deferred (user's reason from brainstorm, if stated)
• Estimated effort level (low | medium | high) — AI estimate only, not a commitment
• Suggested version: v1.1 | v2.0 | unknown

§2 — Technical Risks

For each unresolved [TBD] in NFRs:

• NFR-ID + description
• What data is needed to set the target
• Risk if unresolved: (A) test cannot be written (B) SLA cannot be committed (C) architecture decision blocked
• Suggested owner + resolve-by milestone

For each external integration in §3.1:

• Integration name + system
• Risk: dependency on third-party uptime / API versioning / rate limits
• Mitigation suggestion

§3 — FR Refinement Suggestions

Identify FRs that are:

• Too broad (combines multiple behaviors that should be separate FRs)
• Missing negative cases (what happens when it FAILS?)
• Missing actor variants (same action, different permission level)

List each with the suggested split or addition.

§4 — NFR Gaps

NFRs with [TBD] Response Measure → list with: what benchmark test would produce the real number. NFRs with adjective-only measure (should have been caught by validator) → rewrite suggestion.

§5 — Validation Warnings

Enumerate every WARN from $sr-validate with:

• Warning text
• Which file/FR/NFR it refers to
• Recommended resolution (specific action, not "review this")
• Urgency: must resolve before dev | should resolve before QA | can defer

§6 — Process Recommendations

Observations about the requirements process itself:

• Rounds where user input was vague → note the topic area for follow-up workshop
• Assumptions that carry high invalidation risk → flag for stakeholder sign-off
• Missing subject-matter expert input (e.g., "no security architect reviewed NFR-02")

Step 2 — Handoff

Output:

Improvement report: projects/{slug}/improvement-report.md

Deferred features:      {count}
Technical risks:        {count}
FR refinement items:    {count}
NFR gaps:               {count}
Validation warnings:    {count}
Process recommendations:{count}

Next: $sr-save → saves project context files for future sessions