AI Beyond FDLC Addendum Activity matrix · May 2026

AI Activity Matrix & Prompt Library.

A quick-reference companion to the Tomorrow FDLC. Each activity is keyed to the canvas phase model (Phase 0 Discover through Phase 4 Learn), the G0–G4 gates, the owning role, and an AI mode. Use it to orient on what AI does at each stage and who owns the output. Tool-agnostic by design — for Track A (Copilot/OpenAI) and Track B (Claude Code) specifics see the Cost optimization addendum.

Getting started

Prompting principles.

Apply these to any AI-assisted task across any role.

Be constraint-based

Give the model explicit goals, explicit limitations, clear output expectations, and component or pattern constraints. Constrained prompts produce more consistent, usable output.

Be modular

Break work into steps — spec interpretation, screen generation, state completion, review — rather than one prompt that tries to do everything at once.

Prefer editing over regeneration

Once usable output exists, prompt to update and refine rather than recreate from scratch. Regeneration wastes context and loses accumulated decisions.

Use shared vocabulary

Reference design system components, tokens, pattern names, product terms, and spec sections consistently. The model performs better when it recognises your terminology.

Structure over prose

Encode quality through checklists, sections, constraints, and acceptance criteria. Long narrative instructions produce longer, less focused outputs.

Getting started

Mode definitions.

Each activity is tagged with one of three modes — the same vocabulary the FDLC canvas uses. The mode tells you who owns the work and where the human judgment sits.

Agent-led Agent-assisted Human-led
Agent-led

Agent owns it

Agent owns the activity. Human reviews and approves output.

Agent-assisted

Agent drafts, human owns

Human owns the activity. Agent drafts the first version.

Human-led

Human judgment required

Requires human judgment, accountability, or stakeholder relationship.

Tool-agnostic. The activities and starter prompts below apply to both Track A (GitHub Copilot / OpenAI) and Track B (Claude Code). Tool-specific guidance — interface choice, session/thread management, MCP availability, billing — lives in the Cost optimization addendum. Tier tags (Enhancement, New Capability, New Paradigm) follow the same definitions used in cost-optimization §06 and the workflow walkthrough.
Activity matrix

Activities by phase and gate.

Each row maps an activity to its owning role, the gate it serves, the AI mode, and a starter prompt. Phase numbering follows the FDLC canvas; gates follow the workflow walkthrough.

Phase 0 Discover · continuous signal · always on
ActivityRoleGateModeStarter prompt
Customer signal monitoringPM, CScontinuousAgent-ledRun a weekly synthesis across support, reviews, and community channels. Output themes, frequency, sentiment, suggested action.
VoC and behavioral synthesisPMcontinuousAgent-ledSynthesise this VoC corpus into themes: frequency, sentiment, representative quote, suggested action.
Product and business data analysisPMcontinuousAgent-ledHere is 3 months of support data. Identify top 5 themes with frequency and severity.
Market and competitor analysisPMad-hocAgent-ledAnalyse [competitor] across UX, pricing, and positioning. Output a structured comparison.
Competitor UX reviewDesignad-hocAgent-ledReview these screenshots of [competitor]. Identify UX patterns and friction points.
Brief candidate authoringPM→ G0Agent-assistedDraft a brief from this signal: customer problem, scale, hypothesis, downstream costs.
Brief dispositioningPMG0Human-ledHuman gate. Agent prepares the briefing pack; PM disposes (advance, return, park with rationale).
Phase 1 Define · spec co-authored · Trio sign-off
ActivityRoleGateModeStarter prompt
Problem statement and use casesPMG0 → G1Agent-assistedDraft a problem statement from this brief using Jobs-to-be-Done format.
Value propositionPMG0 → G1Agent-assistedGenerate 3 value proposition options for [feature], one per buyer persona.
User research synthesisDesignG0 → G1Agent-assistedHere are N interview transcripts. Extract pain points and unmet needs. Group by theme.
Persona alignmentDesignG0 → G1Agent-assistedUpdate our persona where new research suggests shifts in behaviour or goals.
Capacity check and dependency scanPod→ G1Agent-assistedIdentify dependencies, blockers, and capacity constraints from this brief. Surface from LDG.
Feature tier classification Enh / NewCap / NewParPod→ G1Agent-assistedClassify this feature as Enhancement, New Capability, or New Paradigm. Cite the sufficiency criteria.
Go / No GoPod (Trio)G1Human-ledHuman gate. Trio decides in a single short meeting; agent prepares the framing pack.
Functional and non-functional requirementsPMG1 → G2Agent-assistedGenerate requirements: As a [role] I need [capability] so that [outcome]. Bind to spec.md §1.x.
Acceptance criteriaPMG1 → G2Agent-assistedWrite Given/When/Then AC into spec.md §1.6 including happy path, error states, and edge cases.
Success metrics & analytics planPMG1 → G2Agent-assistedDraft spec.md §5.x success metrics and analytics plan tied to the job statement.
Variant scope declaration NewCap / NewParDesign, PM→ G2Agent-assistedGiven the tier, declare the variant scope (count + intent) for G3. Log rationale.
Architecture engagement checkEngineering, Architecture→ G2Human-ledHuman gate. Trigger per the architecture engagement policy; log in decision log.
Spec authoring (Trio co-author)Pod→ G2Agent-assistedDraft spec.md sections from the brief, AC list, and analytics plan. Apply the PM spec guide.
Spec sufficiency & AC quality checkPod→ G2Agent-ledCheck spec.md against P7 sufficiency thresholds and AC quality rules. Output JSON with findings.
Trio sign-off (spec approved)Pod (Trio)G2Human-ledHuman gate. PM, Design, Engineering co-sign spec.md. Hard gate that closes Define.
Phase 2 Build · generation · parallel work
ActivityRoleGateModeStarter prompt
User flowsDesignG2 → G3Agent-assistedDraft a user flow for [scenario] covering primary path, alternatives, and error states. Use approved DS components.
Variant generation NewCap / NewParDesignG2 → G3Agent-ledGenerate N variants from spec.md within the design constitution and approved DS components. Output variant intent + code per variant.
Single-variant prototype EnhancementDesignG2 → G3Agent-assistedGenerate a coded prototype from spec.md against the design constitution. Include all spec states.
Accessibility annotationsDesignG2 → G3Agent-assistedAnnotate the prototype with focus order, ARIA, keyboard interactions, and contrast notes.
Spec-to-prototype reconciliationDesign, EngineeringG2 → G3Agent-ledCompare the prototype against spec.md §2.3 / §2.4 / §2.5. Flag deviations and out-of-scope additions.
DS compliance checkDSG2 → G3Agent-ledRun DS compliance: token usage, component usage, state coverage. Output severity-classified findings.
Architecture evaluation (if triggered)Engineering, ArchitectureG2 → G3Agent-assistedOutline 2 architecture options with trade-offs on scalability and reversibility. Draft ADR candidate.
Technical research & R&D spikesEngineeringG2 → G3Agent-assistedSummarise the current state of [technology] and identify key unknowns to spike on.
Engineering spec draftEngineeringG2 → G3Agent-assistedFrom G3-approved inputs, draft the engineering spec: data shape, service hooks, contracts.
Work item decomposition (units of work)EngineeringG2 → G3Agent-assistedBreak spec.md into units of work completable in 1–3 days. Map each unit to AC items.
G3 review briefPod→ G3Agent-ledSynthesise the feature folder into a G3 review brief: variants, ADRs, DS findings, AC coverage.
UX hard gate (G3 sign-off)DesignG3Human-ledHuman gate. Design owns the handoff package; UX hard gate runs before QA testing.
Code development (per unit of work)EngineeringG3 → G4Agent-assistedImplement this unit against the engineering companion and constitution. Output code only; verify against AC before marking done.
Test plan and script generationEngineering (QA)G3 → G4Agent-ledGenerate a test plan covering unit, integration, and UAT. Map each test to an AC item in spec.md §1.6.
Code review and PR descriptionsEngineeringG3 → G4Agent-ledUse the agent PR description as default. Engineer edits and confirms — never skip review.
Bug triage and root causeEngineeringG3 → G4Agent-assistedHere is the error log. Identify the most likely root cause and 2 investigation paths.
AC clarification and gap detectionEngineeringG3 → G4Agent-assistedReview these AC and identify ambiguities, missing edge cases, or untestable conditions. Log gaps via the spec gap protocol.
UAT script generationPMG3 → G4Agent-assistedGenerate a UAT script with pre-conditions, steps, expected outcomes, and pass/fail criteria.
In-product content and microcopyTCG3 → G4Agent-assistedDraft UI copy for empty, loading, error, success, confirmation, and tooltip states.
Build quality and metrics trackingEngineeringG3 → G4Agent-assistedWeekly agent-generated quality digest: coverage, failed builds, open defects.
Security and compliance reviewArchitectureG3 → G4Human-ledHuman gate. Agent prepares the evidence pack but cannot substitute the review.
UX Review GateDesign→ G4Human-ledHuman gate (pre-CI/CD). Verifies the build matches design intent; AC re-verified against spec.
G4 close-out recordPodG4Agent-ledGenerate G4 close-out: decision log, amendments, ACs verified, cost log, pattern candidates.
Phase 3 Ship · release + launch · staged
ActivityRoleGateModeStarter prompt
Release notes draftingTCG4 → LaunchAgent-ledDraft customer-facing release notes from these PRs. Tone: clear, benefit-led.
Documentation draftingTCG4 → LaunchAgent-assistedDraft customer-facing docs from spec.md and the build artifacts.
Launch coordination (GTM)PMktG4 → LaunchAgent-assistedGenerate launch checklist: GTM materials, internal comms, enablement timing.
Telemetry & service health setupEngineeringG4 → LaunchAgent-ledConfigure anomaly thresholds from spec.md §5.x success metrics.
Rollout configurationEngineeringG4 → LaunchAgent-ledGenerate rollout config from the engineering spec: flags, stages, rollback plan.
Final regression sweepEngineering (QA)G4 → LaunchAgent-assistedRun final regression against the test plan; flag deltas vs G4 baseline.
Release authorization (Go / No Go)PodLaunchHuman-ledHuman gate. Agent compiles telemetry, UAT results, and risks into a one-page decision brief.
Phase 4 Learn · structured loop · the system improves
ActivityRoleGateModeStarter prompt
Feature success metric trackingPMpost-LaunchAgent-ledHere are this week's metrics vs targets in spec.md §5.x. Identify on/off track items and decisions needed.
JTBD completion rate analysisPMpost-LaunchAgent-assistedAnalyse completion rates against the job statement (§1.2) and analytics plan (§5.x).
User feedback synthesisPM, CSpost-LaunchAgent-ledSynthesise post-launch feedback into themes: frequency, sentiment, representative quote, suggested action.
Content performance & gap analysisTCpost-LaunchAgent-ledHere is search and support data. Identify gaps where users search but find no answers.
Defect prioritisationEngineeringpost-LaunchAgent-assistedTriage these bugs by customer impact (H/M/L), reproduction frequency, and fix effort.
Pattern candidate identificationPod, DSpost-LaunchAgent-assistedFrom the build, identify reusable patterns to promote to the companion file.
Constitution amendment candidatesDS, Architecturepost-LaunchAgent-assistedSynthesise build close-outs to identify constitution / companion file amendment candidates.
Spec gap / drift loggingEngineeringpost-LaunchAgent-ledCompile the spec gap log entries from this cycle for the AI FDLC Review.
Cost log roll-up (cost-per-outcome)PM, Del Ownerpost-LaunchAgent-assistedCalculate cycle time, rework rate, and cost-per-outcome from these close-out records.
Trio retrospective & amendPod (Trio)post-LaunchHuman-ledHuman-led. The Trio retrospective produces the next constitution version before the next Define begins.
Continuous Overlay · applies across all phases
ActivityRoleCadenceModeStarter prompt
Spec drift detectionEngineeringG2 → G4Agent-ledCompare the build against spec.md AC. Identify deviations, omissions, and out-of-scope additions.
Cost log entryPMevery gate closeAgent-assistedGenerate cost log entry for this gate close: token spend, agent calls, anomalies flagged.
Companion file staleness monitorDScontinuousAgent-ledFlag companion file sections out of date against current build patterns or DS amendments.
Customer signal monitoringPM, CSweeklyAgent-ledRun a weekly synthesis across support, reviews, and community channels.
Oversight / mode reviewPod, AI FDLC ReviewquarterlyHuman-ledReview which activities are agent-led, assisted, or human-led. Adjust based on close-out evidence.
Design prompt templates

Structured prompts for design work.

Design-specific expansions of the one-line starters above. For non-design agent types and the canonical six-section prompt template standard (Role / Context / Task / Output Format / Constraints / Stop Condition), see Cost optimization §03. The templates here follow that standard while remaining design-focused.

Each template below maps to the §03 template standard: Role · Context (Input context) · Task (Objective) · Output format (Output) · Constraints · Stop condition. Adapt them to your feature and context — the structure matters more than the exact wording.
Generation
Generate screen from spec
Objective

Create a production-oriented prototype in code using the design system and shared interaction patterns.

Use
  • Approved design system components only, unless the spec explicitly requires a custom component
  • Platform tokens for spacing, colour, typography, and layout
  • Semantic HTML and accessible interaction patterns
Required
  • Layout structure and hierarchy
  • Navigation context
  • Realistic placeholder content
  • All required states
  • Key interaction behaviour
  • Responsive considerations where relevant
States to include
  • Default, loading, empty, error, disabled, success, no results, validation error
Constraints
  • Prefer composition over custom styling
  • Follow the 8px spacing system
  • Keep output readable and modular
  • Do not omit edge cases if the spec defines them
Input context

[spec] · [domain context] · [relevant patterns] · [approved components list]

Output
  1. Short summary of intended UX
  2. Component structure
  3. Working UI code
  4. Assumptions made
Generate variant set
Objective

Generate 3 distinct UI variants for the same feature. Explore different approaches to hierarchy, flow, and layout without violating the design system.

Vary
  • Information hierarchy
  • Section grouping and navigation emphasis
  • Progressive disclosure
  • Density level where appropriate
Keep constant
  • Core requirements and required actions
  • Data entities
  • Accessibility requirements
  • Design system compliance
Constraints
  • Variants must be meaningfully different
  • Avoid cosmetic-only changes
  • Do not create unnecessary novelty
Output — for each variant
  1. Variant name
  2. Design intent
  3. Trade-offs
  4. Working UI code

End with a recommendation and rationale for the best option.

Generate flow or multi-step experience
Objective

Create a cohesive multi-step flow that supports the user goal from entry to completion.

Required
  • Step structure and navigation between steps
  • Progress indication where appropriate
  • Validation and save/resume behaviour
  • Success and failure handling
  • Edge cases
Use
  • Existing flow, form, modal, wizard, and confirmation patterns from the design system
  • Accessible labels, messaging, and focus handling
Output
  1. Flow summary
  2. Step-by-step interaction model
  3. Screen list with purpose
  4. Working code for each major step
  5. Identified risks or UX trade-offs
Refinement
Incremental update
Requested changes

[changes]

Rules
  • Do not regenerate the entire screen unless required
  • Preserve existing structure and code where possible
  • Keep design system compliance
  • Update only the affected sections
  • Maintain accessibility and interaction behaviour
Output
  1. Summary of changes
  2. Updated code for modified areas only (or full component if necessary)
  3. Any assumptions or dependencies introduced
Refactor to design system
Check and update
  • Component usage and token usage
  • Spacing and typography
  • Interaction patterns and state handling
Replace / Preserve
  • Replace: one-off styles, ad hoc layouts, inconsistent controls
  • Preserve: intended user flow, functionality, core content
Output
  1. List of inconsistencies found
  2. Changes applied
  3. Refactored code
Review
Accessibility audit
Check
  • Semantic structure and heading hierarchy
  • Keyboard navigation and focus visibility
  • ARIA usage and accessible naming
  • Colour contrast
  • Input labelling and error messaging
  • Screen reader clarity
  • Target size and interaction affordance
Classify issues as

Critical · Major · Minor

Output
  1. Summary of findings
  2. Issue list by severity
  3. Exact fixes
  4. Corrected code snippets where appropriate
UX heuristic review
Review for
  • Clarity of hierarchy and cognitive load
  • Discoverability and affordance
  • Feedback and error prevention
  • Consistency and learnability
  • Trust and confidence
  • Efficiency for repeat use
Output
  1. Top strengths
  2. Top UX risks
  3. Recommended improvements
  4. Revised layout or code suggestions if needed
Product quality review
Evaluate
  • User value and alignment to the spec
  • Consistency with platform patterns
  • Implementation feasibility
  • State completeness and design system reuse
  • Long-term maintainability
Output
  1. What is strong
  2. What is missing
  3. Risks to product quality
  4. Recommended next actions
Components & patterns
Create custom component
Component need

[description]

Requirements
  • Define purpose, props, and variants clearly
  • Support theming and accessibility
  • Align with existing tokens and patterns
  • Keep structure modular and reusable
Also include
  • Usage guidelines: when to use, when not to use
  • Examples
Promotion recommendation

Local only · Team shared · Design system candidate

Output
  1. Component spec
  2. Code
  3. Usage examples
Evaluate whether a new component is needed
Determine whether this need requires
  • An existing design system component
  • A composition of existing components
  • A team-level custom component
  • A new global design system component
Evaluate based on
  • Reuse potential and consistency impact
  • Complexity and accessibility
  • Theming needs and cross-team applicability
Output
  1. Recommendation
  2. Rationale
  3. Proposed next step
Cross-functional
Design + engineering feasibility check
Check
  • Component reuse and complexity of implementation
  • State handling and performance implications
  • Responsiveness and architecture fit
  • Maintainability and accessibility implications
Output
  1. Feasibility assessment
  2. Risks
  3. Required engineering collaboration
  4. Suggested adjustments