@forwardimpact/schema 0.4.0 → 0.7.0

package/examples/capabilities/scale.yaml

@@ -2,7 +2,7 @@
 
 name: Scale
 emojiIcon: 📐
-displayOrder: 4
+ordinalRank: 4
 description: |
   Building systems that grow gracefully.
   Encompasses architecture, code quality, testing, performance,
@@ -80,49 +80,66 @@ skills:
           focus: |
             Define cloud infrastructure requirements and constraints.
             Clarify availability, security, and cost expectations.
-          activities:
+          readChecklist:
             - Document availability and reliability requirements
             - Identify security and compliance constraints
             - Specify cost budget and constraints
             - Define performance requirements (latency, throughput)
             - Mark ambiguities with [NEEDS CLARIFICATION]
-          ready:
+          confirmChecklist:
             - Availability requirements are documented
             - Security requirements are specified
             - Cost constraints are defined
             - Performance requirements are clear
         plan:
           focus: Selecting and designing cloud architecture
-          activities:
+          readChecklist:
             - Evaluate service options for the use case
             - Plan multi-AZ deployment for availability
             - Design IAM roles with least privilege
             - Estimate costs and plan resource sizing
-          ready:
+          confirmChecklist:
             - Service selection matches requirements
             - Architecture designed for availability
             - Security approach documented
             - Cost estimate prepared
+        onboard:
+          focus: |
+            Set up cloud development environment. Configure CLI tools,
+            authenticate with cloud provider, and verify infrastructure
+            tooling works.
+          readChecklist:
+            - Install cloud CLI tools (AWS CLI, Terraform)
+            - Configure cloud credentials and authentication
+            - Initialize Terraform workspace and providers
+            - Verify cloud account access and permissions
+            - Set up environment variables for cloud configuration
+          confirmChecklist:
+            - Cloud CLI authenticated and working
+            - Terraform initialized with correct providers
+            - IAM permissions verified for planned resources
+            - Environment variables configured securely
+            - Infrastructure as code directory structure created
         code:
           focus: Implementing cloud infrastructure and deployments
-          activities:
+          readChecklist:
             - Define infrastructure as code (Terraform/CloudFormation)
             - Configure security groups and network policies
             - Set up encryption at rest and in transit
             - Implement monitoring and alerting
-          ready:
+          confirmChecklist:
             - Infrastructure defined as code
             - Security groups properly configured
             - Encryption enabled for data
             - Monitoring and alerting in place
         review:
           focus: Validating cloud configuration and security
-          activities:
+          readChecklist:
             - Verify IAM follows least privilege
             - Check multi-AZ deployment
             - Validate cost controls are in place
             - Review security configuration
-          ready:
+          confirmChecklist:
             - IAM permissions are minimal
             - Multi-AZ deployment confirmed
             - Cost controls established
@@ -131,12 +148,12 @@ skills:
           focus: |
             Deploy cloud infrastructure and verify production readiness.
             Confirm failover and monitoring work correctly.
-          activities:
+          readChecklist:
             - Deploy infrastructure to production
             - Verify multi-AZ failover works
             - Confirm monitoring and alerting are operational
             - Validate cost tracking is in place
-          ready:
+          confirmChecklist:
             - Infrastructure deployed successfully
             - Failover tested in production
             - Monitoring is operational
@@ -197,49 +214,67 @@ skills:
           focus: |
             Define code quality requirements and review criteria.
             Clarify standards and acceptance criteria for the change.
-          activities:
+          readChecklist:
             - Identify applicable coding standards
             - Document quality acceptance criteria
             - Specify test coverage requirements
             - Define review depth based on risk level
             - Mark ambiguities with [NEEDS CLARIFICATION]
-          ready:
+          confirmChecklist:
             - Coding standards are identified
             - Quality criteria are documented
             - Test requirements are specified
             - Review approach matches risk level
         plan:
           focus: Planning for quality before implementation
-          activities:
+          readChecklist:
             - Review project coding conventions
             - Plan testing strategy for the feature
             - Identify edge cases to handle
             - Consider error handling approach
-          ready:
+          confirmChecklist:
             - Coding conventions understood
             - Testing strategy defined
             - Edge cases identified
             - Error handling planned
+        onboard:
+          focus: |
+            Set up code quality tooling. Configure linters, formatters,
+            testing frameworks, and pre-commit hooks for the project.
+          readChecklist:
+            - Install linter (ESLint for JS/TS, Ruff for Python)
+            - Install formatter (Prettier for JS/TS, Ruff for Python)
+            - Configure linter rules matching project standards
+            - Set up pre-commit hooks (husky/lint-staged or pre-commit)
+            - Install testing framework (Node.js test runner, pytest)
+            - Configure editor settings for format-on-save
+          confirmChecklist:
+            - Linter runs without configuration errors
+            - Formatter produces consistent output
+            - Pre-commit hooks catch style violations
+            - Test runner discovers and runs existing tests
+            - Editor integration works (format-on-save, inline errors)
+            - CI pipeline includes quality checks
         code:
           focus: Writing and testing quality code
-          activities:
+          readChecklist:
             - Follow project coding conventions
             - Write tests alongside implementation
             - Handle error conditions appropriately
             - Self-review before requesting review
-          ready:
+          confirmChecklist:
             - Code follows project conventions
             - Changes are covered by tests
             - Error handling is appropriate
             - Self-review completed
         review:
           focus: Verifying code quality and correctness
-          activities:
+          readChecklist:
             - Verify code does what it claims
             - Check test coverage is adequate
             - Evaluate maintainability
             - Ensure no code you don't understand
-          ready:
+          confirmChecklist:
             - Code compiles and passes all tests
             - No obvious security vulnerabilities
             - No unnecessary complexity
@@ -248,12 +283,12 @@ skills:
           focus: |
             Merge and deploy reviewed code. Verify quality checks pass
             in production pipeline.
-          activities:
+          readChecklist:
             - Merge approved changes
             - Verify CI pipeline passes
             - Monitor for issues after deployment
             - Document any lessons learned
-          ready:
+          confirmChecklist:
             - Code merged successfully
             - CI pipeline passes all checks
             - No regressions detected
@@ -306,49 +341,66 @@ skills:
           focus: |
             Define data requirements and access patterns.
             Clarify schema requirements before designing.
-          activities:
+          readChecklist:
             - Document data entities and relationships
             - Identify query patterns and access requirements
             - Specify consistency and performance requirements
             - Define data retention and compliance needs
             - Mark ambiguities with [NEEDS CLARIFICATION]
-          ready:
+          confirmChecklist:
             - Data entities are documented
             - Query patterns are identified
             - Performance requirements are specified
             - Compliance needs are clear
         plan:
           focus: Understanding data requirements and designing schema
-          activities:
+          readChecklist:
             - Gather data requirements and access patterns
             - Choose appropriate storage technology
             - Design normalized schema
             - Plan indexing strategy
-          ready:
+          confirmChecklist:
             - Requirements understood
             - Storage technology selected
             - Schema design documented
             - Index strategy planned
+        onboard:
+          focus: |
+            Set up the database environment. Install ORM/query tools,
+            configure database connections, and verify migration
+            tooling works.
+          readChecklist:
+            - Install database client and ORM (Prisma, SQLAlchemy)
+            - Configure database connection in .env file
+            - Start local database (Supabase, PostgreSQL, etc.)
+            - Initialize migration tooling and verify it connects
+            - Create database user with appropriate privileges
+          confirmChecklist:
+            - Database running locally and accepting connections
+            - ORM/client configured and connected
+            - Migration tooling initialized and working
+            - Test data can be seeded and queried
+            - Database credentials stored securely in .env
         code:
           focus: Implementing schema and migrations
-          activities:
+          readChecklist:
             - Create database migrations
             - Implement schema changes
             - Add indexes for query patterns
             - Write efficient queries
-          ready:
+          confirmChecklist:
             - Schema implemented correctly
             - Indexes support query patterns
             - Migrations are reversible
             - Queries are optimized
         review:
           focus: Validating schema design and performance
-          activities:
+          readChecklist:
             - Verify schema matches requirements
             - Check migration safety
             - Validate query performance
             - Review backward compatibility
-          ready:
+          confirmChecklist:
             - Schema meets requirements
             - Migrations tested on production-like data
             - Query performance acceptable
@@ -357,12 +409,12 @@ skills:
           focus: |
             Deploy schema changes to production safely.
             Verify data integrity and query performance.
-          activities:
+          readChecklist:
             - Run migrations in production
             - Verify data integrity after migration
             - Monitor query performance
             - Confirm rollback plan works
-          ready:
+          confirmChecklist:
             - Migration completed successfully
             - Data integrity verified
             - Performance meets requirements

package/examples/framework.yaml

@@ -6,6 +6,10 @@ tag: "#AcmeCorp"
 description: |
   A unified framework for human and AI collaboration in engineering. Define roles, track skills and behaviours, build career paths, and generate AI coding agents—all from the same coherent foundation. The pathway aligns human capabilities with AI assistance, enabling productive teams in the AI era.
 
+# Distribution configuration
+distribution:
+  siteUrl: https://pathway.example.com
+
 # Entity definitions for pages and chapters
 entityDefinitions:
   driver:
@@ -28,7 +32,7 @@ entityDefinitions:
 
   discipline:
     title: Disciplines
-    emojiIcon: "🔧"
+    emojiIcon: "🔬"
     description: |
       Engineering specializations that define T-shaped skill profiles. Each discipline specifies primary skills for deep expertise, secondary skills for supporting capabilities, and broad skills for general awareness. Disciplines answer the question: "What kind of engineer are you?"
 

package/examples/questions/behaviours/outcome_ownership.yaml

@@ -1,51 +1,228 @@
 # yaml-language-server: $schema=https://www.forwardimpact.team/schema/json/behaviour-questions.schema.json
 
-emerging:
-  - id: own_emerg_1
-    text: Describe a task you completed from start to finish.
-    lookingFor:
-      - Follow-through
-      - Basic accountability
-    expectedDurationMinutes: 5
-developing:
-  - id: own_dev_1
-    text: Tell me about a time when you took responsibility for a mistake.
-    lookingFor:
-      - Accountability
-      - Learning from errors
-    expectedDurationMinutes: 5
-practicing:
-  - id: own_pract_1
-    text:
-      Describe a project where you owned the entire lifecycle from design to
-      production support.
-    lookingFor:
-      - End-to-end ownership
-      - Operational responsibility
-    expectedDurationMinutes: 8
-role_modeling:
-  - id: own_role_1
-    text: How do you build a culture of ownership in your team?
-    lookingFor:
-      - Team accountability
-      - Systemic approaches
-    expectedDurationMinutes: 8
-exemplifying:
-  - id: own_exemp_1
-    text:
-      How do you establish and drive ownership culture across an entire
-      organization?
-    followUps:
-      - How do you balance ownership with collaboration?
-    lookingFor:
-      - Enterprise ownership culture
-      - Accountability at scale
-    expectedDurationMinutes: 10
-  - id: own_exemp_2
-    text:
-      How do you hold yourself and others accountable for outcomes at an
-      organizational level?
-    lookingFor:
-      - Executive-level accountability
-      - Systemic ownership practices
-    expectedDurationMinutes: 10
+professionalQuestions:
+  emerging:
+    - id: own_pro_emerg_1
+      text:
+        A feature you built last week is causing intermittent errors in
+        production. Your tech lead is in a meeting and unavailable for an hour.
+      context:
+        The errors affect about 5% of users and the on-call engineer has pinged
+        the team channel. You have access to logs and the deployment pipeline.
+        The feature was built using AI-generated code that you reviewed before
+        merging.
+      simulationPrompts:
+        - Walk me through your first steps when you see the alert
+        - How would you decide whether to roll back or investigate further?
+        - Who would you communicate with and what would you say?
+        - How would you document what happened for the team?
+      lookingFor:
+        - Takes immediate responsibility rather than waiting for direction
+        - Shows willingness to act within their capability
+        - Communicates status proactively even without being asked
+        - Understands the feature serves a business purpose beyond code
+      expectedDurationMinutes: 20
+
+  developing:
+    - id: own_pro_dev_1
+      text:
+        You shipped a feature using AI-generated code that passed all tests, but
+        a stakeholder reports it behaves differently than specified.
+      context:
+        The stakeholder is frustrated because they demoed the feature to a
+        client and it didn't work as expected. The AI tool generated a plausible
+        but subtly wrong implementation that your tests didn't catch.
+      simulationPrompts:
+        - How do you respond to the stakeholder's frustration?
+        - What do you do to understand the gap between spec and implementation?
+        - How do you decide between a quick patch and a proper fix?
+        - What would you change about your review process going forward?
+      lookingFor:
+        - Takes ownership of the gap rather than blaming the AI tool
+        - Reviews AI-generated code critically against the specification
+        - Makes pragmatic trade-offs between speed and correctness
+        - Considers how to prevent similar gaps in future
+      expectedDurationMinutes: 20
+
+  practicing:
+    - id: own_pro_pract_1
+      text:
+        A key integration your team owns is blocking a partner team's quarterly
+        release. The fix requires accepting significant technical debt.
+      context:
+        The partner team's release is worth £2M in annual revenue. A proper fix
+        would take 3 weeks; a pragmatic workaround takes 3 days but leaves known
+        limitations. You own the stakeholder relationship with the partner
+        team's lead.
+      simulationPrompts:
+        - How do you evaluate the trade-off between technical debt and business
+          value?
+        - Walk me through the conversation you'd have with the partner team lead
+        - How do you ensure the technical debt is tracked and eventually
+          addressed?
+        - How do you communicate the decision and its consequences to your team?
+      lookingFor:
+        - Owns the end-to-end business outcome, not just the code
+        - Accepts technical debt intentionally with clear reasoning
+        - Manages the stakeholder relationship with transparency
+        - Balances delivery speed with long-term quality
+      expectedDurationMinutes: 20
+
+  role_modeling:
+    - id: own_pro_role_1
+      text:
+        Two teams in your function disagree about who owns a cross-cutting
+        reliability issue. Incidents are recurring and both teams blame the
+        other.
+      context:
+        The issue has caused 3 incidents this month, each impacting customer
+        experience. Neither team has full visibility into the other's service.
+        You are a senior IC with credibility with both teams. Leadership is
+        starting to notice.
+      simulationPrompts:
+        - How do you approach the situation without formal authority?
+        - What would you do to establish clear ownership boundaries?
+        - How do you shift the conversation from blame to accountability?
+        - What systemic changes would you propose to prevent this pattern?
+      lookingFor:
+        - Drives accountability culture focused on outcomes not blame
+        - Takes ownership of the problem without formal responsibility
+        - Makes decisions without needing to escalate for permission
+        - Establishes verification rigor for cross-team boundaries
+      expectedDurationMinutes: 20
+
+  exemplifying:
+    - id: own_pro_exemp_1
+      text:
+        The organisation is adopting AI code generation at scale, but there is
+        no accountability framework for AI-generated code quality and outcomes.
+      context:
+        Several teams have shipped AI-generated features with defects not caught
+        in review. Leadership wants velocity but also accountability. You have
+        been asked to define the organizational approach.
+      simulationPrompts:
+        - How do you define accountability standards for AI-generated code?
+        - How do you balance velocity gains from AI with outcome ownership?
+        - What organizational structures would you put in place?
+        - How would you measure success of the accountability framework?
+      lookingFor:
+        - Defines organizational accountability standards for the AI era
+        - Shapes practices that scale beyond individual team behaviour
+        - Sponsors initiatives with full outcome accountability
+        - Takes an approach that could influence industry practices
+      expectedDurationMinutes: 20
+      followUps:
+        - How would you handle a team that resists the framework?
+
+managementQuestions:
+  emerging:
+    - id: own_mgmt_emerg_1
+      text:
+        A team member's task is overdue and they haven't raised it. You discover
+        this during standup where they say everything is "on track."
+      context:
+        The task was due yesterday and blocks another team member's work. The
+        team member is relatively new and you suspect they may be struggling but
+        don't want to appear incompetent. The sprint goal is at risk.
+      simulationPrompts:
+        - How do you address this in the moment without embarrassing them?
+        - What conversation do you have with them privately afterwards?
+        - How do you ensure the blocking dependency is resolved?
+        - What do you put in place to catch this earlier next time?
+      lookingFor:
+        - Ensures follow-through on delegated tasks
+        - Creates psychological safety while maintaining accountability
+        - Addresses both the immediate blocker and the underlying pattern
+        - Shows awareness of team accountability dynamics
+      expectedDurationMinutes: 20
+
+  developing:
+    - id: own_mgmt_dev_1
+      text:
+        A team member shipped code that caused a production incident. During the
+        post-mortem, other team members want to assign blame.
+      context:
+        The incident affected 200 users for 45 minutes. The code was reviewed
+        and approved by another team member before merge. The author is junior
+        and clearly upset. Your team has no established incident ownership
+        culture.
+      simulationPrompts:
+        - How do you run the post-mortem to keep it constructive?
+        - How do you coach the team member privately afterwards?
+        - What do you say to the team about shared accountability?
+        - How do you start building an ownership culture from this moment?
+      lookingFor:
+        - Creates safe space for ownership while addressing the incident
+        - Coaches individual accountability constructively
+        - Models shared ownership rather than individual blame
+        - Begins establishing team accountability patterns
+      expectedDurationMinutes: 20
+
+  practicing:
+    - id: own_mgmt_pract_1
+      text:
+        Your team consistently treats operational issues as "someone else's
+        problem" once features ship. The platform team is overwhelmed.
+      context:
+        Your team shipped 12 features this quarter with strong velocity, but
+        operational tickets have doubled. The platform team lead has escalated
+        to your manager. Your team sees themselves as "builders, not operators."
+      simulationPrompts:
+        - How do you shift the team from feature delivery to outcome ownership?
+        - What structural changes embed operational ownership?
+        - How do you have the conversation with the platform team lead?
+        - How do you measure and recognize end-to-end ownership?
+      lookingFor:
+        - Structures team around end-to-end ownership, not just features
+        - Balances autonomy with accountability for operational outcomes
+        - Builds clear ownership expectations with concrete mechanisms
+        - Takes responsibility for the team culture gap
+      expectedDurationMinutes: 20
+
+  role_modeling:
+    - id: own_mgmt_role_1
+      text:
+        A project you championed has missed its business targets after 6 months.
+        Technology works but adoption is far lower than projected.
+      context:
+        You estimated £500K in annual savings but actual savings are £120K.
+        Technical delivery was on time and on budget. The adoption gap is due to
+        change management issues outside your initial scope. Your peers are
+        distancing themselves from the project.
+      simulationPrompts:
+        - How do you own this outcome publicly with leadership?
+        - What do you do about the adoption gap specifically?
+        - How do you model accountability when the outcome isn't what you
+          projected?
+        - What would you do differently if starting again?
+      lookingFor:
+        - Models personal accountability publicly, including for indirect
+          outcomes
+        - Owns the business outcome, not just the technical delivery
+        - Takes action to close the gap rather than accepting current state
+        - Shows transparency about lessons learned
+      expectedDurationMinutes: 20
+
+  exemplifying:
+    - id: own_mgmt_exemp_1
+      text:
+        You need to establish ownership expectations across a function where
+        teams have very different accountability cultures.
+      context:
+        You lead a function of 8 teams (60+ engineers). Three teams have strong
+        ownership cultures, three are inconsistent, and two actively avoid
+        accountability. Recent reorgs mixed people from different cultures and
+        cross-team incidents are increasing.
+      simulationPrompts:
+        - How do you assess ownership maturity across teams?
+        - What organizational standards would you establish?
+        - How do you bring lower-performing teams up without bureaucracy?
+        - How do you handle managers who resist accountability expectations?
+      lookingFor:
+        - Establishes organizational accountability standards
+        - Takes a systemic approach rather than team-by-team fixing
+        - Balances accountability with psychological safety at scale
+        - Creates sustainable culture that survives personnel changes
+      expectedDurationMinutes: 20
+      followUps:
+        - How would you measure the impact of the ownership culture change?