@forwardimpact/pathway 0.3.0 → 0.5.0

package/examples/agents/.claude/skills/code-quality-review/SKILL.md

@@ -1,108 +0,0 @@
----
-name: code-quality-review
-description: |
-  Guide for reviewing code quality, identifying issues, and suggesting
-  improvements. Use when asked to review code, check for best practices,
-  or conduct code reviews.
----
-
-# Code Quality & Review
-
-## Stage Guidance
-
-### Plan Stage
-
-**Focus:** Understand code review scope and establish review criteria. Consider
-what quality standards apply.
-
-**Activities:**
-
-- Identify code review scope
-- Understand applicable standards
-- Plan review approach
-- Consider risk level
-
-**Ready for Code when:**
-
-- [ ] Review scope is clear
-- [ ] Standards are understood
-- [ ] Review approach is planned
-- [ ] Risk level is assessed
-
-### Code Stage
-
-**Focus:** Write clean, maintainable, tested code. Follow project conventions
-and ensure adequate coverage.
-
-**Activities:**
-
-- Write readable, well-structured code
-- Add appropriate tests
-- Follow project conventions
-- Document non-obvious logic
-
-**Ready for Review when:**
-
-- [ ] Code compiles and passes all tests
-- [ ] Changes are covered by tests
-- [ ] Code follows project conventions
-- [ ] No unnecessary complexity
-
-### Review Stage
-
-**Focus:** Verify correctness, maintainability, and adherence to standards.
-Ensure no code is shipped that isn't understood.
-
-**Activities:**
-
-- Verify code does what it claims
-- Check test coverage
-- Review for maintainability
-- Confirm style compliance
-
-**Ready for Complete when:**
-
-- [ ] No obvious security vulnerabilities
-- [ ] Error handling is appropriate
-- [ ] Documentation updated if needed
-- [ ] No code you don't fully understand
-
-## Reference
-
-## Review Process
-
-### 1. Correctness First
-
-Before anything else, verify the code does what it claims:
-
-- Does it implement the intended behavior?
-- Are there logic errors or off-by-one bugs?
-- Does it handle all specified requirements?
-- Are error conditions handled appropriately?
-
-### 2. Test Coverage
-
-Check that changes are properly tested:
-
-- Unit tests for new functionality
-- Edge cases and error conditions
-- Integration tests where appropriate
-- Tests are readable and maintainable
-
-### 3. Maintainability
-
-Evaluate long-term code health:
-
-- Clear naming (variables, functions, classes)
-- Appropriate abstraction levels
-- No unnecessary duplication (DRY)
-- Single responsibility principle applied
-
-### 4. Code Style
-
-Verify consistency with project standards:
-
-- Follows project coding conventions
-- Consistent formatting and indentation
-- Appropriate comments for non-obvious logic
-- Documentation updated if needed

package/examples/agents/.claude/skills/devops-cicd/SKILL.md

@@ -1,142 +0,0 @@
----
-name: devops-cicd
-description: |
-  Guide for building CI/CD pipelines, managing infrastructure as code, and
-  implementing deployment best practices. Use when setting up pipelines,
-  containerizing applications, or configuring infrastructure.
----
-
-# DevOps & CI/CD
-
-## Stage Guidance
-
-### Plan Stage
-
-**Focus:** Plan CI/CD pipeline architecture and infrastructure requirements.
-Consider deployment strategies and monitoring needs.
-
-**Activities:**
-
-- Define pipeline stages (build, test, deploy)
-- Identify infrastructure requirements
-- Plan deployment strategy (rolling, blue-green, canary)
-- Consider monitoring and alerting needs
-- Plan secret management approach
-
-**Ready for Code when:**
-
-- [ ] Pipeline architecture is documented
-- [ ] Deployment strategy is chosen and justified
-- [ ] Infrastructure requirements are identified
-- [ ] Monitoring approach is defined
-
-### Code Stage
-
-**Focus:** Implement CI/CD pipelines and infrastructure as code. Follow best
-practices for containerization and deployment automation.
-
-**Activities:**
-
-- Configure CI/CD pipeline stages
-- Implement infrastructure as code (Terraform, CloudFormation)
-- Create Dockerfiles with security best practices
-- Set up monitoring and alerting
-- Configure secret management
-- Implement deployment automation
-
-**Ready for Review when:**
-
-- [ ] Pipeline runs on every commit
-- [ ] Tests run before deployment
-- [ ] Deployments are automated
-- [ ] Infrastructure is version controlled
-- [ ] Secrets are managed securely
-- [ ] Monitoring is in place
-
-### Review Stage
-
-**Focus:** Verify pipeline reliability, security, and operational readiness.
-Ensure rollback procedures work and documentation is complete.
-
-**Activities:**
-
-- Verify pipeline runs successfully end-to-end
-- Test rollback procedures
-- Review security configurations
-- Validate monitoring and alerts
-- Check documentation completeness
-
-**Ready for Complete when:**
-
-- [ ] Pipeline is tested and reliable
-- [ ] Rollback procedure is documented and tested
-- [ ] Alerts are configured and tested
-- [ ] Runbooks exist for common issues
-
-## Reference
-
-## CI/CD Pipeline Stages
-
-### Build
-
-- Install dependencies
-- Compile/transpile code
-- Generate artifacts
-- Cache dependencies for speed
-
-### Test
-
-- Run unit tests
-- Run integration tests
-- Static analysis and linting
-- Security scanning
-
-### Deploy
-
-- Deploy to staging environment
-- Run smoke tests
-- Deploy to production
-- Verify deployment health
-
-## Infrastructure as Code
-
-### Terraform
-
-```hcl
-# Define resources declaratively
-resource "aws_instance" "example" {
-  ami           = "ami-0c55b159cbfafe1f0"
-  instance_type = "t2.micro"
-}
-```
-
-### Docker
-
-```dockerfile
-FROM node:18-alpine
-WORKDIR /app
-COPY package*.json ./
-RUN npm ci --only=production
-COPY . .
-CMD ["node", "server.js"]
-```
-
-## Deployment Strategies
-
-### Rolling Deployment
-
-- Gradual replacement of instances
-- Zero downtime
-- Easy rollback
-
-### Blue-Green Deployment
-
-- Two identical environments
-- Switch traffic atomically
-- Fast rollback
-
-### Canary Deployment
-
-- Route small percentage to new version
-- Monitor for issues
-- Gradually increase traffic

package/examples/agents/.claude/skills/full-stack-development/SKILL.md

@@ -1,134 +0,0 @@
----
-name: full-stack-development
-description: |
-  Guide for building complete solutions across the full technology stack.
-  Use when asked to implement features spanning frontend, backend, database,
-  and infrastructure layers.
----
-
-# Full-Stack Development
-
-## Stage Guidance
-
-### Plan Stage
-
-**Focus:** Design the full-stack solution architecture. Define API contracts and
-plan layer interactions.
-
-**Activities:**
-
-- Define the API contract first
-- Plan frontend and backend responsibilities
-- Design database schema
-- Plan infrastructure requirements
-
-**Ready for Code when:**
-
-- [ ] API contract is defined
-- [ ] Layer responsibilities are clear
-- [ ] Database schema is planned
-- [ ] Infrastructure approach is decided
-
-### Code Stage
-
-**Focus:** Build vertically—complete one feature end-to-end before starting
-another. Validates assumptions early.
-
-**Activities:**
-
-- Implement API endpoints
-- Build frontend integration
-- Create database schema and queries
-- Configure infrastructure as needed
-- Test across layers
-
-**Ready for Review when:**
-
-- [ ] Frontend connects to backend correctly
-- [ ] Database schema supports the feature
-- [ ] Error handling spans all layers
-- [ ] Feature works end-to-end
-- [ ] Deployment is automated
-
-### Review Stage
-
-**Focus:** Verify integration across layers and ensure deployment readiness.
-
-**Activities:**
-
-- Test integration across all layers
-- Verify error handling end-to-end
-- Check deployment configuration
-- Review documentation
-
-**Ready for Complete when:**
-
-- [ ] Integration tests pass
-- [ ] Deployment verified
-- [ ] Documentation is complete
-- [ ] Feature is production-ready
-
-## Reference
-
-## Technology Stack
-
-### Primary Languages
-
-- **JavaScript/TypeScript**: Frontend and Node.js backend
-- **Python**: Backend APIs and data processing
-
-### Infrastructure
-
-- **Terraform**: Cloud infrastructure as code
-- **CloudFormation**: AWS-specific infrastructure
-- **Docker**: Containerization
-
-## Layer Responsibilities
-
-### Frontend
-
-- User interface and experience
-- Client-side validation
-- API integration
-- State management
-
-### Backend API
-
-- Business logic
-- Data validation
-- Authentication/authorization
-- External service integration
-
-### Database
-
-- Data persistence
-- Query optimization
-- Schema migrations
-- Data integrity
-
-### Infrastructure
-
-- Deployment pipelines
-- Environment configuration
-- Scaling and reliability
-- Monitoring and logging
-
-## Development Process
-
-### 1. Start with the Interface
-
-- Define the API contract first
-- Frontend and backend can work in parallel
-- Clear interface = fewer integration issues
-
-### 2. Build Vertically
-
-- Complete one feature end-to-end before starting another
-- Validates assumptions early
-- Delivers demonstrable progress
-
-### 3. Test Across Layers
-
-- Unit tests per layer
-- Integration tests across layers
-- End-to-end tests for critical paths

package/examples/agents/.claude/skills/sre-practices/SKILL.md

@@ -1,163 +0,0 @@
----
-name: sre-practices
-description: |
-  Guide for ensuring system reliability through observability, incident
-  response, and capacity planning. Use when designing monitoring, handling
-  incidents, setting SLOs, or improving system resilience.
----
-
-# Site Reliability Engineering
-
-## Stage Guidance
-
-### Plan Stage
-
-**Focus:** Define reliability requirements, SLIs/SLOs, and observability
-strategy. Plan for resilience and capacity needs.
-
-**Activities:**
-
-- Define SLIs for key user journeys
-- Set SLOs with stakeholder agreement
-- Plan observability strategy (metrics, logs, traces)
-- Identify failure modes and resilience patterns
-- Define alerting thresholds
-
-**Ready for Code when:**
-
-- [ ] SLIs defined for key user journeys
-- [ ] SLOs set with stakeholder agreement
-- [ ] Monitoring strategy is planned
-- [ ] Failure modes are identified
-- [ ] Alerting thresholds are defined
-
-### Code Stage
-
-**Focus:** Implement observability, resilience patterns, and operational
-tooling. Build systems that fail gracefully and recover quickly.
-
-**Activities:**
-
-- Implement metrics, logging, and tracing
-- Configure alerts based on SLOs
-- Implement resilience patterns (timeouts, retries, circuit breakers)
-- Create runbooks for common issues
-- Set up error budget tracking
-
-**Ready for Review when:**
-
-- [ ] Comprehensive monitoring is in place
-- [ ] Alerts are actionable and low-noise
-- [ ] Resilience patterns are implemented
-- [ ] Runbooks exist for common issues
-- [ ] Error budget tracking is in place
-
-### Review Stage
-
-**Focus:** Verify reliability implementation meets SLOs and operational
-readiness. Ensure incident response procedures are in place.
-
-**Activities:**
-
-- Validate SLOs are measurable
-- Test failure scenarios
-- Review runbook completeness
-- Verify incident response procedures
-- Check alert quality and coverage
-
-**Ready for Complete when:**
-
-- [ ] SLOs are measurable and validated
-- [ ] Failure scenarios are tested
-- [ ] Incident response process documented
-- [ ] Post-mortem culture established
-- [ ] Disaster recovery approach is tested
-
-## Reference
-
-## Service Level Concepts
-
-### SLI (Service Level Indicator)
-
-Quantitative measure of service behavior:
-
-- Request latency (p50, p95, p99)
-- Error rate (% of failed requests)
-- Availability (% of successful requests)
-- Throughput (requests per second)
-
-### SLO (Service Level Objective)
-
-Target value for an SLI:
-
-- "99.9% of requests complete in < 200ms"
-- "Error rate < 0.1% over 30 days"
-- "99.95% availability monthly"
-
-### Error Budget
-
-Allowed unreliability: 100% - SLO
-
-- 99.9% SLO = 0.1% error budget
-- ~43 minutes downtime per month
-- Spend on features or reliability
-
-## Observability
-
-### Three Pillars
-
-- **Metrics**: Aggregated numeric data (counters, gauges, histograms)
-- **Logs**: Discrete event records with context
-- **Traces**: Request flow across services
-
-### Alerting Principles
-
-- Alert on symptoms, not causes
-- Every alert should be actionable
-- Reduce noise ruthlessly
-- Page only for user-impacting issues
-- Use severity levels appropriately
-
-## Incident Response
-
-### Incident Lifecycle
-
-1. **Detection**: Automated alerts or user reports
-2. **Triage**: Assess severity and impact
-3. **Mitigation**: Stop the bleeding first
-4. **Resolution**: Fix the underlying issue
-5. **Post-mortem**: Learn and improve
-
-### During an Incident
-
-- Communicate early and often
-- Focus on mitigation before root cause
-- Document actions in real-time
-- Escalate when needed
-- Update stakeholders regularly
-
-## Post-Mortem Process
-
-### Blameless Culture
-
-- Focus on systems, not individuals
-- Assume good intentions
-- Ask "how did the system allow this?"
-- Share findings openly
-
-### Post-Mortem Template
-
-1. Incident summary
-2. Timeline of events
-3. Root cause analysis
-4. What went well
-5. What could be improved
-6. Action items with owners
-
-## Resilience Patterns
-
-- **Timeouts**: Don't wait forever
-- **Retries**: With exponential backoff
-- **Circuit breakers**: Fail fast when downstream is unhealthy
-- **Bulkheads**: Isolate failures
-- **Graceful degradation**: Partial functionality over total failure

package/examples/agents/.claude/skills/technical-debt-management/SKILL.md

@@ -1,164 +0,0 @@
----
-name: technical-debt-management
-description: |
-  Guide for identifying, prioritizing, and addressing technical debt. Use
-  when assessing code quality issues, planning refactoring work, or making
-  build vs fix decisions.
----
-
-# Technical Debt Management
-
-## Stage Guidance
-
-### Plan Stage
-
-**Focus:** Assess technical debt and prioritize based on impact and effort.
-Decide whether to accept, defer, or address debt.
-
-**Activities:**
-
-- Identify and document technical debt
-- Assess impact and effort for each item
-- Prioritize using impact/effort matrix
-- Decide accept, defer, or address
-
-**Ready for Code when:**
-
-- [ ] Debt is documented with context
-- [ ] Impact and effort are assessed
-- [ ] Prioritization criteria are clear
-- [ ] Decision is documented
-
-### Code Stage
-
-**Focus:** Address debt incrementally while delivering features. Document
-intentional debt clearly.
-
-**Activities:**
-
-- Apply Boy Scout Rule (leave code better)
-- Refactor while adding features
-- Document new intentional debt
-- Track debt in backlog
-
-**Ready for Review when:**
-
-- [ ] Debt work is visible in planning
-- [ ] New debt is intentional and documented
-- [ ] Code quality improved where touched
-- [ ] Technical debt backlog updated
-
-### Review Stage
-
-**Focus:** Validate debt reduction and ensure new debt is intentional and
-documented.
-
-**Activities:**
-
-- Review debt reduction progress
-- Verify new debt is documented
-- Check debt backlog currency
-- Assess overall technical health
-
-**Ready for Complete when:**
-
-- [ ] Debt reduction validated
-- [ ] New debt justified and documented
-- [ ] Backlog is current
-- [ ] Metrics track debt trends
-
-## Reference
-
-## Types of Technical Debt
-
-### Code Debt
-
-- Duplicated code (DRY violations)
-- Complex, hard-to-understand code
-- Missing or inadequate tests
-- Inconsistent coding patterns
-- Dead or unused code
-
-### Architecture Debt
-
-- Tight coupling between components
-- Missing abstractions
-- Inappropriate technology choices
-- Scalability limitations
-- Security vulnerabilities
-
-### Dependency Debt
-
-- Outdated libraries and frameworks
-- Unsupported dependencies
-- Version conflicts
-- License compliance issues
-
-### Documentation Debt
-
-- Missing or outdated docs
-- Undocumented APIs
-- Tribal knowledge not captured
-- Stale comments in code
-
-## Debt Assessment
-
-### Impact Dimensions
-
-- **Velocity**: How much does it slow development?
-- **Risk**: What could go wrong?
-- **Scope**: How much code is affected?
-- **Effort**: How hard is it to fix?
-
-### Prioritization Matrix
-
-| Impact | Effort | Priority       |
-| ------ | ------ | -------------- |
-| High   | Low    | Do first       |
-| High   | High   | Plan carefully |
-| Low    | Low    | Quick wins     |
-| Low    | High   | Defer          |
-
-## Strategic Debt Decisions
-
-### When to Accept Debt
-
-- Time-to-market is critical
-- Requirements are uncertain
-- Short-lived code (prototypes, experiments)
-- Clear plan to address later
-- Business value justifies risk
-
-### When to Avoid Debt
-
-- Core system components
-- Security-sensitive code
-- High-change-frequency areas
-- No plan to address later
-- Debt compounds existing issues
-
-## Debt Reduction Strategies
-
-### Incremental Improvement
-
-- Boy Scout Rule: Leave code better than you found it
-- Refactor while adding features
-- Small, continuous improvements
-- Low risk, steady progress
-
-### Dedicated Investment
-
-- Scheduled refactoring sprints
-- Tech debt percentage in each sprint
-- Major rewrites when justified
-- Higher risk, larger improvements
-
-## Documentation Template
-
-For each debt item:
-
-- **Description**: What is the debt?
-- **Impact**: How does it affect us?
-- **Effort**: How hard to fix (T-shirt size)?
-- **Owner**: Who can address it?
-- **Plan**: When/how will it be fixed?