agemon 0.1.0 → 6.3.0

package/assets/skills/team-lead/prd-generator/SKILL.md

@@ -0,0 +1,437 @@
+---
+name: prd-generator
+description: Generate comprehensive Product Requirements Documents (PRDs) for product managers. Use this skill when users ask to "create a PRD", "write product requirements", "document a feature", or need help structuring product specifications.
+---
+
+# PRD Generator
+
+## Overview
+
+Generate comprehensive, well-structured Product Requirements Documents (PRDs) that follow industry best practices. This skill helps product managers create clear, actionable requirements documents that align stakeholders and guide development teams.
+
+## Core Workflow
+
+When a user requests to create a PRD (e.g., "create a PRD for a user authentication feature"), follow this workflow:
+
+### Step 1: Gather Context
+
+Before generating the PRD, collect essential information through a discovery conversation:
+
+**Required Information:**
+- **Feature/Product Name**: What are we building?
+- **Problem Statement**: What problem does this solve?
+- **Target Users**: Who is this for?
+- **Business Goals**: What are we trying to achieve?
+- **Success Metrics**: How will we measure success?
+- **Timeline/Constraints**: Any deadlines or limitations?
+
+**Discovery Questions to Ask:**
+
+```
+1. What problem are you trying to solve?
+2. Who is the primary user/audience for this feature?
+3. What are the key business objectives?
+4. Are there any technical constraints we should be aware of?
+5. What does success look like? How will you measure it?
+6. What's the timeline for this feature?
+7. What's explicitly out of scope?
+```
+
+**Note:** If the user provides a detailed brief or requirements upfront, you can skip some questions. Always ask for clarification on missing critical information.
+
+### Step 2: Generate PRD Structure
+
+Structure the document with the following sections:
+
+1. **Executive Summary** - High-level overview (2-3 paragraphs)
+2. **Problem Statement** - Clear articulation of the problem
+3. **Goals & Objectives** - What we're trying to achieve
+4. **User Personas** - Who we're building for
+5. **User Stories & Requirements** - Detailed functional requirements
+6. **Success Metrics** - KPIs and measurement criteria
+7. **Scope** - What's in and out of scope
+8. **Technical Considerations** - Architecture, dependencies, constraints
+9. **Design & UX Requirements** - UI/UX considerations
+10. **Timeline & Milestones** - Key dates and phases
+11. **Risks & Mitigation** - Potential issues and solutions
+12. **Dependencies & Assumptions** - What we're relying on
+13. **Open Questions** - Unresolved items
+
+### Step 3: Create User Stories
+
+For each major requirement, generate user stories using the standard format:
+
+```
+As a [user type],
+I want to [action],
+So that [benefit/value].
+
+Acceptance Criteria:
+- [Specific, testable criterion 1]
+- [Specific, testable criterion 2]
+- [Specific, testable criterion 3]
+```
+
+Keep each story independent, testable, and free of implementation details (see User Story Best Practices below).
+
+### Step 4: Define Success Metrics
+
+Use appropriate metrics frameworks based on the product type:
+
+- **AARRR (Pirate Metrics)**: Acquisition, Activation, Retention, Revenue, Referral
+- **HEART Framework**: Happiness, Engagement, Adoption, Retention, Task Success
+- **North Star Metric**: Single key metric that represents core value
+- **OKRs**: Objectives and Key Results
+
+Pick the framework that matches the product type and stakeholder expectations, and define concrete targets for each metric — not just the metric name.
+
+### Step 5: Validate & Review
+
+Before finalizing, walk through the Self-Review Checklist below to confirm the PRD is complete: all required sections present, user stories follow the standard format, success metrics are defined with targets, scope is clearly bounded, and no placeholder text remains.
+
+## Usage Patterns
+
+### Pattern 1: New Feature PRD
+
+**User Request:** "Create a PRD for adding dark mode to our mobile app"
+
+**Execution:**
+
+1. Ask discovery questions about dark mode requirements
+2. Generate PRD using template
+3. Create user stories for:
+   - Theme switching
+   - Preference persistence
+   - System-level sync
+   - Design token updates
+4. Define success metrics (adoption rate, user satisfaction)
+5. Identify technical dependencies (design system, platform APIs)
+
+### Pattern 2: Product Enhancement PRD
+
+**User Request:** "Write requirements for improving our search functionality"
+
+**Execution:**
+
+1. Gather context on current search limitations
+2. Identify user pain points and desired improvements
+3. Generate PRD with focus on:
+   - Current state analysis
+   - Proposed enhancements
+   - Impact assessment
+4. Create prioritized user stories
+5. Define before/after metrics
+
+### Pattern 3: New Product PRD
+
+**User Request:** "I need a PRD for a new analytics dashboard product"
+
+**Execution:**
+
+1. Comprehensive discovery (market analysis, user research)
+2. Generate full PRD with:
+   - Market opportunity
+   - Competitive analysis
+   - Product vision
+   - MVP scope
+   - Go-to-market considerations
+3. Detailed user stories for core features
+4. Phased rollout plan
+5. Success metrics aligned with business goals
+
+### Pattern 4: Quick PRD / One-Pager
+
+**User Request:** "Create a lightweight PRD for a small bug fix feature"
+
+**Execution:**
+
+1. Generate simplified PRD focusing on:
+   - Problem statement
+   - Solution approach
+   - Acceptance criteria
+   - Success metrics
+2. Skip sections not relevant for small scope
+3. Keep document concise (1-2 pages)
+
+## PRD Best Practices
+
+### Writing Quality Requirements
+
+**Good Requirements Are:**
+- **Specific**: Clear and unambiguous
+- **Measurable**: Can be verified/tested
+- **Achievable**: Technically feasible
+- **Relevant**: Tied to user/business value
+- **Time-bound**: Has clear timeline
+
+**Avoid:**
+- Vague language ("fast", "easy", "intuitive")
+- Implementation details (let engineers decide how)
+- Feature creep (stick to core requirements)
+- Assumptions without validation
+
+### User Story Best Practices
+
+**DO:**
+- Focus on user value, not features
+- Write from user perspective
+- Include clear acceptance criteria
+- Keep stories independent and small
+- Use consistent format
+
+**DON'T:**
+- Write technical implementation details
+- Create dependencies between stories
+- Make stories too large (epics)
+- Use internal jargon
+- Skip acceptance criteria
+
+### Scope Management
+
+**In-Scope Section:**
+- List specific features/capabilities included
+- Be explicit and detailed
+- Link to user stories
+
+**Out-of-Scope Section:**
+- Explicitly state what's NOT included
+- Prevents scope creep
+- Manages stakeholder expectations
+- Can include "future considerations"
+
+### Success Metrics Guidelines
+
+**Choose Metrics That:**
+- Align with business objectives
+- Are measurable and trackable
+- Have clear targets/thresholds
+- Include both leading and lagging indicators
+- Consider user and business value
+
+**Typical Metric Categories:**
+- **Adoption**: How many users use the feature?
+- **Engagement**: How often do they use it?
+- **Satisfaction**: Do users like it?
+- **Performance**: Does it work well?
+- **Business Impact**: Does it drive business goals?
+
+## Advanced Features
+
+### PRD Templates for Different Contexts
+
+The skill supports different PRD formats:
+
+**Standard PRD** - Full comprehensive document
+**Lean PRD** - Streamlined for agile teams
+**One-Pager** - Executive summary format
+**Technical PRD** - Engineering-focused requirements
+**Design PRD** - UX/UI-focused requirements
+
+Specify the format when requesting: "Create a lean PRD for..." or "Generate a technical PRD for..."
+
+### Integration with Design
+
+**Design Requirements Section Should Include:**
+- Visual design requirements
+- Interaction patterns
+- Accessibility requirements (WCAG compliance)
+- Responsive design considerations
+- Design system components to use
+- User flow diagrams
+- Wireframe/mockup references
+
+### Technical Considerations Section
+
+**Should Address:**
+- **Architecture**: High-level technical approach
+- **Dependencies**: External services, libraries, APIs
+- **Security**: Authentication, authorization, data protection
+- **Performance**: Load times, scalability requirements
+- **Compatibility**: Browser, device, platform support
+- **Data**: Storage, migration, privacy considerations
+- **Integration**: How it fits with existing systems
+
+### Stakeholder Alignment
+
+**PRD Should Help:**
+- Align cross-functional teams
+- Set clear expectations
+- Enable parallel work streams
+- Facilitate decision-making
+- Provide single source of truth
+
+**Distribution Checklist:**
+- [ ] Engineering reviewed technical feasibility
+- [ ] Design reviewed UX requirements
+- [ ] Product leadership approved scope
+- [ ] Stakeholders understand timeline
+- [ ] Success metrics agreed upon
+
+## Common PRD Scenarios
+
+### Scenario 1: Feature Request from Customer
+
+When creating a PRD based on customer feedback:
+
+1. Document the customer request verbatim
+2. Analyze the underlying problem
+3. Generalize the solution for all users
+4. Validate with product strategy
+5. Scope appropriately (might be smaller or larger than request)
+
+### Scenario 2: Strategic Initiative
+
+When creating a PRD for a strategic company initiative:
+
+1. Link to company OKRs/goals
+2. Include market analysis
+3. Consider competitive landscape
+4. Think multi-phase rollout
+5. Include success criteria aligned with strategy
+
+### Scenario 3: Technical Debt / Infrastructure
+
+When creating a PRD for technical improvements:
+
+1. Explain user impact (even if indirect)
+2. Document current limitations
+3. Articulate benefits (speed, reliability, maintainability)
+4. Include engineering input heavily
+5. Define measurable improvements
+
+### Scenario 4: Compliance / Regulatory
+
+When creating a PRD for compliance requirements:
+
+1. Reference specific regulations (GDPR, HIPAA, etc.)
+2. Include legal/compliance review
+3. Deadline is usually non-negotiable
+4. Focus on minimum viable compliance
+5. Document audit trail requirements
+
+## Validation & Quality Checks
+
+### Self-Review Checklist
+
+Before finalizing the PRD, verify:
+
+- [ ] **Problem is clear**: Anyone can understand what we're solving
+- [ ] **Users are identified**: We know who this is for
+- [ ] **Success is measurable**: We can determine if it worked
+- [ ] **Scope is bounded**: Clear what's in and out
+- [ ] **Requirements are testable**: QA can verify completion
+- [ ] **Timeline is realistic**: Estimates validated with engineering
+- [ ] **Risks are identified**: We've thought through what could go wrong
+- [ ] **Stakeholders aligned**: Key people have reviewed and approved
+
+## Tips for Product Managers
+
+### Before Writing the PRD
+
+1. **Do your research**: User interviews, data analysis, competitive analysis
+2. **Validate the problem**: Ensure it's worth solving
+3. **Check strategic alignment**: Does this fit our roadmap?
+4. **Estimate effort**: Rough t-shirt size with engineering
+5. **Consider alternatives**: Is this the best solution?
+
+### During PRD Creation
+
+1. **Be clear, not clever**: Simple language wins
+2. **Show, don't tell**: Use examples, mockups, diagrams
+3. **Think edge cases**: What could go wrong?
+4. **Prioritize ruthlessly**: What's MVP vs. nice-to-have?
+5. **Collaborate early**: Don't work in isolation
+
+### After PRD Completion
+
+1. **Review with stakeholders**: Get feedback early
+2. **Iterate based on input**: PRDs are living documents
+3. **Present, don't just share**: Walk through the PRD
+4. **Get formal sign-off**: Ensure commitment
+5. **Keep it updated**: Adjust as understanding evolves
+
+## Examples
+
+### Example 1: Mobile Feature PRD
+
+```bash
+# User: "Create a PRD for adding biometric authentication to our iOS app"
+
+# Assistant will:
+# 1. Ask discovery questions about security requirements, user personas, existing auth
+# 2. Generate PRD covering:
+#    - Problem: Password friction, security concerns
+#    - Solution: Face ID / Touch ID integration
+#    - User stories: Enable biometric, fallback to password, settings management
+#    - Metrics: Adoption rate, login success rate, support tickets
+#    - Technical: iOS Keychain, LocalAuthentication framework
+#    - Risks: Device compatibility, user privacy concerns
+# 3. Output formatted markdown PRD
+```
+
+### Example 2: Web Platform Enhancement
+
+```bash
+# User: "Write requirements for improving our checkout flow conversion"
+
+# Assistant will:
+# 1. Gather data on current conversion rates and drop-off points
+# 2. Generate PRD including:
+#    - Current state analysis with metrics
+#    - Proposed improvements (guest checkout, saved payment, progress indicator)
+#    - A/B test plan
+#    - Success metrics: Conversion rate increase, time to checkout
+#    - User stories for each improvement
+# 3. Include phased rollout approach
+```
+
+### Example 3: B2B Product PRD
+
+```bash
+# User: "I need a PRD for an admin dashboard for enterprise customers"
+
+# Assistant will:
+# 1. Identify B2B-specific requirements (multi-tenancy, permissions, reporting)
+# 2. Generate comprehensive PRD with:
+#    - Enterprise user personas (admin, manager, analyst)
+#    - Role-based access control requirements
+#    - Reporting and analytics needs
+#    - Integration requirements (SSO, SCIM)
+#    - Success metrics: Customer adoption, admin efficiency
+# 3. Include enterprise-specific considerations (compliance, SLAs)
+```
+
+## Troubleshooting
+
+**Issue: PRD is too long/detailed**
+
+Solution: Create a "Lean PRD" focusing on problem, solution, acceptance criteria, and metrics. Reserve full PRD for major initiatives.
+
+**Issue: Requirements are too vague**
+
+Solution: Add specific examples, use concrete numbers, include visual references. Replace "fast" with "loads in under 2 seconds."
+
+**Issue: Stakeholders not aligned**
+
+Solution: Share PRD early as draft, incorporate feedback, present in person, get explicit sign-off before development starts.
+
+**Issue: Scope keeps expanding**
+
+Solution: Use "Out of Scope" section aggressively, create separate PRDs for future phases, tie scope to timeline constraints.
+
+**Issue: Engineers say it's not feasible**
+
+Solution: Involve engineering earlier in process, be flexible on solution approach, focus on problem not implementation.
+
+## Best Practices Summary
+
+1. **Start with the problem, not the solution**
+2. **Write for your audience** (execs need summary, engineers need details)
+3. **Be specific and measurable** (avoid vague language)
+4. **Include visuals** (mockups, diagrams, flows)
+5. **Define success upfront** (metrics, not features)
+6. **Scope aggressively** (MVP mentality)
+7. **Collaborate, don't dictate** (get input from all functions)
+8. **Keep it updated** (PRD is a living document)
+9. **Focus on "why" and "what", not "how"** (let engineers solve "how")
+10. **Make it skimmable** (headers, bullets, summaries)

package/assets/skills/team-lead/skill-headofit-audit/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: skill-headofit-audit
+description: Evaluates SaaS tools, cloud infrastructure costs, self-hosted alternatives, vendor lock-in risks, and compliance readiness for Head of IT and IT Leadership decisions.
+triggers: ["@vendor-audit", "head of it evaluation", "saas audit", "build vs buy", "infrastructure cost audit", "vendor evaluation"]
+---
+
+# Instruction Rules
+1. **Multi-Vector Scoring:** Evaluate across 5 key pillars: Functional Fit, Technical/API Integration, Security & Compliance, Operational Overhead, and Total Cost of Ownership (TCO).
+2. **Require Build vs. Buy Analysis:** Force explicit trade-off comparisons between managed SaaS, open-source/self-hosted (e.g., Coolify/Docker), and custom builds.
+3. **Flag Lock-In & Portability Risks:** Always audit data export formats, vendor exit costs, and migration pathways.
+4. **Output Format:** Clean Markdown featuring comparative scoring matrices, TCO projections, and strategic recommendations.
+
+# Assessment Workflow
+- **Phase 1: Need & Scope Definition:** Clarify business problem, usage scale, must-have constraints, and budget ceilings.
+- **Phase 2: Build vs. Buy vs. Self-Host Analysis:** Evaluate managed options vs. self-hosted/open-source deployments.
+- **Phase 3: Multi-Pillar Scoring & Security Pre-flight:** Audit SOC 2, GDPR, data residency, SLA guarantees, and API capabilities.
+- **Phase 4: Financial TCO & Vendor Decision:** Calculate initial onboarding, subscription, maintenance, and exit costs over a 12–36 month horizon.
+
+---
+
+# Output Schema
+
+# IT Infrastructure & Vendor Audit: [Vendor / Solution Name]
+
+## 1. Executive Brief & Context
+- **Evaluation Goal:** [e.g., Replacing managed DB platform with self-hosted PostgreSQL via Coolify]
+- **Current Annual Spend / Cost:** [e.g., $18,000 / year]
+- **Target Scale:** [e.g., 50 team members, 20 microservices, 99.9% uptime requirement]
+
+---
+
+## 2. Build vs. Buy vs. Self-Host Matrix
+
+| Parameter | Managed SaaS | Self-Hosted / Homelab | Custom In-House |
+| :--- | :--- | :--- | :--- |
+| **Direct License Cost** | High ($1,500/mo) | Low (Infra bare-metal cost) | None |
+| **Ops / Maintenance Effort** | Low (Vendor managed) | Medium-High (Internal Team) | High |
+| **Data Control & Residency** | Moderate (Vendor Cloud) | Complete (Self-managed) | Complete |
+| **Vendor Lock-in Risk** | High | Low | None |
+
+---
+
+## 3. Weighted Evaluation Scorecard
+
+| Category | Weight | Score (1-5) | Key Observations |
+| :--- | :--- | :--- | :--- |
+| **Functional & Workflow Fit** | 30% | 4.5 / 5.0 | Meets 95% of operational requirements out of the box. |
+| **Technical & API Capabilities** | 20% | 4.0 / 5.0 | REST & Webhook support present; missing GraphQL API. |
+| **Security & Compliance** | 20% | 5.0 / 5.0 | GDPR compliant, SOC 2 Type II certified, isolated tenant DBs. |
+| **Ops & Maintenance Overhead** | 15% | 3.5 / 5.0 | Requires internal team onboarding and backup orchestration. |
+| **Financial & TCO Impact** | 15% | 4.0 / 5.0 | Payback period achieved within 6 months. |
+| **Weighted Total** | **100%** | **4.28 / 5.0**| **RECOMMENDED** |
+
+---
+
+## 4. 3-Year Total Cost of Ownership (TCO) Projection
+
+```
+[Year 1 Setup & Licensing] ──> $12,000
+[Year 2 Maintenance & Run]  ──> $8,500
+[Year 3 Maintenance & Run]  ──> $8,500
+Total Estimated 3-Year TCO:   $29,000 (35% savings vs incumbent)
+```
+
+---
+
+## 5. Security, Risk & Exit Strategy
+- **Security Check:** SOC 2 Type II verified, TLS 1.3 enforced, RBAC + SAML/SSO supported.
+- **Vendor Lock-in Risk:** LOW. Native JSON/SQL export supported via API and CLI.
+- **Recommended Next Steps:**
+  1. Initiate 14-day technical pilot on staging infrastructure.
+  2. Draft migration & rollback plan before contract finalization.

package/assets/skills/team-lead/skill-incident-rca/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: skill-incident-rca
+description: Blameless Root Cause Analysis (RCA) and Post-Mortem framework for production outages, regressions, and critical incidents. Uses the 5 Whys and Causal Chain analysis to convert incident logs into durable preventative actions.
+triggers: ["@incident-rca", "post-mortem", "root cause analysis", "incident report", "outage rca", "rca"]
+---
+
+# Instruction Rules
+1. **Enforce Blameless Culture:** Focus strictly on systemic vulnerabilities, process gaps, and missing safeguards. Never attribute failures to individual human error.
+2. **5 Whys Deep-Dive:** Chain every surface symptom down through at least 5 levels of "Why?" until reaching an actionable architectural or process gap. If evidence runs out before reaching level 5, mark the chain `UNKNOWN — insufficient evidence` at that point rather than inventing an unsupported cause.
+3. **Quantify Impact:** Explicitly quantify outage duration, user blast radius, data loss, and SLA breach metrics. Mark any metric not available in the evidence as `UNKNOWN` rather than estimating.
+4. **Action Item Discipline:** Output clear action items with specific owners, category tags, and due dates. Avoid vague terms like "improve testing".
+
+# Execution Workflow
+- **Step 1: Timeline Reconstruction:** Map events chronologically (Start $\rightarrow$ Detection $\rightarrow$ Triage $\rightarrow$ Mitigation $\rightarrow$ Resolution).
+- **Step 2: Root Cause & 5 Whys Analysis:** Dig past immediate triggers (e.g., "database lock") to underlying root causes (e.g., "missing connection pool timeouts").
+- **Step 3: Contributing Factors:** Identify monitoring gaps, missing runbooks, or testing blind spots that aggravated the issue.
+- **Step 4: Preventative Action Matrix:** Create owned, closed-form engineering tasks.
+
+---
+
+# Output Schema
+
+# Post-Mortem: [Incident Title / Outage Name]
+
+## 1. Executive Summary
+- **Incident Date:** {{YYYY-MM-DD}}
+- **Severity Level:** [ SEV-1 | SEV-2 | SEV-3 ]
+- **Time to Detect (TTD):** [e.g., 8 minutes]
+- **Time to Resolve (TTR):** [e.g., 42 minutes]
+- **Blast Radius:** [e.g., 15% of active API traffic received HTTP 500 errors]
+- **Summary:** [3-sentence executive overview of what failed, impact, and mitigation]
+
+---
+
+## 2. Chronological Timeline
+| Timestamp (UTC) | Event Phase | Description & Findings | Source / Evidence |
+| :--- | :--- | :--- | :--- |
+| **14:02** | Incident Start | Spike in background worker memory usage. | Grafana Alert |
+| **14:08** | Detection | Automated alert paged On-Call Lead. | PagerDuty |
+| **14:15** | Containment | Scaled worker pool & cleared queue. | Manual Action |
+| **14:44** | Resolution | Deployed patch `v1.2.1` with memory caps. | CI/CD Deploy |
+
+---
+
+## 3. Root Cause Analysis (The 5 Whys)
+1. **Why did the API crash?** $\rightarrow$ Worker node ran out of memory (OOM).
+2. **Why did it run out of memory?** $\rightarrow$ A background job loaded a 4GB dataset into RAM at once.
+3. **Why did it load the full dataset?** $\rightarrow$ Pagination parameter was omitted in the query payload.
+4. **Why was pagination missing?** $\rightarrow$ The endpoint lacked input schema validation for array bounds.
+5. **Why was validation missing?** $\rightarrow$ Systemic gap: API review checklists do not require execution limits on bulk export endpoints.
+
+---
+
+## 4. Contributing Factors
+- **Monitoring Gap:** No alert was configured for database connection pool saturation prior to node OOM.
+- **Process Gap:** Staging environment data volume was too small to surface memory scaling limits during integration testing.
+
+---
+
+## 5. Preventative Action Items
+
+| Action Item | Category | Assignee | Due Date | Target Ticket |
+| :--- | :--- | :--- | :--- | :--- |
+| Add memory boundary limit to API validator | Prevention | `@developer` | 2026-10-05 | `ENG-402` |
+| Configure connection pool saturation alert at 80% | Detection | `@devops` | 2026-10-02 | `OPS-118` |
+| Seed staging DB with realistic volume mock data | Process | `@qa-lead` | 2026-10-12 | `QA-88` |

package/assets/skills/team-lead/skill-meeting-lifecycle/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: skill-meeting-lifecycle
+description: Processes raw transcripts or meeting notes into structured intelligence, distinguishing executive summaries, key decisions, speaker attributions, and follow-up items.
+triggers: ["@meeting-notes", "process transcript", "meeting summary", "meeting notes", "call breakdown"]
+---
+
+# Instruction Rules
+1. **Never Hallucinate Commitments:** Only extract decisions and action items explicitly stated or clearly implied in the transcript.
+2. **Dual-Tier Summary:** Always provide both a high-level executive brief (for leadership/stakeholders) and a granular technical breakdown (for engineering).
+3. **Obsidian Integration:** Auto-generate `[[WikiLinks]]` for people, projects, and key technologies mentioned.
+4. **Output Format:** Clean Markdown using structured tables and actionable checklists.
+
+# Processing Framework
+- **Step 1: Context & Metadata Extraction:** Identify meeting date, purpose, attendees, and project context.
+- **Step 2: Executive & Granular Synthesis:** Summarize core outcomes and group discussion points by technical topic.
+- **Step 3: Decision Log:** Extract concrete architectural, product, or operational decisions made during the call.
+- **Step 4: Action Items Extraction:** Prepare raw task payloads for downstream PM tools or Obsidian daily notes.
+
+---
+
+# Output Schema
+
+# Meeting Notes: [Meeting Title / Topic]
+
+## 1. Meeting Overview
+- **Date & Time:** {{YYYY-MM-DD}}
+- **Attendees:** [[Person A]], [[Person B]], [[Person C]]
+- **Project Context:** [[Project Name]]
+- **Executive Brief:** [2-3 concise sentences summarizing the core outcome of the call]
+
+---
+
+## 2. Key Decisions Made
+| # | Decision | Rationale | Owner / Lead |
+| :--- | :--- | :--- | :--- |
+| **1** | Migrating auth layer to Supabase | Reduces custom maintenance overhead | [[Person A]] |
+| **2** | Postpone feature X to Sprint 15 | Prioritizing API performance fixes | [[Person B]] |
+
+---
+
+## 3. Topic Breakdown & Discussion Notes
+
+### Topic A: [e.g., Infrastructure & Database Scaling]
+- Discussion focused on recent API latency spikes under load.
+- [[Person A]] shared telemetry showing connection pool exhaustion.
+- Consensus reached to add Redis caching before doubling database instance size.
+
+### Topic B: [e.g., Q3 Product Roadmap Adjustments]
+- Reviewed client feedback on onboarding workflow.
+- Agreed to simplify signup steps down to 2 screens.
+
+---
+
+## 4. Raw Action Items
+- [ ] **Task 1:** [[Person A]] to draft Redis caching proposal by Friday.
+- [ ] **Task 2:** [[Person B]] to update Figma designs for simplified onboarding.
+- [ ] **Task 3:** [[Person C]] to check staging environment log retention settings.
+
+---
+
+## 5. Unresolved Questions & Next Steps
+- [ ] **Open Item:** How will the new caching layer handle multi-region invalidation?
+- **Next Sync:** Scheduled for {{YYYY-MM-DD}}