sdlc-documentation

Plugin sdlc-documentation from marketplace chwezi-sdlc-documentation in peterbamuhigire/chwezi-sdlc-documentation. Commands read from the repo's manifest — yesterday.

Skills (160)

• 01-prd-generation

  Use when converting approved discovery evidence into a traceable PRD with objectives, prioritised features, success measures, constraints, and release scope; use vision-statement for the strategic north star and lean-canvas while assumptions still need testing.

• 02-business-case

  Use when decision-makers need a business case with ROI for a new system or ERP: costs, benefits, ROI, payback, NPV, risks, assumptions, sensitivity and a go/no-go call; use vision-statement for direction, lean-canvas for early hypotheses, and PRD generation after approval.

• 03-vision-statement

  Use when a project needs a concise strategic north star defining target users, problem, differentiated value, success and scope boundaries; use lean-canvas to test uncertain assumptions and PRD generation to specify approved product behaviour.

• 04-lean-canvas

  Use when an MVP, startup, SaaS, AI, website or mobile initiative still has material customer, problem, channel or value assumptions to test through a Lean Canvas, Impact Map and Hypothesis Board; use PRD generation once evidence supports stable requirements.

• 05-system-overview

  Use when every stakeholder needs a plain-language, current view of system purpose, context, major functions, constraints and actors; use vision-statement for strategic intent, PRD generation for product requirements, and high-level-design for technical architecture.

• 06-ai-economic-value-brief

  Use when an AI feature, agent, RAG workflow, predictive product or automation proposal needs business outcomes, data readiness, evaluation, operating cost, risk and delivery evidence before PRD or architecture work; use AI feature strategy for portfolio sequencing.

• 07-premium-product-positioning

  Use when a commercial product, client-facing system, SaaS, app or executive workflow must justify premium pricing through buyer trust, proof, service quality and materially better experience; use vision-statement for broad direction and UX specification for interface detail.

• 10-saas-mvp-scoping-doc

  Use when an early-stage or new SaaS product line needs a tightly bounded v1, one acquisition channel, explicit cuts, escape-velocity measures and a feature-triage log; use lean-canvas while the customer problem is still untested and PRD generation for the approved v1.

• 11-saas-moat-and-defensibility-plan

  Use when a SaaS product needs an evidence-based defensibility plan covering integrations, owned channels, switching costs, proprietary data, brand or network effects; use competitive discovery for market facts and MVP scoping for initial release boundaries.

• 12-saas-pricing-and-packaging-spec

  Use when a SaaS product needs testable tiers, a value metric, feature gates, expansion mechanics, freemium decision, grandfathering and price-change policy; use business-case for investment viability and PRD generation for feature requirements.

• 13-ai-feature-strategy-doc

  Use when a SaaS or digital product needs to choose, tier and sequence AI features, separate table stakes from differentiation, decide build versus buy, and define an AI moat; use AI economic value brief for a single initiative's value proof and AI architecture spec for implementation.

• 14-ai-agent-strategy-doc

  Use when a product may ship tool-using AI agents and needs to decide agent versus workflow, autonomy levels, tiered capabilities, action-catalogue advantage and sequencing; use AI feature strategy for the wider AI portfolio and agent architecture after approval.

• 15-game-product-and-production-brief

  Use when defining a game's player promise, product hypotheses, platform options, production model, vertical-slice evidence, commercial boundaries, or greenlight decision before detailed requirements.

• 13-saas-billing-and-metering-spec

  Use when specifying SaaS usage events, billing, credits, refunds, dunning, finance handoff, and testable metering controls; use pricing-and-packaging for commercial tier design.

• 14-ai-feature-prd-spec

  Use when converting an approved AI feature strategy into testable PRD requirements for quality, latency, cost, abstention, citations, consent, and evaluation; use ai-feature-strategy-doc for portfolio choices.

• 15-ai-data-and-knowledge-base-spec

  Use when specifying AI knowledge sources, ingestion, tenant isolation, freshness, retention, lineage, and training-data exclusions; use ai-feature-prd-spec for user-facing behaviour.

• 16-ai-agent-feature-prd-spec

  Use when defining testable product requirements for an agent's task scope, autonomy, budgets, intervention, success, and irreversible-action gates; use ai-agent-strategy-doc for portfolio strategy.

• 17-ai-agent-action-catalogue-spec

  Use when defining the schema-bound tools an AI agent may invoke, including side effects, reversibility, approvals, audit fields, quotas, and kill switches; use agent PRD for user outcomes.

• 18-embedded-accounting-engine-srs

  Use when specifying software that touches money, inventory value, payroll, tax, grants, payments, assets, or financial reports; use the finance doctrine for accounting policy and current statutory facts.

• 19-game-software-requirements-specification

  Use when a video game needs testable GREQ requirements for the game loop, levels, player progression, saves, multiplayer, monetisation, platform certification, content budgets, accessibility, telemetry, builds or live operations; use 01-initialize-srs for a non-game system SRS.

• 20-hr-module-srs

  Use when specifying the HR module of a multi-tenant system: positions, employee master, contract classes, leave and payroll inputs, workflows, access, audit and personal data. Use the finance doctrine for payroll postings and statutory facts.

• 01-user-story-generation

  Use when decomposing approved features into INVEST user stories, epics, story points, and initial acceptance criteria; use acceptance-criteria when stories already exist and only test oracles are needed.

• 02-acceptance-criteria

  Use when formalising deterministic Given-When-Then acceptance criteria for existing user stories; use user-story-generation when the backlog or personas have not yet been defined.

• 03-story-mapping

  Use when arranging an existing backlog into user activities, a walking skeleton, and release slices; use backlog-prioritization for economic ordering after the map exists.

• 04-backlog-prioritization

  Use when ranking an approved backlog with MoSCoW and WSJF and assigning release or sprint order; use story-mapping when the user journey and walking skeleton are not yet visible.

• 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, including a vague or contradictory stakeholder brief whose ambiguity must be logged as an open decision instead of resolved silently; use requirements-validation for the independent pre-baseline re

• 05-conceptual-data-modeling

  Use when translating business language into conceptual entities, relationships, identifiers, ownership, and invariants before logical database design, or when writing data contract, data dictionary, data catalog, lineage, and data quality and governance requirements; use database-design for physical

• 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.

• 07-requirements-validation

  Use when independently reviewing drafted requirements for correctness, completeness, consistency, feasibility, traceability, and testability before baselining; use requirements-analysis to resolve raw elicitation conflicts.

• 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.

• 10-prototyping-and-solution-discovery

  Use when comparing solution candidates or prototypes to reduce uncertainty before locking requirements or design; use UX-specification after the chosen interaction direction is approved.

• 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.

• hospitality-operating-model-srs

  Use when writing or auditing requirements for hotel, resort, lodge, inn, guest-house, restaurant, bar, catering, or event-venue systems.

• 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 writing a new SRS (software requirements specification) for a business system or module: create the Waterfall SRS workspace, IEEE structure, identifiers and source context; use context-engineering next for 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 writing SRS Sections 3.3-3.6 non-functional quality attribute requirements (performance, constraints, reliability, availability, security, maintainability, standards compliance) as measurable ISO/IEC 25010:2023 scenarios; use feature-decomposition for Section 3.2 functions.

• 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, or an as-built design must be recovered from existing code; use system-overview for orientation, low-level-design for module internals, and infrastructure-design

• 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 isolation.

• 11-ai-architecture-spec

  Use when approved AI features need architecture decisions for direct calls, RAG, fine-tuning or agents, plus model gateway, knowledge stores, evaluation, observability and tenant security; use HLD for the whole system and agent architecture for tool-using runtimes.

• 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 disclosure.

• 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 share a task.

• 15-ai-agent-multi-agent-coordination-spec

  Use when two or more agents participate in one user task and need a bounded topology, role inventory, scratchpad isolation, supervision, message contract and failure handling; use agent architecture for the common single-agent runtime.

• 16-accounting-engine-design

  Use when approved money-flow requirements need SDS/HLD/LLD for an embedded accounting engine with append-only journals, posting service, periods, reversals, idempotency, subledgers, rebuilds and audit trail; consult the finance doctrine and use database-design for general persistence.

• 17-game-system-architecture-specification

  Use when designing game client, authoritative state, engine integration, content, saves, multiplayer backend, platform adapters, telemetry, security, build, and live-operations architecture from an approved game SRS.

• 18-game-3d-content-and-blender-pipeline-specification

  Use when specifying a game's 3D asset and Blender source-to-engine pipeline, including asset briefs, rigs, animation clips, UV/bakes, materials, LODs, collision, export/import, lineage, automation, runtime budgets, and acceptance evidence; use game-system-architecture for whole-system boundaries.

• 01-technical-specification

  Use when producing or updating implementation-ready technical specification for module contracts, interfaces, data schemas, dependencies, and requirement traceability. Use coding-guidelines for the neighbouring concern; this skill owns the named document contract and its acceptance evidence.

• 02-coding-guidelines

  Use when producing or updating project coding guidelines for language and framework conventions, enforceable checks, examples, and exceptions. Use technical-specification for the neighbouring concern; this skill owns the named document contract and its acceptance evidence.

• 03-dev-environment-setup

  Use when producing or updating development environment setup guide for repeatable prerequisites, installation, configuration, build, and verification steps. Use deployment-guide for the neighbouring concern; this skill owns the named document contract and its acceptance evidence.

• 04-contribution-guide

  Use when producing or updating repository contribution guide for branching, commits, pull requests, review gates, CI expectations, and exception handling. Use coding-guidelines for the neighbouring concern; this skill owns the named document contract and its acceptance evidence.

• 05-ai-agent-coding-guidelines-addendum

  Use when producing or updating AI-agent coding-guidelines addendum for tool schemas, reversibility, blast-radius caps, deterministic state, idempotency, timeouts, and HITL gates. Use coding-guidelines for the neighbouring concern; this skill owns the named document contract and its acceptance eviden

• 05-game-technical-implementation-specification

  Use when turning approved game requirements and architecture into implementable Unity, Godot, Unreal, Apple-native, multiplayer, content-pipeline, build, and telemetry work packages with code and asset contracts.

• 01-test-strategy

  Use when producing or updating project test strategy for risk-based test levels, test types, environments, tooling, entry criteria, and exit criteria. Use test-plan for the neighbouring concern; this skill owns the named document contract and its acceptance evidence.

• 02-test-plan
• 03-test-report
• 04-ai-eval-harness-spec
• 05-ai-red-team-test-plan
• 06-ai-agent-eval-spec
• 07-ai-agent-red-team-test-plan
• 08-accounting-engine-test-plan
• 09-game-test-and-player-evidence-plan
• 10-full-coverage-saas-seeding
• 01-deployment-guide
• 02-runbook
• 03-monitoring-setup
• 04-infrastructure-docs
• 05-go-live-readiness
• 06-customer-adoption-and-support-plan
• 07-saas-tenant-lifecycle-runbook
• 08-saas-slo-and-error-budget-doc
• 09-saas-incident-response-and-postmortem
• 10-ai-hallucination-slo-doc
• 11-ai-feature-rollout-runbook
• 12-ai-cost-runbook
• 13-ai-agent-slo-doc
• 13-ai-incident-severity-matrix
• 14-ai-agent-runbook
• 14-ai-incident-response-runbook
• 15-ai-agent-rollout-runbook
• 15-ai-rca-taxonomy-doc
• 16-ai-incident-postmortem-template
• 17-ai-incident-evidence-pack-spec
• 20-ai-agent-compliance-runbook
• 21-accounting-operations-runbook
• 22-game-release-and-live-operations-runbook
• 01-sprint-planning
• 02-definition-of-done
• 03-definition-of-ready
• 04-retrospective-template
• 05-saas-growth-experiment-doc
• 01-user-manual
• 02-installation-guide
• 03-faq
• 04-release-notes
• 05-saas-customer-success-playbook
• 06-saas-onboarding-journey-spec
• 07-saas-lifecycle-email-strategy-doc
• 08-saas-sales-enablement-doc-pack
• 09-ai-agent-user-disclosure-pack
• 01-traceability-matrix
• 02-audit-report
• 03-compliance-documentation
• 04-risk-assessment
• 05-architecture-decision-records
• 05-formal-review-gates
• 06-ccb-charter
• 06-change-impact-analysis
• 07-baseline-delta
• 08-waiver-management
• 09-sign-off-ledger
• 10-evidence-pack-builder
• 11-saas-data-isolation-evidence-pack
• 12-saas-trust-center-document-pack
• 13-saas-dpa-and-privacy-doc-set
• 14-ai-responsible-ai-declaration
• 15-ai-act-and-regulatory-compliance-doc
• 16-ai-data-flow-and-dpia
• 17-ai-adr-catalogue
• 18-ai-agent-responsible-ai-addendum
• 19-ai-agent-adr-catalogue
• 20-ai-agent-soc2-control-pack
• 21-ai-agent-iso27001-control-pack
• 22-ai-agent-hipaa-control-pack
• 23-ai-agent-compliance-policy-pack
• 24-ai-agent-attestation-preparation-spec
• 25-ai-agent-evidence-pack-spec
• 26-ai-agent-baa-and-data-processing-language
• 27-ai-agent-regulator-overlap-mapping
• 28-anti-ai-slop
• 29-ai-slop-audit
• 30-game-delivery-evidence-and-greenlight-pack
• 31-kaizen-engine-and-product-improvement
• plan-canvas

Hooks (3)

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/destructive-bash-gate.js"

• Stop

  node "${CLAUDE_PLUGIN_ROOT}/hooks/plan-canvas-pending.js"

• SessionStart

  node "${CLAUDE_PLUGIN_ROOT}/hooks/plan-canvas-sessions.js"

Similar plugins