agent-toolkit-cli 1.0.3__py3-none-any.whl

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/decision-log/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: decision-log
+description: >-
+  WHAT - Capture lightweight project, product, or operational decisions that do not require a full ADR; includes rationale, date, owner, and references.
+---
+
+# Decision Log (WHAT)
+
+Use for lightweight decisions made in meetings or project discussions.
+
+## Choose the right artifact
+
+- Use **`decision-log`** for lightweight operational, product, or project decisions.
+- Use **`agreement`** for explicit commitments or terms among parties.
+- Use **`adr`** for durable architecture or technical decisions.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Link related work items and meeting minutes where possible.
+
+## References
+
+- `references/default-template.md`
+- `references/example-repository-pattern.md` — example decision log entry for a data access layer migration
+- `meeting-minutes`
+- `adr`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/decision-log/references/example-repository-pattern.md

@@ -0,0 +1,27 @@
+# Decision: Migrate from Monolithic ORM to Repository Pattern
+
+## Decision
+
+Replace the active-record style ORM with a repository pattern that separates data access from business logic. This will happen incrementally, starting with the `orders` and `payments` domains.
+
+## Rationale
+
+The current ORM couples domain logic directly to database schemas, making unit testing difficult and creating hidden dependencies. The repository pattern enables better testability, clearer domain boundaries, and reduces the risk of schema changes rippling through business logic.
+
+## Date
+
+2024-02-15
+
+## Responsible
+
+Backend Platform Team
+
+## References / Linked Work Items
+
+- [TRD-011: Data Access Layer Refactoring](./trd-011-data-access-layer.md)
+- Epic-142: Database Migration Phase 2
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/development-workflow/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: development-workflow
+description: >-
+  WHAT - Default development workflow, task lifecycle, DoR, DoD, validation, and evidence model when a project has no explicit override. Repository instructions still take precedence.
+---
+
+# Development Workflow Fallback (WHAT)
+
+Use this skill when a project has no documented workflow override and you need the default expectations for delivery stages, validation, evidence, and traceability.
+
+## Priority order
+
+1. Repository `AGENTS.md`, CONTRIBUTING, PR templates, CI, and project docs.
+2. Engagement pack or ticket-specific workflow.
+3. This default workflow fallback.
+
+## Default flow
+
+Backlog -> Ready TODO/TODO -> In Progress -> Blocked (if needed) -> Ready for Review -> Ready for Acceptance -> Ready for QA -> Ready for Release -> Closed.
+
+## Validation model
+
+- Definition of Ready before starting development.
+- Definition of Done before completion.
+- Code review and CI validation.
+- Evidence-based validation: tests, screenshots/recordings when relevant, comments, linked PRs, linked work items.
+- Traceability from PRD to Task to PR to Deployment.
+
+## References
+
+- `references/default-workflow-checklist.md` - default lifecycle and validation checklist (use as-is or adapt per project)
+- `pr-fallback` - default PR/MR body when a repo lacks templates
+- `workflow-generic-project` - delivery gates

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/development-workflow/references/default-workflow-checklist.md

@@ -0,0 +1,44 @@
+# Default Development Workflow Checklist
+
+## Scope
+
+Use only when the project has no explicit workflow override.
+
+## Status Lifecycle
+
+- [ ] Backlog: item exists but is not yet estimated/scoped/planned.
+- [ ] Ready TODO / TODO: scope, AC, dependencies, and estimate are ready.
+- [ ] In Progress: development and local testing started.
+- [ ] Blocked: blocker, impacted environment, and dependency owner documented.
+- [ ] Ready for Review: PR/MR created, linked, checks passing or documented.
+- [ ] Ready for Acceptance: testing notes, evidence, and AC validation ready.
+- [ ] Ready for QA: QA validation can start.
+- [ ] Ready for Release: final checks completed.
+- [ ] Closed: released/done/not released status selected with final validation notes.
+
+## Definition of Ready
+
+- [ ] Clear description and scope.
+- [ ] Acceptance criteria agreed.
+- [ ] Dependencies and impact documented.
+- [ ] Estimate and rationale captured.
+- [ ] Designs / technical alignment completed if applicable.
+- [ ] Owner and collaborators known.
+
+## Definition of Done
+
+- [ ] Code follows project standards.
+- [ ] Peer review completed.
+- [ ] CI/CD checks pass or exceptions are documented.
+- [ ] Automated/manual validation completed as needed.
+- [ ] Acceptance criteria verified.
+- [ ] Documentation and communication updated.
+- [ ] Temporary branches/flags cleaned up when appropriate.
+
+## Evidence and Traceability
+
+- [ ] Work item linked to PR/MR.
+- [ ] Test steps and results documented.
+- [ ] Screenshots/recordings attached when useful.
+- [ ] Deployment or release evidence linked when applicable.
+- [ ] Traceability exists: PRD -> Task -> PR/MR -> Deployment.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/epic/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: epic
+description: >-
+  WHAT - Draft and review epics using the Best Practices Epic Template; includes objectives, success criteria, related tasks, stakeholders, and effort metadata.
+---
+
+# Epic (WHAT)
+
+Use when a large body of work needs grouping into related stories, tasks, bugs, or subtasks.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Use **`planning`** for estimation and breakdown.
+3. Use **`clickup-cli`** for ClickUp creation only after user approval.
+
+## References
+
+- `references/default-template.md`
+- `references/example-unified-dashboard.md` — example epic with objectives, success criteria, and stakeholder mapping
+- `work-item`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/epic/references/example-unified-dashboard.md

@@ -0,0 +1,40 @@
+# EPIC-102: Unified Dashboard Redesign
+
+## Objectives
+
+- Consolidate 4 separate admin dashboards into a single coherent interface
+- Reduce average task completion time by 40% for common operations
+- Eliminate context switching for operators managing multiple entity types
+
+## Success Criteria
+
+- Single sign-on to access all entity types (orders, customers, inventory, reports)
+- P99 page load time under 1.5s for dashboard views
+- User satisfaction score above 4.2/5 in post-launch survey
+- Zero critical accessibility violations (WCAG 2.1 AA)
+
+## Related Tasks
+
+- Task-451: Design unified navigation system
+- Task-452: Build entity switcher component
+- Task-453: Migrate orders view to new dashboard shell
+- Task-454: Migrate inventory view
+- Task-455: Build reporting module summary view
+
+## Stakeholders
+
+- Operations team (primary users)
+- Product Management (requirements)
+- Design team (UX/UI)
+- Backend team (API support)
+
+## Additional Information
+
+- Estimated Effort: 21 story points
+- Assigned To: Marcus Johnson
+- Due Date: 2024-04-15
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/incident/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: incident
+description: >-
+  WHAT - Draft and review incident reports and RCA notes using Incident Management guidance; includes detection, impact, timeline, RCA, resolution, and follow-ups.
+---
+
+# Incident (WHAT)
+
+Use for unplanned events that disrupt or degrade production systems, live users, or critical operations.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Capture immediate mitigation separately from root cause and follow-up actions.
+3. Use **`meeting-minutes`** if a validation or post-incident meeting needs minutes.
+4. Create/link follow-up bugs or tasks only after approval.
+
+## References
+
+- `references/default-template.md`
+- `references/example-payment-outage.md` — example incident with full timeline, RCA, and action items
+- `bug`
+- `meeting-minutes`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/incident/references/example-payment-outage.md

@@ -0,0 +1,62 @@
+# INC-2024-018: Payment Processing Outage
+
+## Detection Details
+
+- Detected By: Automated alert from payment-gateway health check
+- Timestamp: 2024-01-18T09:23:41Z
+- Environment: Production
+- Alert Source: PagerDuty — `payment-gateway /health` returning 503
+
+## Timeline of Events
+
+| Time (UTC) | Event |
+| --- | --- |
+| 09:23 | Health check alert fires; on-call engineer paged |
+| 09:27 | Engineer accesses dashboard; confirms gateway is up but processing queue is stalled |
+| 09:31 | Incident declared; severity set to SEV1 |
+| 09:35 | Payment team lead joins war room |
+| 09:42 | Root cause identified: message queue consumer stopped after unhandled exception in poison message processing |
+| 09:58 | Hotfix deployed; queue processing resumed |
+| 10:15 | Processing backlog cleared; all transactions completed or returned to sender |
+| 10:30 | Incident declared resolved |
+
+## Impact Summary
+
+- Scope: New payment transactions failed during outage window
+- User Impact: ~340 customers experienced failed checkout; ~12 support tickets opened
+- Duration: 52 minutes (09:23 to 10:15)
+
+## Root Cause Analysis
+
+- Root Cause: Message consumer crashed when encountering a malformed message with an unexpected schema version. The error was not caught, causing the consumer thread to terminate. No restart mechanism existed for this isolated failure mode.
+- Contributing Factors: Consumer deployed without dead-letter queue configured; monitoring did not alert on queue depth growth; no circuit breaker for poison message handling
+- Misaligned Expectations: Expected all messages to conform to schema v2; a backend service was emitting v1 messages during a brief period during migration
+
+## Resolution
+
+- Immediate Fix: Restarted message consumer with dead-letter queue handler added; failed messages moved to retry queue with backoff
+- Validated In: Staging environment with schema v1 and v2 messages interleaved; confirmed graceful handling
+- Status: Resolved
+
+## Action Items
+
+- [ ] Configure dead-letter queue for payment-gateway consumer (Owner: Backend Platform, Due: 2024-01-25)
+- [ ] Add queue depth alerting with 5-minute threshold (Owner: SRE, Due: 2024-01-22)
+- [ ] Implement circuit breaker for poison message handling (Owner: Payment Team, Due: 2024-02-01)
+- [ ] Update message schema validation to handle versioning gracefully (Owner: Backend Team, Due: 2024-01-30)
+
+## Severity and Priority
+
+- Severity: High
+- Priority: P1
+
+## Additional Information
+
+- Assigned To: Priya Sharma
+- Reported On: 2024-01-18
+- Due Date for Follow-Up: 2024-02-15
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/management-unit-assessment/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: management-unit-assessment
+description: >-
+  WHAT - Evidence-based management unit assessment for governance, delivery,
+  collaboration, culture, and AI-native management readiness. Interactive and
+  source-driven before any score is assigned.
+---
+
+# Management Unit Assessment (WHAT)
+
+Use this skill to assess a management unit: project management, delivery execution, governance, stakeholder alignment, team collaboration, cultural health, and management-layer AI readiness.
+
+Run **`project-assessment-evidence`** first and use **`project-assessment`** as the router when the assessment spans multiple units.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final scorecards or reports.
+2. Ask where each evidence source lives before scoring.
+3. Score only indicators that match the assessment scope and available evidence.
+4. Mark every score with evidence links and confidence.
+5. Use **Not assessed** when evidence is missing or the indicator is out of scope.
+6. For subjective indicators, request validation from the appropriate reviewer or stakeholder.
+
+## Unit intake
+
+Ask:
+
+- What management scope is being assessed: whole project, squad, delivery stream, account, or another scope?
+- What period should the assessment cover?
+- Which methodology, workflow, and governance model is expected?
+- Where are the board, backlog, planning artifacts, delivery reports, risks, retrospectives, decisions, agreements, and meeting notes?
+- Where are stakeholder satisfaction, team satisfaction, and communication signals captured?
+- Who should validate subjective scores?
+
+## Indicator groups
+
+### Governance and structure
+
+- Methodology definition
+- Workflow definition
+- Issue definition
+- Roles definition
+- Risk management
+- Progress tracking
+- Continuous improvement initiatives
+
+### Delivery and execution
+
+- Delivery
+- Agile methodology implementation
+- Sprint planning effectiveness
+- Backlog management
+- Retrospective process
+- Adaptability to change
+
+### Collaboration and communication
+
+- Business knowledge
+- Client or stakeholder satisfaction
+- Communication
+- Stakeholder engagement
+- Daily standup effectiveness
+- Team satisfaction
+
+### Culture and values alignment
+
+- Raise the bar
+- Do what I say
+- Geek out
+
+These indicators are sensitive and subjective. Treat them as conversation-driven evidence unless there are structured feedback artifacts. Record who validated them.
+
+### AI-native management readiness
+
+This does not measure AI tool usage. It measures whether management artifacts are structured enough for AI-assisted execution:
+
+- Knowledge structure and documentation density
+- Decision traceability and governance explicitness
+- Workflow determinism and operational clarity
+- Feedback loops and continuous learning signals
+- Human signal and cultural transparency
+
+## Scoring rules
+
+- Use the 1 to 5 maturity scale.
+- Score 1 means low, reactive, implicit, undocumented, or highly variable.
+- Score 3 means defined, observable, or partially mature with consistency gaps.
+- Score 5 means explicit, repeatable, measurable, and evidence-driven.
+- Do not treat score 3 as average performance; it means moderate structural maturity.
+- Do not average subjective indicators without explaining weighting and validation.
+- For low-confidence scores, record the missing evidence and who should validate it.
+
+## Output
+
+Use `references/default-template.md` for the management unit scorecard.
+
+## References
+
+- `references/default-template.md` - default management unit template
+- `references/example-team-assessment.md` — example assessment for an engineering management unit
+- `project-assessment-evidence` - evidence map
+- `project-assessment` - multi-unit router
+- `planning` - planning and estimation evidence
+- `development-workflow` - workflow, DoR, DoD, and validation evidence
+- `meeting-minutes`, `decision-log`, `agreement`, `incident` - common management evidence artifacts

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/management-unit-assessment/references/example-team-assessment.md

@@ -0,0 +1,126 @@
+# Management Unit Assessment
+
+## Review
+
+- Destination: /docs/assessments/2024-q1/management-review
+- Human reviewer: Director of Engineering
+- Assessment status: Draft
+
+## Unit Summary
+
+- Management scope: Squads 3, 4, and 5 (embedded product teams)
+- Assessment period: 2024-01-01 to 2024-03-31
+- Systems of record: Linear (work items), Notion (decisions), Jira (reporting)
+- Methodology / workflow expected: scrum with 2-week sprints; DoR and DoD defined per squad
+- Overall management health: Moderate — strong delivery, weak risk visibility
+- Key strengths: Sprint planning is consistent; retrospectives produce action items
+- Key risks or gaps: Risks logged but not escalated proactively; dependency tracking inconsistent
+- General confidence level: Medium-High
+
+## Evidence Summary
+
+| Evidence area | Source link or location | Freshness | Confidence | Notes |
+| --- | --- | --- | --- | --- |
+| Board / backlog | Linear → Team Workspaces | Current | High | Most work tracked |
+| Planning / estimation | Linear sprint reports | Current | High | Velocity visible |
+| Delivery reports | Jira delivery dashboards | Weekly | Medium | Reports lag by 1 week |
+| Risks / issues / OIRs | Notion risk register | Updated ad hoc | Medium | Not all risks current |
+| Retrospectives / improvements | Linear cycle retrospectives | Current | High | Actions tracked |
+| Decisions / agreements | Notion decisions page | Current | Medium | Not linked to tasks |
+| Meeting notes / interviews | Notion meeting templates | Variable | Low | Many meetings unrecorded |
+| Stakeholder feedback | Intercom NPS surveys | Quarterly | Low | No direct feedback loop to squad |
+| Team satisfaction signals | Weekly pulse surveys | Weekly | Medium | Response rate declining |
+
+## Scorecard
+
+### Governance and Structure
+
+| Indicator | Score | Confidence | Evidence | Notes |
+| --- | --- | --- | --- | --- |
+| Methodology definition | 4 | High | Linear + Notion | Scrum defined but sprint ceremonies inconsistently attended |
+| Workflow definition | 3 | High | Notion workflow doc | DoR/DoD exist; not enforced on all work items |
+| Issue definition | 3 | Medium | Jira + Linear | Issues opened but severity not consistently applied |
+| Roles definition | 4 | High | Org chart | Clear ownership, sometimes overlaps on cross-team work |
+| Risk management | 2 | Medium | Notion risk register | Risks identified but escalation threshold unclear |
+| Progress tracking | 4 | High | Linear + Jira | Real-time in Linear; reporting in Jira lags |
+| Continuous improvement initiatives | 3 | Medium | Retros | Actions exist; follow-through not tracked |
+
+### Delivery and Execution
+
+| Indicator | Score | Confidence | Evidence | Notes |
+| --- | --- | --- | --- | --- |
+| Delivery | 4 | High | Jira delivery dashboard | 91% on-time in Q1 |
+| Agile methodology implementation | 3 | High | Linear cycles | Ceremonies happen but value questionable |
+| Sprint planning effectiveness | 4 | High | Linear planning view | Scope respected; capacity considered |
+| Backlog management | 3 | Medium | Linear backlog | Grooming inconsistent; old items accumulate |
+| Retrospective process | 4 | High | Linear retros | Action items created; owner and due date sometimes missing |
+| Adaptability to change | 3 | Medium | Jira history | Responds to scope changes but unplanned work disrupts sprints |
+
+### Collaboration and Communication
+
+| Indicator | Score | Confidence | Evidence | Notes |
+| --- | --- | --- | --- | --- |
+| Business knowledge | 4 | High | Interview with PM | PM shares context early; some tech debt from missing context |
+| Client or stakeholder satisfaction | 3 | Low | NPS only quarterly | No direct feedback loop; reliance on PM secondhand |
+| Communication | 3 | Medium | Slack + Linear | Status updates adequate; decisions not always communicated |
+| Stakeholder engagement | 3 | Medium | Meeting attendance | Key stakeholders attend reviews; some absenteeism |
+| Daily standup effectiveness | 3 | Medium | Observation | Often runs 15+ minutes; parking lot items not always resolved |
+| Team satisfaction | 3 | Medium | Weekly pulse | Score 3.8/5; declining response rate signals disengagement |
+
+### Culture and Values Alignment
+
+| Indicator | Score | Confidence | Evidence | Validator | Notes |
+| --- | --- | --- | --- | --- | --- |
+| Raise the bar | 3 | Medium | Code review samples | PRs merged with minor comments; no pattern of pushing back |
+| Do what I say | 4 | High | Jira promises | Commitments generally kept; delays communicated |
+| Geek out | 3 | Low | No innovation time tracked | No dedicated innovation time; ad hoc experimentation |
+
+### AI-Native Management Readiness
+
+| Indicator | Score | Confidence | Evidence | Notes |
+| --- | --- | --- | --- | --- |
+| Knowledge structure and documentation density | 3 | Medium | Notion pages | Decisions captured; ADRs not linked to work items |
+| Decision traceability and governance explicitness | 2 | Medium | Notion decisions | Decisions exist but no link to impact or task |
+| Workflow determinism and operational clarity | 3 | High | Linear + Notion | Workflows defined; exceptions not tracked |
+| Feedback loops and continuous learning signals | 2 | Low | Weekly pulse | Pulse exists but action on signals is inconsistent |
+| Human signal and cultural transparency | 3 | Medium | Team retros | Retros surface issues but resolution not always visible |
+
+## Findings
+
+### Strengths
+
+- Finding: Sprint planning is reliable and respected.
+  - Evidence: 91% on-time delivery; velocity variance under 15%
+  - Confidence: High
+
+### Risks and Gaps
+
+- Finding: Risk register not actively maintained or escalated.
+  - Evidence: 3 risks identified in Q4 2023 still listed as "open" with no update since January
+  - Impact: Leadership blind to actual blockers; may miss escalation window
+  - Confidence: Medium
+
+### Missing Evidence
+
+- Evidence needed: Direct stakeholder satisfaction interviews
+  - Indicator impacted: Client/stakeholder satisfaction
+  - Suggested source or validator: Product leadership, quarterly business review notes
+
+## Recommendations
+
+| Priority | Recommendation | Linked finding | Suggested follow-up |
+| --- | --- | --- | --- |
+| High | Escalate risk register review to monthly leadership sync | Risk register gaps | PM to present risk register monthly |
+| Medium | Add decision links to Linear work items | Decision traceability | Use Linear custom field for ADR reference |
+| Low | Reinstate weekly team pulse with action tracking | Team satisfaction signals | HR to present pulse results and actions quarterly |
+
+## Assumptions and Limitations
+
+- Assumption: Jira reporting lag is due to manual process, not systemic underreporting
+- Limitation: Stakeholder satisfaction relies on quarterly NPS; no real-time signal available
+
+## Validation
+
+- Subjective scores validated by: Squad leads (self-assessment)
+- Scores needing follow-up: Risk management (2) — recommend external review
+- Consensus notes: All squad leads agreed risk escalation was the primary gap

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/meeting-minutes/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: meeting-minutes
+description: >-
+  WHAT - Create structured meeting minutes from notes or transcripts using meeting templates, with redaction, action items, decisions, and traceability.
+---
+
+# Meeting Minutes (WHAT)
+
+Use for meeting notes, validation meetings, or AI-assisted transcript summarization.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Redact PII and sensitive details before finalizing.
+3. Keep minutes concise and actionable.
+4. Extract action items, owners, due dates, and linked task IDs when available.
+5. Use **`clickup-cli`** to create follow-up tasks only after user approval.
+
+## References
+
+- `references/default-template.md`
+- `references/example-weekly-sync.md` — example meeting with agenda, decisions, and action item table
+- `decision-log`
+- `agreement`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/meeting-minutes/references/example-weekly-sync.md

@@ -0,0 +1,72 @@
+# Engineering Weekly Sync
+
+## Meeting Details
+
+- Date: 2024-01-22
+- Time: 10:00–10:45 (UTC-5)
+- Location / Link: https://meet.company.com/eng-weekly
+- Facilitator / Owner: Alice Kim
+- Attendees: Alice Kim, Ben Torres, Carmen Reyes, David Park, Elena Vasquez
+
+## Source and Redaction
+
+- Source link: https://notion.so/eng-sync-2024-01-22
+- Redaction notes: None required — internal only
+
+## Agenda
+
+- [x] Sprint review (5 min)
+- [x] Blocker escalation: payment-gateway queue depth (10 min)
+- [x] Architecture review: service decomposition proposal (15 min)
+- [x] AOB: Confluence migration to new instance (5 min)
+- [x] Closing and action items (5 min)
+
+## Minutes
+
+### Discussion Points
+
+**Sprint Review:**
+- Squad 3 completed 18 story points; 2 items rolled over
+- Squad 4 delivered the search performance fix ahead of schedule
+- Ben noted that deployment tooling caused a 15-minute delay on the staging release
+
+**Blocker Escalation — Payment Gateway:**
+- David presented queue depth metrics: 4,200 messages pending, consumer running at 60% capacity
+- Risk: message age could exceed SLA if consumer does not scale within 48 hours
+- Decision: Scale consumer to 3 replicas immediately; monitor for 24 hours
+
+**Architecture Review — Service Decomposition:**
+- Carmen presented proposal to split monolith into 5 bounded contexts
+- Team discussed boundaries and data ownership
+- Open question: should the search domain be independently deployable?
+- Action: Carmen to create ADR with three options (monolith-first, search extraction, full decomposition)
+
+**Confluence Migration:**
+- Notion being deprecated as team wiki in favor of new Confluence instance
+- Migration scheduled for Feb 5–9
+- All teams need to review their pages and update links
+
+### Decisions Made
+
+- Payment consumer scaled to 3 replicas (immediate effect)
+- Search domain decomposition ADR to be drafted by Carmen (due: Jan 26)
+- Confluence migration: all page owners notified by Alice by Jan 26
+
+## Action Items
+
+| Action Item | Responsible | Due Date | Status | Linked Task |
+| --- | --- | --- | --- | --- |
+| Scale payment consumer to 3 replicas | David Park | 2024-01-22 | Done | OPS-442 |
+| Draft search domain ADR | Carmen Reyes | 2024-01-26 | In Progress | ARCH-018 |
+| Notify team of Confluence migration | Alice Kim | 2024-01-26 | Done | DOC-099 |
+| Review and update Confluence page links | All leads | 2024-02-05 | Not Started | DOC-099 |
+
+## Parking Lot
+
+- [ ] Deployment tooling improvement (Ben to open ticket)
+- [ ] Review sprint capacity after payment incident impact (Alice, next sync)
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/planning/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: planning
+description: >-
+  WHAT - Planning, estimation, task breakdown, and iteration capacity fallback based on Best Practices. Use before finalizing backlog scope, story/task estimates, or iteration commitments.
+---
+
+# Planning and Estimation (WHAT)
+
+Use this skill when work needs planning, breakdown, estimation, or capacity validation before it becomes final backlog content.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before producing any final planning artifact: ask where it should live and confirm human review.
+2. Prefer project-specific planning rules if the repo, ticket system, or engagement pack defines them. Otherwise use this default.
+3. If a work item is being created or refined, pair this with **`work-item`** and the relevant atomic skill.
+
+## What to check
+
+- Scope and goal are clear.
+- Work is broken down into manageable items; anything estimated at 5+ points should be considered for splitting.
+- Acceptance criteria and dependencies are known enough for estimation.
+- Estimation technique is explicit: planning poker, T-shirt sizing, Fibonacci, or the team override.
+- Capacity considers availability, holidays, meetings, focus factor, dependencies, and historical velocity.
+
+## References
+
+- `references/default-template.md` - default planning and capacity template
+- `references/example-sprint-planning.md` — example sprint planning with work item breakdown, capacity, and risk assessment
+- `work-item` - work item hierarchy and creation
+- `clickup-cli` - task updates after user approval