fix(agile-lifecycle): address Gemini PR #59 review comments

- plugin.json: fix gates count from '10 gates, 13 skills' to '6 formal gates (A-F), 9 skills'
- agile-gate-review.md: fix gate table to canonical A-F (Portfolio Entry → Governance Review)
- gate-reviewer.md: fix gate refs (A-J → A-F), schema ref (gate-io-matrix → evidence-index), sign-off table
- feasibility-screening.md: fix template refs (early-feasibility-note → feasibility-note, initial-risk-note → risk-register-init, ai-data-feasibility-note removed)
- problem-validation.md: fix template path prefix (phase-3/ → phase-1/ for phase-1 agent)
- sprint-design.md: fix template refs (phase-4/iteration-plan → phase-3/sprint-backlog, phase-4/iteration-goal and committed-work-set removed, transversal/dod → phase-3/dod-checklist), remove non-existent schemas (product-backlog, acceptance-criteria)

Generated by Nuno Salvação

Co-Authored-By: Nexo <nexo.modeling@gmail.com>

Author: nsalvacao

plugins/agile-lifecycle/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "agile-lifecycle",
   "version": "0.1.0",
-  "description": "Hybrid gated-iterative lifecycle framework for AI/ML products — 7 phases, 10 gates, 31 agents, 13 skills, and full artefact management. Enterprise agile with governance overlay.",
+  "description": "Hybrid gated-iterative lifecycle framework for AI/ML products — 7 phases, 6 formal gates (A–F), 31 agents, 9 skills, and full artefact management. Enterprise agile with governance overlay.",
   "author": {
     "name": "Nuno Salvacao",
     "email": "nuno.salvacao@gmail.com",

plugins/agile-lifecycle/agents/phase-1/feasibility-screening.md

@@ -31,11 +31,11 @@ The key deliverable is the Feasibility Note: a concise document that covers data
 
 5. **Regulatory and ethical screening**: Identify: (a) applicable regulations (GDPR, AI Act, sector-specific regulations), (b) data privacy requirements, (c) AI ethics considerations (bias risk, transparency requirements, explainability needs), (d) any regulatory approvals needed. Flag high-risk areas for deeper assessment in Phase 3.
 
-6. **Initial risk assessment**: Using `templates/phase-1/initial-risk-note.md.template`, identify the top 5-7 risks across all feasibility dimensions. Rate each as low/medium/high/critical probability and impact. For each HIGH/CRITICAL risk, document the initial mitigation approach.
+6. **Initial risk assessment**: Using `templates/phase-1/risk-register-init.md.template`, identify the top 5-7 risks across all feasibility dimensions. Rate each as low/medium/high/critical probability and impact. For each HIGH/CRITICAL risk, document the initial mitigation approach.
 
 7. **Go/no-go recommendation**: Based on the above assessment, produce a clear recommendation: GO (proceed to problem validation), CONDITIONAL GO (proceed with named conditions), or NO GO (pivot or terminate). Document the rationale for the recommendation with reference to specific findings.
 
-8. **Generate Feasibility Note**: Fill `templates/phase-1/early-feasibility-note.md.template` and `templates/phase-1/ai-data-feasibility-note.md.template` with all assessment findings and the go/no-go recommendation.
+8. **Generate Feasibility Note**: Fill `templates/phase-1/feasibility-note.md.template` with all assessment findings — covering technical, commercial, data, and regulatory dimensions — and the go/no-go recommendation.
 
 ## Expected Outputs
 
@@ -46,9 +46,8 @@ The key deliverable is the Feasibility Note: a concise document that covers data
 
 ## Templates Available
 
-- `templates/phase-1/early-feasibility-note.md.template` — main feasibility note
-- `templates/phase-1/ai-data-feasibility-note.md.template` — AI/data feasibility
-- `templates/phase-1/initial-risk-note.md.template` — initial risk documentation
+- `templates/phase-1/feasibility-note.md.template` — comprehensive feasibility note (technical, commercial, data, regulatory)
+- `templates/phase-1/risk-register-init.md.template` — initial risk register documentation
 
 ## Schemas
 
@@ -74,8 +73,7 @@ Technical Lead or Solution Architect — accountable for technical and data feas
 This agent MUST read before producing any output:
 - `docs/phase-essentials/phase-1.md` — 1-pager: what to do, who, evidence required (START HERE)
 - `references/lifecycle-overview.md` — Phase 1 context and Gate A requirements
-- `templates/phase-1/early-feasibility-note.md.template` — fill ALL mandatory fields
-- `templates/phase-1/ai-data-feasibility-note.md.template` — fill ALL mandatory fields
+- `templates/phase-1/feasibility-note.md.template` — fill ALL mandatory fields
 
 See also (consult as needed):
 - `references/gate-criteria-reference.md` — Gate A evidence requirements for Feasibility Note

plugins/agile-lifecycle/agents/phase-1/problem-validation.md

@@ -25,17 +25,17 @@ This subfase uses qualitative and quantitative research methods appropriate to t
 
 2. **User research execution**: Conduct research using the planned method. For interviews: use a semi-structured guide focused on current state pain, workarounds, and impact. Capture verbatim quotes as evidence. For data analysis: extract relevant metrics (error rates, processing times, failure rates) that quantify the problem.
 
-3. **Pain point mapping**: Using `templates/phase-3/pain-point-map.md.template` (reused here for Phase 1 validation), systematically map pain points identified in research. For each pain point: who experiences it, how often, what is the impact, and what workaround is used currently. Rate severity (low/medium/high/critical).
+3. **Pain point mapping**: Using `templates/phase-1/pain-point-map.md.template` (reused here for Phase 1 validation), systematically map pain points identified in research. For each pain point: who experiences it, how often, what is the impact, and what workaround is used currently. Rate severity (low/medium/high/critical).
 
-4. **User journey mapping**: If relevant, document the current-state user journey to identify where pain points occur in context. This reveals the full experience, not just the reported problem. Use `templates/phase-3/user-journey-map.md.template`.
+4. **User journey mapping**: If relevant, document the current-state user journey to identify where pain points occur in context. This reveals the full experience, not just the reported problem. Use `templates/phase-1/user-journey-map.md.template`.
 
 5. **Market context analysis**: Research existing solutions (products, tools, processes) that address the same problem. Assess why they are insufficient or unavailable to the target user. This validates that the problem is unsolved in the current landscape.
 
 6. **Evidence synthesis**: Compile all research findings into a coherent evidence package. The evidence must support specific, falsifiable claims about the problem. Avoid cherry-picking — acknowledge any contradictory findings and explain the interpretation.
 
 7. **Problem statement validation**: Update the problem statement from subfase 1.1 with validated, evidence-backed language. If the research reveals the problem is different from originally hypothesized, revise the problem statement accordingly. If the problem is not validated, escalate to the Product Manager for a pivot or stop decision.
 
-8. **Discovery findings document**: Fill `templates/phase-3/discovery-findings.md.template` with research methodology, key findings, evidence summary, pain-point severity map, and the validated problem statement. This is the primary artefact for this subfase.
+8. **Discovery findings document**: Fill `templates/phase-1/discovery-findings.md.template` with research methodology, key findings, evidence summary, pain-point severity map, and the validated problem statement. This is the primary artefact for this subfase.
 
 ## Expected Outputs
 
@@ -46,9 +46,9 @@ This subfase uses qualitative and quantitative research methods appropriate to t
 
 ## Templates Available
 
-- `templates/phase-3/discovery-findings.md.template` — primary research findings artefact
-- `templates/phase-3/pain-point-map.md.template` — pain point mapping
-- `templates/phase-3/user-journey-map.md.template` — user journey analysis
+- `templates/phase-1/discovery-findings.md.template` — primary research findings artefact
+- `templates/phase-1/pain-point-map.md.template` — pain point mapping
+- `templates/phase-1/user-journey-map.md.template` — user journey analysis
 
 ## Schemas
 
@@ -74,7 +74,7 @@ Product Manager — accountable for research design quality and the decision to
 This agent MUST read before producing any output:
 - `docs/phase-essentials/phase-1.md` — 1-pager: what to do, who, evidence required (START HERE)
 - `references/lifecycle-overview.md` — Phase 1 context and validation approach
-- `templates/phase-3/discovery-findings.md.template` — fill ALL mandatory fields
+- `templates/phase-1/discovery-findings.md.template` — fill ALL mandatory fields
 
 See also (consult as needed):
 - `references/gate-criteria-reference.md` — Gate A evidence requirements

plugins/agile-lifecycle/agents/phase-3/sprint-design.md

@@ -34,28 +34,24 @@ Sprint design bridges the strategic iteration plan from Phase 2 with the daily e
 
 6. **Dependency identification**: For each sprint item, identify: (a) internal dependencies between items, (b) external dependencies on other teams or systems. Create dependency log entries for external dependencies via risk-assumption-tracker. Flag any dependencies that are not yet resolved.
 
-7. **Definition of Done confirmation**: Confirm the Definition of Done for this sprint — what quality criteria must ALL sprint items meet to be considered done? For AI/ML items, confirm model evaluation criteria are included. Document DoD using `templates/transversal/definition-of-done-by-phase.md.template`.
+7. **Definition of Done confirmation**: Confirm the Definition of Done for this sprint — what quality criteria must ALL sprint items meet to be considered done? For AI/ML items, confirm model evaluation criteria are included. Document DoD using `templates/phase-3/dod-checklist.md.template`.
 
-8. **Sprint plan document**: Generate the Sprint Plan using `templates/phase-4/iteration-plan.md.template` with: sprint goal, committed backlog items, task breakdown, team capacity, dependency map, and DoD. This is the primary Sprint Backlog artefact.
+8. **Sprint plan document**: Generate the Sprint Plan using `templates/phase-3/sprint-backlog.md.template` with: sprint goal, committed backlog items, task breakdown, team capacity, dependency map, and DoD. This is the primary Sprint Backlog artefact.
 
 ## Expected Outputs
 
-- `iteration-plan.md` — Sprint Plan with goal, committed backlog, task breakdown, and capacity
+- `sprint-backlog.md` — Sprint Plan with goal, committed backlog, task breakdown, and capacity
 - Sprint Backlog committed and visible to the team
 - Dependency log entries for external dependencies
 - Definition of Done for this sprint documented
 
 ## Templates Available
 
-- `templates/phase-4/iteration-plan.md.template` — sprint plan document
-- `templates/phase-4/iteration-goal.md.template` — sprint goal definition
-- `templates/phase-4/committed-work-set.md.template` — committed backlog
-- `templates/transversal/definition-of-done-by-phase.md.template` — DoD definition
+- `templates/phase-3/sprint-backlog.md.template` — sprint plan document with committed backlog
+- `templates/phase-3/dod-checklist.md.template` — Definition of Done checklist
 
 ## Schemas
 
-- `schemas/product-backlog.schema.json` — validates backlog item structure
-- `schemas/acceptance-criteria.schema.json` — validates acceptance criteria format
 - `schemas/dependency-log.schema.json` — validates dependency entries
 
 ## Responsibility Handover
@@ -77,7 +73,7 @@ Delivery Lead or Scrum Master — accountable for facilitating the sprint planni
 This agent MUST read before producing any output:
 - `docs/phase-essentials/phase-3.md` — 1-pager: what to do, who, evidence required (START HERE)
 - `references/lifecycle-overview.md` — Phase 3 sprint design approach
-- `templates/phase-4/iteration-plan.md.template` — fill ALL mandatory fields
+- `templates/phase-3/sprint-backlog.md.template` — fill ALL mandatory fields
 
 See also (consult as needed):
 - `references/gate-criteria-reference.md` — Gate C (Backlog Readiness) requirements
@@ -118,7 +114,7 @@ See also (consult as needed):
 
 ### Evidence Required
 
-- `iteration-plan.md` with sprint goal, committed backlog, task breakdown, and capacity
+- `sprint-backlog.md` with sprint goal, committed backlog, task breakdown, and capacity
 - Sprint Backlog in the team's backlog management tool (reference from plan)
 - Definition of Done confirmed for this sprint
 

plugins/agile-lifecycle/agents/transversal/gate-reviewer.md

@@ -7,11 +7,11 @@ color: green
 
 ## Context
 
-The gate-reviewer executes formal gate reviews (Gates A through J) and informal reviews (Backlog Readiness Review C, Retrospective Review H, KPI Review I) across the agile-lifecycle framework. Gates are critical governance checkpoints that control progression between phases and iterations.
+The gate-reviewer executes formal gate reviews across the 6 governance gates (A–F) of the agile-lifecycle framework. Gates are critical governance checkpoints that control progression between phases.
 
 This agent uses rigorous evidence-based assessment to determine pass/fail/conditional-pass/waiver status for each gate. It reads gate criteria from `references/gate-criteria-reference.md`, verifies that all required artefacts exist and meet quality thresholds, and produces a formal gate-review-report.
 
-Gates map to phases as follows: Gate A (Phase 1→2), Gate B (Phase 2→3), Gate C (Backlog Readiness), Gate D (Iteration→Validate), Gate E (Phase 5→6), Gate F (Post-hypercare), Gate G (Phase 6→7 if applicable), Gates H/I (periodic reviews), Gate J (Retirement).
+Gates map to phases as follows: Gate A (Phase 1→2, Portfolio Entry), Gate B (Phase 2→3, Inception Closure), Gate C (Phase 3→4, Backlog Readiness), Gate D (Phase 4→5, Release Authorization), Gate E (Phase 5→6, Operations Handover), Gate F (periodic in Phase 6, Governance Review).
 
 ## Workstreams
 
@@ -43,7 +43,7 @@ Gates map to phases as follows: Gate A (Phase 1→2), Gate B (Phase 2→3), Gate
 ## Expected Outputs
 
 - `gate-review-report.md` (from `templates/transversal/gate-review-report.md.template`) — formal assessment with outcome
-- Updated `schemas/gate-io-matrix.schema.json` entry for this gate review
+- Updated `schemas/evidence-index.schema.json` entry for this gate review
 - Waiver entries (if applicable) using `templates/transversal/waiver-entry.md.template`
 - Updated `lifecycle-state.json` reflecting gate outcome
 - Clear remediation plan if gate fails or is conditional
@@ -57,7 +57,7 @@ Gates map to phases as follows: Gate A (Phase 1→2), Gate B (Phase 2→3), Gate
 ## Schemas
 
 - `schemas/gate-review.schema.json` — validates gate review report structure
-- `schemas/gate-io-matrix.schema.json` — validates gate I/O completeness
+- `schemas/evidence-index.schema.json` — validates evidence entries for gate I/O completeness
 - `schemas/waiver-log.schema.json` — validates waiver entries
 
 ## Responsibility Handover
@@ -88,7 +88,7 @@ See also (consult as needed):
 
 ### Mandatory Phase Questions
 
-1. Which specific gate (A-J) is being reviewed, and what is the current lifecycle state?
+1. Which specific gate (A–F) is being reviewed, and what is the current lifecycle state?
 2. Are all required artefacts present and at the required quality threshold (exists/reviewed/approved)?
 3. Are there any unmitigated risks rated HIGH or CRITICAL that would block gate passage?
 4. Has the appropriate sign-off authority been identified and engaged?
@@ -129,7 +129,7 @@ See also (consult as needed):
 
 ### Sign-off Authority
 
-Gate A: Product Manager + Sponsor. Gate B: Product Manager + Delivery Lead. Gates C/H/I: Product Manager (informal). Gate D: Product Manager + QA Lead (+ Security if LLM). Gate E: Product Manager + Sponsor + Operations Lead. Gate F: Operations Lead + Product Manager. Gate J: Sponsor + Product Manager. Mechanism: formal written approval on gate-review-report.
+Gate A: Product Manager + Sponsor. Gate B: Product Manager + Delivery Lead. Gate C: Product Manager (informal — backlog readiness). Gate D: Product Manager + QA Lead (+ Security if LLM). Gate E: Product Manager + Sponsor + Operations Lead. Gate F: Operations Lead + Product Manager. Mechanism: formal written approval on gate-review-report.
 
 ## How to Use
 

plugins/agile-lifecycle/commands/agile-gate-review.md

@@ -25,18 +25,16 @@ Gates are the governance checkpoints in the hybrid gated-iterative framework. Ea
 
 ## Gates Reference
 
-| Gate | Timing | Purpose |
-|------|--------|---------|
-| A | End of Phase 1 | Opportunity validated, investment decision |
-| B | End of Phase 2 | Inception complete, delivery approved |
-| C | End of Phase 3 | Backlog readiness, discovery closure |
-| D | Mid Phase 4 | AI readiness, delivery health check |
-| E | End of Phase 4 iteration | Iteration review |
-| F | End of Phase 4 | Delivery complete, release candidate ready |
-| G | End of Phase 5 | Release approved, transition complete |
-| H | Mid Phase 6 | Operational health review |
-| I | End of Phase 6 | Improvement cycle review |
-| J | Phase 7 | Retirement decision approval |
+| Gate | Name | Timing | Purpose |
+|------|------|--------|---------|
+| A | Portfolio Entry | End of Phase 1 | Opportunity validated — fund and pursue? |
+| B | Inception Closure | End of Phase 2 | Architecture and plan approved — ready to build? |
+| C | Backlog Readiness | End of Phase 3 | Backlog ready, DoD agreed — ready to deliver? |
+| D | Release Authorization | End of Phase 4 | Build complete and quality confirmed — safe to release? |
+| E | Operations Handover | End of Phase 5 | Product stable in production — handover to ops? |
+| F | Governance Review | Periodic in Phase 6 | Continue, pivot, or retire? |
+
+Authoritative criteria for each gate: `references/gate-criteria-reference.md`.
 
 ## What It Does