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

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/task/references/example-nav-system.md

@@ -0,0 +1,33 @@
+# TASK-451: Design unified navigation system for dashboard
+
+## Summary
+
+Design and implement the top-level navigation shell for the unified dashboard. Must support entity switching (orders, customers, inventory, reports), responsive layout, and accessibility compliance.
+
+## Technical Notes
+
+- Use existing design system component library (no new design system work)
+- Navigation state persisted to localStorage to preserve context across sessions
+- Mobile breakpoints: 320px (phone), 768px (tablet), 1024px+ (desktop)
+- WCAG 2.1 AA compliance required for keyboard navigation and screen readers
+- Use CSS Grid for main layout; Flexbox for navigation items
+
+## Acceptance Criteria
+
+- [ ] Entity switcher allows switching between all 4 entity types without page reload
+- [ ] Active entity highlighted in navigation with visible focus indicator
+- [ ] Keyboard navigation works through all nav items (Tab, Enter, Escape)
+- [ ] Layout renders correctly at all 3 breakpoints without horizontal scroll
+- [ ] Mobile hamburger menu opens and closes on tap
+- [ ] Screen reader announces current entity and navigation landmarks
+
+## Additional Information
+
+- Estimated Effort: 3 days
+- Assigned To: Sarah Chen
+- Due Date: 2024-03-15
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.

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

@@ -0,0 +1,58 @@
+---
+name: technical-unit-assessment
+description: >-
+  WHAT - Evidence-based technical unit assessment for repositories, platforms,
+  frontend, backend, infrastructure, data, UI/UX, and AI-native structural readiness.
+---
+
+# Technical Unit Assessment (WHAT)
+
+Assess a technical unit: frontend app, backend API, data platform, infrastructure/IaC scope,
+mobile app, AI/ML pipeline, or another technical workload.
+
+Run **`project-assessment-evidence`** first.
+Use **`project-assessment`** as the router for multi-unit assessments.
+
+## Out of scope
+
+- Does NOT score indicators without evidence — mark as **Not assessed**
+- Does NOT make technical decisions — scores inform, humans decide
+- Does NOT produce final report without **`output-handshake`**
+
+## Unit intake
+
+Ask before scoring:
+- Unit name and type (frontend / backend / infra / data / mobile / AI)
+- Repositories, services, infrastructure scopes, or pipelines included
+- Technical decision ownership (team, client, shared, unknown)
+- Assessment period
+- Authoritative systems for code, docs, CI/CD, incidents, observability, security
+
+## Workflow
+
+1. Run **`project-assessment-evidence`** to build evidence map
+2. Select indicator groups matching the unit type (see `references/indicator-groups.md`)
+3. Score only indicators with evidence; mark rest as **Not assessed**
+4. Note confidence and missing evidence per score
+5. Apply **`output-handshake`** before final scorecard
+
+## Scoring rules
+
+Use the 1–5 scale from `references/indicator-groups.md`. Do not average unrelated indicators
+without explaining weighting. Request validator for subjective scores.
+
+## References
+
+- `references/indicator-groups.md` — all indicator groups + scoring scale + AI-native readiness
+- `references/default-template.md` — technical unit scorecard template
+- `references/example-frontend-assessment.md` — example assessment for a frontend team
+
+## Delegates to
+
+| Need | Skill |
+|------|-------|
+| Evidence intake | **`project-assessment-evidence`** |
+| Multi-unit routing | **`project-assessment`** |
+| Deep UI/UX review | **`ui-ux-pro-max`** |
+| Repo discovery | **`assistant`** |
+| Final output gate | **`output-handshake`** |

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/technical-unit-assessment/references/example-frontend-assessment.md

@@ -0,0 +1,112 @@
+# Technical Unit Assessment — Frontend Engineering
+
+## Review
+
+- Destination: /docs/assessments/2024-q1/frontend
+- Human reviewer: Frontend Lead
+- Assessment status: Draft
+
+## Unit Summary
+
+- Unit name: Frontend Engineering
+- Unit type: Frontend
+- Assessment period: 2024-01-01 to 2024-03-31
+- Repositories / systems: github.com/acme/web-app, github.com/acme/mobile-app, github.com/acme/component-library
+- Documentation: Confluence /eng/frontend + README in each repo
+- Decision ownership: Frontend lead (Marcus) + tech leads (2)
+- Overall technical health: 3.5 / 5
+- Key strengths: Component library adoption, accessibility compliance, CI coverage
+- Key risks or gaps: Test coverage below target, performance regression on bundle size
+- General confidence level: Medium-High
+
+## Evidence Summary
+
+| Evidence area | Source link or location | Freshness | Confidence | Notes |
+| --- | --- | --- | --- | --- |
+| Repositories | GitHub org | Current | High | 3 main repos; all have CI |
+| Documentation | Confluence /eng/frontend | 1 month | Medium | README good; Confluence pages mixed freshness |
+| CI/CD | GitHub Actions | Current | High | All repos have CI; staging auto-deploy |
+| Observability / incidents | Datadog + Sentry | Current | High | Error tracking in Sentry; RUM in Datadog |
+| Architecture / decisions | Notion /decisions/frontend | 2 months | Medium | ADRs exist; not all linked to work |
+| Interviews / validation | 4 engineers | 1 week | Medium | Cross-section: junior to senior |
+
+## Scorecard
+
+### General Technical Indicators
+
+| Indicator | Score | Confidence | Evidence | Notes |
+| --- | --- | --- | --- | --- |
+| Code quality | 4 | High | PR review samples, ESLint compliance | Consistent style; some tech debt in legacy components |
+| Deployment tools | 4 | High | GitHub Actions, Vercel | Staging auto-deploy; prod requires approval |
+| Development experience | 4 | Medium | DX survey, engineer feedback | Hot reload fast; local env setup ~20 min |
+| Monitoring and observability | 4 | High | Datadog RUM, Sentry | Error tracking comprehensive |
+| Security awareness | 3 | Medium | Dependabot alerts, SAST | Weekly triage; no automated DAST |
+| Technical debt volume | 3 | High | GitHub insights, backlog | Known items; no dedicated sprint for reduction |
+| Workflow definition | 4 | High | Linear + Notion | DoR/DoD defined and followed |
+| Testing | 3 | Medium | Coverage reports, CI | ~62% coverage; below 70% target |
+
+### Frontend Indicators
+
+| Indicator | Score | Confidence | Evidence | Notes |
+| --- | --- | --- | --- | --- |
+| Responsiveness | 4 | High | Tested on BrowserStack | All breakpoints covered |
+| Accessibility | 4 | High | axe-core reports, manual audit | WCAG 2.1 AA; audit done quarterly |
+| Performance | 3 | Medium | Lighthouse, bundle analysis | LCP 2.8s (target <2.5s); bundle grew 18% this quarter |
+| UI/UX design | 4 | High | Design system adoption | Component library at 85% reuse |
+| Frontend testing coverage | 3 | Medium | Coverage reports | 62% (target 70%); integration gaps |
+| Frontend dependency management | 4 | High | Dependabot, Renovate | Updates automated; major version manually reviewed |
+
+### AI-Native Structural Readiness
+
+| Indicator | Score | Confidence | Evidence | Notes |
+| --- | --- | --- | --- | --- |
+| Codebase explicitness | 4 | High | Repo structure, README | Clear component boundaries; TypeScript strict |
+| Deterministic build | 4 | High | CI logs, Docker | Reproducible; cache hit rate >75% |
+| Observability | 4 | High | Datadog RUM | Page performance, Core Web Vitals tracked |
+| Testability | 3 | Medium | Coverage, test patterns | Component tests strong; page-level integration weak |
+| Dependency transparency | 4 | High | Dependabot, bundle analysis | SBOM generated monthly |
+
+## Findings
+
+### Strengths
+
+- Finding: Component library has high adoption (85%) and reduces duplicated effort across projects.
+  - Evidence: Confluence adoption metrics, PR samples
+  - Confidence: High
+
+### Risks and Gaps
+
+- Finding: Bundle size grew 18% in Q1, impacting performance scores.
+  - Evidence: Lighthouse trending, bundle analysis reports
+  - Impact: LCP regressed from 2.3s to 2.8s; mobile users affected
+  - Confidence: High
+
+- Finding: Integration test coverage is insufficient for page-level flows.
+  - Evidence: Coverage reports show component tests at 78%, integration at 41%
+  - Impact: 2 regressions escaped to staging in Q1
+  - Confidence: Medium
+
+### Missing Evidence
+
+- Evidence needed: Direct user feedback on dashboard performance
+  - Indicator impacted: Performance (user perception)
+  - Suggested source: PM to provide session recordings or NPS comments
+
+## Recommendations
+
+| Priority | Recommendation | Linked finding | Suggested follow-up |
+| --- | --- | --- | --- |
+| High | Investigate bundle size growth and revert or justify large additions | Bundle size regression | Marcus to lead bundle audit by April 1 |
+| Medium | Add Playwright tests for critical user flows | Integration test gap | 3 critical paths to cover first |
+| Low | Evaluate code splitting strategy for routes | Bundle size | Audit lazy-loaded routes and shared chunk sizes |
+
+## Assumptions and Limitations
+
+- Assumption: Bundle growth is from new dependencies added this quarter, not existing code
+- Limitation: Lighthouse runs on simulated throttling; may not reflect real user conditions
+
+## Validation
+
+- Subjective scores validated by: 4 engineers (self-assessment + lead review)
+- Scores needing follow-up: Performance (3) — Lighthouse not sufficient; need field data
+- Consensus notes: All engineers agreed integration test gap is priority to address

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/technical-unit-assessment/references/indicator-groups.md

@@ -0,0 +1,65 @@
+# Technical Unit Assessment — Indicator Groups Reference
+
+Use only the groups that match the unit being assessed.
+
+## General technical indicators
+
+Repository links, unit type, unit name, documentation links, technical decision responsibility,
+code quality, deployment tools, development experience, monitoring and observability,
+security awareness, technical debt volume, workflow definition, testing.
+
+## Frontend indicators
+
+Frontend languages, responsiveness, accessibility, performance, UI/UX design,
+frontend testing coverage, frontend dependency management.
+
+## Backend indicators
+
+Backend frameworks and libraries, API documentation, databases and storage, backend languages,
+backend testing coverage, API versioning, scalability, error handling, backend dependency management.
+
+## Cloud infrastructure and DevSecOps indicators
+
+Security testing, compliance, CI/CD, Infrastructure as Code, automated environment bootstrapping,
+environment consistency and isolation, secrets management, role-based access control,
+backup/retention/recovery, disaster recovery and resilience, infrastructure monitoring,
+pipeline infrastructure monitoring, cost monitoring and budget controls,
+incident response and postmortems, continuous security.
+
+## Cloud data engineering indicators
+
+Data sources, data architecture documentation, data modeling and schema management,
+pipeline orchestration and reliability, data quality management, data lineage and traceability,
+storage strategy and optimization, data governance and access control, security and compliance,
+monitoring and observability for data pipelines, scalability and performance,
+testing and validation coverage for data workflows, documentation of business rules and metrics,
+data delivery and consumption readiness.
+
+## UI/UX indicators
+
+User interface design, responsiveness, accessibility, user-centered design,
+usability, visual aesthetics. For deep UI review, delegate to **`ui-ux-pro-max`**.
+
+## AI-native structural readiness
+
+Measures whether AI assistance can safely understand and modify the system — NOT tool usage:
+
+- Codebase explicitness and architectural clarity
+- Deterministic build and delivery systems
+- Observability and operational transparency
+- Testability and validation density
+- Dependency and change impact transparency
+
+## Scoring scale
+
+| Score | Meaning |
+|-------|---------|
+| 1 | Low, reactive, implicit, undocumented, or highly variable |
+| 2 | Emerging — some awareness but inconsistent |
+| 3 | Defined, observable, or partially mature with consistency gaps |
+| 4 | Managed — consistent, measured, improving |
+| 5 | Explicit, repeatable, measurable, and evidence-driven |
+
+Mark **Not assessed** when evidence is missing or the indicator is out of scope.
+Do not average unrelated indicators without explaining weighting.
+For subjective scores, request a validator and record consensus status.

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

@@ -0,0 +1,47 @@
+---
+name: trd
+description: >-
+  WHAT — Draft and review a Technical Requirements Document (TRD) using the template, typically from an agreed PRD. Covers architecture, data contracts, technical decisions, risks, and test strategy. English for technical artifacts and tickets unless the user asks otherwise.
+---
+
+# TRD — Technical 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 TRD will live and that a **human** will review.
+2. Then follow the steps below.
+
+## When to use
+
+- A **PRD is approved** (or the task is technical-only) and the team needs design-level agreement before build.
+- You need **API/data contracts**, component boundaries, and **test strategy** aligned to standards.
+- A client doc hub with PRD/TRD cross-links requires **matching** document structure.
+
+## Instructions
+
+1. **Open the TRD template** (`references/default-template.md`). Align sections: Scope, Architecture overview, Data model / API contracts, Technical decisions (link **ADRs** and spikes), Dependencies, Risks & constraints, Testing strategy, Implementation plan.
+2. **Map from PRD:** user stories and AC from the PRD should appear as **addressed** in the TRD with clear technical response; if no PRD exists, state that explicitly and list assumptions.
+3. For **ADRs** that block or explain design, use **`adr`** to structure the decision, then **link** the task or ADR in the forge per your engagement.
+4. Delegate **repo facts** to **`assistant`** (conventions, CI, existing patterns); cite sources.
+5. For **ticket updates**, use the appropriate tool (`clickup-cli`, `jira-*`, etc.); keep task comments **short** with links to the Doc (per `workflow-generic-project`).
+
+## What not to do
+
+- Do not dump the full external template into this skill; use `references/default-template.md` as the local canonical reference.
+- Do not skip **risks** and **testing** when the TRD is a handoff artifact.
+
+## References
+
+- `output-handshake` — destination and review
+- `references/default-template.md` — local TRD template
+- `references/example-unified-api.md` — TRD example for a full API migration (see PRD link in that file)
+- `references/example-api-migration.md` — detailed TRD example with phases, architecture, and testing strategy
+- `prd` — when work starts from product requirements
+- `spike` — research findings used as design evidence
+- `adr` — decision records linked from the TRD
+- `development-workflow` — validation and traceability expectations
+- `incident` — failure handling / incident implications when relevant
+- `workflow-generic-project` — delivery gates and traceability
+- `clickup-cli`, `jira-*` — ticket / comment operations (per engagement)

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/trd/references/example-api-migration.md

@@ -0,0 +1,122 @@
+# TRD-007: Platform API Migration
+
+## Scope
+
+Migrate the legacy REST API surface (`/api/v1/products`, `/api/v1/orders`, `/api/v1/users`) into a new GraphQL Federation layer. This covers the gateway setup, product domain migration, client migration, and deprecation of legacy endpoints.
+
+**Out of scope:** User and Order domain migrations (Phase 2), Auth service changes.
+
+## Architecture Overview
+
+```
+Client (Web/Mobile)
+       ↓
+  Apollo Gateway  ←  /graphql endpoint
+       ↓
+┌──────────┬──────────────┐
+│Product   │  Legacy REST │  (future: additional subgraphs)
+│Subgraph  │  /api/v1/*   │
+└──────────┴──────────────┘
+```
+
+- **Apollo Gateway** runs as a separate service (`api-gateway`) on `gateway.svc.internal:4000`
+- **Product Subgraph** implemented in `product-service` (Node.js + GraphQL Nexus)
+- **Legacy REST** continues serving `/api/v1/*` during transition period
+- Gateway is the single entry point; clients updated to call `/graphql` exclusively
+
+## Data Model / API Contracts
+
+### Product Entity (GraphQL)
+
+```graphql
+type Product {
+  id: ID!
+  name: String!
+  category: Category!
+  pricing: PriceInfo!
+  inventory: InventoryStatus!
+  media: [MediaItem!]!
+  relatedProducts: [Product!]!
+}
+
+type Category {
+  id: ID!
+  name: String!
+  parent: Category
+  attributes: [Attribute!]!
+}
+
+type PriceInfo {
+  amount: Float!
+  currency: String!
+  discountedAmount: Float
+  validFrom: DateTime
+  validTo: DateTime
+}
+```
+
+### REST Legacy Contract (to be deprecated)
+
+```json
+GET /api/v1/products?category=&sort=&include=
+{
+  "products": [...],
+  "pagination": { "total": 0, "page": 1, "per_page": 20 }
+}
+```
+
+Legacy contract must remain functional until 6-month deprecation notice expires.
+
+## Technical Decisions
+
+- [ADR-003: API Versioning Standard](./references/adr-003-api-versioning.md) — Gateway versioning approach
+- [SPIKE-012: GraphQL Federation Evaluation](./references/spike-012-graphql-evaluation.md) — Chosen over REST with JSON:API
+
+## Dependencies
+
+| Dependency | Owner | Status | Notes |
+|---|---|---|---|
+| Apollo Federation v2 | Platform | Ready | License confirmed |
+| Product service GraphQL schema | Backend Team A | In Progress | ETA: Week 3 |
+| Client SDK update (Apollo Client 3) | Frontend Team | Not Started | Handoff: Week 5 |
+| Staging environment for gateway | SRE/Infra | Not Started | Request submitted |
+
+## Risks & Constraints
+
+| Risk | Likelihood | Impact | Mitigation |
+|---|---|---|---|
+| Staging env not ready by Week 3 | Medium | High | Follow up with Infra by Jan 23; fall back to manual testing |
+| Client migration delays | Medium | Medium | Maintain `/api/v1` in parallel during transition |
+| Schema drift between subgraphs | Low | High | Schema checks in CI before merge |
+| Auth team bandwidth for User subgraph | High | Medium | ADR to propose User subgraph deferral to Phase 2 |
+
+## Testing Strategy
+
+1. **Unit tests:** GraphQL resolvers tested with Jest; schema validation with `graphql剑法` import validation
+2. **Integration tests:** Apollo Gateway integration tests with product subgraph; use staging environment
+3. **Contract tests:** Use Apollo Studio contract checks in CI to prevent breaking changes
+4. **E2E tests:** Playwright tests for product listing and detail pages (critical user flows)
+5. **Performance:** Lighthouse for page load; Datadog RUM for real-user metrics post-deploy
+
+## Implementation Plan
+
+### Phase 1 (Weeks 1-4): Gateway + Product Subgraph
+
+- Week 1: Gateway service setup; local dev environment
+- Week 2: Product subgraph implementation; schema design review
+- Week 3: Gateway + subgraph integration in staging; test client (Postman/Insomnia)
+- Week 4: Internal dogfood; Frontend team onboards to test client
+
+### Phase 2 (Weeks 5-8): Client Migration + Search
+
+- Week 5: Frontend team updates Apollo Client; web app points to `/graphql`
+- Week 6: Mobile team migration (React Native Apollo Client 3)
+- Week 7: Search endpoint migration (faceted search with aggregations)
+- Week 8: Remove REST from web client; staging clean
+
+### Phase 3 (Weeks 9-12): Legacy Deprecation + Monitoring
+
+- Week 9: Publish GraphQL Explorer in Confluence; announce deprecation
+- Week 10-12: Monitor error rates; collect usage metrics on legacy endpoints
+- Week 12: Issue 6-month deprecation notice for `/api/v1` (if not already done)
+- Ongoing: Phase 2 domains (Orders, Users) tbd based on Phase 1 learnings

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/user-story/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: user-story
+description: >-
+  WHAT - Draft and review user stories using the task template plus the As a/I want/so that format from Best Practices examples.
+---
+
+# User Story (WHAT)
+
+Use for user-centered requirements that need business value, technical notes, and acceptance criteria.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Use **`planning`** when estimation or splitting is needed.
+3. Use **`task`** for purely technical work that is not a user story.
+
+## References
+
+- `references/default-template.md`
+- `references/example-advanced-filtering.md` — example user story for a multi-attribute product filter with AC and technical notes

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/user-story/references/example-advanced-filtering.md

@@ -0,0 +1,37 @@
+# US-204: Implement Advanced Filtering Options
+
+**As a** returning customer, **I want** to filter products by multiple attributes simultaneously (category, price range, brand, availability), **so that** I can narrow results quickly without navigating through multiple pages.
+
+## Summary
+
+Add a multi-attribute filter panel to the product listing page. Users can apply multiple filters at once; filters are applied client-side where possible for instant feedback, with server-side fallback for large result sets.
+
+## Technical Notes
+
+- Reuse existing `FilterPanel` component from component library (already handles single-attribute filtering)
+- Extend `ProductFilters` context to support multi-select for category and brand
+- Price range uses dual-slider component; debounce API calls by 300ms
+- URL sync: filter state reflected in query params (`?category=electronics&brand=acme&price=100-500`)
+- Server-side filtering triggered when filter combination exceeds 50 possible combinations client-side
+
+## Acceptance Criteria
+
+- [ ] Filter panel displays all available filterable attributes (category, brand, price, availability)
+- [ ] Multiple filters can be selected and combined without page reload
+- [ ] Active filters shown as removable chips above product grid
+- [ ] Filter state preserved in URL and restored on page reload
+- [ ] Empty result state displays friendly message with option to clear filters
+- [ ] Clear all filters button resets to default unfiltered view
+- [ ] WCAG 2.1 AA: keyboard navigation through all filter controls
+- [ ] Performance: filter results update within 300ms for up to 200 products client-side
+
+## Additional Information
+
+- Estimated Effort: 5 story points
+- Assigned To: Sarah Chen
+- Due Date: 2024-02-28
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/work-item/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: work-item
+description: >-
+  WHAT - Router for creating and refining epics, user stories, tasks, bugs, and incidents using Best Practices work item hierarchy.
+---
+
+# Work Item Router (WHAT)
+
+Use this skill when the user asks to create, refine, or evaluate work items.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before producing final content or writing to a tool.
+2. Use the smallest applicable skill:
+   - Epic -> `epic`
+   - User story -> `user-story`
+   - Technical task -> `task`
+   - Bug -> `bug`
+   - Incident -> `incident`
+3. Use **`planning`** when the item needs breakdown, estimation, prioritization, or capacity checks.
+4. Use **`clickup-cli`** for ClickUp writes only after user approval.
+
+## Hierarchy
+
+Epic -> Story/Task/Bug -> Subtasks. Not every methodology uses every level; follow the engagement pack and ticket system.
+
+## References
+
+- `references/default-template.md`
+- `references/example-routing-dashboard.md` — example routing decision classifying a feature request as user story

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/work-item/references/example-routing-dashboard.md

@@ -0,0 +1,23 @@
+# Routing: Request for new Dashboard Analytics Feature
+
+## Requested Item
+
+- [ ] Epic
+- [x] User story
+- [ ] Task
+- [ ] Bug
+- [ ] Incident
+- [ ] Unknown / needs classification
+
+## Classification Notes
+
+Feature request from product team. Fits existing user story pattern; would be part of EPIC-102 (Unified Dashboard). Requested scope fits within a single sprint if broken into 3 stories: filtering (US-204), sorting (US-205), and saved views (US-206).
+
+## Destination and Review
+
+- [x] Destination confirmed: Linear backlog, will link to EPIC-102
+- [x] Human review required: PM review scheduled for Jan 25 sync
+
+## Next Skill
+
+- [x] `user-story` — proceed with drafting US-204, US-205, US-206