@forwardimpact/pathway 0.1.0

package/examples/agents/.claude/skills/knowledge-management/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: knowledge-management
+description: |
+  Guide for capturing, organizing, and sharing organizational knowledge.
+  Use when creating knowledge bases, organizing documentation, reducing
+  knowledge silos, or establishing knowledge sharing practices.
+---
+
+# Knowledge Management
+
+## When to use this skill
+
+Use this skill when:
+
+- Creating or organizing knowledge bases
+- Documenting institutional knowledge
+- Reducing single-person dependencies
+- Establishing knowledge sharing practices
+- Making information discoverable
+
+## Knowledge Capture
+
+### What to Document
+
+- **Decisions**: Why we chose X over Y
+- **Context**: What we knew when we decided
+- **Procedures**: How to do recurring tasks
+- **Troubleshooting**: Common problems and solutions
+- **Architecture**: How systems work and why
+
+### When to Capture
+
+- After making significant decisions
+- After solving novel problems
+- Before someone leaves or changes roles
+- When you explain something more than twice
+- During incident post-mortems
+
+## Knowledge Organization
+
+### Structure Principles
+
+- Organize by task, not by team
+- Use consistent naming conventions
+- Create clear navigation paths
+- Link related content together
+- Maintain a clear hierarchy
+
+### Discoverability
+
+- Searchable titles and headings
+- Keywords and tags for filtering
+- Landing pages for major topics
+- Recently updated sections visible
+- Cross-linking between related docs
+
+## Knowledge Maintenance
+
+### Keep Current
+
+- Review docs when code changes
+- Date-stamp time-sensitive content
+- Archive rather than delete outdated info
+- Assign ownership for key documents
+- Schedule periodic review cycles
+
+### Quality Standards
+
+- Clear ownership for each document
+- Last-updated dates visible
+- Contact for questions listed
+- Review schedule defined
+- Deprecation process documented
+
+## Reducing Knowledge Silos
+
+### Identify Risks
+
+- Single points of knowledge failure
+- Undocumented tribal knowledge
+- Expertise concentrated in individuals
+- Critical processes in one person's head
+
+### Mitigation Strategies
+
+- Pair programming and shadowing
+- Recorded walkthroughs for complex systems
+- Cross-training sessions
+- Written runbooks for critical processes
+- Regular knowledge sharing meetings
+
+## Knowledge Management Checklist
+
+- [ ] Key decisions are documented with rationale
+- [ ] Procedures are written and discoverable
+- [ ] No critical single-person dependencies
+- [ ] Documentation ownership is clear
+- [ ] Content is regularly reviewed and updated
+- [ ] New team members can self-serve information
+- [ ] Search finds relevant content quickly

package/examples/agents/.claude/skills/pattern-generalization/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: pattern-generalization
+description: |
+  Guide for extracting reusable patterns from specific solutions. Use when
+  identifying candidates for generalization, designing abstractions, or
+  building platform capabilities from field-validated solutions.
+---
+
+# Pattern Generalization
+
+## When to use this skill
+
+Use this skill when:
+
+- Identifying solutions that could benefit other teams
+- Extracting reusable components from custom code
+- Designing abstractions for common patterns
+- Building platform capabilities from field solutions
+- Deciding when to generalize vs keep custom
+
+## Generalization Criteria
+
+### When to Generalize
+
+- Pattern appears in 3+ implementations
+- Solution has been validated in production
+- Multiple teams would benefit
+- Core logic is stable and understood
+- Customization needs are well-defined
+
+### When to Keep Custom
+
+- Only one team needs it
+- Requirements are still evolving
+- Context is highly specific
+- Generalization cost exceeds benefit
+- Speed to market is critical
+
+## Abstraction Design
+
+### Principles
+
+- Solve the common case simply
+- Allow escape hatches for edge cases
+- Make the right thing easy, wrong thing possible
+- Prefer composition over configuration
+- Hide complexity, expose simplicity
+
+### Trade-offs
+
+- **Flexibility vs Simplicity**: More options = more complexity
+- **Generality vs Performance**: Generic solutions may be slower
+- **Reusability vs Fit**: Shared code may not fit any use case perfectly
+- **Maintainability vs Features**: More features = more maintenance
+
+## Extraction Process
+
+### 1. Identify the Pattern
+
+- What's common across implementations?
+- What varies between uses?
+- What are the extension points?
+- What are the invariants?
+
+### 2. Design the Interface
+
+- Start with the simplest API that works
+- Make common cases one-liners
+- Provide sensible defaults
+- Document customization options
+
+### 3. Validate in New Context
+
+- Test with a different team/use case
+- Gather feedback on API usability
+- Identify missing flexibility
+- Refine based on real usage
+
+### 4. Document and Publish
+
+- Clear getting-started guide
+- Examples for common patterns
+- Migration guide from custom solutions
+- Support and contribution process
+
+## Generalization Anti-patterns
+
+- **Premature generalization**: Abstracting before understanding
+- **Kitchen sink**: Adding every possible feature
+- **Leaky abstraction**: Implementation details exposed
+- **Configuration overload**: Too many options to understand
+- **Orphaned abstraction**: No clear owner or support
+
+## Pattern Generalization Checklist
+
+- [ ] Pattern validated in multiple contexts
+- [ ] Clear benefit over custom solutions
+- [ ] Simple API for common cases
+- [ ] Extension points for customization
+- [ ] Documentation and examples ready
+- [ ] Migration path from existing solutions
+- [ ] Ownership and support defined

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

@@ -0,0 +1,117 @@
+---
+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
+
+## When to use this skill
+
+Use this skill when:
+
+- Designing monitoring and alerting
+- Defining SLIs, SLOs, and error budgets
+- Handling or preparing for incidents
+- Conducting post-mortems
+- Planning for capacity and resilience
+
+## 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
+
+## SRE Checklist
+
+- [ ] SLIs defined for key user journeys
+- [ ] SLOs set with stakeholder agreement
+- [ ] Error budget tracking in place
+- [ ] Alerts are actionable and low-noise
+- [ ] Runbooks exist for common issues
+- [ ] Incident response process documented
+- [ ] Post-mortem culture established
+- [ ] Resilience patterns implemented

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

@@ -0,0 +1,123 @@
+---
+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
+
+## When to use this skill
+
+Use this skill when:
+
+- Identifying technical debt in codebases
+- Prioritizing debt for remediation
+- Deciding whether to take on new debt
+- Planning refactoring initiatives
+- Balancing debt work with feature delivery
+
+## 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?
+
+## Technical Debt Checklist
+
+- [ ] Debt is documented with context
+- [ ] Impact and effort are assessed
+- [ ] Prioritization criteria are clear
+- [ ] Debt work is visible in planning
+- [ ] New debt is intentional and documented
+- [ ] Regular reviews of debt backlog
+- [ ] Metrics track debt trends

package/examples/agents/.claude/skills/technical-writing/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: technical-writing
+description: |
+  Guide for creating clear technical documentation. Use when writing READMEs,
+  API docs, specifications, or any technical content that needs to be clear
+  and accurate.
+---
+
+# Technical Writing
+
+## When to use this skill
+
+Use this skill when:
+
+- Writing README files
+- Creating API documentation
+- Writing technical specifications
+- Documenting code and systems
+- Creating guides and tutorials
+
+## Writing Principles
+
+### Clarity First
+
+- Use simple, direct language
+- One idea per sentence
+- Active voice over passive
+- Avoid jargon unless defined
+- Be specific, not vague
+
+### Know Your Audience
+
+- What do they already know?
+- What do they need to accomplish?
+- What's their skill level?
+- What questions will they have?
+
+### Structure for Scanning
+
+- Lead with the most important information
+- Use headings and subheadings
+- Keep paragraphs short
+- Use lists for multiple items
+- Highlight key terms
+
+## Document Types
+
+### README
+
+- What is this project?
+- How do I get started?
+- How do I use it?
+- Where do I get help?
+
+### API Documentation
+
+- Endpoint description
+- Parameters and types
+- Request/response examples
+- Error codes and handling
+
+### Technical Specification
+
+- Problem statement
+- Proposed solution
+- Alternatives considered
+- Implementation plan
+
+### Tutorial
+
+- Clear learning objective
+- Prerequisites listed
+- Step-by-step instructions
+- Expected outcomes shown
+
+## README Template
+
+```markdown
+# Project Name
+
+Brief description of what this project does.
+
+## Getting Started
+
+### Prerequisites
+
+- Required software and versions
+
+### Installation
+
+Step-by-step installation instructions.
+
+### Quick Start
+
+Minimal example to get running.
+
+## Usage
+
+Common use cases with examples.
+
+## Contributing
+
+How to contribute to the project.
+
+## License
+
+License information.
+```
+
+## Code Examples
+
+Good examples are:
+
+- Complete and runnable
+- Minimal but realistic
+- Copy-pasteable
+- Annotated with comments
+- Tested and verified
+
+## Technical Writing Checklist
+
+- [ ] Purpose is clear in first paragraph
+- [ ] Audience is identified
+- [ ] Prerequisites are listed
+- [ ] Examples are tested and work
+- [ ] Technical terms are defined
+- [ ] Structure supports scanning
+- [ ] No ambiguous pronouns
+- [ ] Updated when code changes