@monoes/monomindcli 2.15.2 → 2.15.4

package/org-skills/agent-tool-design/references/best_practices.md

@@ -0,0 +1,176 @@
+# Tool Design Best Practices
+
+This document provides additional best practices and guidelines for designing tools for agent systems.
+
+## Tool Philosophy
+
+Tools are the primary interface between agents and the world. Unlike traditional APIs designed for developers who understand underlying systems, tools must be designed for language models that infer intent from descriptions and generate calls from natural language requests. This fundamental difference requires rethinking how we design and document tool interfaces.
+
+The goal is to create tools that agents can discover, understand, and use correctly without extensive trial and error. Every ambiguity in tool definitions becomes a potential failure mode. Every unclear parameter name forces the agent to guess. Every missing example leaves the agent without guidance for edge cases.
+
+## Description Engineering Principles
+
+### Principle 1: Answer the Fundamental Questions
+
+Every tool description should clearly answer four questions. What does the tool do? State exactly what the tool accomplishes in specific terms, avoiding vague language like "helps with" or "can be used for." When should it be used? Provide specific triggers and contexts, including both direct triggers and indirect signals that indicate the tool's applicability. What inputs does it accept? Document parameters with types, constraints, and defaults, explaining what each parameter controls. What does it return? Describe output format and structure, including examples of successful responses and error conditions.
+
+### Principle 2: Use Consistent Structure
+
+Maintain consistent structure across all tool descriptions in your codebase. When agents encounter a new tool, they should be able to predict where to find specific information based on patterns learned from other tools. This reduces cognitive overhead and prevents errors caused by inconsistent formatting.
+
+A recommended structure includes a brief description in the first sentence, a detailed explanation with usage context, a parameters section with clear type information, a returns section describing output structure, and an errors section listing possible failure modes with recovery guidance.
+
+### Principle 3: Include Concrete Examples
+
+Examples bridge the gap between abstract description and actual usage. Include examples of typical calls showing common parameter combinations, examples of edge cases and how to handle them, and examples of error responses and appropriate recovery actions.
+
+Good examples are specific rather than generic. Instead of "Use an ID like '123'", use "Use format: 'CUST-######' (e.g., 'CUST-000001')". Instead of "Provide a date", use "Format: 'YYYY-MM-DD' (e.g., '2024-01-15')".
+
+## Naming Conventions
+
+### Parameter Naming
+
+Parameter names should be self-documenting. Use names that clearly indicate purpose without requiring additional explanation. Prefer full words over abbreviations except for widely understood acronyms like "id" or "url". Use consistent naming across tools for similar concepts.
+
+Good parameter names include customer_id, search_query, output_format, max_results, and include_details. Poor parameter names include x, val, param1, and info.
+
+### Enumeration Values
+
+When parameters accept enumerated values, use consistent naming across all tools. For boolean-style options, use prefix patterns like "include_" for affirmative options (include_history, include_metadata) and "exclude_" for negative options (exclude_archived, exclude_inactive). For categorical values, use consistent terminology like "format": "concise" | "detailed" rather than mixing "format": "short" | "long" in some tools and "format": "brief" | "complete" in others.
+
+## Error Message Design
+
+### The Dual Audience
+
+Error messages serve two audiences with different needs. Developers debugging issues need detailed technical information including stack traces and internal state. Agents recovering from failures need actionable guidance that tells them what went wrong and how to correct it.
+
+Design error messages with agent recovery as the primary consideration. Include what specifically went wrong in clear language. Provide resolution guidance describing what the agent should do next. Include corrected format for input errors. Add examples of valid input.
+
+### Error Message Structure
+
+```json
+{
+    "error": {
+        "code": "INVALID_CUSTOMER_ID",
+        "category": "validation",
+        "message": "Customer ID 'CUST-123' does not match required format",
+        "expected_format": {
+            "description": "Customer ID must be 9 characters",
+            "pattern": "CUST-######",
+            "example": "CUST-000001"
+        },
+        "resolution": "Provide a customer ID matching pattern CUST-######",
+        "retryable": true
+    }
+}
+```
+
+### Common Error Patterns
+
+Validation errors should specify what was received, what format was expected, and how to correct it. Rate limit errors should specify wait time and retry guidance. Not found errors should suggest alternative approaches or verification steps. System errors should indicate whether retry is appropriate and suggest alternatives.
+
+## Response Format Optimization
+
+### The Token-Accuracy Trade-off
+
+Verbose responses provide comprehensive information but consume significant context tokens. Concise responses minimize token usage but may lack necessary detail. The optimal approach provides format options that allow agents to request appropriate verbosity for their needs.
+
+### Format Options Pattern
+
+```python
+def get_customer_response(format: str = "concise"):
+    """
+    Retrieve customer information.
+    
+    Args:
+        format: Response format - 'concise' for key fields only,
+                'detailed' for complete customer record
+    """
+    if format == "concise":
+        return {
+            "id": customer.id,
+            "name": customer.name,
+            "status": customer.status
+        }
+    else:  # detailed
+        return {
+            "id": customer.id,
+            "name": customer.name,
+            "email": customer.email,
+            "phone": customer.phone,
+            "address": customer.address,
+            "status": customer.status,
+            "created_at": customer.created_at,
+            "history": customer.history,
+            "preferences": customer.preferences
+        }
+```
+
+### When to Use Each Format
+
+Use concise format for quick verification or simple lookups, when only confirmation is needed, and in subsequent tool calls after initial retrieval. Use detailed format when making decisions based on customer data, when output becomes input for other processing, and when complete context is necessary for correctness.
+
+## Tool Collection Design
+
+### Managing Tool Proliferation
+
+As agent systems grow, tool collections tend to proliferate. More tools can enable more capabilities but create selection challenges. Research shows that tool description overlap causes model confusion. The key insight is that if a human engineer cannot definitively say which tool should be used in a given situation, an agent cannot be expected to do better.
+
+### Consolidation Guidelines
+
+Consolidate tools that represent sequential steps in a single workflow into a single tool that handles the entire workflow. For example, instead of list_users, list_events, and create_event, implement schedule_event that finds availability and schedules in one call.
+
+Keep separate tools that have fundamentally different behaviors even if they share some functionality. Tools used in different contexts should maintain separation to prevent confusion.
+
+Maintain clear boundaries between tools even when they operate in similar domains. Overlapping functionality should be minimized through careful design.
+
+### Tool Selection Guidance
+
+When designing tool collections, consider what information an agent needs to make correct selections. If multiple tools could apply to a situation, clarify the distinction in descriptions. Use namespacing to create logical groupings that help agents navigate the tool space.
+
+## Testing Tool Design
+
+### Evaluation Criteria
+
+Evaluate tool designs against clarity, completeness, recoverability, efficiency, and consistency criteria. Clarity measures whether agents can determine when to use the tool. Completeness measures whether descriptions include all necessary information. Recoverability measures whether agents can recover from errors. Efficiency measures whether tools support appropriate response formats. Consistency measures whether tools follow naming and schema conventions.
+
+### Agent Testing Pattern
+
+Test tools by presenting representative agent requests and evaluating the resulting tool calls:
+
+1. Prepare test cases with diverse agent requests
+2. Have an agent formulate tool calls for each request
+3. Evaluate call correctness against expected patterns
+4. Identify common failure modes
+5. Refine tool definitions based on findings
+
+## Anti-Patterns to Avoid
+
+### Vague Descriptions
+
+Bad: "Search the database for customer information." This leaves too many questions unanswered. What database? What information is available? What format should queries take?
+
+Good: "Retrieve customer information by ID or email. Use when user asks about specific customer details, history, or status. Returns customer object with id, name, email, account_status, and optional order history."
+
+### Cryptic Parameter Names
+
+Bad: Parameters named x, val, or param1 force agents to guess meaning.
+
+Good: Parameters named customer_id, max_results, or include_history are self-documenting.
+
+### Missing Error Handling
+
+Bad: Tools that fail with generic errors or no error handling.
+
+Good: Tools that provide specific error types, messages, and resolution guidance.
+
+### Inconsistent Naming
+
+Bad: Using id in some tools, identifier in others, customer_id in some and user_id in others for similar concepts.
+
+Good: Maintaining consistent naming patterns across all tools for similar concepts.
+
+## Checklist for Tool Design
+
+Before deploying a new tool, verify that the description clearly states what the tool does and when to use it. Verify that all parameters have descriptive names and clear type information. Verify that return values are documented with structure and examples. Verify that error cases are covered with actionable messages. Verify that the tool follows naming conventions used elsewhere. Verify that examples demonstrate common usage patterns. Verify that format options are available if response size varies significantly.
+

package/org-skills/agile-product-owner/LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Alireza Rezvani
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/org-skills/agile-product-owner/SKILL.md

@@ -0,0 +1,397 @@
+---
+name: agile-product-owner
+description: "Agile product ownership for backlog management and sprint execution. Covers user story writing, acceptance criteria, sprint planning, and velocity tracking. Use when writing user stories, creating acceptance criteria, planning sprints, estimating story points, breaking down epics, or prioritizing the backlog."
+tags: ["product"]
+tools: []
+license: MIT
+source: https://github.com/alirezarezvani/claude-skills
+source_path: "product-team/agile-product-owner/skills/agile-product-owner"
+source_commit: 19392f7a08264ed00486a251f5b2098321771f94
+---
+# Agile Product Owner
+
+Backlog management and sprint execution toolkit for product owners, including user story generation, acceptance criteria patterns, sprint planning, and velocity tracking.
+
+---
+
+## Table of Contents
+
+- [What Makes This Skill Different](#what-makes-this-skill-different)
+- [User Story Generation Workflow](#user-story-generation-workflow)
+- [Acceptance Criteria Patterns](#acceptance-criteria-patterns)
+- [Epic Breakdown Workflow](#epic-breakdown-workflow)
+- [Sprint Planning Workflow](#sprint-planning-workflow)
+- [Backlog Prioritization](#backlog-prioritization)
+- [Reference Documentation](#reference-documentation)
+- [Tools](#tools)
+
+---
+
+## What Makes This Skill Different
+
+- **Capacity math that aligns with reality:** sprint capacity is based on velocity × availability factor, not hope.
+- **Acceptance criteria scaled by story size:** minimum AC counts map to story points to avoid under-spec'ing large items.
+- **Weighted prioritization that stays consistent:** value 40%, impact 30%, risk 15%, effort 15% keeps tradeoffs explicit.
+- **Systematic epic splitting techniques:** five concrete split patterns prevent oversized stories.
+- **INVEST validation baked into workflows:** every story includes a validation step, not just guidance.
+
+## User Story Generation Workflow
+
+Create INVEST-compliant user stories from requirements:
+
+1. Identify the persona (who benefits from this feature)
+2. Define the action or capability needed
+3. Articulate the benefit or value delivered
+4. Write acceptance criteria using Given-When-Then
+5. Estimate story points using Fibonacci scale
+6. Validate against INVEST criteria
+7. Add to backlog with priority
+8. **Validation:** Story passes all INVEST criteria; acceptance criteria are testable
+
+### User Story Template
+
+```
+As a [persona],
+I want to [action/capability],
+So that [benefit/value].
+```
+
+**Example:**
+```
+As a marketing manager,
+I want to export campaign reports to PDF,
+So that I can share results with stakeholders who don't have system access.
+```
+
+### Story Types
+
+| Type | Template | Example |
+|------|----------|---------|
+| Feature | As a [persona], I want to [action] so that [benefit] | As a user, I want to filter search results so that I find items faster |
+| Improvement | As a [persona], I need [capability] to [goal] | As a user, I need faster page loads to complete tasks without frustration |
+| Bug Fix | As a [persona], I expect [behavior] when [condition] | As a user, I expect my cart to persist when I refresh the page |
+| Enabler | As a developer, I need to [technical task] to enable [capability] | As a developer, I need to implement caching to enable instant search |
+
+### Persona Reference
+
+| Persona | Typical Needs | Context |
+|---------|--------------|---------|
+| End User | Efficiency, simplicity, reliability | Daily feature usage |
+| Administrator | Control, visibility, security | System management |
+| Power User | Automation, customization, shortcuts | Expert workflows |
+| New User | Guidance, learning, safety | Onboarding |
+
+---
+
+## Acceptance Criteria Patterns
+
+Write testable acceptance criteria using Given-When-Then format.
+
+### Given-When-Then Template
+
+```
+Given [precondition/context],
+When [action/trigger],
+Then [expected outcome].
+```
+
+**Examples:**
+```
+Given the user is logged in with valid credentials,
+When they click the "Export" button,
+Then a PDF download starts within 2 seconds.
+
+Given the user has entered an invalid email format,
+When they submit the registration form,
+Then an inline error message displays "Please enter a valid email address."
+
+Given the shopping cart contains items,
+When the user refreshes the browser,
+Then the cart contents remain unchanged.
+```
+
+### Acceptance Criteria Checklist
+
+Each story should include criteria for:
+
+| Category | Example |
+|----------|---------|
+| Happy Path | Given valid input, When submitted, Then success message displayed |
+| Validation | Should reject input when required field is empty |
+| Error Handling | Must show user-friendly message when API fails |
+| Performance | Should complete operation within 2 seconds |
+| Accessibility | Must be navigable via keyboard only |
+
+### Minimum Criteria by Story Size
+
+| Story Points | Minimum AC Count |
+|--------------|------------------|
+| 1-2 | 3-4 criteria |
+| 3-5 | 4-6 criteria |
+| 8 | 5-8 criteria |
+| 13+ | Split the story |
+
+See `references/user-story-templates.md` for complete template library.
+
+---
+
+## Epic Breakdown Workflow
+
+Break epics into deliverable sprint-sized stories:
+
+1. Define epic scope and success criteria
+2. Identify all personas affected by the epic
+3. List all capabilities needed for each persona
+4. Group capabilities into logical stories
+5. Validate each story is ≤8 points
+6. Identify dependencies between stories
+7. Sequence stories for incremental delivery
+8. **Validation:** Each story delivers standalone value; total stories cover epic scope
+
+### Splitting Techniques
+
+| Technique | When to Use | Example |
+|-----------|-------------|---------|
+| By workflow step | Linear process | "Checkout" → "Add to cart" + "Enter payment" + "Confirm order" |
+| By persona | Multiple user types | "Dashboard" → "Admin dashboard" + "User dashboard" |
+| By data type | Multiple inputs | "Import" → "Import CSV" + "Import Excel" |
+| By operation | CRUD functionality | "Manage users" → "Create" + "Edit" + "Delete" |
+| Happy path first | Risk reduction | "Feature" → "Basic flow" + "Error handling" + "Edge cases" |
+
+### Epic Example
+
+**Epic:** User Dashboard
+
+**Breakdown:**
+```
+Epic: User Dashboard (34 points total)
+├── US-001: View key metrics (5 pts) - End User
+├── US-002: Customize layout (5 pts) - Power User
+├── US-003: Export data to CSV (3 pts) - End User
+├── US-004: Share with team (5 pts) - End User
+├── US-005: Set up alerts (5 pts) - Power User
+├── US-006: Filter by date range (3 pts) - End User
+├── US-007: Admin overview (5 pts) - Admin
+└── US-008: Enable caching (3 pts) - Enabler
+```
+
+---
+
+## Sprint Planning Workflow
+
+Plan sprint capacity and select stories:
+
+1. Calculate team capacity (velocity × availability)
+2. Review sprint goal with stakeholders
+3. Select stories from prioritized backlog
+4. Fill to 80-85% of capacity (committed)
+5. Add stretch goals (10-15% additional)
+6. Identify dependencies and risks
+7. Break complex stories into tasks
+8. **Validation:** Committed points ≤85% capacity; all stories have acceptance criteria
+
+### Capacity Calculation
+
+```
+Sprint Capacity = Average Velocity × Availability Factor
+
+Example:
+Average Velocity: 30 points
+Team availability: 90% (one member partially out)
+Adjusted Capacity: 27 points
+
+Committed: 23 points (85% of 27)
+Stretch: 4 points (15% of 27)
+```
+
+### Availability Factors
+
+| Scenario | Factor |
+|----------|--------|
+| Full sprint, no PTO | 1.0 |
+| One team member out 50% | 0.9 |
+| Holiday during sprint | 0.8 |
+| Multiple members out | 0.7 |
+
+### Sprint Loading Template
+
+```
+Sprint Capacity: 27 points
+Sprint Goal: [Clear, measurable objective]
+
+COMMITTED (23 points):
+[H] US-001: User dashboard (5 pts)
+[H] US-002: Export feature (3 pts)
+[H] US-003: Search filter (5 pts)
+[M] US-004: Settings page (5 pts)
+[M] US-005: Help tooltips (3 pts)
+[L] US-006: Theme options (2 pts)
+
+STRETCH (4 points):
+[L] US-007: Sort options (2 pts)
+[L] US-008: Print view (2 pts)
+```
+
+See `references/sprint-planning-guide.md` for complete planning procedures.
+
+---
+
+## Backlog Prioritization
+
+Prioritize backlog using value and effort assessment.
+
+### Priority Levels
+
+| Priority | Definition | Sprint Target |
+|----------|------------|---------------|
+| Critical | Blocking users, security, data loss | Immediate |
+| High | Core functionality, key user needs | This sprint |
+| Medium | Improvements, enhancements | Next 2-3 sprints |
+| Low | Nice-to-have, minor improvements | Backlog |
+
+### Prioritization Factors
+
+| Factor | Weight | Questions |
+|--------|--------|-----------|
+| Business Value | 40% | Revenue impact? User demand? Strategic alignment? |
+| User Impact | 30% | How many users? How frequently used? |
+| Risk/Dependencies | 15% | Technical risk? External dependencies? |
+| Effort | 15% | Size? Complexity? Uncertainty? |
+
+### INVEST Criteria Validation
+
+Before adding to sprint, validate each story:
+
+| Criterion | Question | Pass If... |
+|-----------|----------|------------|
+| **I**ndependent | Can this be developed without other uncommitted stories? | No blocking dependencies |
+| **N**egotiable | Is the implementation flexible? | Multiple approaches possible |
+| **V**aluable | Does this deliver user or business value? | Clear benefit in "so that" |
+| **E**stimable | Can the team estimate this? | Understood well enough to size |
+| **S**mall | Can this complete in one sprint? | ≤8 story points |
+| **T**estable | Can we verify this is done? | Clear acceptance criteria |
+
+---
+
+## Reference Documentation
+
+### User Story Templates
+
+`references/user-story-templates.md` contains:
+
+- Standard story formats by type (feature, improvement, bug fix, enabler)
+- Acceptance criteria patterns (Given-When-Then, Should/Must/Can)
+- INVEST criteria validation checklist
+- Story point estimation guide (Fibonacci scale)
+- Common story antipatterns and fixes
+- Story splitting techniques
+
+### Sprint Planning Guide
+
+`references/sprint-planning-guide.md` contains:
+
+- Sprint planning meeting agenda
+- Capacity calculation formulas
+- Backlog prioritization framework (WSJF)
+- Sprint ceremony guides (standup, review, retro)
+- Velocity tracking and burndown patterns
+- Definition of Done checklist
+- Sprint metrics and targets
+
+---
+
+## Tools
+
+### User Story Generator
+
+```bash
+# Generate stories from sample epic
+python scripts/user_story_generator.py
+
+# Plan sprint with capacity
+python scripts/user_story_generator.py sprint 30
+```
+
+Generates:
+- INVEST-compliant user stories
+- Given-When-Then acceptance criteria
+- Story point estimates (Fibonacci scale)
+- Priority assignments
+- Sprint loading with committed and stretch items
+
+### Sample Output
+
+```
+USER STORY: USR-001
+========================================
+Title: View Key Metrics
+Type: story
+Priority: HIGH
+Points: 5
+
+Story:
+As a End User, I want to view key metrics and KPIs
+so that I can save time and work more efficiently
+
+Acceptance Criteria:
+  1. Given user has access, When they view key metrics, Then the result is displayed
+  2. Should validate input before processing
+  3. Must show clear error message when action fails
+  4. Should complete within 2 seconds
+  5. Must be accessible via keyboard navigation
+
+INVEST Checklist:
+  ✓ Independent
+  ✓ Negotiable
+  ✓ Valuable
+  ✓ Estimable
+  ✓ Small
+  ✓ Testable
+```
+
+---
+
+## Sprint Metrics
+
+Track sprint health and team performance.
+
+### Key Metrics
+
+| Metric | Formula | Target |
+|--------|---------|--------|
+| Velocity | Points completed / sprint | Stable ±10% |
+| Commitment Reliability | Completed / Committed | >85% |
+| Scope Change | Points added or removed mid-sprint | <10% |
+| Carryover | Points not completed | <15% |
+
+### Velocity Tracking
+
+```
+Sprint 1: 25 points
+Sprint 2: 28 points
+Sprint 3: 30 points
+Sprint 4: 32 points
+Sprint 5: 29 points
+------------------------
+Average Velocity: 28.8 points
+Trend: Stable
+
+Planning: Commit to 24-26 points
+```
+
+### Definition of Done
+
+Story is complete when:
+
+- [ ] Code complete and peer reviewed
+- [ ] Unit tests written and passing
+- [ ] Acceptance criteria verified
+- [ ] Documentation updated
+- [ ] Deployed to staging environment
+- [ ] Product Owner accepted
+- [ ] No critical bugs remaining
+
+## Related Skills
+
+- **Scrum Master** (`project-management/scrum-master/`) — Velocity data and sprint ceremonies complement backlog management
+- **Product Manager Toolkit** (`product-team/product-manager-toolkit/`) — RICE prioritization feeds backlog ordering

package/org-skills/agile-product-owner/assets/sprint_planning_template.md

@@ -0,0 +1,84 @@
+# Sprint Planning Document
+
+## Sprint Info
+
+| Field | Value |
+|-------|-------|
+| **Sprint** | Sprint [Number] |
+| **Dates** | [Start Date] - [End Date] |
+| **Sprint Goal** | [One sentence describing what this sprint achieves] |
+| **Scrum Master** | [Name] |
+| **Product Owner** | [Name] |
+
+---
+
+## Sprint Goal
+
+[Expand on the sprint goal. What is the single most important outcome? What does "done" look like for this sprint? 2-3 sentences.]
+
+---
+
+## Team Capacity
+
+| Team Member | Available Days | Notes |
+|------------|---------------|-------|
+| [Name] | [X] / [Total] | [PTO, training, on-call, etc.] |
+| [Name] | [X] / [Total] | |
+| [Name] | [X] / [Total] | |
+
+**Total Capacity:** [X] person-days
+**Historical Velocity:** [X] story points (avg of last 3 sprints)
+**Planned Velocity:** [X] story points (adjusted for capacity)
+
+---
+
+## Selected Stories
+
+| # | Story | Points | Assignee | Priority | Status |
+|---|-------|--------|----------|----------|--------|
+| 1 | [Story title with ticket link] | [SP] | [Name] | Must Have | To Do |
+| 2 | [Story title with ticket link] | [SP] | [Name] | Must Have | To Do |
+| 3 | [Story title with ticket link] | [SP] | [Name] | Should Have | To Do |
+| 4 | [Story title with ticket link] | [SP] | [Name] | Nice to Have | To Do |
+
+**Total Planned:** [X] story points
+
+---
+
+## Dependencies
+
+| Dependency | Blocking Story | Owner | Status | Due Date |
+|-----------|---------------|-------|--------|----------|
+| [External API ready] | [Story #] | [Name/Team] | [Status] | [Date] |
+| [Design review complete] | [Story #] | [Name] | [Status] | [Date] |
+
+---
+
+## Risks
+
+| Risk | Impact | Likelihood | Mitigation |
+|------|--------|-----------|-----------|
+| [Risk description] | High/Med/Low | High/Med/Low | [Plan] |
+| [Risk description] | High/Med/Low | High/Med/Low | [Plan] |
+
+---
+
+## Definition of Done
+
+- [ ] Code complete and peer reviewed
+- [ ] Unit tests written and passing
+- [ ] Acceptance criteria verified
+- [ ] Documentation updated (if applicable)
+- [ ] Deployed to staging environment
+- [ ] QA sign-off received
+- [ ] Product Owner acceptance
+
+---
+
+## Sprint Ceremonies
+
+| Ceremony | Day/Time | Duration |
+|----------|----------|----------|
+| Daily Standup | [Day] [Time] | 15 min |
+| Sprint Review | [Date] [Time] | 60 min |
+| Sprint Retrospective | [Date] [Time] | 60 min |