Roles & Responsibilities

In a small team, one person may perform several roles. The important point is that the responsibility still exists, even when the same person handles it.

Role definitions

Role	Main responsibility
Client/Business Owner	Explains the business, provides funding and approves major scope decisions
Product Owner	Decides what the product should do and what should be prioritised
Business Analyst	Converts raw business information into requirements, rules and process documentation
Project Manager	Plans delivery, coordinates people, tracks schedule, risks and blockers
UX Designer	Defines user journeys, information architecture, wireframes and interaction behaviour
UI Designer	Defines visual direction, design system and high-fidelity screens
Technical Lead/Architect	Owns technical structure, boundaries, standards and major technical decisions
Backend Engineer	Implements domain logic, APIs, database access and integrations
Frontend Engineer	Implements interface behaviour, components and frontend integration
QA Engineer	Verifies requirements, flows, edge cases and regressions
DevOps/Platform Engineer	Owns environments, CI/CD, deployment and infrastructure
Security Reviewer	Reviews authentication, permissions, data protection and abuse risks
Stakeholder/Approver	Confirms that outputs accurately represent the business

Phase 1: Project intake and discovery

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Collect raw project information	Product Owner / Business Analyst	Client, stakeholders, technical lead	Client	Gather goals, problems, users, budget, timeline, restrictions and existing processes	Google Docs, Notion, meeting notes, email	Yes: organise and summarise notes	Raw notes and source documents
Create project brief	Business Analyst / Product Owner	Client, PM, technical lead	Client/Product Owner	Structure confirmed facts without inventing requirements	Google Docs, Notion, Markdown	Yes: draft from source information	`PROJECT-BRIEF.md`
Identify stakeholders	PM / Product Owner	Client	Client/Product Owner	List decision-makers, users, approvers and affected teams	Notion, Google Sheets	Yes: identify likely missing stakeholder categories	`STAKEHOLDER-REGISTER.md`
Create glossary	Business Analyst	Domain experts, developers	Product Owner	Define project-specific language and remove ambiguity	Notion, Google Docs	Yes: extract terms from notes	`GLOSSARY.md`
Create open questions	Business Analyst	Product owner, designer, technical lead	Relevant decision owner	Record missing or conflicting information	Notion, Google Docs	Yes: detect gaps and contradictions	`OPEN-QUESTIONS.md`
Record assumptions	Whoever identifies the gap	Product owner, technical lead, designer	Relevant decision owner	Clearly label unconfirmed beliefs and their impact	Notion, Google Sheets	Yes: suggest assumptions, never approve them	`ASSUMPTIONS.md`
Record constraints	Product Owner / Technical Lead	Client, legal, finance	Client/Product Owner	Document fixed limits such as budget, deadline, platform and required vendors	Notion, Google Docs	Yes: organise and classify	`CONSTRAINTS.md`
Create initial risk register	Project Manager	Entire team	Product Owner/Technical Lead	Identify delivery, business, technical and external risks	Google Sheets, Notion	Yes: suggest likely risks	`RISK-REGISTER.md`

AI prompt: project intake

You are assisting with software-project discovery.

Use only the information I provide. Do not invent facts or silently fill gaps.

From the attached notes, produce:

1. Confirmed facts
2. Business problem
3. Proposed product objective
4. Target users
5. Business goals
6. Known scope
7. Known constraints
8. Stakeholders
9. Contradictions
10. Missing information
11. Clarification questions
12. Proposed assumptions, clearly labelled as unconfirmed
13. Initial delivery risks

Separate facts, assumptions, decisions, requirements, constraints and risks.

Do not convert an assumption into a requirement.

Return a structured draft suitable for a PROJECT-BRIEF.md file.

Phase 2: Scope and product requirements

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Define product vision	Product Owner	Client, leadership	Client/Product Owner	State what change the product should create	Google Docs, Notion	Yes: help rewrite clearly	Vision section
Define product goals	Product Owner	Business stakeholders	Client/Product Owner	Select measurable outcomes	Notion, Google Sheets	Yes: propose measurable formats	Goals and success metrics
Define users and actors	Product Owner / Business Analyst	UX designer, operations	Product Owner	Confirm real roles and responsibilities	FigJam, Notion	Yes: extract likely actors	`ACTORS-AND-ROLES.md`
Define MVP scope	Product Owner	PM, technical lead, designer	Client/Product Owner	Decide what must ship first	Notion, Linear, GitHub Projects	Yes: group and highlight dependencies	`SCOPE.md`
Define out-of-scope items	Product Owner	Client, technical lead	Client/Product Owner	Prevent hidden expectations	Notion, Google Docs	Yes: detect implied extras	Out-of-scope section
Write functional requirements	Business Analyst / Product Owner	Designer, technical lead, developers	Product Owner	Define testable system behaviour	Notion, Google Docs, Markdown	Yes: draft and audit requirements	`FUNCTIONAL-REQUIREMENTS.md`
Write non-functional requirements	Technical Lead	Security, QA, product owner	Technical Lead/Product Owner	Define security, performance, reliability, accessibility and maintainability needs	Notion, Markdown	Yes: suggest categories and missing areas	`NON-FUNCTIONAL-REQUIREMENTS.md`
Add requirement IDs	Business Analyst	PM	Product Owner	Make every requirement traceable	Notion, Markdown	Yes: generate naming scheme	Requirement catalogue
Build traceability matrix	Business Analyst / QA	Product owner, technical lead	Product Owner	Link goals, requirements, flows, tickets and tests	Google Sheets, Notion database	Yes: generate initial links	`REQUIREMENTS-TRACEABILITY-MATRIX`

AI prompt: requirements

Act as a business analyst.

Inputs:
- Approved project brief
- Confirmed assumptions
- Constraints
- Open questions already answered
- Product goals

Produce a first draft of:

1. Functional requirements
2. Non-functional requirements
3. Out-of-scope items
4. Requirement dependencies
5. Ambiguous statements that still require clarification
6. A traceability table linking each requirement to a business goal

Rules:

- Assign stable IDs such as FR-AUTH-001 and NFR-SEC-001.
- Each requirement must describe observable or testable behaviour.
- Do not invent business rules.
- Do not decide priorities.
- Do not merge unrelated requirements.
- Mark uncertain statements as questions.
- Include success conditions and major failure conditions where known.

Phase 3: Domain analysis and business rules

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Identify domain concepts	Business Analyst / Technical Lead	Domain experts	Product Owner	Identify important business objects and meanings	FigJam, Notion	Yes: extract nouns and concepts	`DOMAIN-GLOSSARY.md`
Define business rules	Product Owner / Business Analyst	Domain experts, operations	Business Owner	Decide how the business operates	Notion, Google Docs	Yes: structure and find contradictions	`BUSINESS-RULES.md`
Define user roles	Product Owner	UX, technical lead	Product Owner	Confirm capabilities for each role	Notion, FigJam	Yes: build first-pass role list	`ACTORS-AND-ROLES.md`
Define permissions	Product Owner / Technical Lead	Security, QA	Product Owner/Technical Lead	Decide who may perform each action	Google Sheets, Notion	Yes: generate a matrix draft	`PERMISSION-MATRIX.md`
Define states	Business Analyst / Technical Lead	Product owner, QA	Product Owner	Confirm valid lifecycle states	Draw.io, Mermaid, FigJam	Yes: detect missing states	State-machine diagrams
Define transitions	Product Owner / Technical Lead	QA, developers	Product Owner	Approve valid and invalid transitions	Draw.io, Mermaid	Yes: find impossible or missing transitions	`STATE-MACHINES/`
Define calculations	Business Owner / Product Owner	Finance, technical lead	Business Owner	Confirm formulas, rounding and exceptions	Google Sheets, Notion	Yes: test examples, not decide formula	Decision tables
Define decision tables	Business Analyst / QA	Product owner	Product Owner	Explicitly document complex conditions	Google Sheets, Notion	Yes: generate table structure	`DECISION-TABLES/`

AI prompt: business rules

Review the approved requirements as a business-rules analyst.

Extract:

1. Actors
2. Business entities
3. Actions
4. Preconditions
5. State changes
6. Permission rules
7. Time-based rules
8. Financial or calculation rules
9. Approval rules
10. Cancellation, reversal and recovery rules
11. Notifications
12. Audit requirements

Then identify:

- Contradictory rules
- Rules without an owner
- Actions without a permission rule
- Statuses without valid transitions
- States with no exit
- Transitions without a triggering actor
- Missing failure behaviour

Do not decide missing rules. Convert them into questions.

Return drafts for:
- BUSINESS-RULES.md
- PERMISSION-MATRIX.md
- STATE-MACHINE.md
- DECISION-TABLES.md

Phase 4: Epics, features and roadmap

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Group requirements into epics	Product Owner / PM	Business analyst, technical lead	Product Owner	Organise related capabilities	Linear, Jira, GitHub Projects, Notion	Yes: suggest groupings	`EPIC-INVENTORY.md`
Break epics into features	Product Owner / Business Analyst	UX, technical lead	Product Owner	Define manageable user capabilities	Linear, GitHub Projects	Yes: propose feature catalogue	`FEATURE-CATALOGUE.md`
Identify dependencies	Technical Lead / PM	Developers, UX	Technical Lead	Determine required order	Draw.io, Notion, Linear	Yes: detect dependency chains	`DEPENDENCY-MAP.md`
Prioritise features	Product Owner	Client, PM, technical lead	Product Owner	Choose Must/Should/Could/Won’t	Linear, Notion	AI may provide impact analysis, not final priority	Prioritised backlog
Define releases	Product Owner / PM	Technical lead, QA	Product Owner	Group features into valuable releases	Linear, GitHub Projects	Yes: propose release groupings	`RELEASE-ROADMAP.md`
Estimate delivery	Technical Lead / Team	PM	Team/PM	Estimate complexity after enough detail exists	Planning Poker, Linear	AI may suggest risks, not commitments	Initial estimates

AI prompt: epics and features

Using the approved requirements and business rules:

1. Group requirements into coherent epics.
2. Break each epic into independently understandable features.
3. Give every epic and feature a stable ID.
4. Link every feature to its requirement IDs.
5. Identify dependencies.
6. Identify cross-cutting capabilities.
7. Flag features that are too large.
8. Flag features that combine unrelated user goals.
9. Suggest an MVP grouping, but do not make the final priority decision.

Return:

- EPIC-INVENTORY.md
- FEATURE-CATALOGUE.md
- DEPENDENCY-MAP.md
- Suggested release slices

Do not create development tickets yet.

Phase 5: User flows

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Create system flow map	Business Analyst / UX Designer	Product owner, technical lead	Product Owner	Show major capabilities and hand-offs	FigJam, Draw.io, Whimsical	Yes: check requirement coverage	`SYSTEM-FLOW-MAP`
Choose feature flow	Product Owner / UX	Business analyst	Product Owner	Select one prioritised feature	Linear, Notion	No major AI decision needed	Feature selected
Define flow goal	Product Owner	UX designer	Product Owner	State actor, trigger and desired outcome	Notion	Yes: rewrite clearly	Flow header
Draw happy path	UX Designer / Business Analyst	Product owner, developers	Product Owner	Model successful behaviour	FigJam, Draw.io, Whimsical	Yes: convert text to first draft	Business-flow diagram
Add decisions	UX / Business Analyst	Product owner	Product Owner	Confirm actual business decisions	FigJam, Draw.io	Yes: identify likely missing decisions	Updated flow
Add alternative paths	UX / Business Analyst	Product owner	Product Owner	Confirm valid alternate methods	FigJam, Draw.io	Yes: suggest branches	Alternative flows
Add exception paths	QA / Business Analyst	UX, technical lead	Product Owner/Technical Lead	Define failure and recovery behaviour	FigJam, Draw.io	Yes: generate edge-case checklist	`EDGE-CASES.md`
Create UI flow	UX Designer	UI designer, frontend engineer	Product Owner/Design Lead	Decide how business behaviour maps to screens	Figma, FigJam	Yes: suggest layouts	UI-flow diagram
Write flow specification	Business Analyst	UX, QA	Product Owner	Record all flow details in text	Markdown, Notion	Yes: generate from approved diagram	`FLOW-SPEC.md`

AI prompt: user-flow review

Review this approved feature:

- Requirement IDs:
- Business rules:
- Actors:
- Permissions:
- Current state machine:
- Human-created happy path:

Do not replace the happy path.

Audit it for:

1. Missing decisions
2. Validation failures
3. Permission failures
4. Duplicate submission
5. Cancellation
6. Retry behaviour
7. Timeout
8. Session expiry
9. External-service failure
10. Partial completion
11. Offline behaviour
12. Empty states
13. Notification failure
14. Audit requirements
15. Invalid state transitions
16. Alternative routes to the same goal

For every suggestion, provide:

- Suggested branch
- Trigger
- User-visible outcome
- System behaviour
- Recovery path
- Requirement or business rule affected
- Whether stakeholder confirmation is required

Do not add a branch automatically. Present suggestions for human approval.

Phase 6: Acceptance criteria and test planning

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Write acceptance criteria	Business Analyst / Product Owner	QA, UX, technical lead	Product Owner	Define what successful implementation means	Linear, GitHub Issues, Notion	Yes: draft from approved flows	`ACCEPTANCE-CRITERIA.md`
Create scenario inventory	QA	Product owner, developers	QA Lead/Product Owner	Cover success, failure and recovery	Google Sheets, TestRail, Notion	Yes: expand cases	`TEST-SCENARIO-INVENTORY.md`
Define critical journeys	QA / Product Owner	UX, technical lead	Product Owner	Identify journeys that must never fail	Notion, Playwright plan	Yes: suggest risk-based journeys	`E2E-CRITICAL-JOURNEYS.md`
Build traceability	QA / Business Analyst	PM	Product Owner	Link tests to requirements	Google Sheets, Notion	Yes: automate mapping draft	Updated traceability matrix

AI prompt: acceptance criteria

Generate draft acceptance criteria using only:

- Approved requirement
- Approved business rules
- Approved user flow
- Approved edge cases
- Permission matrix
- State machine

Use Given/When/Then where appropriate.

Cover:

1. Successful path
2. Validation failure
3. Permission failure
4. Invalid state
5. Duplicate action
6. External-service failure
7. Retry or recovery
8. Cancellation
9. Loading and submission behaviour
10. Accessibility expectations
11. Audit and notification expectations

Link every scenario to requirement and business-rule IDs.

Do not invent expected behaviour where none has been approved. Mark such cases as OPEN DECISION.

Phase 7: Information architecture and screen planning

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Create information architecture	UX Designer	Product owner, business analyst	Product Owner	Organise content and navigation	FigJam, Figma, Whimsical	Yes: suggest grouping	`INFORMATION-ARCHITECTURE.md`
Create sitemap	UX Designer	Product owner	Product Owner	Define page hierarchy	FigJam, Draw.io	Yes: generate draft from flows	`SITEMAP`
Create screen inventory	UX Designer / Business Analyst	Frontend engineer, QA	Product Owner	List every required screen and state	Notion, Google Sheets	Yes: derive from flows	`SCREEN-INVENTORY.md`
Define route map	Frontend Lead / UX	Product owner	Technical Lead	Decide URL and access structure	Markdown, Draw.io	Yes: draft route map	`ROUTE-MAP.md`
Define navigation model	UX Designer	UI designer, frontend engineer	Product Owner	Decide global and local navigation	Figma, FigJam	Yes: compare alternatives	`NAVIGATION-MODEL.md`
Identify reusable patterns	UX/UI Designer	Frontend engineer	Design Lead	Reduce repeated unique designs	Figma, Notion	Yes: detect repetition	`PATTERN-LIBRARY.md`

AI prompt: screen inventory

Using the approved user flows, create a screen inventory.

For each screen include:

- Screen name
- Purpose
- Actors
- Entry flows
- Exit flows
- Main actions
- Data displayed
- Permissions
- Required states
- Responsive considerations
- Reusable pattern
- Requirement IDs

Required states may include:

- Default
- Loading
- Empty
- Error
- Validation
- Submitting
- Disabled
- Permission denied
- Partial data
- Success

Also identify:

- Duplicate screens
- Screens with too many responsibilities
- Screens that can reuse the same pattern
- Flows that have no screen representation
- Screens that have no linked flow

Phase 8: Wireframes and UX design

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Wireframe feature flow	UX Designer	Product owner, frontend engineer	Product Owner	Decide content hierarchy and interaction structure	Figma, Penpot, FigJam	Yes: scaffold alternatives	`WIREFRAMES`
Annotate behaviour	UX Designer	Business analyst, QA	Product Owner	Explain states and transitions	Figma notes, Markdown	Yes: create draft annotations	`WIREFRAME-ANNOTATIONS.md`
Create state matrix	UX / QA	Frontend engineer	Product Owner	Confirm each screen state	Google Sheets, Notion	Yes: derive from flows	`SCREEN-STATE-MATRIX.md`
Prototype critical flow	UX Designer	Product owner	Product Owner	Make the complete flow testable	Figma prototype	Yes: assist with repetitive connections	Clickable prototype
Conduct UX review	Product Owner / UX	Users, QA	Product Owner	Validate usability and flow clarity	Figma, Maze, meetings	AI may summarise feedback	UX review notes

AI prompt: wireframe assistant

You are assisting with low-fidelity UX design.

Use the supplied:

- Screen inventory
- User flow
- Acceptance criteria
- Business rules
- Permission rules

Generate wireframe recommendations for the selected feature.

Focus only on:

- Information hierarchy
- Navigation
- Main actions
- Form structure
- Feedback placement
- Loading, empty, error and permission states
- Responsive priority

Do not apply a visual design style.

Provide:

1. Recommended screen structure
2. Required components
3. Interaction notes
4. Screen-state variations
5. Mobile adaptations
6. Alternative layout options and trade-offs
7. Questions requiring human decision

Phase 9: Design system and high-fidelity design

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Choose design direction	UI Designer / Product Owner	Brand stakeholders	Design Owner/Product Owner	Select visual language	Figma, reference boards	Yes: analyse visual references	`DESIGN-DIRECTION.md`
Define design tokens	UI Designer	Frontend engineer	Design Lead	Confirm colours, type, spacing, radius, shadow and motion	Figma Variables, Tokens Studio	Yes: propose values	`DESIGN-TOKENS.json`
Build core components	UI Designer	Frontend engineer	Design Lead	Create reusable component variants	Figma	Yes: scaffold states	Figma component library
Design anchor screens	UI Designer	UX, product owner	Product Owner/Design Lead	Establish patterns for the product	Figma	Yes: generate variations	Hi-fi anchor screens
Define responsive rules	UI/UX Designer	Frontend engineer	Design Lead	Decide behaviour by viewport	Figma	Yes: check omissions	`RESPONSIVE-SPECS.md`
Define interactions and motion	UI/UX Designer	Frontend engineer	Design Lead	Specify purposeful motion	Figma prototype	Yes: suggest restrained patterns	`INTERACTION-SPECS.md`
Create component specifications	UI Designer / Frontend Lead	QA	Design Lead	Document states and behaviour	Figma Dev Mode, Storybook later	Yes: draft specs	`COMPONENT-SPECS.md`

AI prompt: visual design

The attached reference images define visual language only.

They do not define my application's content, business domain or screen layout.

Reverse engineer:

- Layout rhythm
- Typography scale
- Colour composition
- Surface hierarchy
- Border treatment
- Shadow mechanics
- Radius hierarchy
- Icon scale and stroke
- Card composition
- List composition
- Form treatment
- Table treatment
- Chart treatment
- Navigation treatment
- Interaction language
- Visual density
- Repeated component patterns

Then apply the extracted design grammar to the supplied wireframes.

Preserve:

- User flow
- Information hierarchy
- Functionality
- Required states
- Accessibility
- Responsiveness

Do not expose default shadcn styling.
Do not merely copy colours.
Do not copy the reference's business content.
Do not create unrelated decoration.

Produce:

1. Design DNA
2. Token recommendations
3. Component rules
4. Anchor-screen directions
5. States and variants
6. Responsive rules
7. Prohibited patterns

Phase 10: Architecture

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Identify architectural constraints	Technical Lead	Product owner, security, developers	Technical Lead	Confirm scale, team, budget, integrations and compliance	Notion, Markdown	Yes: organise constraints	Architecture context
Propose architecture options	Technical Lead	Senior developers	Technical Lead	Compare viable options	Draw.io, Structurizr, Mermaid	Yes: produce option analysis	Architecture options
Choose architecture	Technical Lead	Product owner, team	Technical Owner	Make and own decision	ADR documents	AI cannot approve	ADR
Create system context diagram	Architect	Product owner	Technical Lead	Show actors and external systems	Draw.io, Structurizr	Yes: draft from approved actors	System context
Create container diagram	Architect	Developers, DevOps	Technical Lead	Show deployable applications and data stores	Draw.io, Structurizr	Yes: draft alternatives	Container diagram
Define module boundaries	Technical Lead	Backend/frontend leads	Technical Lead	Assign responsibility and ownership	Draw.io, Markdown	Yes: detect coupling risks	Module diagram
Define data flows	Architect	Security, developers	Technical Lead	Show where data enters, moves and leaves	Draw.io	Yes: detect missing trust boundaries	Data-flow diagram
Define deployment model	Architect/DevOps	Technical lead	Technical Lead	Decide environments and hosting	Draw.io, cloud docs	Yes: compare options	Deployment diagram
Record decisions	Technical Lead	Team	Technical Lead	Explain reasons and trade-offs	Markdown ADRs	Yes: draft ADR	`ADRs/`
Threat modelling	Security/Technical Lead	Developers	Security/Technical Lead	Identify abuse and security threats	OWASP Threat Dragon, Draw.io	Yes: suggest threats	`THREAT-MODEL.md`

AI prompt: architecture

Act as an architecture-review assistant.

Inputs:

- Approved PRD
- Non-functional requirements
- Business rules
- State machines
- User flows
- Team size and skills
- Expected usage
- Budget
- Deployment constraints
- Required integrations
- Security requirements

Provide three viable architecture options.

For each option include:

1. System structure
2. Module boundaries
3. Data ownership
4. Deployment model
5. Advantages
6. Disadvantages
7. Operational complexity
8. Security implications
9. Scaling limits
10. Cost implications
11. Team-skill requirements
12. Migration or exit path
13. Conditions under which this option should be chosen

Do not select the final architecture.

Flag any requirement that cannot be supported by an option.

After a human chooses an option, generate a draft ADR without changing the decision.

Phase 11: Database, API and integration design

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Identify entities	Backend Lead / Architect	Business analyst	Technical Lead	Map business concepts to persistent data	dbdiagram.io, Draw.io	Yes: extract candidate entities	Entity list
Design ERD	Backend Lead	Technical lead	Technical Lead	Define relationships and constraints	dbdiagram.io, Draw.io	Yes: draft schema	`DATABASE-ERD`
Create data dictionary	Backend Engineer	Business analyst	Technical Lead	Define every field and rule	Google Sheets, Markdown	Yes: generate initial table	`DATA-DICTIONARY.md`
Define database constraints	Backend Lead	QA, technical lead	Technical Lead	Protect data integrity	PostgreSQL migrations	Yes: identify likely constraints	Migration plan
Define API operations	Backend/Frontend Leads	Product owner	Technical Lead	Agree contracts before implementation	OpenAPI, Bruno, Scalar	Yes: draft endpoints	`API-SPEC.yaml`
Define errors	Backend Lead	Frontend, QA	Technical Lead	Standardise error behaviour	OpenAPI, Markdown	Yes: generate catalogue	`ERROR-CATALOGUE.md`
Define events/webhooks	Backend Lead	Integrations, QA	Technical Lead	Specify asynchronous behaviour	AsyncAPI, Markdown	Yes: draft event catalogue	`EVENT-CATALOGUE.md`
Define integration contracts	Technical Lead	External provider owners	Technical Lead	Confirm external dependencies and failures	Bruno, OpenAPI, provider sandbox	Yes: produce test matrix	Integration specs

AI prompt: database and API

Using the approved:

- Requirements
- Business rules
- State machines
- Permission matrix
- User flows
- Architecture boundaries

Draft:

1. Candidate entities
2. Relationships
3. Primary and foreign keys
4. Important constraints
5. Index candidates based on known queries
6. Nullable-field review
7. Audit fields
8. Data-retention concerns
9. API endpoints
10. Request and response schemas
11. Error codes
12. Idempotency requirements
13. Webhooks or events
14. Transaction boundaries

Rules:

- Do not invent business fields.
- Link each table and endpoint to requirements.
- Distinguish database constraints from application rules.
- Highlight uncertain modelling decisions.
- Do not generate production migrations until the schema is approved.

Phase 12: Sprint and ticket preparation

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Set sprint goal	Product Owner / PM	Team	Product Owner	Define one valuable outcome	Linear, Jira, GitHub Projects	AI may help rewrite	Sprint goal
Select ready features	Product Owner / PM	Technical lead, QA	Product Owner	Choose work meeting Definition of Ready	Project board	AI can flag incomplete features	Sprint backlog
Break features into tickets	Technical Lead / Team	PM, QA, designer	Team	Define implementable tasks	Linear, GitHub Issues	Yes: draft task breakdown	Tickets
Estimate tickets	Developers	Technical lead, PM	Team	Estimate complexity collaboratively	Planning Poker, Linear	AI can highlight hidden work	Estimates
Assign tickets	PM / Technical Lead	Team	PM/Technical Lead	Match work to capacity	Linear, GitHub Projects	Limited AI usefulness	Assigned sprint
Track dependencies	PM	Team	PM	Prevent blocked work	Linear, Jira	Yes: detect dependency risks	Dependency view
Confirm Definition of Ready	Product Owner/Technical Lead	QA, designer	Team	Ensure no missing input	Checklist	Yes: audit readiness	Ready tickets

AI prompt: ticket generation

Create development tickets for this approved feature.

Inputs:

- Feature specification
- Requirement IDs
- Business rules
- User flow
- Acceptance criteria
- Design references
- API contract
- Database impact
- Architecture rules
- Testing requirements

Break the feature into the smallest coherent implementation units.

Consider:

- Database migration
- Domain logic
- API handler
- Authentication and authorisation
- Validation
- Frontend data layer
- UI components
- Loading, empty and error states
- Responsive behaviour
- Accessibility
- Unit tests
- Integration tests
- E2E tests
- Observability
- Documentation
- Deployment concerns

For every ticket include:

- Title
- Type
- Objective
- Scope
- Out of scope
- Dependencies
- Requirement IDs
- Acceptance criteria
- Tests required
- Risks
- Definition of Done

Do not create implementation details that conflict with the approved architecture.

Phase 13: Repository setup and engineering rules

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Create repository	Technical Lead	Developers	Technical Lead	Establish ownership and access	GitHub	No substantial AI need	Repository
Define branch strategy	Technical Lead	Team	Technical Lead	Decide main, staging and feature branches	GitHub	Yes: draft conventions	`CONTRIBUTING.md`
Define project structure	Technical Lead	Developers	Technical Lead	Establish module and file boundaries	Markdown	Yes: draft from architecture	`ARCHITECTURE.md`
Define coding conventions	Technical Lead	Team	Technical Lead	Standardise naming, validation, errors and tests	ESLint, Prettier, TypeScript	Yes: draft rules	`ENGINEERING-CONVENTIONS.md`
Define agent rules	Technical Lead	Developers	Technical Lead	Control AI coding behaviour	`AGENTS.md`, Copilot instructions	Yes: generate from conventions	`AGENTS.md`
Configure CI	DevOps/Technical Lead	Developers	Technical Lead	Automate verification	GitHub Actions	Yes: draft workflow	CI pipeline
Configure environments	DevOps	Technical lead	Technical Lead	Create dev, staging and production boundaries	Vercel, Render, Supabase, cloud platform	AI can draft runbooks	Environment setup

AI prompt: repository guardrails

Create a repository-specific AGENTS.md using these approved documents:

- ARCHITECTURE.md
- ENGINEERING-CONVENTIONS.md
- TEST-STRATEGY.md
- SECURITY.md
- Design-system rules
- Branching strategy

The file must instruct coding agents to:

1. Inspect relevant files before editing.
2. Produce a plan before non-trivial changes.
3. Never invent requirements.
4. Stop when documents conflict.
5. Stay within assigned ticket scope.
6. Respect module boundaries.
7. Reuse existing patterns.
8. Avoid unnecessary dependencies.
9. Preserve public contracts.
10. Use version-controlled migrations.
11. Add or update tests.
12. Run lint, typecheck and tests.
13. Report commands executed.
14. Never claim unexecuted tests passed.
15. Keep diffs small and reviewable.
16. Protect secrets and sensitive data.
17. Avoid modifying generated or protected files.

Phase 14: Development

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Investigate repository	Assigned developer	Technical lead	Developer/Lead	Understand existing implementation	VS Code, GitHub	Yes: repository analysis	Investigation notes
Create implementation plan	Assigned developer	Technical lead	Technical Lead for complex work	Decide approach before editing	Markdown, issue comments	Yes: draft plan	Implementation plan
Implement database changes	Backend engineer	Technical lead	Code reviewer	Write safe migrations	PostgreSQL, migration tool	Yes: draft, human reviews every line	Migration
Implement domain logic	Backend engineer	Technical lead	Code reviewer	Enforce approved rules	IDE, tests	Yes: pair-programming	Domain code
Implement APIs	Backend engineer	Frontend engineer	Code reviewer	Match approved contract	OpenAPI, Bruno	Yes: scaffold	API code
Implement UI	Frontend engineer	Designer	Code reviewer	Match design and behaviour	Next.js, React, Tailwind, shadcn	Yes: scaffold and refactor	UI code
Connect frontend/backend	Frontend/backend	QA	Code reviewer	Handle contract and failures	TanStack Query, API client	Yes: generate typed clients	Integrated feature
Add observability	Backend/DevOps	QA	Technical Lead	Add useful logs and metrics	Sentry, logs	Yes: suggest events	Logging and monitoring
Write tests	Developer/QA	Product owner for behaviour	Code reviewer	Validate approved behaviour	Vitest, Playwright, Testing Library	Yes: generate test drafts	Automated tests
Self-review	Developer	AI reviewer optional	Human reviewer	Check diff before PR	Git diff, linting	Yes: secondary review	Clean PR

AI prompt: implementation workflow

Implement the assigned ticket only.

Before changing code:

1. Read AGENTS.md.
2. Read the linked requirement, business rules, flow, acceptance criteria and architecture documents.
3. Inspect the relevant repository modules.
4. Identify existing patterns.
5. List candidate files.
6. Report assumptions or conflicts.
7. Produce an implementation plan.

Do not edit files until the plan is approved.

After approval:

- Keep the change within ticket scope.
- Reuse existing abstractions.
- Preserve contracts.
- Do not introduce dependencies without justification.
- Add tests for behaviour changes.
- Handle loading, empty, error and permission states.
- Run required verification commands.
- Report files changed, decisions made, tests run and unresolved limitations.

Never claim success without executed verification.

Phase 15: Storybook and component verification

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Identify components needing stories	Frontend Lead	UI designer, QA	Frontend Lead	Select reusable/state-heavy components	Storybook	Yes: analyse component complexity	Story list
Create stories	Frontend Engineer	Designer	Code reviewer	Represent important states	Storybook	Yes: generate first draft	`*.stories.tsx`
Add accessibility checks	Frontend/QA	Designer	QA	Verify semantics and keyboard use	Storybook a11y, axe	Yes: suggest fixes	Accessibility results
Add interaction tests	Frontend/QA	Product owner	QA	Validate component behaviour	Storybook Test, Testing Library	Yes: draft tests	Interaction tests
Add visual regression	QA/Frontend	Designer	QA/Design	Detect unintended visual changes	Chromatic or screenshot tests	Limited AI use	Baseline images

AI prompt: Storybook

Create Storybook coverage for this reusable component.

Analyse its props and approved behaviour.

Include only meaningful states:

- Default
- Loading
- Empty
- Error
- Disabled
- Long content
- Short content
- Mobile width
- Desktop width
- Permission variations
- Dark mode, where supported
- Important interactions

Also generate:

- Interaction tests
- Accessibility checks
- Realistic mock data

Do not create stories for meaningless prop combinations.
Do not change the component API unless necessary and justified.

Phase 16: QA and review

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Static verification	Developers	CI	Technical Lead	Maintain clean types and lint	TypeScript, ESLint	AI can help fix errors	Passing checks
Unit testing	Developers	QA	Code reviewer	Validate isolated logic	Vitest	Yes: draft cases	Unit tests
Integration testing	Developers/QA	Backend/frontend	QA	Validate modules together	Vitest, test database	Yes: draft tests	Integration suite
Contract testing	Backend/frontend	QA	Technical Lead	Ensure API agreement	OpenAPI, Bruno	Yes: generate checks	Contract tests
E2E testing	QA	Developers	QA	Validate critical journeys	Playwright	Yes: draft scripts	E2E tests
Exploratory testing	QA	Product owner, users	QA/Product Owner	Find unexpected problems	Browser, devices	AI can generate charters	QA notes
Accessibility testing	QA/UI/Frontend	Users where possible	QA/Design	Validate real usability	axe, keyboard, screen reader	AI can suggest issues	A11y report
Performance testing	Technical Lead/QA	DevOps	Technical Lead	Verify agreed performance	Lighthouse, k6	AI can analyse results	Performance report
Security review	Security/Technical Lead	Developers	Security/Technical Lead	Verify sensitive behaviour	OWASP tools, manual review	Yes: secondary audit	Security checklist
Code review	Human reviewer	AI reviewer optional	Reviewer	Approve correctness and maintainability	GitHub PR	Yes: secondary reviewer	Approved PR

AI prompt: code and test review

Review this pull request as an independent reviewer.

Use:

- Requirement IDs
- Business rules
- Acceptance criteria
- Architecture rules
- API contracts
- Security requirements

Review in this order:

1. Requirement correctness
2. Business-rule correctness
3. Permissions and security
4. Data integrity
5. State transitions
6. Error and recovery behaviour
7. Contract compatibility
8. Missing tests
9. Test quality
10. Architecture boundaries
11. Maintainability
12. Performance
13. Accessibility

For every issue include:

- Severity
- File and location
- Why it matters
- Requirement affected
- Suggested correction

Do not approve the pull request. Human review is required.

Phase 17: Staging and user acceptance

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Deploy to staging	DevOps	Technical lead	Technical Lead	Make release candidate available safely	GitHub Actions, hosting platform	AI can draft pipeline	Staging release
Run smoke tests	QA	Developers	QA	Confirm system basics	Playwright, checklist	Yes: generate checklist	Smoke-test report
Conduct UAT	Product Owner/Client	QA, business users	Client/Product Owner	Confirm business outcomes	Staging, test script	AI can draft scripts	`UAT-RESULTS.md`
Record bugs	QA	Developers	QA/Product Owner	Capture reproducible evidence	GitHub Issues, Linear	Yes: structure raw reports	`BUG-REGISTER.md`
Prioritise defects	Product Owner/QA/Technical Lead	PM	Product Owner	Decide release blockers	Linear, Jira	AI may classify risk	Defect priorities
Run regression	QA	Developers	QA	Confirm fixes did not break behaviour	Playwright, manual checks	Yes: suggest affected areas	Regression report

AI prompt: UAT preparation

Create a user-acceptance-test plan from:

- Approved features
- Acceptance criteria
- Critical user flows
- User roles

For each UAT scenario include:

- Scenario ID
- Business purpose
- Tester role
- Preconditions
- Test data
- Steps
- Expected result
- Requirement IDs
- Pass/fail/blocked fields

Focus on user outcomes, not implementation details.

Include success, failure and permission scenarios.

Phase 18: Release and deployment

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Prepare release plan	DevOps/Technical Lead	QA, PM	Technical Lead/Product Owner	Define deployment sequence	Markdown, GitHub	Yes: draft runbook	`DEPLOYMENT-PLAN.md`
Prepare migration plan	Backend Lead	DevOps	Technical Lead	Protect production data	Migration tooling	Yes: analyse risk	`MIGRATION-RUNBOOK.md`
Prepare rollback plan	Technical Lead/DevOps	Backend/frontend	Technical Lead	Define recovery before release	Markdown	Yes: draft scenarios	`ROLLBACK-PLAN.md`
Prepare release notes	Product Owner/PM	Developers	Product Owner	Explain user-facing changes	Markdown	Yes: generate from merged PRs	`RELEASE-NOTES.md`
Approve production release	Product Owner/Technical Lead	QA	Product Owner/Technical Lead	Make final go/no-go decision	Release checklist	AI cannot approve	Release approval
Deploy	DevOps	Technical lead	Technical Lead	Execute approved runbook	CI/CD	AI may assist automation	Production deployment
Run production smoke tests	QA/DevOps	Developers	QA/Technical Lead	Verify critical health	Playwright, monitoring	Yes: draft checklist	Smoke-test results
Monitor release	DevOps/Technical Lead	Developers	Technical Lead	Watch errors, latency and behaviour	Sentry, PostHog, uptime monitor	Yes: summarise signals	Release monitoring report

AI prompt: release preparation

Prepare a release runbook using:

- Features included
- Pull requests
- Database migrations
- Environment changes
- External integrations
- Test results
- Known limitations

Produce:

1. Pre-deployment checklist
2. Deployment sequence
3. Migration sequence
4. Smoke tests
5. Monitoring signals
6. Rollback triggers
7. Rollback procedure
8. Communication plan
9. Post-deployment verification
10. Known risks

Do not authorise deployment.
Clearly mark every human approval gate.

Phase 19: Operations and continuous improvement

Workflow	Main owner	Contributors	Approver	Human responsibility	Tools	AI use	Required output
Monitor errors	Technical Lead/DevOps	Developers	Technical Lead	Investigate meaningful production failures	Sentry	Yes: cluster and summarise	Error reports
Monitor product usage	Product Owner	Data analyst, UX	Product Owner	Interpret whether product goals are achieved	PostHog, GA	Yes: summarise patterns	Product metrics
Manage incidents	Technical Lead	DevOps, developers	Technical Lead	Restore service and coordinate response	Incident channel, runbooks	Yes: timeline drafting	Incident record
Write postmortems	Technical Lead	Entire incident team	Technical Lead	Identify root cause without blame	Markdown	Yes: draft from evidence	Postmortem
Track technical debt	Technical Lead	Developers	Technical Lead/Product Owner	Record debt and business impact	Linear, GitHub Issues	Yes: classify debt	`TECHNICAL-DEBT-REGISTER.md`
Review product feedback	Product Owner	Support, users	Product Owner	Decide what feedback enters roadmap	Notion, Linear	Yes: cluster feedback	Product learnings
Plan next release	Product Owner/PM	Team	Product Owner	Select next valuable outcome	Linear, roadmap	Yes: dependency and impact analysis	Updated roadmap

AI prompt: post-release review

Analyse these post-release inputs:

- Error reports
- Support tickets
- Usage metrics
- UAT comments
- Incident records
- Team feedback

Produce:

1. Repeated issues
2. User-experience problems
3. Technical failures
4. Suspected root causes
5. Requirements that may be incorrect
6. Missing tests
7. Technical debt introduced
8. Product opportunities
9. Recommended investigations
10. Possible backlog items

Separate evidence from inference.

Do not automatically recommend a feature merely because one user requested it.

Complete authority matrix

Decision or activity	AI may assist	AI may draft	AI may execute	Human approval required
Summarise meeting notes	Yes	Yes	Yes	Review
Define business problem	Assist	Draft	No	Yes
Create project brief	Yes	Yes	No	Yes
Propose assumptions	Yes	Yes	No	Yes
Confirm assumptions	No	No	No	Yes
Define scope	Assist	Draft	No	Yes
Prioritise MVP	Suggest	Draft options	No	Yes
Write requirements	Yes	Yes	No	Yes
Invent requirements	No	No	No	Yes
Define business rules	Structure	Draft	No	Yes
Approve business rules	No	No	No	Yes
Suggest edge cases	Yes	Yes	No	Yes
Draw initial flows	Yes	Yes	Yes	Yes
Choose UX layout	Suggest	Draft	No	Yes
Generate wireframes	Yes	Yes	Yes	Yes
Choose visual direction	Suggest	Draft	No	Yes
Generate design variants	Yes	Yes	Yes	Yes
Choose architecture	Suggest options	Yes	No	Yes
Write ADR	Yes	Yes	No	Yes
Draft database schema	Yes	Yes	No	Yes
Apply production migration	Assist	Draft	Controlled	Yes
Generate tickets	Yes	Yes	Yes	Review
Estimate delivery	Suggest risk	No final estimate	No	Team
Generate code	Yes	Yes	Yes	Review
Generate tests	Yes	Yes	Yes	Review
Approve its own code	No	No	No	Human
Merge pull request	No	No	No	Human
Approve release	No	No	No	Human
Deploy production	Assist	Prepare	Controlled	Human
Interpret product strategy	Assist	Options	No	Product Owner

Minimum workflow for a solo developer

When you are working alone, use this responsibility model:

Responsibility	You act as
Business clarification	Business analyst
Scope and priority	Product owner
Timeline and tracking	Project manager
User flows and wireframes	UX designer
Visual system	UI designer
Technical decisions	Technical lead
Implementation	Developer
Verification	QA
Deployment	DevOps

You should deliberately change “hats.”

Do not make all decisions while coding.

Use this sequence:

Business-analyst mode
→ Product-owner mode
→ UX mode
→ Architecture mode
→ Planning mode
→ Developer mode
→ Reviewer mode
→ QA mode
→ Release mode

Universal AI prompt wrapper

Use this before any phase-specific prompt:

# Project control rules

You are assisting me, not acting as the final decision-maker.

Use only approved project documents as sources of truth.

You must:

1. Separate facts, requirements, assumptions, decisions, risks and suggestions.
2. Never invent missing business behaviour.
3. Mark uncertainty clearly.
4. Ask questions when documents conflict.
5. Link recommendations to requirement or rule IDs.
6. Present options and trade-offs for important decisions.
7. Never silently change scope.
8. Never approve your own output.
9. Produce reviewable drafts.
10. Preserve human ownership of product, architecture, security and release decisions.

Current task:
[INSERT PHASE-SPECIFIC PROMPT]

The central rule is:

AI may prepare almost every artifact, but the correct human owner must still supply the facts, evaluate the options and approve the result.