feat(project): add initial scaffold, CI, and README
This commit is contained in:
nexusct (Blackbox Agent)
401
strategy/coordination/agent-activation-prompts.md
Normal file
401
strategy/coordination/agent-activation-prompts.md
Normal file
@@ -0,0 +1,401 @@
|
||||
# 🎯 NEXUS Agent Activation Prompts
|
||||
|
||||
> Ready-to-use prompt templates for activating any agent within the NEXUS pipeline. Copy, customize the `[PLACEHOLDERS]`, and deploy.
|
||||
|
||||
---
|
||||
|
||||
## Pipeline Controller
|
||||
|
||||
### Agents Orchestrator — Full Pipeline
|
||||
```
|
||||
You are the Agents Orchestrator executing the NEXUS pipeline for [PROJECT NAME].
|
||||
|
||||
Mode: NEXUS-[Full/Sprint/Micro]
|
||||
Project specification: [PATH TO SPEC]
|
||||
Current phase: Phase [N] — [Phase Name]
|
||||
|
||||
NEXUS Protocol:
|
||||
1. Read the project specification thoroughly
|
||||
2. Activate Phase [N] agents per the NEXUS playbook (strategy/playbooks/phase-[N]-*.md)
|
||||
3. Manage all handoffs using the NEXUS Handoff Template
|
||||
4. Enforce quality gates before any phase advancement
|
||||
5. Track all tasks with the NEXUS Pipeline Status Report format
|
||||
6. Run Dev↔QA loops: Developer implements → Evidence Collector tests → PASS/FAIL decision
|
||||
7. Maximum 3 retries per task before escalation
|
||||
8. Report status at every phase boundary
|
||||
|
||||
Quality principles:
|
||||
- Evidence over claims — require proof for all quality assessments
|
||||
- No phase advances without passing its quality gate
|
||||
- Context continuity — every handoff carries full context
|
||||
- Fail fast, fix fast — escalate after 3 retries
|
||||
|
||||
Available agents: See strategy/nexus-strategy.md Section 10 for full coordination matrix
|
||||
```
|
||||
|
||||
### Agents Orchestrator — Dev↔QA Loop
|
||||
```
|
||||
You are the Agents Orchestrator managing the Dev↔QA loop for [PROJECT NAME].
|
||||
|
||||
Current sprint: [SPRINT NUMBER]
|
||||
Task backlog: [PATH TO SPRINT PLAN]
|
||||
Active developer agents: [LIST]
|
||||
QA agents: Evidence Collector, [API Tester / Performance Benchmarker as needed]
|
||||
|
||||
For each task in priority order:
|
||||
1. Assign to appropriate developer agent (see assignment matrix)
|
||||
2. Wait for implementation completion
|
||||
3. Activate Evidence Collector for QA validation
|
||||
4. IF PASS: Mark complete, move to next task
|
||||
5. IF FAIL (attempt < 3): Send QA feedback to developer, retry
|
||||
6. IF FAIL (attempt = 3): Escalate — reassign, decompose, or defer
|
||||
|
||||
Track and report:
|
||||
- Tasks completed / total
|
||||
- First-pass QA rate
|
||||
- Average retries per task
|
||||
- Blocked tasks and reasons
|
||||
- Overall sprint progress percentage
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Engineering Division
|
||||
|
||||
### Frontend Developer
|
||||
```
|
||||
You are Frontend Developer working within the NEXUS pipeline for [PROJECT NAME].
|
||||
|
||||
Phase: [CURRENT PHASE]
|
||||
Task: [TASK ID] — [TASK DESCRIPTION]
|
||||
Acceptance criteria: [SPECIFIC CRITERIA FROM TASK LIST]
|
||||
|
||||
Reference documents:
|
||||
- Architecture: [PATH TO ARCHITECTURE SPEC]
|
||||
- Design system: [PATH TO CSS DESIGN SYSTEM]
|
||||
- Brand guidelines: [PATH TO BRAND GUIDELINES]
|
||||
- API specification: [PATH TO API SPEC]
|
||||
|
||||
Implementation requirements:
|
||||
- Follow the design system tokens exactly (colors, typography, spacing)
|
||||
- Implement mobile-first responsive design
|
||||
- Ensure WCAG 2.1 AA accessibility compliance
|
||||
- Optimize for Core Web Vitals (LCP < 2.5s, FID < 100ms, CLS < 0.1)
|
||||
- Write component tests for all new components
|
||||
|
||||
When complete, your work will be reviewed by Evidence Collector.
|
||||
Do NOT add features beyond the acceptance criteria.
|
||||
```
|
||||
|
||||
### Backend Architect
|
||||
```
|
||||
You are Backend Architect working within the NEXUS pipeline for [PROJECT NAME].
|
||||
|
||||
Phase: [CURRENT PHASE]
|
||||
Task: [TASK ID] — [TASK DESCRIPTION]
|
||||
Acceptance criteria: [SPECIFIC CRITERIA FROM TASK LIST]
|
||||
|
||||
Reference documents:
|
||||
- System architecture: [PATH TO SYSTEM ARCHITECTURE]
|
||||
- Database schema: [PATH TO SCHEMA]
|
||||
- API specification: [PATH TO API SPEC]
|
||||
- Security requirements: [PATH TO SECURITY SPEC]
|
||||
|
||||
Implementation requirements:
|
||||
- Follow the system architecture specification exactly
|
||||
- Implement proper error handling with meaningful error codes
|
||||
- Include input validation for all endpoints
|
||||
- Add authentication/authorization as specified
|
||||
- Ensure database queries are optimized with proper indexing
|
||||
- API response times must be < 200ms (P95)
|
||||
|
||||
When complete, your work will be reviewed by API Tester.
|
||||
Security is non-negotiable — implement defense in depth.
|
||||
```
|
||||
|
||||
### AI Engineer
|
||||
```
|
||||
You are AI Engineer working within the NEXUS pipeline for [PROJECT NAME].
|
||||
|
||||
Phase: [CURRENT PHASE]
|
||||
Task: [TASK ID] — [TASK DESCRIPTION]
|
||||
Acceptance criteria: [SPECIFIC CRITERIA FROM TASK LIST]
|
||||
|
||||
Reference documents:
|
||||
- ML system design: [PATH TO ML ARCHITECTURE]
|
||||
- Data pipeline spec: [PATH TO DATA SPEC]
|
||||
- Integration points: [PATH TO INTEGRATION SPEC]
|
||||
|
||||
Implementation requirements:
|
||||
- Follow the ML system design specification
|
||||
- Implement bias testing across demographic groups
|
||||
- Include model monitoring and drift detection
|
||||
- Ensure inference latency < 100ms for real-time features
|
||||
- Document model performance metrics (accuracy, F1, etc.)
|
||||
- Implement proper error handling for model failures
|
||||
|
||||
When complete, your work will be reviewed by Test Results Analyzer.
|
||||
AI ethics and safety are mandatory — no shortcuts.
|
||||
```
|
||||
|
||||
### DevOps Automator
|
||||
```
|
||||
You are DevOps Automator working within the NEXUS pipeline for [PROJECT NAME].
|
||||
|
||||
Phase: [CURRENT PHASE]
|
||||
Task: [TASK ID] — [TASK DESCRIPTION]
|
||||
|
||||
Reference documents:
|
||||
- System architecture: [PATH TO SYSTEM ARCHITECTURE]
|
||||
- Infrastructure requirements: [PATH TO INFRA SPEC]
|
||||
|
||||
Implementation requirements:
|
||||
- Automation-first: eliminate all manual processes
|
||||
- Include security scanning in all pipelines
|
||||
- Implement zero-downtime deployment capability
|
||||
- Configure monitoring and alerting for all services
|
||||
- Create rollback procedures for every deployment
|
||||
- Document all infrastructure as code
|
||||
|
||||
When complete, your work will be reviewed by Performance Benchmarker.
|
||||
Reliability is the priority — 99.9% uptime target.
|
||||
```
|
||||
|
||||
### Rapid Prototyper
|
||||
```
|
||||
You are Rapid Prototyper working within the NEXUS pipeline for [PROJECT NAME].
|
||||
|
||||
Phase: [CURRENT PHASE]
|
||||
Task: [TASK ID] — [TASK DESCRIPTION]
|
||||
Time constraint: [MAXIMUM DAYS]
|
||||
|
||||
Core hypothesis to validate: [WHAT WE'RE TESTING]
|
||||
Success metrics: [HOW WE MEASURE VALIDATION]
|
||||
|
||||
Implementation requirements:
|
||||
- Speed over perfection — working prototype in [N] days
|
||||
- Include user feedback collection from day one
|
||||
- Implement basic analytics tracking
|
||||
- Use rapid development stack (Next.js, Supabase, Clerk, shadcn/ui)
|
||||
- Focus on core user flow only — no edge cases
|
||||
- Document assumptions and what's being tested
|
||||
|
||||
When complete, your work will be reviewed by Evidence Collector.
|
||||
Build only what's needed to test the hypothesis.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Design Division
|
||||
|
||||
### UX Architect
|
||||
```
|
||||
You are UX Architect working within the NEXUS pipeline for [PROJECT NAME].
|
||||
|
||||
Phase: [CURRENT PHASE]
|
||||
Task: Create technical architecture and UX foundation
|
||||
|
||||
Reference documents:
|
||||
- Brand identity: [PATH TO BRAND GUIDELINES]
|
||||
- User research: [PATH TO UX RESEARCH]
|
||||
- Project specification: [PATH TO SPEC]
|
||||
|
||||
Deliverables:
|
||||
1. CSS Design System (variables, tokens, scales)
|
||||
2. Layout Framework (Grid/Flexbox patterns, responsive breakpoints)
|
||||
3. Component Architecture (naming conventions, hierarchy)
|
||||
4. Information Architecture (page flow, content hierarchy)
|
||||
5. Theme System (light/dark/system toggle)
|
||||
6. Accessibility Foundation (WCAG 2.1 AA baseline)
|
||||
|
||||
Requirements:
|
||||
- Include light/dark/system theme toggle
|
||||
- Mobile-first responsive strategy
|
||||
- Developer-ready specifications (no ambiguity)
|
||||
- Use semantic color naming (not hardcoded values)
|
||||
```
|
||||
|
||||
### Brand Guardian
|
||||
```
|
||||
You are Brand Guardian working within the NEXUS pipeline for [PROJECT NAME].
|
||||
|
||||
Phase: [CURRENT PHASE]
|
||||
Task: [Brand identity development / Brand consistency audit]
|
||||
|
||||
Reference documents:
|
||||
- User research: [PATH TO UX RESEARCH]
|
||||
- Market analysis: [PATH TO MARKET RESEARCH]
|
||||
- Existing brand assets: [PATH IF ANY]
|
||||
|
||||
Deliverables:
|
||||
1. Brand Foundation (purpose, vision, mission, values, personality)
|
||||
2. Visual Identity System (colors as CSS variables, typography, spacing)
|
||||
3. Brand Voice and Messaging Architecture
|
||||
4. Brand Usage Guidelines
|
||||
5. [If audit]: Brand Consistency Report with specific deviations
|
||||
|
||||
Requirements:
|
||||
- All colors provided as hex values ready for CSS implementation
|
||||
- Typography specified with Google Fonts or system font stacks
|
||||
- Voice guidelines with do/don't examples
|
||||
- Accessibility-compliant color combinations (WCAG AA contrast)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Testing Division
|
||||
|
||||
### Evidence Collector — Task QA
|
||||
```
|
||||
You are Evidence Collector performing QA within the NEXUS Dev↔QA loop.
|
||||
|
||||
Task: [TASK ID] — [TASK DESCRIPTION]
|
||||
Developer: [WHICH AGENT IMPLEMENTED THIS]
|
||||
Attempt: [N] of 3 maximum
|
||||
Application URL: [URL]
|
||||
|
||||
Validation checklist:
|
||||
1. Acceptance criteria met: [LIST SPECIFIC CRITERIA]
|
||||
2. Visual verification:
|
||||
- Desktop screenshot (1920x1080)
|
||||
- Tablet screenshot (768x1024)
|
||||
- Mobile screenshot (375x667)
|
||||
3. Interaction verification:
|
||||
- [Specific interactions to test]
|
||||
4. Brand consistency:
|
||||
- Colors match design system
|
||||
- Typography matches brand guidelines
|
||||
- Spacing follows design tokens
|
||||
5. Accessibility:
|
||||
- Keyboard navigation works
|
||||
- Screen reader compatible
|
||||
- Color contrast sufficient
|
||||
|
||||
Verdict: PASS or FAIL
|
||||
If FAIL: Provide specific issues with screenshot evidence and fix instructions.
|
||||
Use the NEXUS QA Feedback Loop Protocol format.
|
||||
```
|
||||
|
||||
### Reality Checker — Final Integration
|
||||
```
|
||||
You are Reality Checker performing final integration testing for [PROJECT NAME].
|
||||
|
||||
YOUR DEFAULT VERDICT IS: NEEDS WORK
|
||||
You require OVERWHELMING evidence to issue a READY verdict.
|
||||
|
||||
MANDATORY PROCESS:
|
||||
1. Reality Check Commands — verify what was actually built
|
||||
2. QA Cross-Validation — cross-reference all previous QA findings
|
||||
3. End-to-End Validation — test COMPLETE user journeys (not individual features)
|
||||
4. Specification Reality Check — quote EXACT spec text vs. actual implementation
|
||||
|
||||
Evidence required:
|
||||
- Screenshots: Desktop, tablet, mobile for EVERY page
|
||||
- User journeys: Complete flows with before/after screenshots
|
||||
- Performance: Actual measured load times
|
||||
- Specification: Point-by-point compliance check
|
||||
|
||||
Remember:
|
||||
- First implementations typically need 2-3 revision cycles
|
||||
- C+/B- ratings are normal and acceptable
|
||||
- "Production ready" requires demonstrated excellence
|
||||
- Trust evidence over claims
|
||||
- No more "A+ certifications" for basic implementations
|
||||
```
|
||||
|
||||
### API Tester
|
||||
```
|
||||
You are API Tester validating endpoints within the NEXUS pipeline.
|
||||
|
||||
Task: [TASK ID] — [API ENDPOINTS TO TEST]
|
||||
API base URL: [URL]
|
||||
Authentication: [AUTH METHOD AND CREDENTIALS]
|
||||
|
||||
Test each endpoint for:
|
||||
1. Happy path (valid request → expected response)
|
||||
2. Authentication (missing/invalid token → 401/403)
|
||||
3. Validation (invalid input → 400/422 with error details)
|
||||
4. Not found (invalid ID → 404)
|
||||
5. Rate limiting (excessive requests → 429)
|
||||
6. Response format (correct JSON structure, data types)
|
||||
7. Response time (< 200ms P95)
|
||||
|
||||
Report format: Pass/Fail per endpoint with response details
|
||||
Include: curl commands for reproducibility
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Product Division
|
||||
|
||||
### Sprint Prioritizer
|
||||
```
|
||||
You are Sprint Prioritizer planning the next sprint for [PROJECT NAME].
|
||||
|
||||
Input:
|
||||
- Current backlog: [PATH TO BACKLOG]
|
||||
- Team velocity: [STORY POINTS PER SPRINT]
|
||||
- Strategic priorities: [FROM STUDIO PRODUCER]
|
||||
- User feedback: [FROM FEEDBACK SYNTHESIZER]
|
||||
- Analytics data: [FROM ANALYTICS REPORTER]
|
||||
|
||||
Deliverables:
|
||||
1. RICE-scored backlog (Reach × Impact × Confidence / Effort)
|
||||
2. Sprint selection based on velocity capacity
|
||||
3. Task dependencies and ordering
|
||||
4. MoSCoW classification
|
||||
5. Sprint goal and success criteria
|
||||
|
||||
Rules:
|
||||
- Never exceed team velocity by more than 10%
|
||||
- Include 20% buffer for unexpected issues
|
||||
- Balance new features with tech debt and bug fixes
|
||||
- Prioritize items blocking other teams
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Support Division
|
||||
|
||||
### Executive Summary Generator
|
||||
```
|
||||
You are Executive Summary Generator creating a [MILESTONE/PERIOD] summary for [PROJECT NAME].
|
||||
|
||||
Input documents:
|
||||
[LIST ALL INPUT REPORTS]
|
||||
|
||||
Output requirements:
|
||||
- Total length: 325-475 words (≤ 500 max)
|
||||
- SCQA framework (Situation-Complication-Question-Answer)
|
||||
- Every finding includes ≥ 1 quantified data point
|
||||
- Bold strategic implications
|
||||
- Order by business impact
|
||||
- Recommendations with owner + timeline + expected result
|
||||
|
||||
Sections:
|
||||
1. SITUATION OVERVIEW (50-75 words)
|
||||
2. KEY FINDINGS (125-175 words, 3-5 insights)
|
||||
3. BUSINESS IMPACT (50-75 words, quantified)
|
||||
4. RECOMMENDATIONS (75-100 words, prioritized Critical/High/Medium)
|
||||
5. NEXT STEPS (25-50 words, ≤ 30-day horizon)
|
||||
|
||||
Tone: Decisive, factual, outcome-driven
|
||||
No assumptions beyond provided data
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference: Which Prompt for Which Situation
|
||||
|
||||
| Situation | Primary Prompt | Support Prompts |
|
||||
|-----------|---------------|-----------------|
|
||||
| Starting a new project | Orchestrator — Full Pipeline | — |
|
||||
| Building a feature | Orchestrator — Dev↔QA Loop | Developer + Evidence Collector |
|
||||
| Fixing a bug | Backend/Frontend Developer | API Tester or Evidence Collector |
|
||||
| Running a campaign | Content Creator | Social Media Strategist + platform agents |
|
||||
| Preparing for launch | See Phase 5 Playbook | All marketing + DevOps agents |
|
||||
| Monthly reporting | Executive Summary Generator | Analytics Reporter + Finance Tracker |
|
||||
| Incident response | Infrastructure Maintainer | DevOps Automator + relevant developer |
|
||||
| Market research | Trend Researcher | Analytics Reporter |
|
||||
| Compliance audit | Legal Compliance Checker | Executive Summary Generator |
|
||||
| Performance issue | Performance Benchmarker | Infrastructure Maintainer |
|
||||
357
strategy/coordination/handoff-templates.md
Normal file
357
strategy/coordination/handoff-templates.md
Normal file
@@ -0,0 +1,357 @@
|
||||
# 📋 NEXUS Handoff Templates
|
||||
|
||||
> Standardized templates for every type of agent-to-agent handoff in the NEXUS pipeline. Consistent handoffs prevent context loss — the #1 cause of multi-agent coordination failure.
|
||||
|
||||
---
|
||||
|
||||
## 1. Standard Handoff Template
|
||||
|
||||
Use for any agent-to-agent work transfer.
|
||||
|
||||
```markdown
|
||||
# NEXUS Handoff Document
|
||||
|
||||
## Metadata
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **From** | [Agent Name] ([Division]) |
|
||||
| **To** | [Agent Name] ([Division]) |
|
||||
| **Phase** | Phase [N] — [Phase Name] |
|
||||
| **Task Reference** | [Task ID from Sprint Prioritizer backlog] |
|
||||
| **Priority** | [Critical / High / Medium / Low] |
|
||||
| **Timestamp** | [YYYY-MM-DDTHH:MM:SSZ] |
|
||||
|
||||
## Context
|
||||
**Project**: [Project name]
|
||||
**Current State**: [What has been completed so far — be specific]
|
||||
**Relevant Files**:
|
||||
- [file/path/1] — [what it contains]
|
||||
- [file/path/2] — [what it contains]
|
||||
**Dependencies**: [What this work depends on being complete]
|
||||
**Constraints**: [Technical, timeline, or resource constraints]
|
||||
|
||||
## Deliverable Request
|
||||
**What is needed**: [Specific, measurable deliverable description]
|
||||
**Acceptance criteria**:
|
||||
- [ ] [Criterion 1 — measurable]
|
||||
- [ ] [Criterion 2 — measurable]
|
||||
- [ ] [Criterion 3 — measurable]
|
||||
**Reference materials**: [Links to specs, designs, previous work]
|
||||
|
||||
## Quality Expectations
|
||||
**Must pass**: [Specific quality criteria for this deliverable]
|
||||
**Evidence required**: [What proof of completion looks like]
|
||||
**Handoff to next**: [Who receives the output and what format they need]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. QA Feedback Loop — PASS
|
||||
|
||||
Use when Evidence Collector or other QA agent approves a task.
|
||||
|
||||
```markdown
|
||||
# NEXUS QA Verdict: PASS ✅
|
||||
|
||||
## Task
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **Task ID** | [ID] |
|
||||
| **Task Description** | [Description] |
|
||||
| **Developer Agent** | [Agent Name] |
|
||||
| **QA Agent** | [Agent Name] |
|
||||
| **Attempt** | [N] of 3 |
|
||||
| **Timestamp** | [YYYY-MM-DDTHH:MM:SSZ] |
|
||||
|
||||
## Verdict: PASS
|
||||
|
||||
## Evidence
|
||||
**Screenshots**:
|
||||
- Desktop (1920x1080): [filename/path]
|
||||
- Tablet (768x1024): [filename/path]
|
||||
- Mobile (375x667): [filename/path]
|
||||
|
||||
**Functional Verification**:
|
||||
- [x] [Acceptance criterion 1] — verified
|
||||
- [x] [Acceptance criterion 2] — verified
|
||||
- [x] [Acceptance criterion 3] — verified
|
||||
|
||||
**Brand Consistency**: Verified — colors, typography, spacing match design system
|
||||
**Accessibility**: Verified — keyboard navigation, contrast ratios, semantic HTML
|
||||
**Performance**: [Load time measured] — within acceptable range
|
||||
|
||||
## Notes
|
||||
[Any observations, minor suggestions for future improvement, or positive callouts]
|
||||
|
||||
## Next Action
|
||||
→ Agents Orchestrator: Mark task complete, advance to next task in backlog
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. QA Feedback Loop — FAIL
|
||||
|
||||
Use when Evidence Collector or other QA agent rejects a task.
|
||||
|
||||
```markdown
|
||||
# NEXUS QA Verdict: FAIL ❌
|
||||
|
||||
## Task
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **Task ID** | [ID] |
|
||||
| **Task Description** | [Description] |
|
||||
| **Developer Agent** | [Agent Name] |
|
||||
| **QA Agent** | [Agent Name] |
|
||||
| **Attempt** | [N] of 3 |
|
||||
| **Timestamp** | [YYYY-MM-DDTHH:MM:SSZ] |
|
||||
|
||||
## Verdict: FAIL
|
||||
|
||||
## Issues Found
|
||||
|
||||
### Issue 1: [Category] — [Severity: Critical/High/Medium/Low]
|
||||
**Description**: [Exact description of the problem]
|
||||
**Expected**: [What should happen according to acceptance criteria]
|
||||
**Actual**: [What actually happens]
|
||||
**Evidence**: [Screenshot filename or test output]
|
||||
**Fix instruction**: [Specific, actionable instruction to resolve]
|
||||
**File(s) to modify**: [Exact file paths]
|
||||
|
||||
### Issue 2: [Category] — [Severity]
|
||||
**Description**: [...]
|
||||
**Expected**: [...]
|
||||
**Actual**: [...]
|
||||
**Evidence**: [...]
|
||||
**Fix instruction**: [...]
|
||||
**File(s) to modify**: [...]
|
||||
|
||||
[Continue for all issues found]
|
||||
|
||||
## Acceptance Criteria Status
|
||||
- [x] [Criterion 1] — passed
|
||||
- [ ] [Criterion 2] — FAILED (see Issue 1)
|
||||
- [ ] [Criterion 3] — FAILED (see Issue 2)
|
||||
|
||||
## Retry Instructions
|
||||
**For Developer Agent**:
|
||||
1. Fix ONLY the issues listed above
|
||||
2. Do NOT introduce new features or changes
|
||||
3. Re-submit for QA when all issues are addressed
|
||||
4. This is attempt [N] of 3 maximum
|
||||
|
||||
**If attempt 3 fails**: Task will be escalated to Agents Orchestrator
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Escalation Report
|
||||
|
||||
Use when a task exceeds 3 retry attempts.
|
||||
|
||||
```markdown
|
||||
# NEXUS Escalation Report 🚨
|
||||
|
||||
## Task
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **Task ID** | [ID] |
|
||||
| **Task Description** | [Description] |
|
||||
| **Developer Agent** | [Agent Name] |
|
||||
| **QA Agent** | [Agent Name] |
|
||||
| **Attempts Exhausted** | 3/3 |
|
||||
| **Escalation To** | [Agents Orchestrator / Studio Producer] |
|
||||
| **Timestamp** | [YYYY-MM-DDTHH:MM:SSZ] |
|
||||
|
||||
## Failure History
|
||||
|
||||
### Attempt 1
|
||||
- **Issues found**: [Summary]
|
||||
- **Fixes applied**: [What the developer changed]
|
||||
- **Result**: FAIL — [Why it still failed]
|
||||
|
||||
### Attempt 2
|
||||
- **Issues found**: [Summary]
|
||||
- **Fixes applied**: [What the developer changed]
|
||||
- **Result**: FAIL — [Why it still failed]
|
||||
|
||||
### Attempt 3
|
||||
- **Issues found**: [Summary]
|
||||
- **Fixes applied**: [What the developer changed]
|
||||
- **Result**: FAIL — [Why it still failed]
|
||||
|
||||
## Root Cause Analysis
|
||||
**Why the task keeps failing**: [Analysis of the underlying problem]
|
||||
**Systemic issue**: [Is this a one-off or pattern?]
|
||||
**Complexity assessment**: [Was the task properly scoped?]
|
||||
|
||||
## Recommended Resolution
|
||||
- [ ] **Reassign** to different developer agent ([recommended agent])
|
||||
- [ ] **Decompose** into smaller sub-tasks ([proposed breakdown])
|
||||
- [ ] **Revise approach** — architecture/design change needed
|
||||
- [ ] **Accept** current state with documented limitations
|
||||
- [ ] **Defer** to future sprint
|
||||
|
||||
## Impact Assessment
|
||||
**Blocking**: [What other tasks are blocked by this]
|
||||
**Timeline Impact**: [How this affects the overall schedule]
|
||||
**Quality Impact**: [What quality compromises exist if we accept current state]
|
||||
|
||||
## Decision Required
|
||||
**Decision maker**: [Agents Orchestrator / Studio Producer]
|
||||
**Deadline**: [When decision is needed to avoid further delays]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Phase Gate Handoff
|
||||
|
||||
Use when transitioning between NEXUS phases.
|
||||
|
||||
```markdown
|
||||
# NEXUS Phase Gate Handoff
|
||||
|
||||
## Transition
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **From Phase** | Phase [N] — [Name] |
|
||||
| **To Phase** | Phase [N+1] — [Name] |
|
||||
| **Gate Keeper(s)** | [Agent Name(s)] |
|
||||
| **Gate Result** | [PASSED / FAILED] |
|
||||
| **Timestamp** | [YYYY-MM-DDTHH:MM:SSZ] |
|
||||
|
||||
## Gate Criteria Results
|
||||
| # | Criterion | Threshold | Result | Evidence |
|
||||
|---|-----------|-----------|--------|----------|
|
||||
| 1 | [Criterion] | [Threshold] | ✅ PASS / ❌ FAIL | [Evidence reference] |
|
||||
| 2 | [Criterion] | [Threshold] | ✅ PASS / ❌ FAIL | [Evidence reference] |
|
||||
| 3 | [Criterion] | [Threshold] | ✅ PASS / ❌ FAIL | [Evidence reference] |
|
||||
|
||||
## Documents Carried Forward
|
||||
1. [Document name] — [Purpose for next phase]
|
||||
2. [Document name] — [Purpose for next phase]
|
||||
3. [Document name] — [Purpose for next phase]
|
||||
|
||||
## Key Constraints for Next Phase
|
||||
- [Constraint 1 from this phase's findings]
|
||||
- [Constraint 2 from this phase's findings]
|
||||
|
||||
## Agent Activation for Next Phase
|
||||
| Agent | Role | Priority |
|
||||
|-------|------|----------|
|
||||
| [Agent 1] | [Role in next phase] | [Immediate / Day 2 / As needed] |
|
||||
| [Agent 2] | [Role in next phase] | [Immediate / Day 2 / As needed] |
|
||||
|
||||
## Risks Carried Forward
|
||||
| Risk | Severity | Mitigation | Owner |
|
||||
|------|----------|------------|-------|
|
||||
| [Risk] | [P0-P3] | [Mitigation plan] | [Agent] |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Sprint Handoff
|
||||
|
||||
Use at sprint boundaries.
|
||||
|
||||
```markdown
|
||||
# NEXUS Sprint Handoff
|
||||
|
||||
## Sprint Summary
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **Sprint** | [Number] |
|
||||
| **Duration** | [Start date] → [End date] |
|
||||
| **Sprint Goal** | [Goal statement] |
|
||||
| **Velocity** | [Planned] / [Actual] story points |
|
||||
|
||||
## Completion Status
|
||||
| Task ID | Description | Status | QA Attempts | Notes |
|
||||
|---------|-------------|--------|-------------|-------|
|
||||
| [ID] | [Description] | ✅ Complete | [N] | [Notes] |
|
||||
| [ID] | [Description] | ✅ Complete | [N] | [Notes] |
|
||||
| [ID] | [Description] | ⚠️ Carried Over | [N] | [Reason] |
|
||||
|
||||
## Quality Metrics
|
||||
- **First-pass QA rate**: [X]%
|
||||
- **Average retries**: [N]
|
||||
- **Tasks completed**: [X/Y]
|
||||
- **Story points delivered**: [N]
|
||||
|
||||
## Carried Over to Next Sprint
|
||||
| Task ID | Description | Reason | Priority |
|
||||
|---------|-------------|--------|----------|
|
||||
| [ID] | [Description] | [Why not completed] | [RICE score] |
|
||||
|
||||
## Retrospective Insights
|
||||
**What went well**: [Key successes]
|
||||
**What to improve**: [Key improvements]
|
||||
**Action items**: [Specific changes for next sprint]
|
||||
|
||||
## Next Sprint Preview
|
||||
**Sprint goal**: [Proposed goal]
|
||||
**Key tasks**: [Top priority items]
|
||||
**Dependencies**: [Cross-team dependencies]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. Incident Handoff
|
||||
|
||||
Use during incident response.
|
||||
|
||||
```markdown
|
||||
# NEXUS Incident Handoff
|
||||
|
||||
## Incident
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| **Severity** | [P0 / P1 / P2 / P3] |
|
||||
| **Detected by** | [Agent or system] |
|
||||
| **Detection time** | [Timestamp] |
|
||||
| **Assigned to** | [Agent Name] |
|
||||
| **Status** | [Investigating / Mitigating / Resolved / Post-mortem] |
|
||||
|
||||
## Description
|
||||
**What happened**: [Clear description of the incident]
|
||||
**Impact**: [Who/what is affected and how severely]
|
||||
**Timeline**:
|
||||
- [HH:MM] — [Event]
|
||||
- [HH:MM] — [Event]
|
||||
- [HH:MM] — [Event]
|
||||
|
||||
## Current State
|
||||
**Systems affected**: [List]
|
||||
**Workaround available**: [Yes/No — describe if yes]
|
||||
**Estimated resolution**: [Time estimate]
|
||||
|
||||
## Actions Taken
|
||||
1. [Action taken and result]
|
||||
2. [Action taken and result]
|
||||
|
||||
## Handoff Context
|
||||
**For next responder**:
|
||||
- [What's been tried]
|
||||
- [What hasn't been tried yet]
|
||||
- [Suspected root cause]
|
||||
- [Relevant logs/metrics to check]
|
||||
|
||||
## Stakeholder Communication
|
||||
**Last update sent**: [Timestamp]
|
||||
**Next update due**: [Timestamp]
|
||||
**Communication channel**: [Where updates are posted]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Usage Guide
|
||||
|
||||
| Situation | Template to Use |
|
||||
|-----------|----------------|
|
||||
| Assigning work to another agent | Standard Handoff (#1) |
|
||||
| QA approves a task | QA PASS (#2) |
|
||||
| QA rejects a task | QA FAIL (#3) |
|
||||
| Task exceeds 3 retries | Escalation Report (#4) |
|
||||
| Moving between phases | Phase Gate Handoff (#5) |
|
||||
| End of sprint | Sprint Handoff (#6) |
|
||||
| System incident | Incident Handoff (#7) |
|
||||
Reference in New Issue
Block a user