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

agent_toolkit_cli-1.0.3.data/data/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_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/prd/SKILL.md

@@ -0,0 +1,44 @@
+---
+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.
+---
+
+# 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_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/prd/references/example-unified-api.md

@@ -0,0 +1,71 @@
+# PRD-042: Unified API Strategy
+
+## Objective
+
+Consolidate the current fragmented API landscape (4 REST endpoints, 2 legacy SOAP services, and 1 internal gRPC interface) into a unified, versioned API surface that supports frontend and mobile clients with a single, coherent interface. This enables faster iteration, reduces backend coupling, and provides the foundation for a future GraphQL federation layer.
+
+## User Flow / Personas
+
+**Primary Users:**
+- Frontend developers building product pages (web and mobile)
+- Mobile team requiring low-latency, expressive queries
+- Partner integrations consuming the public API
+
+**User Flow:**
+1. Client sends query to unified endpoint (REST or GraphQL)
+2. Gateway validates request and routes to domain service
+3. Domain service returns typed response through API layer
+4. Client receives consistent, versioned response
+
+## Entities & Use Cases
+
+**Core Entities:**
+- Product (id, name, category, pricing, inventory, media)
+- Category (id, name, parent, attributes, metadata)
+- User (id, roles, preferences, session)
+- Order (id, user, items, status, fulfillment)
+
+**Primary Use Cases:**
+- UC-1: Fetch product details with category hierarchy
+- UC-2: Search products by filters and sort options
+- UC-3: Fetch related products or accessories
+- UC-4: Aggregate analytics data per product
+
+## Acceptance Criteria
+
+- [ ] `/api/v1/products` returns product list with pagination
+- [ ] `/api/v1/products/:id` returns full product details with media URLs
+- [ ] `?category=` filter supports hierarchical category traversal
+- [ ] `?include=related` embeds related products in response
+- [ ] Response schema is documented in OpenAPI 3.1
+- [ ] Version header (`API-Version: 1`) accepted on all requests
+- [ ] Deprecation notice returned in headers for versions with EOL within 6 months
+
+## Edge Cases
+
+- Category filter returns empty set: return empty array with 200, not error
+- Product not found: return 404 with error schema `{code, message, request_id}`
+- Invalid include parameter: return 400 with valid values in error message
+- Rate limit exceeded: return 429 with `Retry-After` header
+
+## Integrations
+
+- Inventory Service (gRPC): for real-time stock levels
+- Pricing Service (REST): for dynamic pricing rules
+- Analytics Platform (Kafka): for event emission on product views
+
+## Timeline
+
+- Phase 1 (Weeks 1-4): API Gateway setup + `/products` endpoint migration
+- Phase 2 (Weeks 5-8): Search and filter endpoints
+- Phase 3 (Weeks 9-12): Deprecate legacy endpoints; publish GraphQL
+
+## Approvals
+
+- VP Engineering: Elena Vasquez — 2024-01-15
+- Product Lead: Marcus Chen — 2024-01-16
+
+## Related
+
+- [TRD-007: Platform API Migration](./trd-007-platform-api-migration.md)
+- [ADR-003: API Versioning Standard](./adr-003-api-versioning.md)

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

@@ -0,0 +1,90 @@
+---
+name: project-assessment
+description: >-
+  WHAT - Interactive project assessment router: define assessment scope and units,
+  collect evidence through project-assessment-evidence, then delegate to
+  technical or management unit assessment skills. Always evidence-based and human-reviewed.
+---
+
+# Project Assessment (WHAT)
+
+Use this skill when the user asks for a project assessment, maturity assessment, delivery audit, technical assessment, management assessment, quality indicator review, or improvement roadmap.
+
+This is a router skill. Keep it focused on assessment flow, gates, and delegation. Use the unit-specific skills for scoring details.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before producing any final assessment report, scorecard, action plan, or executive summary: ask where the artifact should live and confirm human review.
+2. Apply **`project-assessment-evidence`** before scoring. Evidence may live in repositories, boards, docs, spreadsheets, dashboards, incidents, PRs, meetings, interviews, Slack, emails, or any other project system. Ask the user where to find each source.
+3. Never assign a score without evidence. If evidence is missing, mark the indicator as **Not assessed** or score it with **Low confidence** and state the assumption explicitly.
+4. Keep sensitive details out of reusable artifacts. Redact secrets, credentials, private customer data, and unnecessary personal data.
+5. Do not mention client-specific reference examples or internal audit links in generated outputs. Use only abstracted patterns.
+
+## Assessment flow
+
+1. **Intake**
+   - Ask the assessment purpose: baseline, periodic review, due diligence, quality improvement, delivery health check, AI-readiness review, or internal audit support.
+   - Ask the assessment period and target audience.
+   - Ask whether the assessment should cover management units, technical units, or both.
+   - Ask which repositories, products, squads, platforms, or delivery scopes form each assessment unit.
+2. **Evidence collection**
+   - Delegate to **`project-assessment-evidence`**.
+   - Build an evidence map before scoring.
+   - Ask the user where each evidence category lives instead of assuming ClickUp or repository-only evidence.
+3. **Unit assessment**
+   - For technical workloads, delegate to **`technical-unit-assessment`**.
+   - For project management and delivery scopes, delegate to **`management-unit-assessment`**.
+   - If UI depth is required, pair the technical unit assessment with **`ui-ux-pro-max`**.
+   - If repository discovery is required, pair with **`assistant`** and the repository-specific rules.
+4. **Consensus and scoring**
+   - Use the 1 to 5 maturity scale from the assessment indicators.
+   - Treat score 3 as "defined or partially mature", not as average performance.
+   - Record confidence per score: High, Medium, Low, or Not assessed.
+   - For subjective indicators, ask who should validate the score and whether weights are needed.
+5. **Findings and action plan**
+   - Summarize strengths, risks, gaps, and opportunities.
+   - Separate confirmed findings from assumptions and missing evidence.
+   - Convert recommendations into actionable follow-ups only after user approval, delegating ticket creation to the relevant ticket skill.
+
+## Required interactive questions
+
+Ask these before creating the final assessment artifact:
+
+- Where should the final assessment live?
+- Who will review and approve it?
+- What is the assessment purpose and period?
+- Which management units and technical units are in scope?
+- Which systems of record should be used for evidence?
+- Where are the repositories, docs, boards, diagrams, CI/CD pipelines, dashboards, incident records, meeting notes, decisions, agreements, and stakeholder feedback?
+- Which indicators must be skipped, weighted, or treated as out of scope?
+- Which people should be interviewed or asked to validate subjective scores?
+
+## Outputs
+
+Typical outputs are:
+
+- Assessment plan and scope
+- Evidence map
+- Unit scorecards
+- Findings with evidence links
+- Missing evidence register
+- Risk and opportunity summary
+- Recommendations and action plan
+- Follow-up work item candidates
+
+## Boundaries
+
+- This skill does not execute ClickUp, Jira, Confluence, GitHub, GitLab, Slack, or repository commands. Delegate HOW to tool skills.
+- This skill does not replace project-specific assessment procedures. If an engagement pack or repository defines stricter rules, surface the difference and follow the stricter/project-specific rule.
+- This skill does not create tasks or update documents without explicit user approval.
+
+## References
+
+- `references/default-template.md` - default assessment report template
+- `references/example-platform-assessment.md` — example assessment for a platform engineering team with full scorecard
+- `project-assessment-evidence` - evidence map and source-by-source intake
+- `technical-unit-assessment` - technical unit indicators and template
+- `management-unit-assessment` - management unit indicators and template
+- `output-handshake` - destination and human review
+- `assistant` - repository discovery
+- `clickup-cli`, external Jira/Confluence skills, forge skills, and Slack skills - evidence retrieval or artifact updates after approval

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/project-assessment/references/example-platform-assessment.md

@@ -0,0 +1,122 @@
+# Project Assessment Report — Q1 2024 Platform Engineering
+
+## Review
+
+- Destination: /docs/assessments/2024-q1/platform-engineering
+- Human reviewer: VP Engineering
+- Assessment status: Reviewed
+
+## Assessment Summary
+
+- Assessment purpose: Quarterly health check for Platform Engineering unit
+- Assessment period: 2024-01-01 to 2024-03-31
+- Assessment scope: Platform team (4 engineers), 14 repositories, 2 production services
+- Units assessed: Technical — Platform Engineering
+- Overall health: 3.8 / 5 — Strong delivery with documented risk areas
+- Key strengths: CI/CD coverage, code review culture, incident response speed
+- Key risks or gaps: Documentation freshness, decision traceability to work items
+- Overall confidence level: High
+
+## Method
+
+- Evidence sources used: GitHub repos, Linear, Datadog, Confluence, 6 engineer interviews
+- Interviews or validation sessions: 6 structured interviews (Jan 15-17); all squad leads validated findings
+- Indicators in scope: Standard technical indicators plus AI-Native Structural Readiness
+- Indicators out of scope: Mobile-specific, data engineering (separate assessments)
+- Scoring scale: 1 to 5 maturity scale
+- Weighting approach, if any: Equal weight across indicators; maturity scale 1=ad-hoc, 5=optimized
+
+## Evidence Map
+
+| Evidence area | Source link or location | Owner | Freshness | Used for | Confidence | Notes |
+| --- | --- | --- | --- | --- | --- | --- |
+| Repositories | github.com/acme/platform | David Park | Current | All technical indicators | High | 14 repos |
+| Work tracking | Linear /platform-squad | Alice Kim | Current | Delivery, Methodology | High | All work visible |
+| Documentation | Confluence /eng/platform | Carmen Reyes | 2 weeks | Docs density, AI readiness | Medium | Some outdated pages |
+| Architecture and decisions | Notion /decisions/architecture | Elena Vasquez | 1 month | Decision traceability | Medium | ADRs exist, not linked to tasks |
+| CI/CD and releases | GitHub Actions + Datadog | David Park | Current | Deployment, Security | High | All repos have CI |
+| Observability and incidents | Datadog dashboards | SRE team | Current | Monitoring, Incident response | High | 5 dashboards active |
+| Meetings and stakeholder feedback | Interview notes | Alice Kim | 2 weeks | All indicators | Medium | 6 engineers |
+
+## Unit Scorecards
+
+### Unit: Platform Engineering
+
+- Unit type: Technical
+- Scope: Core platform services (API gateway, message queue infrastructure, deployment tooling)
+- Evidence confidence: High
+
+| Category | Indicator | Score | Confidence | Evidence | Notes |
+| --- | --- | --- | --- | --- | --- |
+| General Technical | Code quality | 4 | High | PR review samples, GitHub insights | Consistent style; some tech debt in legacy modules |
+| General Technical | Deployment tools | 4 | High | GitHub Actions, Datadog deploy events | All automated; rollback tested |
+| General Technical | Development experience | 4 | High | DX survey results, interview feedback | Onboarding doc adequate; local env setup takes ~2hrs |
+| General Technical | Monitoring and observability | 5 | High | Datadog dashboards | Comprehensive; P50/P95/P99 visible |
+| General Technical | Security awareness | 3 | Medium | Dependabot alerts, SAST results | Alerts triaged weekly; no automated DAST in pipeline |
+| General Technical | Technical debt volume | 3 | High | GitHub debt analysis, interviews | Known items tracked in backlog; not actively reduced |
+| General Technical | Workflow definition | 4 | High | Linear + Notion | DoR/DoD defined; mostly followed |
+| General Technical | Testing | 3 | Medium | Test coverage reports, CI runs | ~68% coverage; unit tests strong, integration weak |
+| Infrastructure | CI/CD | 4 | High | GitHub Actions logs | All repos CI; staging deploys automated, prod manual |
+| Infrastructure | Infrastructure as Code | 4 | High | Terraform configs in repo | All infra in Terraform; drift detection enabled |
+| Infrastructure | Secrets management | 4 | High | Vault + GitHub secrets | No hardcoded secrets; rotation policy documented |
+| Infrastructure | Incident response | 4 | High | INC log, Datadog alerts | Median time to acknowledge: 8 min; P95 resolution: 2.4 hrs |
+| AI-Native | Codebase explicitness | 4 | High | Repo structure, docs | Clear layering; README in each repo |
+| AI-Native | Deterministic build | 4 | High | CI logs, Docker builds | Builds reproducible; cache hit rate >80% |
+| AI-Native | Observability | 4 | High | Datadog + logging | Structured logs; trace IDs across services |
+| AI-Native | Testability | 3 | Medium | Test coverage + patterns | Unit tests strong; integration test gaps |
+| AI-Native | Dependency transparency | 3 | Medium | Dependabot, SBOM | Dependencies tracked; SBOM not auto-generated |
+
+## Findings
+
+### Strengths
+
+- Finding: CI/CD pipeline is mature and reliable across all 14 repositories.
+  - Evidence: GitHub Actions covers 100% of repos; all have automated tests; staging deploy automated
+  - Confidence: High
+
+- Finding: Incident response is fast and well-documented.
+  - Evidence: Median acknowledge time 8 min; all postmortems within 48 hrs; action items tracked
+  - Confidence: High
+
+### Risks and Gaps
+
+- Finding: Documentation is not kept in sync with code changes.
+  - Evidence: 5 of 12 Confluence pages reviewed were last updated before relevant code change
+  - Impact: Onboarding time is higher than it should be; engineers report spending time tracing actual behavior
+  - Confidence: Medium
+
+- Finding: ADRs are not linked to Linear work items, breaking traceability.
+  - Evidence: 7 ADRs exist in Notion; zero cross-references to tasks or PRs
+  - Impact: Cannot trace architectural decision to implementation or验证 decision rationale
+  - Confidence: Medium
+
+### Missing Evidence
+
+- Evidence needed: Direct product team satisfaction for platform reliability
+  - Why it matters: Stakeholder satisfaction indicator currently relies on indirect signals
+  - Suggested source or owner: PM lead to provide 1:1 feedback from product stakeholders
+
+## Recommendations
+
+| Priority | Recommendation | Rationale | Owner | Suggested follow-up |
+| --- | --- | --- | --- | --- |
+| High | Implement doc-on-code policy: README or Confluence update required with architectural changes | Docs freshness directly impacts onboarding and AI assistant context quality | Carmen Reyes | Create checklist item in PR template |
+| Medium | Link ADRs to Linear tasks using custom field | Restore traceability; enable future AI-assisted decision retrieval | Elena Vasquez | Add `adr_link` field to Linear task template |
+| Low | Add DAST to CI pipeline | Security indicator below target; easy automation | David Park | Evaluate OWASP ZAP GitHub Action |
+
+## Action Plan Candidates
+
+- [ ] Update Confluence pages for API gateway and message queue (Owner: Carmen, Due: 2024-04-15)
+- [ ] Add ADR link field to Linear work item template (Owner: Alice, Due: 2024-04-01)
+- [ ] Evaluate DAST integration (Owner: David, Due: 2024-05-01)
+
+## Assumptions and Limitations
+
+- Assumption: Confluence page timestamps reflect actual content freshness (not just metadata edits)
+- Limitation: Stakeholder feedback relies on quarterly NPS; no real-time signal for platform-specific issues
+
+## Approval
+
+- Reviewed by: Elena Vasquez, VP Engineering
+- Review date: 2024-03-28
+- Approval notes: Assessment approved with action items prioritized. Elena to review progress in June check-in.

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/project-assessment-evidence/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: project-assessment-evidence
+description: >-
+  WHAT - Interactive evidence intake for project assessments. Ask the user where
+  each evidence source lives, build an evidence map, track missing evidence,
+  assumptions, freshness, and confidence before any scoring happens.
+---
+
+# Project Assessment Evidence (WHAT)
+
+Use this skill before scoring a project assessment. It turns scattered project knowledge into a structured evidence map.
+
+This skill is intentionally interactive. Evidence can be outside ClickUp and outside the repository. Ask for source locations instead of assuming where they live.
+
+## Default behavior
+
+1. Ask the user for the systems of record and evidence locations.
+2. Collect source links, paths, owners, dates, and freshness for each evidence item.
+3. Mark evidence quality: Direct, Indirect, Interview-only, Stale, Missing, or Not applicable.
+4. Record confidence for each evidence item: High, Medium, Low, or Not assessed.
+5. Do not score indicators. Return the evidence map to **`project-assessment`**, **`technical-unit-assessment`**, or **`management-unit-assessment`**.
+
+## Evidence intake questions
+
+Ask only the questions relevant to the assessment scope, but cover each required source class before scoring.
+
+### Scope and systems
+
+- What project, product, platform, squad, or delivery scope is being assessed?
+- What period should evidence cover?
+- What are the official systems of record?
+- Which sources should be considered authoritative when sources conflict?
+
+### Delivery and management evidence
+
+- Where is the project board or backlog?
+- Where are epics, stories, tasks, bugs, incidents, and subtasks tracked?
+- Where are sprint plans, delivery reports, retrospectives, risks, and OIRs?
+- Where are PRDs, TRDs, ADRs, decisions, agreements, and meeting minutes stored?
+- Where can stakeholder feedback, client satisfaction signals, and team health signals be found?
+- Who should validate subjective management indicators?
+
+### Technical evidence
+
+- Where are the repositories and deployment manifests?
+- Where are architecture diagrams, API docs, runbooks, and operations docs?
+- Where are CI/CD pipelines, deployment history, and release notes?
+- Where are test reports, coverage data, quality gates, and static analysis outputs?
+- Where are observability dashboards, alerts, logs, incident records, and postmortems?
+- Where are security, compliance, access control, secrets management, and dependency signals?
+- For data systems, where are lineage, data quality checks, orchestration, schemas, business rules, and consumption docs?
+- For UI/UX, where are design files, UX research, accessibility reports, performance reports, screenshots, recordings, or product analytics?
+
+### Interviews and validation
+
+- Who should be interviewed or asked for context?
+- Which questions must be answered by humans because no artifact exists?
+- Which scores require cross-review or consensus?
+
+## Evidence quality rules
+
+- Prefer direct artifacts over recollection.
+- Treat interview notes as valid evidence only when clearly labeled as interview evidence.
+- Do not use stale evidence without marking freshness risk.
+- If an indicator has conflicting evidence, record both sources and request validation.
+- If no evidence is available, record **Missing evidence** and avoid pretending certainty.
+
+## Output
+
+Return an evidence map with:
+
+- Source type
+- Source link or location
+- Owner or contact
+- Freshness
+- Related indicators
+- Evidence strength
+- Confidence
+- Notes and limitations
+
+## References
+
+- `references/default-template.md` - evidence map template
+- `references/example-evidence-map.md` — example evidence map for a multi-team engineering assessment
+- `project-assessment` - assessment router
+- `technical-unit-assessment` - technical scoring
+- `management-unit-assessment` - management scoring
+- `output-handshake` - destination and review for final artifacts

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/project-assessment-evidence/references/example-evidence-map.md

@@ -0,0 +1,46 @@
+# Project Assessment Evidence Map
+
+## Scope
+
+- Assessment: Q1 2024 Engineering Platform Assessment
+- Period: 2024-01-01 to 2024-03-31
+- Units covered: Platform Engineering, Frontend, Backend, Data
+- Systems of record: Linear (work), GitHub (code), Jira (delivery), Confluence (docs)
+- Source precedence rules: Primary — repo configs and CI; Secondary — linear and docs; Tertiary — interviews
+
+## Evidence Ledger
+
+| ID | Evidence area | Source type | Source link or location | Owner | Freshness | Related indicators | Strength | Confidence | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| E-001 | Work tracking | Linear boards | Platform Squad workspace | Alice Kim | Current | Delivery, Methodology | Direct | High | All platform work in Linear |
+| E-002 | Repository | GitHub org | github.com/acme/platform | David Park | Current | Code quality, CI/CD, Architecture | Direct | High | 14 repos assessed |
+| E-003 | Documentation | Confluence | /eng/platform/docs | Carmen Reyes | 2 weeks old | Docs density, Decision traceability | Direct | Medium | Some pages outdated |
+| E-004 | CI/CD | GitHub Actions | .github/workflows in repos | David Park | Current | Pipeline, Deployment, Security | Direct | High | All repos have CI |
+| E-005 | Observability | Datadog | dashboards/engineering | SRE team | Current | Monitoring, Incidents | Direct | High | Dashboards linked |
+| E-006 | Decisions | Notion | /decisions/architecture | Elena Vasquez | 1 month old | Decision traceability | Indirect | Medium | Decisions exist, not always linked |
+| E-007 | Interviews | Notes | /evidence/interviews-2024-q1 | Alice Kim | 2 weeks old | All indicators | Direct | Medium | 6 engineers interviewed |
+| E-008 | Stakeholder feedback | Intercom | NPS dashboard Q1 | PM lead | Quarterly | Client satisfaction | Indirect | Low | No direct engineering signal |
+
+## Missing Evidence Register
+
+| Missing evidence | Indicators impacted | Why it matters | Suggested source or owner | Required before scoring? |
+| --- | --- | --- | --- | --- |
+| Direct stakeholder satisfaction for Platform team | Stakeholder engagement | Quarterly NPS too lagged for actionable feedback | PM to schedule 1:1 with product leads | No (can score 3 as placeholder) |
+
+## Conflicts and Validation Needs
+
+| Topic | Conflicting sources | Proposed validator | Status |
+| --- | --- | --- | --- |
+| Deployment frequency: Jira reports weekly; GitHub Actions logs show bi-weekly | David Park to reconcile | Pending — David to audit actual deploy timestamps | Pending |
+| Documentation freshness: Confluence shows pages from 2023; engineers claim docs are current | Carmen to update Confluence or note which pages are maintained | Carmen | In Progress |
+
+## Assumptions
+
+- Assumption: GitHub Actions logs reflect actual deployment events, not just CI runs
+  - Evidence gap: No separate deployment log to cross-reference
+  - Impact: Deployment frequency indicator may be inflated if CI = deploy
+  - Validation needed: David to confirm pipeline stages and actual prod deploy events
+- Assumption: Intercom NPS reflects platform team contribution (not overall product NPS)
+  - Evidence gap: No segment for platform vs feature work
+  - Impact: Scores may mask platform-specific issues
+  - Validation needed: PM to provide breakdown if available

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

@@ -0,0 +1,23 @@
+---
+name: spike
+description: >-
+  WHAT - Produce spike and research findings using the spike template; captures purpose, findings, implementation strategy, risks, tradeoffs, open questions, and references.
+---
+
+# Spike and Research Findings (WHAT)
+
+Use for technical exploration, feasibility validation, architecture assessment, or research outputs that should influence design or implementation.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Make findings actionable: recommendation, tradeoffs, open questions, and next steps.
+3. Link from **`trd`** when the spike informs technical design.
+4. Link from **`adr`** when the spike leads to a durable decision.
+
+## References
+
+- `references/default-template.md`
+- `references/example-graphql-federation.md` — example spike for evaluating GraphQL Federation with tradeoffs and phased approach
+- `trd`
+- `adr`

agent_toolkit_cli-1.0.3.data/data/agent_toolkit/data/skills/delivery/spike/references/example-graphql-federation.md

@@ -0,0 +1,79 @@
+# SPIKE-012: GraphQL Federation Evaluation
+
+## Purpose
+
+Evaluate GraphQL Federation as the future API architecture for the platform. Assess feasibility, team readiness, and infrastructure requirements before committing to a migration path.
+
+**Spike Ticket:** ARCH-018
+
+## Findings and Conclusions
+
+GraphQL Federation is viable for the platform and recommended for adoption. The team has sufficient backend expertise; frontend teams have expressed strong interest. Infrastructure exists to support the gateway. The main risk is the learning curve for distributed schema ownership.
+
+**Decision recommended:** Proceed with phased adoption starting with the product domain.
+
+### Architecture Fit (if applicable)
+
+| Layer / Area | Purpose / Role | Tools / Services | Notes |
+| --- | --- | --- | --- |
+| API Gateway | Schema routing, query planning | Apollo Federation v2 | Supports REST passthrough during migration |
+| Product Subgraph | Product domain data | GraphQL Nexus + Prisma | Team owns this subgraph |
+| User Subgraph | User and session data | GraphQL Nexus | Owned by Auth team |
+| Inventory Subgraph | Stock levels, warehouse | REST (existing) → GraphQL | Low priority; can remain REST behind Apollo |
+| Clients | Web (React), Mobile (React Native) | Apollo Client 3 | Both support Federation |
+
+## High-Level Implementation Strategy
+
+### Components / Layers
+
+1. **Gateway layer:** Deploy Apollo Gateway as `/graphql` endpoint; existing `/api/v1` REST remains available
+2. **Product subgraph:** Migrate from REST to GraphQL first; establishes pattern for other teams
+3. **Client migration:** Update Apollo Client to use GraphQL; maintain REST fallback during transition
+4. **Auth integration:** User subgraph implemented by Auth team; timeline TBD
+
+### Phase 1 (Weeks 1-6)
+
+- Gateway + Product subgraph
+- REST backward compatibility maintained
+- Mobile team as early adopter
+
+### Phase 2 (Weeks 7-12)
+
+- Expand to other domains (orders, customers)
+- Deprecate REST endpoints with 6-month notice
+
+## Security, Governance, or Compliance Considerations
+
+- Access controls: Field-level auth via JWT claims in GraphQL context
+- Auditability: GraphQL operation logging to Datadog (query, variables, user ID)
+- Sensitive data handling: PII fields marked with `@auth` directive; rate limiting per client ID
+
+## Start Small, Scale Fast
+
+- **First safe step:** Deploy gateway with Product subgraph only; no client traffic yet
+- **Deferred work:** Auth subgraph, order history, mobile-optimized queries
+
+## Research Notes / Tradeoffs
+
+| Option | Pros | Cons | Notes |
+| --- | --- | --- | --- |
+| GraphQL Federation | Expressive queries, type safety, single graph | More infra, learning curve, caching harder | Recommended |
+| REST with JSON:API | Simple, CDN-cacheable, team familiarity | Versioning complexity, over-fetching | Rejected — does not solve core pain points |
+| gRPC | Performance, binary protocol | Not browser-native, mobile support weak | Rejected for client-facing; consider for service-to-service |
+
+## Open Questions
+
+1. Auth team bandwidth for User subgraph? Status: Open — meeting scheduled Jan 30
+2. Existing REST endpoint deprecation timeline? Status: Open — PM to define
+3. GraphQL schema registry tooling? Status: Answered — Apollo Studio with schema checks in CI
+
+## References
+
+- [PRD-042: Unified API Strategy](./prd-042-unified-api-strategy.md)
+- Apollo Federation docs: https://www.apollographql.com/docs/federation/
+- Engineering sync notes 2024-01-15
+
+## Review
+
+- [ ] Destination confirmed.
+- [ ] Human review required.

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

@@ -0,0 +1,20 @@
+---
+name: task
+description: >-
+  WHAT - Draft and review technical tasks using the Best Practices Task Template; includes summary, technical notes, AC, estimate, owner, and due date.
+---
+
+# Task (WHAT)
+
+Use for technical or operational work that is not best represented as a user story.
+
+## Default guardrails
+
+1. Apply **`output-handshake`** before final output.
+2. Use **`planning`** for estimation, dependencies, and breakdown.
+3. Use **`bug`** for defects and **`incident`** for urgent production impact.
+
+## References
+
+- `references/default-template.md`
+- `references/example-nav-system.md` — example task for a dashboard navigation system with AC and tech notes