waterfall-lifecycle

Generate a waterfall lifecycle artefact from a template, pre-populated with project context.

Validate requirements baseline completeness against all Gate B mandatory artefacts and RTM coverage before submitting for gate review.

Initiate a formal gate review by invoking the gate-reviewer agent with the evidence package for the specified gate.

Prepare inter-phase handover package by validating Gate C artefacts, generating handover summary, and assessing phase transition readiness.

Initialize waterfall-lifecycle framework for a new project. Creates lifecycle-state.json, directory structure, and bootstraps Phase 1.

Use this agent when constructing the project charter, setting up governance, and assembling the Gate A initiation pack at Phase 1 of the waterfall lifecycle. <example> Context: All Phase 1 artefacts are complete and the team needs to consolidate them into a governance-ready package for the initiation gate. user: "We have the problem statement, feasibility, and risk register — now we need a project charter and gate pack" assistant: "I'll use the delivery-framing agent to construct the project charter, define governance structure, and assemble the complete Gate A initiation pack from all Phase 1 artefacts." <commentary> Project charter and gate pack are the final mandatory Gate A artefacts — this agent synthesises all upstream Phase 1 work into the governance submission. </commentary> </example> <example> Context: Sponsor is questioning whether the AI justification in the charter is robust enough and whether the governance forum will approve it. user: "The sponsor wants to make sure the AI reasoning in the charter will stand up to scrutiny at the gate — can you review it?" assistant: "I'll use the delivery-framing agent to review the AI justification against Gate A criteria, strengthen the fallback scenario documentation, and confirm the charter meets the sign-off authority requirements." <commentary> Delivery framing validates charter completeness and governance readiness — a weak AI justification at gate leads to rejection or rework that delays project start. </commentary> </example>

Use this agent when assessing whether a proposed project is feasible across technical, data, AI/ML, organisational, financial, and legal dimensions at Phase 1 of the waterfall lifecycle. <example> Context: A stakeholder wants to use machine learning for fraud detection but data availability and regulatory compliance are uncertain. user: "We want to build a fraud detection model — is this actually feasible given our current data and GDPR constraints?" assistant: "I'll use the feasibility-assessment agent to evaluate technical, data, AI/ML, legal, organisational, and financial feasibility across all six dimensions and produce a documented verdict." <commentary> Multi-dimension feasibility assessment is required before Gate A — this agent structures the analysis and produces the mandatory feasibility artefacts. </commentary> </example> <example> Context: Project team is debating whether AI is the right approach or whether rule-based logic would suffice. user: "Do we actually need AI here, or are we over-engineering this with ML?" assistant: "I'll use the feasibility-assessment agent to run the AI justification test and document whether AI, rules-based logic, or a hybrid approach is the appropriate technical direction." <commentary> AI justification must be formally documented at Gate A — this agent ensures the decision is evidence-based and the fallback scenario is explicit. </commentary> </example>

Use this agent when starting Phase 1 of the waterfall lifecycle — defining the problem, articulating the vision, and mapping stakeholders. <example> Context: A sponsor has identified a process inefficiency and wants to formalise it before requesting budget. user: "We have a manual reconciliation process that takes 3 days per month — help me define the problem properly" assistant: "I'll use the problem-value-context agent to articulate the problem statement, quantify the impact, frame a vision statement, and map all affected stakeholders." <commentary> Formal problem definition is required at Gate A — this agent structures the evidence-backed problem statement and stakeholder map needed for the initiation gate pack. </commentary> </example> <example> Context: Business owner has a vague idea about improving customer onboarding but hasn't formalised scope or ownership. user: "We want to improve onboarding — who should be involved and what are we actually trying to achieve?" assistant: "I'll use the problem-value-context agent to clarify the problem scope, define measurable success, and identify all stakeholder groups before committing to delivery." <commentary> Stakeholder mapping and vision articulation must precede any feasibility work — this agent ensures the initiative has a clear, shared understanding of the problem before phase progression. </commentary> </example>

Use this agent when identifying initial risks, capturing assumptions, logging clarifications, and running compliance checks at Phase 1 of the waterfall lifecycle. <example> Context: Project team is preparing for Gate A and needs to formalise risks, assumptions, and open decisions before presenting to the governance forum. user: "We need to document what could go wrong and what we're assuming before the initiation gate" assistant: "I'll use the risk-compliance-screening agent to build the initial risk register, capture assumptions, log clarifications, and run a compliance check against known regulatory requirements." <commentary> A risk register with ≥3 identified risks is a mandatory Gate A exit criterion — this agent ensures the team enters the gate with documented risk awareness. </commentary> </example> <example> Context: Legal and compliance status is unclear and the team is unsure whether the project needs a Data Protection Impact Assessment. user: "Do we need a DPIA for this project? What compliance obligations should we be tracking?" assistant: "I'll use the risk-compliance-screening agent to assess DPIA applicability, identify all compliance obligations, and log them in the clarification register with owners and due dates." <commentary> Compliance screening at initiation prevents late-stage regulatory blockers — this agent surfaces obligations early and assigns resolution owners. </commentary> </example>

Use this agent when specifying AI/ML-specific requirements, acceptance thresholds, model constraints, data requirements, and fallback behavior at Phase 2 (Requirements and Baseline) of the waterfall lifecycle. <example> Context: The business requirements set is complete and the team needs to translate AI-related business requirements into measurable AI/ML specifications with acceptance thresholds. user: "We have the business requirements set — now we need to define the AI acceptance criteria, data requirements, and what happens if the model underperforms" assistant: "I'll use the ai-requirements-engineer agent to specify measurable AI acceptance thresholds (precision, recall, F1, latency), document data requirements for training and validation, define fallback behavior for underperformance scenarios, and produce the ai-requirements-specification.md linked to the relevant REQ-IDs." <commentary> AI requirements must be specified with concrete measurable thresholds — vague AI acceptance criteria lead to disagreements at test time about whether the system has met its targets. </commentary> </example> <example> Context: The sponsor is asking whether the AI system needs to explain its decisions and what the team will do if the model drifts post-deployment. user: "The sponsor wants to know if we need explainability and how we'll handle model drift — where does this fit in requirements?" assistant: "I'll use the ai-requirements-engineer agent to specify explainability requirements (what decisions must be explained, to whom, and in what format), define model drift monitoring thresholds, and document the retraining and fallback triggers. These will be captured in the ai-requirements-specification.md." <commentary> Explainability and drift monitoring requirements are frequently missed at requirements stage and cause post-deployment compliance issues — they must be explicit and measurable. </commentary> </example>

This skill should be used when creating, completing, or reviewing a waterfall lifecycle artefact. Ensures artefacts follow templates, satisfy completeness requirements, and are ready for gate evidence submission with correct closure obligations.

This skill should be used when preparing for or executing a gate review. Provides binary pass/fail/waived checklists for all 8 gates A-H of the waterfall-lifecycle framework. Use this skill as a pre-flight check before invoking the gate-reviewer agent.

This skill should be used when preparing, validating, or executing inter-phase handovers in the waterfall lifecycle. Covers artefact inventory, open items log, risk register transfer, phase transition readiness checklist, and formal handover sign-off.

This skill should be used when enforcing compliance with a signed waterfall phase contract — checking mandatory fields, verifying exit criteria completeness before a gate review, and blocking gate requests when contract gaps are found. Distinct from the phase-contract skill (which creates contracts); this skill enforces them.

This skill should be used when creating or validating a waterfall phase contract — the formal agreement that gates phase entry and exit. Phase contracts in waterfall are binding: no phase starts without approved entry criteria and no gate review without met exit criteria.

2 hooks across 2 events