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

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

@@ -0,0 +1,56 @@
+---
+name: adr
+description: WHAT — Create and maintain Architecture Decision Records (ADRs) per the process. Covers when
+  to write an ADR, required sections, review, and linking to epics/PRs. English for cross-team artifacts
+  unless the user asks otherwise.
+origin:
+  type: first-party
+---
+# ADR — Architecture Decisions (WHAT)
+
+**Template:** `references/default-template.md` — local reference for ADR structure and workflow.
+
+## Default guardrails (before any final content)
+
+1. Apply **`output-handshake`**: confirm **where** the final ADR will be recorded and that a **human** will review.
+2. Then follow the steps below.
+
+## When to use
+
+Use **`decision-log`** for lightweight product/project/operational decisions and **`agreement`** for explicit commitments or terms among parties. Use this ADR skill only for durable architecture or technical decisions.
+
+- A change has **long-term** architectural, security, data-model, or cost impact.
+- You need **options with pros/cons** and a **record** for future readers (and for supersession later).
+- The project needs decisions linked to PRDs, TRDs, tasks, PRs, diagrams, or other supporting artifacts.
+
+## Instructions
+
+0. **Match existing convention first** (per `addyosmani/agent-skills` `documentation-and-adrs` 2026-08-12, diff `docs/research/diff-394-documentation-and-adrs.md`): inspect `docs/adr/` (or `Documentation/Decisions/`, MADR, `adr-tools` `.adr-dir`) — location/format (Markdown vs reStructuredText), numbering/naming (`0004-*.md` vs `ADR-004-*.rst`), section headings. Surface conflict rather than silently introducing another scheme. Only when no convention can be established, default to `docs/adr/000N-*.md` six-part structure.
+
+1. **Confirm the decision qualifies** (new service, tech selection, schema change, deployment change, etc.) per the "When to Create an ADR" criteria.
+2. **Draft** using the six-part structure: Title & status, Context, Options, Decision, Consequences, References (link **PRD/TRD**, tasks, PRs, diagrams as applicable). Use lifecycle `PROPOSED → ACCEPTED → (SUPERSEDED | DEPRECATED)` and **don't delete old ADRs** — when decision changes, write new ADR that references and supersedes old (per upstream 2026-08-12).
+3. **Review** with the tech lead / peers as in the workflow; keep ADRs **short and actionable** (clarity over completeness).
+4. **Link** the ADR to the relevant **epic or story** and to **PRs** in the forge (use **`github-cli-workflow` / `gitlab-cli-workflow`** for PR text when applicable).
+5. If an ADR is **superseded**, **preserve history**: update status and point to the replacement document.
+
+### Red flags & verification (after documenting)
+
+* **No ADR for significant architectural choices** — every expensive-to-reverse decision needs one.
+* **README missing quick start / architecture overview**, API without types, rules files (`CLAUDE.md`/`AGENTS.md`) stale, commented-out code, week-old `TODO`s, or docs that restate code.
+* Verify: ADRs exist, README covers quick start/commands/architecture (link ADRs), API docs have types, gotchas inline, no commented-out code, `personas/` (HOW agent thinks) vs `skills/` (HOW task executes) preserved — see `docs/CONCEPTS.md`.
+
+## What not to do
+
+- Do not use an ADR for one-line fixes with no long-term effect (use a normal task or PR description).
+- Do not paste the full org policy into this skill; keep a single **canonical** copy in the wiki.
+
+## References
+
+- `output-handshake` — destination and review
+- `references/default-template.md` — ADR structure and workflow
+- `references/example-001-graphql-adoption.md` — example ADR for a GraphQL migration decision
+- `trd` — where technical design references decisions
+- `decision-log` — lightweight decisions
+- `agreement` — explicit commitments or terms
+- `workflow-generic-project` — traceability and plan approval
+- `clickup-cli`, `jira-*` — ticket and comment operations (per engagement)

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

@@ -0,0 +1,35 @@
+# ADR-NNN: [Short decision title]
+
+**Status:** Proposed | Accepted | Deprecated | Superseded
+
+## Context
+
+Describe the problem, constraints, and forces driving the decision.
+
+## Options Considered
+
+### Option A: [Name]
+**Pros:**
+- 
+
+**Cons:**
+- 
+
+### Option B: [Name]
+**Pros:**
+- 
+
+**Cons:**
+- 
+
+## Decision
+
+State the chosen option and rationale.
+
+## Consequences
+
+Positive and negative outcomes of this decision.
+
+## References
+
+- Linked PRD/TRD, tasks, PRs, diagrams

agent_toolkit/data/skills/delivery/adr/references/example-001-graphql-adoption.md

@@ -0,0 +1,66 @@
+# ADR-001: Adopt GraphQL for the Product API
+
+**Status:** Accepted
+
+## Context
+
+The current REST API has accumulated significant complexity as the product domain grew. Multiple frontend clients (web, mobile) are experiencing over-fetching, under-fetching, and fragile coupling to backend structure. The team spends significant time on API versioning and backward compatibility work.
+
+Key constraints:
+- Existing REST endpoints cannot be deprecated immediately
+- Mobile team needs faster iteration cycles
+- Analytics requirements demand a more expressive data querying interface
+
+## Options Considered
+
+### Option A: GraphQL Federation
+**Pros:**
+- Single coherent graph for all clients
+- Type safety and auto-generated docs
+- Separate subgraph ownership reduces coupling
+
+**Cons:**
+- Higher initial infrastructure complexity
+- Requires Apollo Federation or equivalent gateway
+- Caching strategies differ from REST patterns
+
+### Option B: REST with JSON:API
+**Pros:**
+- Team familiarity with REST patterns
+- Simpler infrastructure (no gateway needed)
+- Easier to cache at CDN level
+
+**Cons:**
+- Still requires versioning as domain grows
+- Multiple endpoints needed for complex queries
+- No built-in type safety or schema
+
+### Option C:渐进式迁移 — Evolve REST to GraphQL incrementally
+**Pros:**
+- Low risk approach
+- Existing clients unaffected during transition
+- Can validate GraphQL value before full commitment
+
+**Cons:**
+- Longer timeline to realize benefits
+- Requires maintaining both API styles temporarily
+- Higher total implementation effort
+
+## Decision
+
+Adopt GraphQL with a phased approach: establish a new `/graphql` endpoint alongside existing REST, migrate the product domain first, then expand to other domains as teams gain familiarity.
+
+Rationale: Provides immediate relief for frontend teams while preserving existing investments. The federation model future-proofs architecture for microservices decomposition.
+
+## Consequences
+
+- New `api-gateway` service will be introduced in Q3
+- Mobile team leads the product domain migration (most urgent need)
+- REST API maintained for backward compatibility until deprecation notice (6-month notice period)
+- Existing client SDKs updated to support both endpoints during transition
+
+## References
+
+- [PRD-042: Unified API Strategy](./prd-042-unified-api-strategy.md)
+- [Spike-012: GraphQL vs REST evaluation](./spike-012-graphql-evaluation.md)
+- Engineering sync 2024-11-15

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

@@ -0,0 +1,24 @@
+---
+name: agreement
+description: WHAT - Capture explicit agreements, terms, parties involved, dates, validity, and linked
+  work items using the Agreement Document structure.
+origin:
+  type: first-party
+---
+# Agreement Document (WHAT)
+
+Use for formal agreements or commitments made during meetings or project discussions.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Identify parties involved and affected.
+3. Include validity/review dates when the agreement has a time boundary.
+4. Link related work items and meeting minutes where possible.
+
+## References
+
+- `references/default-template.md`
+- `references/example-api-versioning.md` — example agreement covering semantic versioning and deprecation policy
+- `meeting-minutes`
+- `decision-log`

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

@@ -0,0 +1,17 @@
+# Agreement: [Title]
+
+**Date:** YYYY-MM-DD
+**Parties:** [List stakeholders or teams]
+**Valid until:** YYYY-MM-DD (or ongoing)
+
+## Terms
+
+Describe commitments, responsibilities, and scope.
+
+## Affected work items
+
+- [Link or ID]
+
+## Review / renewal
+
+When and how this agreement will be revisited.

agent_toolkit/data/skills/delivery/agreement/references/example-api-versioning.md

@@ -0,0 +1,29 @@
+# Agreement: API Versioning Policy
+
+## Agreement Summary
+
+All public APIs will follow semantic versioning with a minimum 6-month deprecation notice before breaking changes. Version support windows are tied to major versions.
+
+## Parties Involved
+
+- Platform Team (API owners)
+- All consuming service teams
+- Product Management (for public API consumers)
+
+## Terms and Conditions
+
+1. **Version numbering:** Follows `MAJOR.MINOR.PATCH` semantic versioning
+2. **Breaking changes:** Require a new major version with 6-month overlap period
+3. **Deprecation notice:** Written notice in API response headers and changelog minimum 6 months before EOL
+4. **Sunset timeline:** Major versions receive security patches for 18 months from release, then EOL
+5. **Version discovery:** `/versions` endpoint lists supported versions with EOL dates
+
+## Date and Validity
+
+- Start Date: 2024-01-01
+- Review / Due Date: 2025-07-01 (first review)
+
+## References / Linked Work Items
+
+- [ADR-003: API Versioning Standard](./adr-003-api-versioning.md)
+- [TRD-007: Platform API Migration](./trd-007-platform-api-migration.md)

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

@@ -0,0 +1,26 @@
+---
+name: bug
+description: WHAT - Draft and review bugs using the Bug Template; classifies whether an issue should be
+  escalated to incident based on production/user impact.
+origin:
+  type: first-party
+---
+# Bug (WHAT)
+
+Use for defects that can be handled through the normal development workflow.
+
+## Bug vs incident rule
+
+Route to **`incident`** instead if the problem impacts production or live users now, degrades service, blocks critical business operations, creates client-reported urgency, or needs immediate response outside planning cycles.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Capture reproduction steps and environment details.
+3. Use **`clickup-cli`** for ClickUp writes only after approval.
+
+## References
+
+- `references/default-template.md` — bug template
+- `references/example-search-filter-bug.md` — example bug with environment details, diagnostics, and severity assessment
+- `incident` — when to escalate to incident

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

@@ -0,0 +1,26 @@
+# BUG-NNN: [Short summary]
+
+## Steps to Reproduce
+
+1. 
+
+## Expected Result
+
+## Actual Result
+
+## Environment Details
+
+| Field | Value |
+| --- | --- |
+| Environment | |
+| Browser / Client | |
+| App Version | |
+
+## Diagnostics and Observations
+
+- Console errors, logs, screenshots
+
+## Acceptance Criteria
+
+- [ ] Reproduction steps no longer fail after fix
+- [ ] Regression coverage added where practical

agent_toolkit/data/skills/delivery/bug/references/example-search-filter-bug.md

@@ -0,0 +1,58 @@
+# BUG-042: Search results not displaying after deployment
+
+## Steps to Reproduce
+
+1. Navigate to `/products` with query parameter `?category=electronics&sort=price_asc`
+2. Click on the "Filter" button to open the filter panel
+3. Select "Screen Size: 40-50 inch" and click Apply
+4. Observe the results area
+
+## Expected Result
+
+Product grid updates to show only electronics with screen sizes between 40 and 50 inches, sorted by price ascending. Total count shows "47 products found".
+
+## Actual Result
+
+Results area shows a spinner indefinitely. Network tab shows 200 response but no DOM updates. After 30 seconds the spinner is replaced with an empty state: "No products match your filters."
+
+## Environment Details
+
+| Field | Value |
+| --- | --- |
+| Environment | Production |
+| Browser | Chrome 120.0.6099.130 |
+| Device / OS | macOS 14.2 (M2 Pro) |
+| App Version | 2.14.1 |
+| User Role | Authenticated consumer |
+| Network Conditions | WiFi, 50 Mbps down |
+
+## Diagnostics and Observations
+
+- Screenshots, videos, or logs: [Recording attached to ticket]
+- Console errors or stack traces: `TypeError: Cannot read properties of undefined (reading 'length')` at `FilterPanel.jsx:142`
+- External system behavior: Analytics events fire successfully — the failure is in frontend rendering only
+- Previous working version: 2.13.4 (verified via rollback test)
+
+## Acceptance Criteria
+
+- [ ] Expected behavior is working and manually verified in Production.
+- [ ] Original reproduction steps no longer reproduce the bug.
+- [ ] Fix was tested in the relevant environment (Production-like staging).
+- [ ] Resolution evidence was added (recording, logs confirming the TypeError is gone).
+- [ ] Documentation or user guidance was updated if needed (release notes mention the fix).
+
+## Severity and Priority
+
+- Severity: High
+- Priority: P1
+
+## Additional Information
+
+- Estimated Effort: 2 days
+- Assigned To: Sarah Chen
+- Due Date: 2024-01-20
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.

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

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

@@ -0,0 +1,17 @@
+# Decision: [Short title]
+
+**Date:** YYYY-MM-DD
+**Owner:** [Name or role]
+**Status:** Active | Superseded
+
+## Context
+
+What prompted this decision?
+
+## Decision
+
+What was decided and why?
+
+## References
+
+- Related meeting minutes, tasks, ADRs

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

@@ -0,0 +1,34 @@
+---
+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.
+origin:
+  type: first-party
+---
+# 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/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/data/skills/delivery/epic/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: epic
+description: WHAT - Draft and review epics using the Best Practices Epic Template; includes objectives,
+  success criteria, related tasks, stakeholders, and effort metadata.
+origin:
+  type: first-party
+---
+# 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/data/skills/delivery/epic/references/default-template.md

@@ -0,0 +1,26 @@
+# Epic: [Title]
+
+## Objective
+
+Business goal this epic delivers.
+
+## Success Criteria
+
+- [ ] Measurable outcome
+
+## Scope
+
+In scope / out of scope summary.
+
+## Stakeholders
+
+| Role | Name / team |
+| --- | --- |
+
+## Related work items
+
+- Stories, tasks, bugs linked to this epic
+
+## Effort / timeline (optional)
+
+Estimate or target milestone.

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

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

@@ -0,0 +1,29 @@
+# Incident: [Title]
+
+**Severity:** SEV-1 | SEV-2 | SEV-3
+**Status:** Investigating | Mitigated | Resolved
+
+## Summary
+
+One-paragraph impact statement.
+
+## Timeline
+
+| Time (UTC) | Event |
+| --- | --- |
+
+## Impact
+
+Users, services, and business impact.
+
+## Root Cause Analysis
+
+Primary cause and contributing factors.
+
+## Resolution
+
+Mitigation and permanent fix.
+
+## Follow-up actions
+
+- [ ] Action item — owner — due date