agent-toolkit-cli 1.11.0__py3-none-win_amd64.whl

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/data/skills/delivery/management-unit-assessment/SKILL.md

@@ -0,0 +1,104 @@
+---
+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.
+origin:
+  type: first-party
+---
+# 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/data/skills/delivery/management-unit-assessment/references/default-template.md

@@ -0,0 +1,24 @@
+# Management Unit Assessment: [Unit name]
+
+**Period:** YYYY-MM-DD to YYYY-MM-DD
+**Assessor:** [Name]
+**Confidence:** High | Medium | Low
+
+## Scope
+
+Management unit, methodology, and systems of record reviewed.
+
+## Scorecard summary
+
+| Indicator group | Score (1–5) | Confidence | Evidence |
+| --- | --- | --- | --- |
+
+## Strengths
+
+## Risks and gaps
+
+## Recommendations
+
+## Missing evidence
+
+Indicators marked **Not assessed** and why.

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/data/skills/delivery/meeting-minutes/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: meeting-minutes
+description: WHAT - Create structured meeting minutes from notes or transcripts using meeting templates,
+  with redaction, action items, decisions, and traceability.
+origin:
+  type: first-party
+---
+# 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/data/skills/delivery/meeting-minutes/references/default-template.md

@@ -0,0 +1,22 @@
+# Meeting: [Title]
+
+**Date:** YYYY-MM-DD
+**Attendees:** [Names or roles]
+**Facilitator:** [Name]
+
+## Agenda
+
+1. 
+
+## Decisions
+
+- 
+
+## Discussion notes
+
+Concise summary by topic.
+
+## Action items
+
+| Action | Owner | Due | Task ID |
+| --- | --- | --- | --- |

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/data/skills/delivery/planning/SKILL.md

@@ -0,0 +1,31 @@
+---
+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.
+origin:
+  type: first-party
+---
+# 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

agent_toolkit/data/skills/delivery/planning/references/default-template.md

@@ -0,0 +1,25 @@
+# Planning: [Sprint / iteration name]
+
+**Period:** YYYY-MM-DD to YYYY-MM-DD
+**Team capacity:** [Points or hours available]
+
+## Goals
+
+Top outcomes for this iteration.
+
+## Work items
+
+| Item | Type | Estimate | Dependencies |
+| --- | --- | --- | --- |
+
+## Capacity notes
+
+Meetings, holidays, focus factor, known risks.
+
+## Risks
+
+- 
+
+## Commitments
+
+What the team agrees to deliver.

agent_toolkit/data/skills/delivery/planning/references/example-sprint-planning.md

@@ -0,0 +1,62 @@
+# Planning and Estimation Notes
+
+## Scope / Goal
+
+Sprint 24 planning for Squad 4 (platform). Focus on payment infrastructure reliability and tech debt reduction.
+
+## Work Item Breakdown
+
+- [x] Scope is clear and bounded.
+- [x] Work is split into manageable stories/tasks/subtasks.
+- [x] Items estimated at 5+ points were reviewed for splitting.
+- [x] Dependencies are identified.
+- [x] Acceptance criteria are clear enough for estimation.
+
+**Note:** PAY-102 ("Refactor message consumer") was initially estimated at 8 points; after discussion, split into PAY-102a (3pts, consumer restart logic) and PAY-102b (5pts, dead-letter queue and circuit breaker).
+
+## Estimation
+
+**Technique used:** Planning Poker (Fibonacci)
+
+| Item | Estimate | Rationale | Risks / Unknowns |
+| --- | --- | --- | --- |
+| OPS-442: Scale payment consumer | 2 | Standard infra config, no code change | None |
+| PAY-102a: Consumer restart logic | 3 | Follows existing pattern for graceful shutdown | Low — well-understood problem |
+| PAY-102b: Dead-letter queue + circuit breaker | 5 | New infrastructure component; testing requires staging env | Medium — staging env provisioning could slip |
+| TECH-203: Confluence page audit | 1 | Documentation work, no code | None |
+| TECH-204: Upgrade API gateway | 3 | Dependency update; follows migration guide | Low — similar upgrade done last quarter |
+
+**Total:** 14 points
+
+## Capacity Assumptions
+
+| Factor | Notes |
+| --- | --- |
+| Iteration length | 2 weeks (Jan 22 – Feb 2) |
+| Team availability | 4 engineers (Alice, Ben, Carmen, David) |
+| Holidays / planned leave | No holidays; Ben on call Jan 25 |
+| Meetings / non-development time | ~6 hours/week estimated for meetings |
+| Focus factor | 0.7 (accounting for meetings, context switching) |
+| Historical velocity | 15 points/sprint (last 3 sprints) |
+
+**Effective capacity:** 4 engineers × 8 hrs/day × 10 days × 0.7 focus = 224 hours ≈ 16-18 points at historical mix
+
+## Dependencies and Risks
+
+**Dependencies:**
+- PAY-102b requires staging environment with queue infrastructure (ticket with Infra team submitted Jan 19; response expected Jan 23)
+- Confluence migration (DOC-099) may generate unplanned work for TECH-203 owners
+
+**Risks:**
+- Staging env delay: if not ready by Jan 24, PAY-102b testing cannot complete in sprint
+- Mitigation: Alice to follow up with Infra on Jan 23 if no response
+- Payment team may be pulled into INC response if another alert fires
+
+## Final Planning Notes
+
+Sprint 24 is conservative due to payment incident aftermath and Confluence migration. If staging env is ready early and no incidents, we may pick up TECH-205 from backlog.
+
+## Review
+
+- [x] Destination confirmed by user.
+- [x] Human review required before treating this as approved.

agent_toolkit/data/skills/delivery/prd/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: prd
+description: WHAT — Draft and review a Product Requirements Document (PRD) using the template. Business-level
+  requirements, acceptance criteria, and traceability. Does not replace the product owner. English for
+  tickets, PRs, and client-facing text unless the user asks otherwise.
+origin:
+  type: first-party
+---
+# PRD — Product Requirements (WHAT)
+
+**Template:** `references/default-template.md` — local reference, kept up to date with the standard structure.
+
+## Default guardrails (before any final content)
+
+1. Apply **`output-handshake`**: confirm **where** the final PRD will be stored (path, Doc page, task, paste-only, etc.) and that a **human** will review. Engagements may store PRDs in different places; do not assume.
+2. Then follow the steps below.
+
+## When to use
+
+- A feature or product increment needs a **shared agreement** on scope, users, and acceptance.
+- The team must **trace** work from PRD → implementation → tests.
+- An engagement uses an **Operations**-style doc hub with linked requirements documents.
+
+## Instructions
+
+1. **Open the PRD template** (`references/default-template.md`) and keep section headings **aligned** with it: Objective, User flow / Personas, Entities & use cases, Acceptance criteria, Edge cases, Integrations, Timeline, Approvals.
+2. For **discovery** in an existing repository, delegate repository inspection to **`assistant`**; cite `AGENTS.md` and test/lint commands from the project.
+3. **Acceptance criteria** must be testable and in **English** for work items/PRs (match `workflow-generic-project`).
+4. Link **stakeholder approval** to your engagement process (task lists, doc pages, or client sign-off). Do not invent sign-off if not agreed.
+5. For **ticket updates**, use the appropriate tool (`clickup-cli`, `jira-*`, etc.) to post a short plan comment or attach links — do not paste the full document into a task; link the Doc or page when possible.
+
+## What not to do
+
+- Do not copy the full text of an external template into this skill; use `references/default-template.md` as the local canonical reference.
+- Do not skip **edge cases** or **integrations** when the PRD is meant for handoff to a TRD.
+
+## References
+
+- `output-handshake` — destination and review (required first for final output)
+- `references/default-template.md` — local PRD template
+- `references/example-unified-api.md` — PRD example for an API strategy initiative
+- `workflow-generic-project` — delivery phases and ticket traceability
+- `trd` — next step for technical design from an approved PRD
+- `planning` — estimation and capacity before commitment
+- `epic`, `user-story`, `task` — downstream breakdown
+- `clickup-cli`, `jira-*` — ticket / comment operations (per engagement)

agent_toolkit/data/skills/delivery/prd/references/default-template.md

@@ -0,0 +1,31 @@
+# PRD: [Feature / initiative title]
+
+## Objective
+
+Business goal and success metrics.
+
+## User flow / Personas
+
+Primary users and how they interact with the feature.
+
+## Entities & use cases
+
+Key entities and primary use cases.
+
+## Acceptance criteria
+
+- [ ] Testable criterion in English
+
+## Edge cases
+
+## Integrations
+
+External systems, APIs, and dependencies.
+
+## Timeline
+
+Milestones and target dates.
+
+## Approvals
+
+Stakeholder sign-off plan.