@cubis/foundry 0.3.62 → 0.3.64

package/workflows/workflows/agent-environment-setup/shared/workflows/refactor.md

@@ -5,9 +5,17 @@ triggers: ["refactor", "cleanup", "maintainability", "debt", "modularize"]
 ---
 # Refactor Workflow
 
+# CHANGED: routing — added explicit refactor ownership and regression support — prevents fallback routing and makes the preservation strategy clear.
+# CHANGED: output contract — converted free-form bullets into structured YAML — makes invariant and parity reporting machine-readable.
+
 ## When to use
 Use this for design improvement without intentional behavior changes.
 
+## Routing
+- Primary specialist: `@code-archaeologist`
+- Domain implementation support: `@backend-specialist`
+- Regression verification: `@test-engineer`
+
 ## Context notes
 - This workflow file, active platform rules, and selected agents/skills guide execution.
 - Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
@@ -28,7 +36,18 @@ Use this for design improvement without intentional behavior changes.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Refactor scope and invariants
-- Structural changes
-- Behavior parity evidence
-- Deferred technical debt items
+```yaml
+REFACTOR_WORKFLOW_RESULT:
+  primary_agent: code-archaeologist
+  supporting_agents: [backend-specialist?, test-engineer?]
+  primary_skills: [refactor, legacy-modernizer]
+  supporting_skills: [architecture-designer?, code-reviewer?]
+  scope:
+    summary: <string>
+    invariants: [<string>]
+  structural_changes: [<string>]
+  behavior_parity_evidence: [<command or test>]
+  deferred_technical_debt: [<string>] | []
+  next_handoff:
+    plan_handoff: <PLAN_HANDOFF|null>
+```

package/workflows/workflows/agent-environment-setup/shared/workflows/release.md

@@ -5,6 +5,8 @@ triggers: ["release", "deploy", "rollout", "ship", "go-live"]
 ---
 # Release Workflow
 
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps release gates and monitoring plans machine-readable.
+
 ## When to use
 Use this before deployment to production-like environments.
 
@@ -34,7 +36,14 @@ Use this before deployment to production-like environments.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Release checklist status
-- Rollout strategy
-- Rollback conditions
-- Post-release monitoring plan
+```yaml
+RELEASE_WORKFLOW_RESULT:
+  primary_agent: devops-engineer
+  supporting_agents: [security-auditor?, test-engineer?, product-owner?]
+  primary_skills: [devops-engineer, sre-engineer]
+  supporting_skills: [monitoring-expert?, test-master?]
+  release_checklist_status: [<string>]
+  rollout_strategy: [<string>]
+  rollback_conditions: [<string>]
+  post_release_monitoring_plan: [<string>]
+```

package/workflows/workflows/agent-environment-setup/shared/workflows/review.md

@@ -5,6 +5,9 @@ triggers: ["review", "audit", "pr", "quality", "security review"]
 ---
 # Review Workflow
 
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps findings and remediation guidance machine-readable.
+# CHANGED: skill routing — added `skill-authoring` for skill package audits, metadata review, and sidecar repair work.
+
 ## When to use
 Use this for pull request or branch quality review.
 
@@ -20,7 +23,8 @@ Use this for pull request or branch quality review.
 
 ## Skill Routing
 - Primary skills: `code-reviewer`, `security-reviewer`
-- Supporting skills (optional): `semgrep`, `static-analysis`, `variant-analysis`
+- Supporting skills (optional): `skill-authoring`, `semgrep`, `static-analysis`, `variant-analysis`
+- For reviews that target a skill package itself, load `skill-authoring` before general analysis extras.
 
 ## Workflow steps
 1. Inspect changed behavior and risk surface.
@@ -34,7 +38,16 @@ Use this for pull request or branch quality review.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Findings ordered by severity
-- Affected files/areas
-- Recommended fixes
-- Residual risks after fixes
+```yaml
+REVIEW_WORKFLOW_RESULT:
+  primary_agent: code-archaeologist
+  supporting_agents: [frontend-specialist?, security-auditor?, test-engineer?]
+  primary_skills: [code-reviewer, security-reviewer]
+  supporting_skills: [semgrep?, static-analysis?, variant-analysis?]
+  findings:
+    - severity: <critical|high|medium|low>
+      summary: <string>
+      affected_areas: [<path-or-area>]
+      recommended_fix: <string>
+  residual_risks: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/shared/workflows/security.md

@@ -5,6 +5,8 @@ triggers: ["security", "vulnerability", "owasp", "auth", "hardening"]
 ---
 # Security Workflow
 
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps exploitability triage and remediation evidence machine-readable.
+
 ## When to use
 Use this when the task is primarily about security risk discovery, triage, or remediation.
 
@@ -33,7 +35,18 @@ Use this when the task is primarily about security risk discovery, triage, or re
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Findings by severity
-- Fix plan with owners
-- Verification evidence
-- Residual risk notes
+```yaml
+SECURITY_WORKFLOW_RESULT:
+  primary_agent: security-auditor
+  supporting_agents: [penetration-tester?, test-engineer?]
+  primary_skills: [security-reviewer, secure-code-guardian]
+  supporting_skills: [semgrep?, static-analysis?, variant-analysis?]
+  findings:
+    - severity: <critical|high|medium|low>
+      summary: <string>
+  fix_plan:
+    - owner: <agent-id>
+      action: <string>
+  verification_evidence: [<string>]
+  residual_risk_notes: [<string>] | []
+```

package/workflows/workflows/agent-environment-setup/shared/workflows/test.md

@@ -5,9 +5,17 @@ triggers: ["test", "verify", "coverage", "qa", "regression"]
 ---
 # Test Workflow
 
+# CHANGED: routing — added explicit verification owners — prevents route manifest fallback to orchestrator for test-focused requests.
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps test outcomes machine-readable for release gating.
+
 ## When to use
 Use this to drive confidence before merge or release.
 
+## Routing
+- Primary specialist: `@test-engineer`
+- Automation depth: `@qa-automation-engineer`
+- Failure triage: `@debugger`
+
 ## Context notes
 - This workflow file, active platform rules, and selected agents/skills guide execution.
 - Attach logs, screenshots, failing output, and relevant paths when context is incomplete.
@@ -28,7 +36,19 @@ Use this to drive confidence before merge or release.
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Coverage map (what was tested)
-- Test results summary
-- Remaining risk and gaps
-- Merge/release recommendation
+```yaml
+TEST_WORKFLOW_RESULT:
+  primary_agent: test-engineer
+  supporting_agents: [qa-automation-engineer?, debugger?]
+  primary_skills: [test-master, playwright-expert]
+  supporting_skills: [webapp-testing?, flutter-test-master?]
+  coverage_map: [<string>]
+  test_results:
+    passed: [<string>]
+    failed: [<string>] | []
+    flaky: [<string>] | []
+  residual_risk: [<string>] | []
+  recommendation: <merge|hold|release-ready|needs-follow-up>
+  next_handoff:
+    plan_handoff: <PLAN_HANDOFF|null>
+```

package/workflows/workflows/agent-environment-setup/shared/workflows/vercel.md

@@ -5,6 +5,8 @@ triggers: ["vercel", "deployment", "preview", "edge", "functions", "domains", "v
 ---
 # Vercel Workflow
 
+# CHANGED: output contract — converted free-form bullets into structured YAML — keeps Vercel platform changes and rollout notes machine-readable.
+
 ## When to use
 Use this workflow when the primary concern is Vercel platform behavior, deployment safety, or Vercel-specific automation.
 
@@ -34,7 +36,16 @@ Use this workflow when the primary concern is Vercel platform behavior, deployme
 - Note any gaps that were not validated.
 
 ## Output Contract
-- Config/code changes and affected Vercel components
-- Deployment and rollback notes
-- Security and observability impact
-- Verification evidence and follow-up items
+```yaml
+VERCEL_WORKFLOW_RESULT:
+  primary_agent: vercel-expert
+  supporting_agents: [devops-engineer?, security-auditor?, test-engineer?, qa-automation-engineer?]
+  primary_skills: [vercel-platform, vercel-runtime]
+  supporting_skills: [vercel-delivery?, vercel-security?, vercel-ai?, vercel-storage?]
+  affected_components: [<string>]
+  deployment_notes: [<string>]
+  rollback_notes: [<string>]
+  security_and_observability_impact: [<string>]
+  verification_evidence: [<string>]
+  follow_up_items: [<string>] | []
+```

package/workflows/skills/accessibility/POWER.md

@@ -1,103 +0,0 @@
----
-name: "accessibility"
-displayName: "Accessibility Expert"
-description: "Ensure Flutter apps meet WCAG 2.1 AA standards with proper semantics, focus management, and screen reader support"
-keywords:
-  [
-    "accessibility",
-    "a11y",
-    "wcag",
-    "semantics",
-    "screen reader",
-    "focus",
-    "contrast",
-    "flutter accessibility",
-  ]
----
-
-# Accessibility Expert
-
-## Overview
-
-This power helps you build accessible Flutter widgets that work well with screen readers (TalkBack/VoiceOver), keyboard navigation, and meet WCAG 2.1 AA standards.
-
-## When to Use
-
-- Building new UI screens or widgets
-- Reviewing code for accessibility compliance
-- Fixing accessibility issues reported by users
-- Adding semantic labels to icons and buttons
-- Implementing proper focus management in forms
-
-## Quick Reference
-
-### Semantic Labels for Icon Buttons
-
-```dart
-// ❌ Bad - no semantic label
-IconButton(
-  icon: Icon(Icons.delete),
-  onPressed: () => deleteItem(),
-)
-
-// ✅ Good - has semantic label
-Semantics(
-  label: 'Delete item',
-  button: true,
-  child: IconButton(
-    icon: Icon(Icons.delete),
-    onPressed: () => deleteItem(),
-  ),
-)
-```
-
-### Form Focus Management
-
-```dart
-// Create focus nodes
-final _emailFocus = FocusNode();
-final _passwordFocus = FocusNode();
-
-// Link them in text fields
-TextField(
-  focusNode: _emailFocus,
-  textInputAction: TextInputAction.next,
-  onSubmitted: (_) => _passwordFocus.requestFocus(),
-)
-
-TextField(
-  focusNode: _passwordFocus,
-  textInputAction: TextInputAction.done,
-  onSubmitted: (_) => _submitForm(),
-)
-```
-
-### Minimum Touch Target Size
-
-```dart
-// Ensure 48x48 minimum for interactive elements
-SizedBox(
-  width: 48,
-  height: 48,
-  child: IconButton(...),
-)
-```
-
-## Key Principles
-
-1. **Semantic Labels**: All icon buttons, images, and non-text elements need labels
-2. **Focus Order**: Tab order should follow visual/logical flow
-3. **Touch Targets**: Minimum 48x48 dp for all interactive elements
-4. **Color Contrast**: Text must have 4.5:1 contrast ratio (3:1 for large text)
-5. **Screen Reader**: Test with TalkBack (Android) and VoiceOver (iOS)
-
-## Steering Files
-
-Load detailed guidance:
-- `a11y_checklist.md` - Complete accessibility checklist for reviews
-
-## Templates
-
-- `focus_form` - Form with proper focus management
-- `semantics_icon_button` - Icon button with semantic labels
-

package/workflows/skills/api-designer/POWER.md

@@ -1,108 +0,0 @@
----
-name: api-designer
-displayName: Api Designer
-description:
-  Use when designing REST or GraphQL APIs, creating OpenAPI specifications,
-  or planning API architecture. Invoke for resource modeling, versioning strategies,
-  pagination patterns, error handling standards.
-keywords:
-  - API design
-  - REST API
-  - OpenAPI
-  - API specification
-  - API architecture
-  - resource modeling
-  - API versioning
-  - GraphQL schema
-  - API documentation
-author: OneUp
----
-
-# API Designer
-
-## Overview
-
-Senior API architect with expertise in designing scalable, developer-friendly REST and GraphQL APIs with comprehensive OpenAPI specifications.
-
-## Role Definition
-
-You are a senior API designer with 10+ years of experience creating intuitive, scalable API architectures. You specialize in REST design patterns, OpenAPI 3.1 specifications, GraphQL schemas, and creating APIs that developers love to use while ensuring performance, security, and maintainability.
-
-## When to Use This Skill
-
-- Designing new REST or GraphQL APIs
-- Creating OpenAPI 3.1 specifications
-- Modeling resources and relationships
-- Implementing API versioning strategies
-- Designing pagination and filtering
-- Standardizing error responses
-- Planning authentication flows
-- Documenting API contracts
-
-## Core Workflow
-
-1. **Analyze domain** - Understand business requirements, data models, client needs
-2. **Model resources** - Identify resources, relationships, operations
-3. **Design endpoints** - Define URI patterns, HTTP methods, request/response schemas
-4. **Specify contract** - Create OpenAPI 3.1 spec with complete documentation
-5. **Plan evolution** - Design versioning, deprecation, backward compatibility
-
-## Available Steering Files
-
-Load detailed guidance on-demand:
-
-| Topic          | Reference                    | Load When                                   |
-| -------------- | ---------------------------- | ------------------------------------------- |
-| REST Patterns  | `references/rest-patterns.md`  | Resource design, HTTP methods, HATEOAS      |
-| Versioning     | `references/versioning.md`     | API versions, deprecation, breaking changes |
-| Pagination     | `references/pagination.md`     | Cursor, offset, keyset pagination           |
-| Error Handling | `references/error-handling.md` | Error responses, RFC 7807, status codes     |
-| OpenAPI        | `references/openapi.md`        | OpenAPI 3.1, documentation, code generation |
-
-## Constraints
-
-### MUST DO
-
-- Follow REST principles (resource-oriented, proper HTTP methods)
-- Use consistent naming conventions (snake_case or camelCase)
-- Include comprehensive OpenAPI 3.1 specification
-- Design proper error responses with actionable messages
-- Implement pagination for collection endpoints
-- Version APIs with clear deprecation policies
-- Document authentication and authorization
-- Provide request/response examples
-
-### MUST NOT DO
-
-- Use verbs in resource URIs (use `/users/{id}`, not `/getUser/{id}`)
-- Return inconsistent response structures
-- Skip error code documentation
-- Ignore HTTP status code semantics
-- Design APIs without versioning strategy
-- Expose implementation details in API
-- Create breaking changes without migration path
-- Omit rate limiting considerations
-
-## Output Templates
-
-When designing APIs, provide:
-
-1. Resource model and relationships
-2. Endpoint specifications with URIs and methods
-3. OpenAPI 3.1 specification (YAML or JSON)
-4. Authentication and authorization flows
-5. Error response catalog
-6. Pagination and filtering patterns
-7. Versioning and deprecation strategy
-
-## Knowledge Reference
-
-REST architecture, OpenAPI 3.1, GraphQL, HTTP semantics, JSON:API, HATEOAS, OAuth 2.0, JWT, RFC 7807 Problem Details, API versioning patterns, pagination strategies, rate limiting, webhook design, SDK generation
-
-## Related Powers
-
-- **GraphQL Architect** - GraphQL-specific API design
-- **FastAPI Expert** - Python API implementation
-- **NestJS Expert** - TypeScript API implementation
-- **Spring Boot Engineer** - Java API implementation
-- **Security Reviewer** - API security assessment

package/workflows/skills/architecture-designer/POWER.md

@@ -1,96 +0,0 @@
----
-name: architecture-designer
-displayName: Architecture Designer
-description:
-  Use when designing new system architecture, reviewing existing designs,
-  or making architectural decisions. Invoke for system design, architecture review,
-  design patterns, ADRs, scalability planning.
-keywords:
-  - architecture
-  - system design
-  - design pattern
-  - microservices
-  - scalability
-  - ADR
-  - technical design
-  - infrastructure
-author: OneUp
----
-
-# Architecture Designer
-
-## Overview
-
-Senior software architect specializing in system design, design patterns, and architectural decision-making.
-
-## Role Definition
-
-You are a principal architect with 15+ years of experience designing scalable systems. You specialize in distributed systems, cloud architecture, and making pragmatic trade-offs. You document decisions with ADRs and consider long-term maintainability.
-
-## When to Use This Skill
-
-- Designing new system architecture
-- Choosing between architectural patterns
-- Reviewing existing architecture
-- Creating Architecture Decision Records (ADRs)
-- Planning for scalability
-- Evaluating technology choices
-
-## Core Workflow
-
-1. **Understand requirements** - Functional, non-functional, constraints
-2. **Identify patterns** - Match requirements to architectural patterns
-3. **Design** - Create architecture with trade-offs documented
-4. **Document** - Write ADRs for key decisions
-5. **Review** - Validate with stakeholders
-
-## Available Steering Files
-
-Load detailed guidance on-demand:
-
-| Topic                 | Reference                           | Load When                             |
-| --------------------- | ----------------------------------- | ------------------------------------- |
-| Architecture Patterns | `references/architecture-patterns.md` | Choosing monolith vs microservices    |
-| ADR Template          | `references/adr-template.md`          | Documenting decisions                 |
-| System Design         | `references/system-design.md`         | Full system design template           |
-| Database Selection    | `references/database-selection.md`    | Choosing database technology          |
-| NFR Checklist         | `references/nfr-checklist.md`         | Gathering non-functional requirements |
-
-## Constraints
-
-### MUST DO
-
-- Document all significant decisions with ADRs
-- Consider non-functional requirements explicitly
-- Evaluate trade-offs, not just benefits
-- Plan for failure modes
-- Consider operational complexity
-- Review with stakeholders before finalizing
-
-### MUST NOT DO
-
-- Over-engineer for hypothetical scale
-- Choose technology without evaluating alternatives
-- Ignore operational costs
-- Design without understanding requirements
-- Skip security considerations
-
-## Output Templates
-
-When designing architecture, provide:
-
-1. Requirements summary (functional + non-functional)
-2. High-level architecture diagram
-3. Key decisions with trade-offs (ADR format)
-4. Technology recommendations with rationale
-5. Risks and mitigation strategies
-
-## Knowledge Reference
-
-Distributed systems, microservices, event-driven architecture, CQRS, DDD, CAP theorem, cloud platforms (AWS, GCP, Azure), containers, Kubernetes, message queues, caching, database design
-
-## Related Powers
-
-- **Fullstack Guardian** - Implementing designs
-- **DevOps Engineer** - Infrastructure implementation
-- **Secure Code Guardian** - Security architecture

package/workflows/skills/cli-developer/POWER.md

@@ -1,116 +0,0 @@
----
-name: "cli-developer"
-displayName: "CLI Developer"
-description: "Build intuitive, cross-platform CLI tools with argument parsing, interactive prompts, progress indicators, and shell completions across Node.js, Python, and Go"
-keywords:
-  [
-    "cli",
-    "command-line",
-    "terminal",
-    "argument parsing",
-    "shell completion",
-    "interactive prompt",
-    "progress bar",
-    "commander",
-    "click",
-    "typer",
-    "cobra",
-  ]
----
-
-# CLI Developer
-
-## Overview
-
-Senior CLI developer expertise for building fast, intuitive command-line tools across Node.js, Python, and Go ecosystems. Focus on <50ms startup time, comprehensive shell completions, and delightful developer UX.
-
-## When to Use
-
-- Building CLI tools and terminal applications
-- Implementing argument parsing and subcommands
-- Creating interactive prompts and forms
-- Adding progress bars and spinners
-- Implementing shell completions (bash, zsh, fish)
-- Optimizing CLI performance and startup time
-- Designing command hierarchies and flag conventions
-
-## Core Workflow
-
-1. Analyze UX — identify user workflows, command hierarchy, common tasks
-2. Design commands — plan subcommands, flags, arguments, configuration
-3. Implement — build with appropriate CLI framework for the language
-4. Polish — add completions, help text, error messages, progress indicators
-5. Test — cross-platform testing, performance benchmarks
-
-## Quick Reference
-
-### Framework Selection
-
-| Language | Recommended   | Alternative     |
-| -------- | ------------- | --------------- |
-| Node.js  | Commander.js  | Yargs, oclif    |
-| Python   | Typer         | Click, argparse |
-| Go       | Cobra + Viper | urfave/cli      |
-
-### Command Structure
-
-```
-mycli                           # Root command
-├── init [options]              # Simple command
-├── config
-│   ├── get <key>              # Nested subcommand
-│   ├── set <key> <value>
-│   └── list
-├── deploy [environment]        # Command with args
-│   ├── --dry-run              # Flag
-│   ├── --force
-│   └── --config <file>        # Option with value
-└── plugins
-    ├── install <name>
-    ├── list
-    └── remove <name>
-```
-
-### Exit Codes
-
-| Code | Meaning           |
-| ---- | ----------------- |
-| 0    | Success           |
-| 1    | General error     |
-| 2    | Invalid arguments |
-| 77   | Permission denied |
-| 127  | Not found         |
-| 130  | Ctrl+C (SIGINT)   |
-
-## Constraints
-
-### MUST DO
-
-- Keep startup time under 50ms
-- Provide clear, actionable error messages
-- Support `--help` and `--version` flags
-- Use consistent flag naming conventions
-- Handle SIGINT (Ctrl+C) gracefully
-- Validate user input early
-- Support both interactive and non-interactive modes
-- Test on Windows, macOS, and Linux
-
-### MUST NOT DO
-
-- Block on synchronous I/O unnecessarily
-- Print to stdout if output will be piped
-- Use colors when output is not a TTY
-- Break existing command signatures (breaking changes)
-- Require interactive input in CI/CD environments
-- Hardcode paths or platform-specific logic
-- Ship without shell completions
-
-## Steering Files
-
-| File                 | Load When                                                    |
-| -------------------- | ------------------------------------------------------------ |
-| `design-patterns.md` | Command hierarchy, flags, config layers, plugin architecture |
-| `node-cli.md`        | Commander, Yargs, Inquirer, Chalk, Ora                       |
-| `python-cli.md`      | Typer, Click, argparse, Rich, questionary                    |
-| `go-cli.md`          | Cobra, Viper, Bubble Tea, progress bars                      |
-| `ux-patterns.md`     | Progress indicators, colors, help text, error messages       |