🎯 Product Manager - Production & Testing Oversight
1. Release Cycle (Release Management)
Release Phases
| Phase |
Description |
Quality Gate |
| Development |
Active feature work |
Lint + TypeCheck pass |
| Code Review |
PR review, feedback |
Approved PR, no blockers |
| Testing |
E2E + Unit tests |
100% tests passing |
| Staging |
Verification on test environment |
Manual QA pass |
| Production |
Deploy to production |
Monitoring OK, no regressions |
Pre-Release Checklist
[!CAUTION]
NEVER ship a release without passing all quality gates!
# 1. Check status of all tests
npm run test
npx playwright test
# 2. Type and lint verification
npm run typecheck
npm run lint
# 3. Production build
npm run build
# 4. Check CI/CD status
gh run list --limit 5
2. Quality Gates
Quality Gate Levels
| Gate |
Requirements |
Blocking? |
| QG1: Code Quality |
ESLint 0 errors, TypeScript 0 errors |
✅ Yes |
| QG2: Unit Tests |
Vitest pass, coverage > 70% |
✅ Yes |
| QG3: E2E Tests |
Playwright all pass |
✅ Yes |
| QG4: Performance |
Lighthouse > 80, Core Web Vitals green |
⚠️ Warning |
| QG5: Security |
No known vulnerabilities |
✅ Yes |
Verification Commands
# Full pre-release verification (uses validate:all + build)
npm run pre-deploy
# Or manually:
npm run lint && npm run typecheck && npm test && npm run build
3. Test Coordination
Testing Strategy
| Test Type |
When |
Responsible |
Tool |
| Unit |
Every commit |
Developer |
Vitest |
| E2E |
Every PR |
QA/Developer |
Playwright |
| Regression |
Before release |
ProductManager |
Playwright full suite |
| Manual QA |
Before production |
ProductManager |
Checklist |
| UAT |
New features |
Stakeholder |
Manual |
Pre-Release Testing Workflow
Run the full E2E suite:
npx playwright test --reporter=html
Review the report:
npx playwright show-report
For failing tests:
- Create an Issue tagged
bug with priority P0
- Assign to the appropriate developer
- Block the release until fixed
4. Product Metrics
KPIs to Monitor
| Metric |
Target |
How to Measure |
| Uptime |
> 99.9% |
Monitoring (Supabase/Vercel) |
| Error Rate |
< 0.1% |
Logs, Sentry |
| Build Time |
< 5 min |
GitHub Actions |
| Test Coverage |
> 70% |
Vitest coverage |
| Lighthouse Score |
> 80 |
Chrome DevTools |
Reporting
# Check deploy history
gh run list --workflow=deploy --limit 10
# Check open bugs
gh issue list --label "bug" --state open
5. Prioritization and Blockers
Priority Matrix (for production bugs)
| Severity |
Response Time |
Action |
| P0 Critical |
< 1h |
Hotfix, immediate deploy |
| P1 High |
< 24h |
Fix in the current sprint |
| P2 Medium |
< 1 week |
Schedule for the next sprint |
| P3 Low |
Backlog |
When time allows |
Blocker Management
When you find a release blocker:
- Identify — what exactly is blocking?
- Escalate — notify stakeholders
- Document — create an Issue with full description
- Resolve — assign and track progress
# Create an issue for a blocker
gh issue create --title "[BLOCKER] Problem description" \
--body "## Problem\n\n## Impact\n\n## Proposed Solution" \
--label "bug,P0"
6. Coordination with Other Skills
| Skill |
When to collaborate |
| RepoOps |
Release notes, versioning, PR management |
| TestAutomation |
Creating new tests, debugging E2E |
| CodeQualityGuard |
Resolving code issues |
| GrowthStrategist |
Go-to-market for new features |
| SupabaseAdmin |
DB migrations before release |
7. Release Documentation
Release Notes Format
## v X.Y.Z (YYYY-MM-DD)
### ✨ New Features
- Feature 1 (#issue)
- Feature 2 (#issue)
### 🐛 Bug Fixes
- Bug fix 1 (#issue)
### 🔧 Improvements
- Improvement 1
### ⚠️ Breaking Changes
- (if any)
Post-Release Checklist
8. Rollback Procedure
[!WARNING]
Rollback only when production is unstable!
- Identify the problem — logs, monitoring
- Decide — rollback vs hotfix?
- Execute the rollback:
# Restore the previous deploy (Vercel)
# Or revert the commit:
git revert HEAD
git push
- Postmortem — what went wrong?
9. Daily Standup Checklist
Check daily:
# Quick status check
gh run list --limit 3
gh issue list --label "P0,P1" --state open
10. Standard PR Procedure
[!NOTE]
For every PR, automatically set labels and project attributes.
Creating a PR with Labels
gh pr create \
--title "type(scope): Description" \
--body "## Summary\n- ...\n\n## Test plan\n- ..." \
--label "Copilot" \
--label "enhancement"
After PR Creation — Set Project Fields
# 1. Get the PR number
PR_NUMBER=$(gh pr view --json number -q .number)
# 2. Get the Item ID from the project
ITEM_ID=$(gh api graphql -F number=$PR_NUMBER -f query='
query($number: Int!) {
repository(owner: "<OWNER>", name: "<REPO>") {
pullRequest(number: $number) {
projectItems(first: 1) { nodes { id } }
}
}
}' --jq '.data.repository.pullRequest.projectItems.nodes[0].id')
# All <UPPER_SNAKE> values below come from .agent/context/project-ids.md.
# If any is still `<...>`, halt and ask the user to fill it in.
# 3. Set Priority to P1
gh project item-edit --id "$ITEM_ID" \
--project-id <PROJECT_ID> \
--field-id <PRIORITY_FIELD_ID> \
--single-select-option-id <PRIORITY_P1_ID>
# 4. Set Size to M
gh project item-edit --id "$ITEM_ID" \
--project-id <PROJECT_ID> \
--field-id <SIZE_FIELD_ID> \
--single-select-option-id <SIZE_M_ID>
# 5. Set Status to "In progress"
gh project item-edit --id "$ITEM_ID" \
--project-id <PROJECT_ID> \
--field-id <STATUS_FIELD_ID> \
--single-select-option-id <STATUS_IN_PROGRESS_ID>
Available Labels
| Category |
Labels |
| Agents |
Copilot, Antigravity, Human |
| Types |
bug, enhancement, refactor, documentation |
| Areas |
area: database, area: tests, area: ui/ux, area: i18n |
Project Field IDs (Reference)
GitHub Project IDs: see .agent/context/project-ids.md
11. Escalation Path
| Problem |
Escalate to |
Channel |
| Production bug |
Tech Lead |
Slack/Issue P0 |
| Release delay |
Stakeholder |
Email/Meeting |
| Security issue |
CTO |
Immediately, confidentially |
| Performance degradation |
DevOps |
Monitoring alert |
1---2name: product-manager3description: Production and quality supervisor. Manages the release cycle, coordinates testing, enforces quality gates, and monitors product metrics. Trigger when: check release readiness, prepare a release, production status, quality gate, review metrics, coordinate tests, pre-deployment checklist, sprawdź gotowość do release, przygotuj wydanie, status produkcji, przegląd metryk, koordynacja testów, checklist przed wdrożeniem.4---56# 🎯 Product Manager - Production & Testing Oversight78## 1. Release Cycle (Release Management)910### Release Phases1112| Phase | Description | Quality Gate |13|-------|-------------|--------------|14| **Development** | Active feature work | Lint + TypeCheck pass |15| **Code Review** | PR review, feedback | Approved PR, no blockers |16| **Testing** | E2E + Unit tests | 100% tests passing |17| **Staging** | Verification on test environment | Manual QA pass |18| **Production** | Deploy to production | Monitoring OK, no regressions |1920### Pre-Release Checklist2122> [!CAUTION]23> **NEVER** ship a release without passing all quality gates!2425```bash26# 1. Check status of all tests27npm run test28npx playwright test2930# 2. Type and lint verification31npm run typecheck32npm run lint3334# 3. Production build35npm run build3637# 4. Check CI/CD status38gh run list --limit 539```4041## 2. Quality Gates4243### Quality Gate Levels4445| Gate | Requirements | Blocking? |46|------|-------------|-----------|47| **QG1: Code Quality** | ESLint 0 errors, TypeScript 0 errors | ✅ Yes |48| **QG2: Unit Tests** | Vitest pass, coverage > 70% | ✅ Yes |49| **QG3: E2E Tests** | Playwright all pass | ✅ Yes |50| **QG4: Performance** | Lighthouse > 80, Core Web Vitals green | ⚠️ Warning |51| **QG5: Security** | No known vulnerabilities | ✅ Yes |5253### Verification Commands5455```bash56# Full pre-release verification (uses validate:all + build)57npm run pre-deploy5859# Or manually:60npm run lint && npm run typecheck && npm test && npm run build61```6263## 3. Test Coordination6465### Testing Strategy6667| Test Type | When | Responsible | Tool |68|-----------|------|-------------|------|69| **Unit** | Every commit | Developer | Vitest |70| **E2E** | Every PR | QA/Developer | Playwright |71| **Regression** | Before release | ProductManager | Playwright full suite |72| **Manual QA** | Before production | ProductManager | Checklist |73| **UAT** | New features | Stakeholder | Manual |7475### Pre-Release Testing Workflow76771. **Run the full E2E suite:**78 ```bash79 npx playwright test --reporter=html80 ```81822. **Review the report:**83 ```bash84 npx playwright show-report85 ```86873. **For failing tests:**88 - Create an Issue tagged `bug` with priority `P0`89 - Assign to the appropriate developer90 - Block the release until fixed9192## 4. Product Metrics9394### KPIs to Monitor9596| Metric | Target | How to Measure |97|--------|--------|----------------|98| **Uptime** | > 99.9% | Monitoring (Supabase/Vercel) |99| **Error Rate** | < 0.1% | Logs, Sentry |100| **Build Time** | < 5 min | GitHub Actions |101| **Test Coverage** | > 70% | Vitest coverage |102| **Lighthouse Score** | > 80 | Chrome DevTools |103104### Reporting105106```bash107# Check deploy history108gh run list --workflow=deploy --limit 10109110# Check open bugs111gh issue list --label "bug" --state open112```113114## 5. Prioritization and Blockers115116### Priority Matrix (for production bugs)117118| Severity | Response Time | Action |119|----------|---------------|--------|120| **P0 Critical** | < 1h | Hotfix, immediate deploy |121| **P1 High** | < 24h | Fix in the current sprint |122| **P2 Medium** | < 1 week | Schedule for the next sprint |123| **P3 Low** | Backlog | When time allows |124125### Blocker Management126127When you find a release blocker:1281291. **Identify** — what exactly is blocking?1302. **Escalate** — notify stakeholders1313. **Document** — create an Issue with full description1324. **Resolve** — assign and track progress133134```bash135# Create an issue for a blocker136gh issue create --title "[BLOCKER] Problem description" \137 --body "## Problem\n\n## Impact\n\n## Proposed Solution" \138 --label "bug,P0"139```140141## 6. Coordination with Other Skills142143| Skill | When to collaborate |144|-------|---------------------|145| **RepoOps** | Release notes, versioning, PR management |146| **TestAutomation** | Creating new tests, debugging E2E |147| **CodeQualityGuard** | Resolving code issues |148| **GrowthStrategist** | Go-to-market for new features |149| **SupabaseAdmin** | DB migrations before release |150151## 7. Release Documentation152153### Release Notes Format154155```markdown156## v X.Y.Z (YYYY-MM-DD)157158### ✨ New Features159- Feature 1 (#issue)160- Feature 2 (#issue)161162### 🐛 Bug Fixes163- Bug fix 1 (#issue)164165### 🔧 Improvements166- Improvement 1167168### ⚠️ Breaking Changes169- (if any)170```171172### Post-Release Checklist173174- [ ] Release notes published175- [ ] Monitoring enabled176- [ ] Stakeholders notified177- [ ] Baseline metrics recorded178- [ ] Rollback plan ready179180## 8. Rollback Procedure181182> [!WARNING]183> Rollback only when production is unstable!1841851. **Identify the problem** — logs, monitoring1862. **Decide** — rollback vs hotfix?1873. **Execute the rollback:**188 ```bash189 # Restore the previous deploy (Vercel)190 # Or revert the commit:191 git revert HEAD192 git push193 ```1944. **Postmortem** — what went wrong?195196## 9. Daily Standup Checklist197198Check daily:199200- [ ] CI/CD status (recent builds)201- [ ] Open P0/P1 Issues202- [ ] Failing tests (if any)203- [ ] User feedback204- [ ] Current sprint progress205206```bash207# Quick status check208gh run list --limit 3209gh issue list --label "P0,P1" --state open210```211212## 10. Standard PR Procedure213214> [!NOTE]215> For every PR, automatically set labels and project attributes.216217### Creating a PR with Labels218219```bash220gh pr create \221 --title "type(scope): Description" \222 --body "## Summary\n- ...\n\n## Test plan\n- ..." \223 --label "Copilot" \224 --label "enhancement"225```226227### After PR Creation — Set Project Fields228229```bash230# 1. Get the PR number231PR_NUMBER=$(gh pr view --json number -q .number)232233# 2. Get the Item ID from the project234ITEM_ID=$(gh api graphql -F number=$PR_NUMBER -f query='235 query($number: Int!) {236 repository(owner: "<OWNER>", name: "<REPO>") {237 pullRequest(number: $number) {238 projectItems(first: 1) { nodes { id } }239 }240 }241 }' --jq '.data.repository.pullRequest.projectItems.nodes[0].id')242243# All <UPPER_SNAKE> values below come from .agent/context/project-ids.md.244# If any is still `<...>`, halt and ask the user to fill it in.245246# 3. Set Priority to P1247gh project item-edit --id "$ITEM_ID" \248 --project-id <PROJECT_ID> \249 --field-id <PRIORITY_FIELD_ID> \250 --single-select-option-id <PRIORITY_P1_ID>251252# 4. Set Size to M253gh project item-edit --id "$ITEM_ID" \254 --project-id <PROJECT_ID> \255 --field-id <SIZE_FIELD_ID> \256 --single-select-option-id <SIZE_M_ID>257258# 5. Set Status to "In progress"259gh project item-edit --id "$ITEM_ID" \260 --project-id <PROJECT_ID> \261 --field-id <STATUS_FIELD_ID> \262 --single-select-option-id <STATUS_IN_PROGRESS_ID>263```264265### Available Labels266267| Category | Labels |268|----------|--------|269| **Agents** | `Copilot`, `Antigravity`, `Human` |270| **Types** | `bug`, `enhancement`, `refactor`, `documentation` |271| **Areas** | `area: database`, `area: tests`, `area: ui/ux`, `area: i18n` |272273### Project Field IDs (Reference)274275> GitHub Project IDs: see `.agent/context/project-ids.md`276277## 11. Escalation Path278279| Problem | Escalate to | Channel |280|---------|-------------|---------|281| Production bug | Tech Lead | Slack/Issue P0 |282| Release delay | Stakeholder | Email/Meeting |283| Security issue | CTO | Immediately, confidentially |284| Performance degradation | DevOps | Monitoring alert |