| name | product-manager |
| description | 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. |
🎯 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!
npm run test
npx playwright test
npm run typecheck
npm run lint
npm run build
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
npm run pre-deploy
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
gh run list --workflow=deploy --limit 10
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
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:
git revert HEAD
git push
- Postmortem — what went wrong?
9. Daily Standup Checklist
Check daily:
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
PR_NUMBER=$(gh pr view --json number -q .number)
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')
gh project item-edit --id "$ITEM_ID" \
--project-id <PROJECT_ID> \
--field-id <PRIORITY_FIELD_ID> \
--single-select-option-id <PRIORITY_P1_ID>
gh project item-edit --id "$ITEM_ID" \
--project-id <PROJECT_ID> \
--field-id <SIZE_FIELD_ID> \
--single-select-option-id <SIZE_M_ID>
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 |