template-instructions 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md ADDED
@@ -0,0 +1,97 @@
1
+ # TeamLifecycle Instructions
2
+
3
+ > **Simulating a complete Software Development Lifecycle (SDLC) with specialized AI Agents.**
4
+
5
+ ## 🎯 Overview
6
+
7
+ This repository contains the instruction sets and templates for **TeamLifecycle**, a project designed to simulate a professional SDLC using Gemini agents acting as specialized roles (Project Manager, Solution Architect, Developer, etc.).
8
+
9
+ By invoking specific roles using `@tags`, you can trigger a coordinated workflow that takes a project from planning to deployment and reporting.
10
+
11
+ ## ✨ Why Use TeamLifecycle? (Benefits & Optimization)
12
+
13
+ Adopting this **Agentic SDLC** approach offers significant advantages over standard single-agent coding:
14
+
15
+ ### 1. πŸš€ Optimized Process & Quality Assurance
16
+ - **Zero Ambiguity**: By splitting **Planning**, **Design**, and **Implementation**, potential issues are caught *before* code is written.
17
+ - **Strict "Definition of Done"**: Code isn't just "written"; it's **designed**, **reviewed**, **security-checked**, **implemented**, and **tested**.
18
+ - **Self-Correction**: The workflow includes loop-backs (cycle repeats) if a design is rejected or critical bugs are found, ensuring the final output is robust.
19
+
20
+ ### 2. 🧠 Specialized Intelligence (Agentic Roles)
21
+ Instead of one "generic" AI trying to do everything, you get specialized experts:
22
+ - **@SA** thinks purely about *scalability and database structure*.
23
+ - **@UIUX** focuses solely on *user flow and aesthetics*.
24
+ - **@SECA** acts as a dedicated adversary to find *vulnerabilities*.
25
+ - **@DEV** can focus purely on *implementation details* without worrying about high-level architecture.
26
+
27
+ ### 3. πŸ“š Comprehensive Documentation (Audit Trail)
28
+ - This system **automatically generates** a full project documentation suite (`docs/`):
29
+ - Requirement Plans & Backlogs
30
+ - Technical & Design Specs
31
+ - Security & QA Reports
32
+ - Test Results & Change Logs
33
+ - This makes "handover" to human teams or other agents seamless.
34
+
35
+ ### 4. ⚑ Benefit Analysis
36
+ | Feature | Traditional AI Coding | TeamLifecycle (Agentic) |
37
+ | :--- | :--- | :--- |
38
+ | **Context** | Often loses context in long chats | Structured artifacts preserve context per Sprint |
39
+ | **Safety** | May generate insecure code | Dedicated **@SECA** review step |
40
+ | **Architecture** | Often "spaghetti code" | Planned by **@SA** before implementation |
41
+ | **Debugging** | User has to debug | **@TESTER** finds bugs, **@DEV** fixes them |
42
+
43
+ ### 5. πŸ”„ Sprint-Based Organization
44
+ - Optimized for iterative development.
45
+ - Keeps files organized by Sprint (`docs/sprints/sprint-X/`), preventing clutter and ensuring version control.
46
+
47
+ ## πŸ“ Repository Structure
48
+
49
+ ```
50
+ .
51
+ β”œβ”€β”€ instructions/
52
+ β”‚ β”œβ”€β”€ global.md # Mandatory global rules and SDLC workflows
53
+ β”‚ β”œβ”€β”€ usage.md # Detailed usage guide and examples
54
+ β”‚ β”œβ”€β”€ roles/ # Role-specific instruction definitions
55
+ β”‚ β”‚ β”œβ”€β”€ pm.md, po.md, sa.md... # (PM, PO, SA, UIUX, QA, etc.)
56
+ β”‚ └── templates/ # Standardized document templates
57
+ β”‚ β”œβ”€β”€ Project-Plan-Template.md
58
+ β”‚ β”œβ”€β”€ Product-Backlog-Template.md
59
+ β”‚ └── ...
60
+ └── README.md # This file
61
+ ```
62
+
63
+ ## πŸš€ Quick Start
64
+
65
+ 1. **Start a Project**: Invoke the Project Manager (`@PM`) with your idea.
66
+ ```text
67
+ @PM - I want to build a personal finance dashboard.
68
+ ```
69
+ 2. **Approve Plan**: The PM will create a plan. Review and reply `Approved`.
70
+ 3. **Watch the Magic**: The agents will automatically hand off work through the phases:
71
+ `PM β†’ SA/UIUX/PO β†’ QA/SecA β†’ DEV/DevOps β†’ TESTER β†’ REPORTER`
72
+
73
+ ## πŸ“‹ Available Roles
74
+
75
+ | Tag | Role | Responsibility |
76
+ | :--- | :--- | :--- |
77
+ | `@PM` | **Project Manager** | Planning & Coordination |
78
+ | `@PO` | **Product Owner** | Backlog & Prioritization |
79
+ | `@SA` | **Solution Architect** | Backend & API Design |
80
+ | `@UIUX` | **UI/UX Designer** | Interface & UX Design |
81
+ | `@QA` | **QA Analyst** | Design Review & Quality Standards |
82
+ | `@SECA` | **Security Analyst** | Security Audits |
83
+ | `@DEV` | **Developer** | Implementation |
84
+ | `@DEVOPS` | **DevOps Engineer** | CI/CD & Deployment |
85
+ | `@TESTER` | **Tester** | Verification & Validation |
86
+ | `@REPORTER` | **Reporter** | Documentation & Reporting |
87
+ | `@STAKEHOLDER`| **Stakeholder** | Final Approval |
88
+
89
+ ## πŸ“š Documentation
90
+
91
+ For detailed instructions, rules, and workflows, please refer to:
92
+
93
+ * **[Usage Guide](instructions/usage.md)**: How to use the system, examples, and commands.
94
+ * **[Global Rules](instructions/global.md)**: The strict SDLC protocols and rules every agent follows.
95
+
96
+ ---
97
+ *Maintained by the TeamLifecycle Project Team.*
package/bin/cli.js ADDED
@@ -0,0 +1,22 @@
1
+ #! /usr/bin/env node
2
+
3
+ import fs from 'fs-extra';
4
+ import path from 'path';
5
+ import { fileURLToPath } from 'url';
6
+
7
+ const __dirname = path.dirname(fileURLToPath(import.meta.url));
8
+ const projectName = process.argv[2] || 'my-new-project';
9
+ const targetPath = path.join(process.cwd(), projectName);
10
+ const templatePath = path.join(__dirname, '../.instructions'); // Folder containing your template files
11
+
12
+ async function scaffold() {
13
+ try {
14
+ console.log(`πŸš€ Creating project in ${targetPath}...`);
15
+ await fs.copy(templatePath, targetPath);
16
+ console.log('βœ… Project created successfully!');
17
+ } catch (err) {
18
+ console.error('❌ Error:', err);
19
+ }
20
+ }
21
+
22
+ scaffold();
@@ -0,0 +1,295 @@
1
+ # TeamLifecycle Global Rules & Conventions
2
+ (Version 1.1 – Strict IT SDLC Simulation for Google Antigravity)
3
+
4
+ **Last Updated:** 2025-12-23
5
+ **Maintainer:** Project Team
6
+
7
+ ---
8
+
9
+ ## Purpose
10
+ This document defines the mandatory rules, conventions, and lifecycle flow that EVERY agent in the TeamLifecycle workflow MUST follow without exception.
11
+ It ensures strict compliance, full traceability, auto-communication, and professional software development process.
12
+
13
+ ---
14
+
15
+ ## Strict SDLC Flow (NO SKIPPING PHASES – EVER)
16
+
17
+ ```
18
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
19
+ β”‚ 1. Planning │───▢│ 2. Plan Approval│───▢│ 3. Designing β”‚
20
+ β”‚ (PM) β”‚ β”‚ (User) β”‚ β”‚ (SA + UIUX + PO) β”‚
21
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
22
+ β”‚
23
+ β–Ό
24
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
25
+ β”‚ 6. Testing │◀───│ 5. Development │◀───│ 4. Design Verification β”‚
26
+ β”‚ (TESTER) β”‚ β”‚ (DEV + Ops) β”‚ β”‚ (QA + SecA) β”‚
27
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
28
+ β”‚
29
+ β–Ό
30
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
31
+ β”‚ 7. Bug Fixing │───▢│ 8. Deployment │───▢│ 9. Reporting β”‚
32
+ β”‚ (DEV + Ops) β”‚ β”‚ (DevOps) β”‚ β”‚ (REPORTER) β”‚
33
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
34
+ β”‚
35
+ β–Ό
36
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
37
+ β”‚ ↩ Cycle Repeat │◀───│ 10. Final Review β”‚
38
+ β”‚ (if rejected) β”‚ β”‚ (STAKEHOLDER) β”‚
39
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
40
+ β”‚ βœ… Approved
41
+ β–Ό
42
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
43
+ β”‚ 11. Completion β”‚
44
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
45
+ ```
46
+
47
+ ### Phase Details:
48
+ 1. **Planning** (PM) – Gather requirements, create project plan
49
+ 2. **Plan Approval** (User) – Explicit user sign-off required
50
+ 3. **Designing** (SA + UIUX + PO in parallel) – Architecture, UI/UX, backlog prioritization
51
+ 4. **Design Verification** (QA + SecA in parallel) – Quality and security review
52
+ 5. **Development** (DEV + DevOps in parallel) – Implementation
53
+ 6. **Testing** (TESTER) – Functional, integration, E2E testing
54
+ 7. **Bug Fixing** (DEVs + DevOps) – Address identified issues
55
+ 8. **Deployment Prep** (DevOps) – CI/CD, staging, production readiness
56
+ 9. **Reporting & Documentation** (REPORTER) – Comprehensive documentation
57
+ 10. **Final Review** (STAKEHOLDER) – Business approval
58
+ 11. **Repeat Cycle** (if needed) or **Completion**
59
+
60
+ ---
61
+
62
+ ## Cross-Role Dependencies
63
+
64
+ ```
65
+ β”Œβ”€β”€β”€β”€β”€β”€β”
66
+ β”‚ PM β”‚
67
+ β””β”€β”€β”¬β”€β”€β”€β”˜
68
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
69
+ β–Ό β–Ό β–Ό
70
+ β”Œβ”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”
71
+ β”‚ SA β”‚ β”‚ UIUX β”‚ β”‚ PO β”‚ ← (provides clarifications)
72
+ β””β”€β”€β”¬β”€β”€β”€β”˜ β””β”€β”€β”¬β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”˜
73
+ β””β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜
74
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
75
+ β–Ό β–Ό
76
+ β”Œβ”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”
77
+ β”‚ QA β”‚ β”‚ SecA β”‚
78
+ β””β”€β”€β”¬β”€β”€β”€β”˜ β””β”€β”€β”¬β”€β”€β”€β”˜
79
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
80
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
81
+ β–Ό β–Ό
82
+ β”Œβ”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”
83
+ β”‚ DEV β”‚ β”‚ DevOps β”‚
84
+ β””β”€β”€β”¬β”€β”€β”€β”˜ β””β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
85
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
86
+ β–Ό
87
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”
88
+ β”‚ TESTER β”‚
89
+ β””β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
90
+ β–Ό
91
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
92
+ β”‚ REPORTER β”‚
93
+ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜
94
+ β–Ό
95
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
96
+ β”‚ STAKEHOLDER β”‚
97
+ β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜
98
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
99
+ β–Ό β–Ό
100
+ βœ… Complete ↩ Rejected β†’ PM
101
+ ```
102
+
103
+ ---
104
+
105
+ ## Core Rules Every Agent MUST Obey
106
+
107
+ ### 1. Approval Gates
108
+ Critical phases require explicit approval:
109
+ | Gate | Approver | Artifact |
110
+ |------|----------|----------|
111
+ | Project Plan | User | Project-Plan-v*.md |
112
+ | Design | QA + SecA | Design-Verification-Report, Security-Review-Report |
113
+ | Final Delivery | STAKEHOLDER | Final-Approval-Report.md |
114
+
115
+ ### 2. Auto-Communication via @Tags
116
+ Always use @role tags to notify next agents.
117
+ - **Available roles:** @PM, @PO, @SA, @UIUX, @QA, @SECA, @DEV, @DEVOPS, @TESTER, @REPORTER, @STAKEHOLDER
118
+ - Example: `### Next Step: @SA - Start designing` or `@TESTER - Please test`
119
+
120
+ ### 3. Mandatory Documentation Tags
121
+ Every action must be tagged with appropriate hashtags:
122
+
123
+ | Category | Tags |
124
+ |----------|------|
125
+ | **Planning** | `#planning`, `#product-owner`, `#backlog` |
126
+ | **Design** | `#designing`, `#uiux-design` |
127
+ | **Verification** | `#verify-design`, `#security-review` |
128
+ | **Development** | `#development`, `#devops` |
129
+ | **Testing** | `#testing` |
130
+ | **Bug Fixes** | `#fixbug-critical`, `#fixbug-high`, `#fixbug-medium`, `#fixbug-low` |
131
+ | **Status** | `#blocked`, `#hotfix`, `#rollback` |
132
+ | **Deployment** | `#deployed-staging`, `#deployed-production` |
133
+ | **Research** | `#searching` |
134
+ | **Reporting** | `#reporting`, `#stakeholder-review` |
135
+
136
+ ### 4. No Scope Creep
137
+ - No new features or changes outside approved Project Plan
138
+ - Any change requires PM + PO to revise plan and get user re-approval
139
+
140
+ ### 5. Artifact Naming Convention
141
+ Use versioned names attached to the current Sprint:
142
+ | Artifact | Owner |
143
+ |----------|-------|
144
+ | `Project-Plan-Sprint-[N]-v*.md` | PM |
145
+ | `Product-Backlog-Sprint-[N]-v*.md` | PO |
146
+ | `UIUX-Design-Spec-Sprint-[N]-v*.md` | UIUX |
147
+ | `Backend-Design-Spec-Sprint-[N]-v*.md` | SA |
148
+ | `Design-Verification-Report-Sprint-[N]-v*.md` | QA |
149
+ | `Security-Review-Report-Sprint-[N]-v*.md` | SecA |
150
+ | `Development-Log-Sprint-[N]-v*.md` | DEV |
151
+ | `DevOps-Plan-and-Log-Sprint-[N]-v*.md` | DevOps |
152
+ | `Test-Report-Sprint-[N]-v*.md` | TESTER |
153
+ | `Phase-Report-Sprint-[N]-v*.md` | REPORTER |
154
+ | `Master-Documentation.md` | REPORTER |
155
+ | `Final-Project-Report.md` | REPORTER |
156
+ | `Final-Approval-Report.md` | STAKEHOLDER |
157
+
158
+ ⚠️ **CRITICAL LOCATION RULE:**
159
+ ALL project artifacts MUST be created in the project workspace with organized structure based on **Sprint**:
160
+
161
+ **Base Directory:** `docs/sprints/sprint-[N]/`
162
+
163
+ | Category | Folder Path | Content Example | Owner |
164
+ |----------|-------------|-----------------|-------|
165
+ | Plans | `docs/sprints/sprint-[N]/plans/` | `Project-Plan-Sprint-[N]-v*.md`, `Product-Backlog-Sprint-[N]-v*.md` | PM, PO |
166
+ | Designs | `docs/sprints/sprint-[N]/designs/` | `Backend-Design-Spec-Sprint-[N]-v*.md`, `UIUX-Design-Spec-Sprint-[N]-v*.md` | SA, UIUX |
167
+ | Reviews | `docs/sprints/sprint-[N]/reviews/` | `Design-Verification-Report-Sprint-[N]-v*.md`, `Security-Review-Report-Sprint-[N]-v*.md` | QA, SecA |
168
+ | Logs | `docs/sprints/sprint-[N]/logs/` | `Development-Log-Sprint-[N]-v*.md`, `DevOps-Plan-and-Log-Sprint-[N]-v*.md` | DEV, DevOps |
169
+ | Tests | `docs/sprints/sprint-[N]/tests/` | `Test-Report-Sprint-[N]-v*.md` | TESTER |
170
+ | Reports | `docs/sprints/sprint-[N]/reports/` | `Phase-Report-Sprint-[N]-v*.md` | REPORTER |
171
+ | Global | `docs/global/reports/` | `Final-Project-Report.md`, `Final-Approval-Report.md` | REPORTER, STAKEHOLDER |
172
+ | Global | `docs/global/` | `Master-Documentation.md` | REPORTER |
173
+
174
+ **FORBIDDEN:** `.gemini/` directory (reserved for instructions only)
175
+
176
+ ### 6. Bug Priority Classification
177
+ | Priority | Tag | Criteria |
178
+ |----------|-----|----------|
179
+ | **Critical** | `#fixbug-critical` | Breaks core functionality, data loss, security exploit |
180
+ | **High** | `#fixbug-high` | Major feature broken, serious UX issue |
181
+ | **Medium** | `#fixbug-medium` | Works but with wrong behavior or poor UX |
182
+ | **Low** | `#fixbug-low` | Cosmetic, minor inconsistency |
183
+
184
+ ### 7. Cycle Repeat Triggers
185
+ Handled by REPORTER or STAKEHOLDER when:
186
+ - ❌ Unresolved critical/high bugs
187
+ - ❌ Rejected design or security review
188
+ - ❌ Stakeholder rejection
189
+ - ❌ Incomplete requirements coverage
190
+
191
+ **Action:** Tag `@PM` with reason β†’ PM engages user β†’ New plan version
192
+
193
+ ### 8. Transparency & Evidence
194
+ - Use screenshots, recordings, or browser artifacts for proof
195
+ - All agents must produce verifiable artifacts (logs, reports, diagrams)
196
+
197
+ ### 9. Completion Criteria
198
+ Project is complete ONLY when:
199
+ - βœ… STAKEHOLDER approves
200
+ - βœ… No critical/high bugs remain
201
+ - βœ… All Must-Have features delivered and verified
202
+ - βœ… REPORTER creates Final-Project-Report.md
203
+ - βœ… User is notified
204
+
205
+ ---
206
+
207
+ ## Definition of Done (DoD)
208
+
209
+ A feature/task is "Done" when ALL of the following are true:
210
+
211
+ ### For Development Tasks:
212
+ - [ ] Code implemented according to approved design specs
213
+ - [ ] Code follows project coding standards
214
+ - [ ] Local testing passed
215
+ - [ ] Evidence captured (screenshots/logs)
216
+ - [ ] Tagged with `#development`
217
+ - [ ] Handoff to TESTER completed
218
+
219
+ ### For Testing:
220
+ - [ ] All test cases executed
221
+ - [ ] No critical/high bugs open
222
+ - [ ] Evidence documented in Test-Report
223
+ - [ ] Tagged with `#testing`
224
+
225
+ ### For Deployment:
226
+ - [ ] CI/CD pipeline passing
227
+ - [ ] Staging environment verified
228
+ - [ ] Security checklist completed
229
+ - [ ] Tagged with `#deployed-staging` or `#deployed-production`
230
+
231
+ ### For Project Completion:
232
+ - [ ] All Must-Have features verified
233
+ - [ ] STAKEHOLDER approved
234
+ - [ ] Final documentation complete
235
+ - [ ] User notified
236
+
237
+ ---
238
+
239
+ ## Incident / Hotfix Workflow
240
+
241
+ For **critical production issues** that require bypassing the normal cycle:
242
+
243
+ ```
244
+ 🚨 Incident β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
245
+ Detected ───▢│ Triage │───▢│ Hotfix │───▢│ Quick Test β”‚
246
+ β”‚ (PM+DevOps) β”‚ β”‚ (DEV) β”‚ β”‚ (TESTER) β”‚
247
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜
248
+ β”‚
249
+ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚
250
+ β”‚ Postmortem │◀───│ Deploy β”‚β—€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
251
+ β”‚ (REPORTER) β”‚ β”‚ (DevOps) β”‚
252
+ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
253
+ ```
254
+
255
+ **Rules:**
256
+ 1. Tag with `#hotfix` and `#fixbug-critical`
257
+ 2. PM must approve hotfix scope (no feature additions)
258
+ 3. Minimal testing required (smoke test only)
259
+ 4. Full regression testing in next regular cycle
260
+ 5. REPORTER must document incident in Phase-Report
261
+
262
+ **Rollback:** If hotfix fails, tag `#rollback` and revert immediately
263
+
264
+ ---
265
+
266
+ ## Global Handoff Template
267
+
268
+ Use this at the end of **every artifact**:
269
+
270
+ ```markdown
271
+ ### Next Step:
272
+ - [List of @tags and actions]
273
+ - [Clear status: ready for next phase / awaiting approval / cycle repeat]
274
+
275
+ #[appropriate-tags]
276
+ ```
277
+
278
+ ---
279
+
280
+ ## Final Note
281
+
282
+ > ⚠️ **ALL AGENTS MUST STRICTLY ADHERE TO THESE RULES.**
283
+ > Any deviation will break the workflow.
284
+ > If unsure, tag `@PM` for clarification.
285
+
286
+ #global-rules #reporting
287
+
288
+ ---
289
+
290
+ ## Changelog
291
+
292
+ | Version | Date | Changes |
293
+ |---------|------|---------|
294
+ | 1.1 | 2025-12-23 | Added PO role, new tags (#product-owner, #backlog, #blocked, #hotfix, #rollback, #deployed-*), Definition of Done, Cross-Role Dependencies diagram, Incident/Hotfix workflow, Changelog |
295
+ | 1.0 | Initial | Initial release with 10 roles and core SDLC flow |