@forwardimpact/pathway 0.4.0 → 0.6.0

package/examples/agents/.github/agents/se-platform-review.agent.md

@@ -1,136 +0,0 @@
----
-name: se-platform-review
-description:
-  Verify & Ship agent for Software Engineering on Platform track. Builds and
-  maintains software systems, focusing on code quality, architecture, and
-  reliable delivery of business value. In the AI era, emphasizes verification
-  and review of AI-generated code.
-tools:
-  [
-    "search",
-    "search/codebase",
-    "search/grep",
-    "search/file",
-    "read",
-    "read/dir",
-    "terminal",
-    "git/changes",
-    "todo",
-  ]
-infer: true
-handoffs:
-  - label: Request Changes
-    agent: se-platform-code
-    prompt:
-      "Address the review feedback. Summarize what was completed in the Review
-      stage. Before starting, the Code stage requires: (1) Problem statement
-      documented, (2) Approach selected with rationale, (3) Implementation plan
-      exists. If critical items are missing, hand back to Review."
-    send: true
-  - label: Needs Replanning
-    agent: se-platform-plan
-    prompt:
-      "The implementation needs replanning. Summarize what was completed in the
-      Review stage."
-    send: true
----
-
-# Software Engineering - Platform - Review Agent
-
-Verify & Ship - Review, approve, deploy, document
-
-## Core Identity
-
-You are a Platform Software Engineer agent. Your primary focus is building
-self-service capabilities that enable other engineers.
-
-Developer experience is paramount. You design golden paths, maintain backward
-compatibility, and document everything. Code quality and architecture matter
-because your consumers depend on your stability.
-
-Every API change must consider developer experience. Treat breaking changes with
-extreme caution—your consumers build on your stability.
-
-Your primary capabilities:
-
-- Architecture & Design
-- Code Quality & Review
-- Full-Stack Development
-- Cloud Platforms
-- DevOps & CI/CD
-- Site Reliability Engineering
-
-Before making changes:
-
-1. Understand the existing architecture and patterns
-2. Identify test coverage requirements
-3. Consider backward compatibility implications
-4. Plan documentation updates
-
-## Delegation
-
-When facing tasks outside your expertise, use `runSubagent` to delegate:
-
-- Data modeling or statistical analysis → data science subagent
-- Security assessment or threat modeling → research subagent
-- Complex debugging across unfamiliar systems → research subagent
-
-Subagents run in isolated context. Provide clear task descriptions and specify
-what information to return.
-
-## Operational Context
-
-In this platform-focused role, you will build internal tooling and shared
-infrastructure that enables other engineering teams to be more productive. As
-part of the discovery-to-scale pipeline, you will receive validated patterns
-from Forward Deployed Engineers and generalize them into self-service platform
-capabilities. You will treat the platform as a product—conducting user research,
-building golden paths, and optimizing for developer experience.
-
-## Working Style
-
-### Consider the whole system
-
-For every change:
-
-1. Identify upstream and downstream impacts
-2. Consider non-functional requirements (performance, security)
-3. Document assumptions and trade-offs
-
-### Communicate with clarity
-
-When providing output:
-
-1. Separate blocking issues from suggestions
-2. Explain the "why" behind each recommendation
-3. Provide concrete examples or alternatives
-
-### Investigate before acting
-
-Before taking action:
-
-1. Confirm your understanding of the goal
-2. Identify unknowns that could affect the approach
-3. Research unfamiliar areas via subagent if needed
-
-## Return Format
-
-When completing work (for handoff or as a subagent), provide:
-
-1. **Work completed**: What was accomplished
-2. **Checklist status**: Items verified from Before Handoff section
-3. **Recommendation**: Ready for next stage, or needs more work
-
-## Constraints
-
-- Do not make code edits
-- Prioritize actionable feedback over exhaustive lists
-- Track findings and required changes with the todo tool
-- Committing code without running tests
-- Making changes without understanding the existing codebase
-- Ignoring error handling and edge cases
-- Over-engineering simple solutions
-- Maintain backward compatibility
-- Document breaking changes with migration guides
-- Test all changes against real consumer use cases
-- Design for Day 50, not just Day 1

package/examples/agents/.vscode/settings.json

@@ -1,8 +0,0 @@
-{
-  "chat.agent.enabled": true,
-  "chat.agent.maxRequests": 999,
-  "chat.edits2.enabled": true,
-  "chat.extensionUnification.enabled": true,
-  "chat.customAgentInSubagent.enabled": true,
-  "chat.useAgentSkills": true
-}

package/examples/behaviours/_index.yaml

@@ -1,8 +0,0 @@
-# Auto-generated index for browser loading
-# Do not edit manually - regenerate with: npx pathway --generate-index
-files:
-  - outcome_ownership
-  - polymathic_knowledge
-  - precise_communication
-  - relentless_curiosity
-  - systems_thinking

package/examples/behaviours/outcome_ownership.yaml

@@ -1,43 +0,0 @@
-# yaml-language-server: $schema=https://schema.forwardimpact.team/json/behaviour.schema.json
-
-name: Own the Outcome
-human:
-  description:
-    Business outcomes trump engineering elegance. Embrace extreme ownership of
-    what you build—not just code quality, but business relationships, impact
-    metrics, and end-to-end results. Accept technical debt when it enables
-    faster business value, but own the consequences. AI may generate the code,
-    but responsibility for outcomes remains with you.
-  maturityDescriptions:
-    emerging:
-      Takes responsibility for assigned tasks with supervision; follows through
-      when reminded; asks for help appropriately; understands that work serves
-      business goals
-    developing:
-      Owns task completion independently; reviews AI-generated code critically;
-      makes pragmatic trade-offs between speed and polish; takes responsibility
-      for understanding code before shipping; considers business impact of
-      technical decisions
-    practicing:
-      Takes end-to-end ownership of features and business outcomes; accepts
-      technical debt intentionally when it accelerates value; builds trust
-      through rapid delivery of working solutions; owns stakeholder
-      relationships; balances quality with delivery speed
-    role_modeling:
-      Drives accountability culture focused on outcomes not deliverables; owns
-      business relationships and impact metrics across their function; makes
-      trade-offs between custom solutions and generalizable work; there is no "I
-      must run this by X"; ensures verification rigor for AI-generated code
-    exemplifying:
-      Defines organizational accountability standards focused on business
-      impact; shapes industry practices around outcome ownership in the AI era;
-      sponsors transformational initiatives with full outcome accountability;
-      recognized externally for ownership culture leadership
-
-agent:
-  title: Own the outcome end-to-end
-  workingStyle: |
-    At each step:
-    1. Define success criteria before starting
-    2. Verify the change achieves the criteria
-    3. Don't hand off until you've validated the work

package/examples/behaviours/polymathic_knowledge.yaml

@@ -1,41 +0,0 @@
-# yaml-language-server: $schema=https://schema.forwardimpact.team/json/behaviour.schema.json
-
-name: Be Polymath Oriented
-human:
-  description:
-    Depth of expertise combined with breadth across multiple domains. Go beyond
-    T-shaped, building knowledge that spans technology, business, science, and
-    the pharmaceutical domain. Like Jim Gray, who made better architectural
-    decisions by understanding business beyond his database expertise, see
-    connections others miss.
-  maturityDescriptions:
-    emerging:
-      Recognizes that problems benefit from cross-disciplinary insights; shows
-      interest in domains beyond immediate technical requirements
-    developing:
-      Applies knowledge from one domain to inform decisions in another; studies
-      adjacent fields like design, business, or science; begins learning domain
-      language of business partners
-    practicing:
-      Bridges gaps between engineering, design, business, and science; rapidly
-      immerses in new domains; speaks the language of Commercial, Manufacturing,
-      or R&D; makes better decisions by understanding broader context
-    role_modeling:
-      Champions cross-disciplinary learning; creates holistic solutions spanning
-      technical and business domains; embodies the Renaissance Engineer ideal;
-      translates specialized knowledge into accessible explanations; thinks like
-      a business insider
-    exemplifying:
-      Shapes organizational learning strategy across disciplines; recognized
-      industry thought leader bridging technology and business; advises
-      executive leadership on cross-functional strategy; publishes on polymathic
-      approaches to engineering; influences industry hiring and development
-      practices
-
-agent:
-  title: Apply cross-domain insight
-  workingStyle: |
-    When solving problems:
-    1. Draw on knowledge from multiple domains
-    2. Consider perspectives beyond pure technical implementation
-    3. Look for patterns that can be generalized

package/examples/behaviours/precise_communication.yaml

@@ -1,39 +0,0 @@
-# yaml-language-server: $schema=https://schema.forwardimpact.team/json/behaviour.schema.json
-
-name: Communicate with Precision
-human:
-  description:
-    In the age of AI, clarity becomes a superpower. Communicate with
-    precision—reducing ambiguity in specifications, requirements, and designs.
-    Natural language is inherently vague; AI can only generate accurate
-    solutions when given clear, unambiguous intent.
-  maturityDescriptions:
-    emerging:
-      Communicates basic technical concepts when prompted; participates in team
-      discussions; writes simple documentation
-    developing:
-      Writes clear documentation and specifications; reduces ambiguity in
-      requirements; crafts effective prompts for AI tools; adapts communication
-      style for different audiences
-    practicing:
-      Separates requirements, designs, and tasks with precision; enables AI to
-      generate accurate code through clear specifications; translates between
-      technical and business language; facilitates productive discussions
-    role_modeling:
-      Creates spec-driven development practices; mentors others on precise
-      communication; spans C-level executives to frontline workers; drives
-      clarity as a core value across their function; represents the organization
-      externally
-    exemplifying:
-      Shapes industry standards for technical communication; recognized
-      authority on spec-driven AI development; influences organizational
-      communication culture; publishes on precision in the AI era; keynotes at
-      industry conferences
-
-agent:
-  title: Communicate with clarity
-  workingStyle: |
-    When providing output:
-    1. Separate blocking issues from suggestions
-    2. Explain the "why" behind each recommendation
-    3. Provide concrete examples or alternatives

package/examples/behaviours/relentless_curiosity.yaml

@@ -1,37 +0,0 @@
-# yaml-language-server: $schema=https://schema.forwardimpact.team/json/behaviour.schema.json
-
-name: Don't Lose Your Curiosity
-human:
-  description:
-    The driving force behind learning and invention. Protect your instinct to
-    break things down and understand them deeply. Embrace an experimental spirit
-    that treats failure as a path to discovery, not a setback to avoid.
-  maturityDescriptions:
-    emerging:
-      Asks basic questions when prompted; shows interest in learning about
-      immediate tasks; willing to try new approaches
-    developing:
-      Regularly asks clarifying questions about "why" and "how"; explores
-      related topics with guidance; experiments without fear of failure;
-      investigates how AI tools work rather than using them blindly
-    practicing:
-      Proactively investigates root causes; experiments with new technologies
-      and AI capabilities; protects time for exploration; treats failure as
-      learning; discovers requirements through immersion in problem spaces
-    role_modeling:
-      Drives team curiosity through challenging questions; creates environments
-      where exploration and experimentation are encouraged; models problem
-      discovery orientation; seeks out ambiguity rather than avoiding it
-    exemplifying:
-      Shapes organizational culture around curiosity and continuous learning;
-      sponsors experimental initiatives across the organization; recognized
-      externally as a thought leader in problem discovery; influences industry
-      practices around innovation and exploration
-
-agent:
-  title: Investigate before acting
-  workingStyle: |
-    Before taking action:
-    1. Confirm your understanding of the goal
-    2. Identify unknowns that could affect the approach
-    3. Research unfamiliar areas via subagent if needed

package/examples/behaviours/systems_thinking.yaml

@@ -1,40 +0,0 @@
-# yaml-language-server: $schema=https://schema.forwardimpact.team/json/behaviour.schema.json
-
-name: Think in Systems
-human:
-  description:
-    The ability to see beyond individual components to understand how the entire
-    system behaves. Like understanding how reintroducing wolves to Yellowstone
-    transformed not just deer but rivers, engineers recognize that every
-    service, API, and queue is part of a larger whole—isolated changes ripple
-    across the system.
-  maturityDescriptions:
-    emerging:
-      Recognizes that systems have interconnected parts; considers immediate
-      dependencies in code; understands basic cause-and-effect
-    developing:
-      Identifies upstream and downstream impacts; uses observability tools to
-      trace requests across services; understands feedback loops; maps
-      dependencies before making changes
-    practicing:
-      Maps complex system interactions across technical and business domains;
-      anticipates cascading effects; designs systems that degrade gracefully;
-      understands how technology changes impact business operations
-    role_modeling:
-      Shapes systems design practices across their function; conducts chaos
-      engineering experiments; influences cross-team architecture decisions;
-      creates clarity from complexity; bridges technical systems with business
-      processes
-    exemplifying:
-      Defines organizational systems architecture principles; recognized
-      industry authority on complex systems; advises executive leadership on
-      systemic risks and opportunities; publishes thought leadership on systems
-      thinking in technology organizations
-
-agent:
-  title: Consider the whole system
-  workingStyle: |
-    For every change:
-    1. Identify upstream and downstream impacts
-    2. Consider non-functional requirements (performance, security)
-    3. Document assumptions and trade-offs

package/examples/capabilities/_index.yaml

@@ -1,8 +0,0 @@
-# Auto-generated index for browser loading
-# Do not edit manually - regenerate with: npx pathway --generate-index
-files:
-  - business
-  - delivery
-  - people
-  - reliability
-  - scale

package/examples/capabilities/business.yaml

@@ -1,189 +0,0 @@
-# yaml-language-server: $schema=https://schema.forwardimpact.team/json/capability.schema.json
-
-name: Business
-emoji: 💼
-displayOrder: 8
-description: |
-  Understanding and driving business value.
-  Includes domain knowledge, stakeholder management, strategic thinking,
-  and translating between technical and business contexts.
-professionalResponsibilities:
-  awareness:
-    Understand the business context for your assigned work and communicate
-    progress clearly when asked
-  foundational:
-    Connect your technical work to business outcomes, engage with stakeholders
-    to clarify requirements
-  working:
-    Translate business needs into technical solutions, manage stakeholder
-    expectations, and articulate technical decisions in business terms
-  practitioner:
-    Drive business outcomes through technical solutions across your area,
-    influence product roadmaps, and partner effectively with business
-    stakeholders
-  expert:
-    Shape technology-driven business strategy, represent technical perspective
-    at executive level, and be recognized as a bridge between engineering and
-    business
-managementResponsibilities:
-  awareness:
-    Understand business context and communicate team progress to stakeholders
-    with guidance
-  foundational:
-    Align team priorities with business objectives, manage stakeholder
-    relationships, and communicate team impact
-  working:
-    Translate business strategy into team objectives, own stakeholder
-    relationships, and ensure team delivers business value
-  practitioner:
-    Partner with business leaders to shape strategy for your area, influence
-    direction across teams, and deliver measurable business impact
-  expert:
-    Shape technology-driven business strategy, represent engineering at
-    executive level, and own strategic business outcomes
-skills:
-  - id: stakeholder_management
-    name: Stakeholder Management
-    isHumanOnly: true
-    human:
-      description:
-        Building relationships with and managing expectations of stakeholders
-        across the organization, from frontline workers to C-level executives
-      levelDescriptions:
-        awareness:
-          You identify key stakeholders for your work and communicate status
-          when asked. You understand that different stakeholders have different
-          needs.
-        foundational:
-          You proactively update stakeholders on progress, handle basic
-          expectation setting, and escalate concerns appropriately. You build
-          rapport with regular collaborators.
-        working:
-          You manage multiple stakeholders with different interests, navigate
-          conflicting priorities diplomatically, and build trust through
-          consistent delivery. You tailor communication to each audience.
-        practitioner:
-          You influence senior stakeholders effectively across your area, manage
-          complex stakeholder landscapes with competing agendas, build trust
-          rapidly with new stakeholders, and shield teams from organizational
-          friction.
-        expert:
-          You shape stakeholder practices across the business unit. You manage
-          executive relationships, represent engineering at the highest levels,
-          and are recognized for exceptional stakeholder partnerships.
-  - id: technical_writing
-    name: Technical Writing
-    human:
-      description:
-        Creating clear, accurate, and useful technical documentation. Good specs
-        enable AI to generate accurate solutions; poor specs lead to poor
-        results.
-      levelDescriptions:
-        awareness:
-          You document your own work following team templates and standards. You
-          keep code comments current and write basic README content.
-        foundational:
-          You write clear READMEs, inline documentation, and technical guides.
-          You update existing docs when making changes and ensure documentation
-          matches implementation.
-        working:
-          You create comprehensive documentation for complex systems. You write
-          precise specifications that enable accurate AI-generated code,
-          establish documentation practices for your projects, and ensure docs
-          are discoverable.
-        practitioner:
-          You define documentation standards across teams in your area, create
-          documentation systems and templates, train engineers on spec-driven
-          development, and ensure documentation quality across projects.
-        expert:
-          You shape documentation culture and standards across the business
-          unit. You innovate on documentation approaches, are recognized for
-          exceptional technical writing clarity, and lead documentation
-          initiatives.
-    agent:
-      name: technical-writing
-      description: Guide for creating clear technical documentation.
-      useWhen: |
-        Writing READMEs, API docs, specifications, or any technical content
-        that needs to be clear and accurate.
-      stages:
-        specify:
-          focus: |
-            Define documentation requirements and audience needs.
-            Clarify what the documentation must accomplish.
-          activities:
-            - Identify target audience and their skill level
-            - Document what questions the docs must answer
-            - Define documentation type (README, API, spec, tutorial)
-            - Specify accuracy and completeness requirements
-            - Mark ambiguities with [NEEDS CLARIFICATION]
-          ready:
-            - Audience is identified
-            - Questions to answer are documented
-            - Documentation type is chosen
-            - Requirements are clear
-        plan:
-          focus: Understanding audience and planning documentation
-          activities:
-            - Identify target audience and their needs
-            - Determine document type and structure
-            - List prerequisites and assumptions
-            - Outline key sections and content
-          ready:
-            - Audience is identified
-            - Document type and structure planned
-            - Prerequisites listed
-            - Outline complete
-        code:
-          focus: Writing clear and accurate documentation
-          activities:
-            - Write using simple, direct language
-            - Structure content for scanning
-            - Include tested, runnable examples
-            - Define technical terms
-          ready:
-            - Purpose clear in first paragraph
-            - Examples are tested and work
-            - Technical terms are defined
-            - Structure supports scanning
-        review:
-          focus: Verifying documentation quality
-          activities:
-            - Check accuracy against implementation
-            - Verify examples are runnable
-            - Review for clarity and completeness
-            - Test with target audience if possible
-          ready:
-            - Documentation matches implementation
-            - All examples verified working
-            - No ambiguous pronouns
-            - Structure is logical and complete
-        deploy:
-          focus: |
-            Publish documentation and ensure it reaches the audience.
-            Set up maintenance process.
-          activities:
-            - Publish to documentation site
-            - Announce to relevant teams
-            - Add to search indexes and navigation
-            - Establish update and review schedule
-          ready:
-            - Documentation is published and accessible
-            - Audience can discover and find it
-            - Search and navigation are updated
-            - Maintenance schedule is established
-    implementationReference: |
-      ## Document Types
-
-      | Type | Purpose | Key Sections |
-      |------|---------|--------------|
-      | README | Project overview | Description, Getting Started, Usage |
-      | API Docs | API reference | Endpoints, Parameters, Examples |
-      | Spec | Design proposal | Problem, Solution, Alternatives |
-      | Tutorial | Learning guide | Objective, Steps, Outcomes |
-
-      ## Writing Principles
-      - Use simple, direct language
-      - One idea per sentence
-      - Active voice over passive
-      - Lead with most important info