peterbamuhigire/srs-skills - Page 2

08-requirements-management

Use when baselining requirements and controlling changes, versions, decisions, and impact after requirements exist; use requirements-validation before accepting content into a baseline.

09-traceability-engineering

Use when establishing forward and backward links among goals, requirements, design, code, tests, and evidence; use traceability-matrix for the governance roll-up artefact.

10-requirements-metrics

Use when measuring requirement quality and enforcing quantitative gates for ambiguity, completeness, traceability, volatility, and testability; use requirements-validation for content review.

11-requirements-reuse

Use when curating approved reusable requirement patterns and product-line variants after a stable baseline exists; use requirements-patterns to structure one project's complex behaviour.

12-solution-evaluation-and-transition

Use when planning adoption, readiness, go/no-go evidence, transition, and post-implementation outcome evaluation; use go-live-readiness for the release-day operational gate.

01-stakeholder-analysis

Use when identifying and classifying stakeholders, influence, interests, decision rights, and communication needs before elicitation; use elicitation-toolkit to gather requirements from them.

02-elicitation-toolkit

Use when selecting and conducting interviews, workshops, observation, surveys, document analysis, or prototypes to gather requirements; use stakeholder-analysis to identify participants first.

03-brd-generation

Use when a Business Requirements Document is needed to bridge strategy and detailed requirements; use prd-generation for product scope and user value, or initialize-srs for formal system specification.

04-business-analysis-planning

Use when defining business-analysis governance, decision rights, stakeholder engagement, cadence, artefact plan, and change approach before detailed work; use stakeholder-analysis for the stakeholder register.

04-requirements-analysis

Use when classifying, reconciling, prioritising, and testing the feasibility of elicited requirements; use requirements-validation for the independent pre-baseline review.

05-conceptual-data-modeling

Use when translating business language into conceptual entities, relationships, identifiers, ownership, and invariants before logical database design; use database-design for physical schema decisions.

06-requirements-patterns

Use when expressing complex behaviour with decision tables, state transitions, CRUD matrices, or requirement patterns; use business-rules-analysis to establish the policy content first.

08-business-process-modeling

Use when modelling as-is and to-be workflows, actors, handoffs, controls, events, and exceptions to expose requirements; use service-blueprint-requirements for frontstage/backstage service delivery.

09-business-rules-analysis

Use when capturing and reconciling policies, calculations, eligibility, decisions, constraints, ownership, and effective dates; use requirements-patterns to express the approved behaviour structurally.

11-experience-mapping-requirements

Use when converting customer, employee, stakeholder, or ecosystem journeys into traceable requirements across touchpoints, pain points, evidence, and future states; use service-blueprint-requirements for backstage delivery detail.

12-service-blueprint-requirements

Use when turning a service blueprint into requirements for frontstage UX, backstage operations, support, evidence, handoffs, failures, and recovery; use experience-mapping-requirements for the journey view.

hybrid-synchronization

Use when synchronising a Water-Scrum-Fall project so Agile backlog items, DoR/DoD, and delivery evidence remain tied to the approved baseline; use requirements-management for baseline change control itself.

retail-operating-model-srs

Use when specifying retail, omnichannel, POS, merchandising, pricing, promotions, fulfilment, returns, shrink, loyalty, vendor funding, or store operations; use embedded-accounting-engine-srs for the shared ledger core.

01-initialize-srs

Use when creating the Waterfall SRS workspace, selecting the specification structure, and establishing identifiers and source context; use context-engineering after initialisation to model boundaries and actors.

02-context-engineering

Use when defining the system boundary, actors, external systems, interfaces, assumptions, and context after an SRS workspace exists; use descriptive-modeling for detailed behavioural views.

03-descriptive-modeling

Use when modelling requirement behaviour with scenarios, flows, states, activities, and domain views after the system context is known; use logic-modeling for formal decision logic.

04-interface-specification

Use when specifying system-level user, software, hardware, communication, and external interfaces in the SRS; use api-specification for an implementation-ready OpenAPI contract.

05-feature-decomposition

Use when decomposing approved scope into traceable capabilities, features, subfeatures, and atomic requirements; use user-story-generation for Agile backlog phrasing.

06-logic-modeling

Use when formalising decisions, calculations, state transitions, constraints, and exception logic for Waterfall requirements; use descriptive-modeling for narrative flows and views.

07-attribute-mapping

Use when assigning priority, source, rationale, risk, stability, verification method, owner, and other governed attributes to requirements; use traceability-engineering for lifecycle links.

08-semantic-auditing

Use when performing a read-only semantic audit for ambiguity, contradiction, undefined terms, weak modals, and inconsistent requirement language; use requirements-validation for the full multidisciplinary gate.

09-use-case-modeling

Use when specifying actor-goal use cases with preconditions, main flow, alternatives, exceptions, postconditions, and trace links; use user-story-generation for Agile backlog items.

01-high-level-design

Use when approved requirements need a system-level architecture with boundaries, components, critical flows, deployment topology and ADRs; use system-overview for stakeholder orientation, low-level-design for module internals, and infrastructure-design for…

02-low-level-design

Use when an approved HLD needs implementation-ready module, class, sequence, state, algorithm and error contracts; use high-level-design for system boundaries, api-specification for external APIs, and database-design for persistence structures.

03-api-specification

Use when approved behaviours must become a versioned external or service API contract with operations, schemas, authentication, errors, idempotency and OpenAPI evidence; use HLD for service boundaries and LLD for internal implementation.

04-database-design

Use when approved requirements and access patterns need an entity model, normalised schema, keys, constraints, indexes, tenancy, retention and migration plan; use HLD for ownership and accounting-engine-design for ledger invariants.

05-ux-specification

Use when approved user journeys need testable information architecture, interaction patterns, states, accessibility, design-system rules, usability evidence and handoff specifications; use UX content and form specification for copy and validation detail.

06-infrastructure-design

Use when a scored decision gate shows that availability, scale, distributed deployment, security or recovery needs infrastructure design beyond the HLD; use HLD for logical architecture and deployment planning for release execution.

07-iot-system-design

Use when approved requirements involve devices, sensors, gateways, edge processing or operational technology and need end-to-end connectivity, identity, lifecycle, safety and fleet operations; use HLD for the wider system context.

08-engineering-strategy-brief

Use when major HLD, platform, SaaS, AI, public-sector or modernisation work needs a concise diagnosis, guiding policies, operating mechanisms, ADR agenda and implementation sequence; use HLD after strategy choices are approved.

09-ux-content-and-form-specification

Use when a UX specification needs testable labels, microcopy, forms, validation, errors, empty states, accessibility and completion measures; use UX specification for journeys and interaction structure, and content strategy for broader editorial work.

10-saas-multi-tenancy-architecture-spec

Use when a multi-tenant SaaS HLD needs explicit control/application planes, per-service tenancy patterns, context propagation, isolation, noisy-neighbour controls and cost attribution; use generic HLD for the complete system and accounting design for ledger…

12-ai-model-card

Use when a production AI feature needs a version-specific model card covering purpose, data, evaluation, limitations, bias, intended use, prohibited use and operational pins; use AI architecture for system design and evaluation artefacts as evidence inputs.

13-ai-prompt-and-system-message-spec

Use when production AI features rely on owned prompts that require registry tags, change control, regression evaluation, safe system-message patterns, retrieval formatting and rollback; use AI architecture for the wider runtime and model card for release…

14-ai-agent-architecture-spec

Use when an approved tool-using AI agent needs a runtime loop, state machine, memory tiers, planner, dispatcher, durability, kill switch and tenant isolation; use AI architecture for non-agent AI services and multi-agent coordination only when several agents…