@cubis/foundry 0.3.66 → 0.3.68

package/workflows/workflows/agent-environment-setup/platforms/copilot/workflows/brainstorm.md

@@ -1,56 +0,0 @@
----
-command: "/brainstorm"
-description: "Generate concrete solution options and tradeoffs before committing to implementation."
-triggers: ["idea", "brainstorm", "options", "tradeoff", "approach"]
----
-# Brainstorm Workflow
-
-# CHANGED: routing — added explicit primary and supporting specialists — prevents route manifest fallback to orchestrator for ideation work.
-# CHANGED: output contract — converted free-form bullets into structured YAML — keeps option handoff machine-readable across platforms.
-
-## When to use
-Use this when requirements are still fluid and architecture choices are open.
-
-## Routing
-- Primary specialist: `@project-planner`
-- Scope and user-value framing: `@product-manager`
-- Technical tradeoff review: `@backend-specialist`
-
-## 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.
-
-## Skill Routing
-- Primary skills: `brainstorming`, `feature-forge`
-- Supporting skills (optional): `plan-writing`
-
-## Workflow steps
-1. Restate problem, constraints, and success metrics.
-2. Produce 2-4 options with architecture shape.
-3. Compare complexity, risk, and implementation speed.
-4. Recommend one option and justify rejection of others.
-
-## Verification
-- Run focused checks/tests for the changed scope.
-- Confirm no regressions in adjacent behavior.
-- Note any gaps that were not validated.
-
-## Output Contract
-```yaml
-BRAINSTORM_WORKFLOW_RESULT:
-  primary_agent: project-planner
-  supporting_agents: [product-manager?, backend-specialist?]
-  primary_skills: [brainstorming, feature-forge]
-  supporting_skills: [plan-writing?]
-  options:
-    - id: <string>
-      summary: <string>
-      pros: [<string>]
-      cons: [<string>]
-      risks: [<string>]
-  recommended_option: <option-id>
-  known_unknowns: [<string>] | []
-  first_milestone: <string>
-  next_handoff:
-    plan_handoff: <PLAN_HANDOFF|null>
-```

package/workflows/workflows/agent-environment-setup/platforms/copilot/workflows/incident.md

@@ -1,52 +0,0 @@
----
-command: "/incident"
-description: "Handle production incidents with triage, mitigation, root cause, and post-incident actions."
-triggers: ["incident", "outage", "sev", "degraded", "hotfix"]
----
-# Incident Workflow
-
-# CHANGED: output contract — converted free-form bullets into structured YAML — keeps incident mitigation and follow-up data structured for resumability.
-
-## When to use
-Use this for active or recent production incidents.
-
-## Routing
-- Runtime/service issues: `@backend-specialist` + `@debugger`
-- Data inconsistencies: `@database-architect`
-- Security events: `@security-auditor`
-- Recovery validation: `@test-engineer`
-- Deployment rollback execution: `@devops-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.
-
-## Skill Routing
-- Primary skills: `systematic-debugging`, `sre-engineer`
-- Supporting skills (optional): `monitoring-expert`, `security-reviewer`
-
-## Workflow steps
-1. Establish impact, severity, and current status.
-2. Mitigate first, then stabilize.
-3. Identify probable root cause and confirm.
-4. Implement and verify durable fix.
-5. Document post-incident follow-up actions.
-
-## Verification
-- Run focused checks/tests for the changed scope.
-- Confirm no regressions in adjacent behavior.
-- Note any gaps that were not validated.
-
-## Output Contract
-```yaml
-INCIDENT_WORKFLOW_RESULT:
-  primary_agent_id: "backend-specialist"
-  escalation_agent_ids: ["debugger", "database-architect", "security-auditor", "test-engineer", "devops-engineer"]
-  primary_skill_ids: ["systematic-debugging", "sre-engineer"]
-  supporting_skill_ids: ["monitoring-expert", "security-reviewer"]
-  incident_timeline: ["Summarize sequence of impact, detection, mitigation, and recovery"]
-  mitigation_actions: ["Describe mitigation steps taken"]
-  root_cause: "Describe confirmed or best-supported root cause"
-  durable_fix: null
-  follow_up_prevention_tasks: ["Describe prevention and hardening actions"]
-```

package/workflows/workflows/agent-environment-setup/platforms/copilot/workflows/postman.md

@@ -1,74 +0,0 @@
----
-command: "/postman"
-description: "Execute Postman MCP operations for workspaces, collections, environments, and runs."
-triggers: ["postman", "collection", "workspace", "environment", "runcollection", "monitor", "mock", "api test"]
----
-# Postman Workflow
-
-# CHANGED: output contract — converted free-form bullets into structured YAML — keeps workspace/action identifiers machine-readable for follow-on automation.
-
-## When to use
-Use this when tasks are primarily about Postman workspaces, collections, environments, monitors, mocks, or collection runs.
-
-## Routing
-- Postman operations and execution: `@backend-specialist`
-- Security/compliance checks on test data: `@security-auditor`
-- Validation quality and assertions: `@test-engineer`
-
-## Context notes
-- This workflow file, active platform rules, and selected agents/skills guide execution.
-- Resolve and pass workspace IDs explicitly when tools require them.
-- Use direct Postman MCP server tools for real Postman actions (`postman.<tool>` or client-wrapped equivalent such as `mcp__postman__<tool>`).
-- Reserve Foundry `postman_*` tools for status/mode/config only.
-- Prefer direct Postman MCP tools over manual JSON/CLI fallback unless fallback is explicitly requested by the user.
-- Support monitor tasks only when the user explicitly asks for monitor-based cloud execution or monitor validation.
-- Never auto-fallback from `postman.runCollection` failure into `postman.runMonitor`.
-- Recommend Postman CLI as the default secondary path after direct MCP execution fails.
-
-## Skill Routing
-- Primary skills: `postman`
-- Supporting skills (optional): `api-designer`, `test-master`
-
-## Workflow steps
-1. Load Postman skill and check integration status (`postman_get_status` for config/status only).
-2. Resolve workspace ID (user-provided, configured default, or explicit selection).
-3. Execute required direct Postman MCP operations (list/create/update/run) with explicit IDs.
-4. If execution fails, classify the error before suggesting any fallback.
-5. Summarize outcomes, failures, and next actions with exact object identifiers.
-
-## Verification
-- Confirm requested Postman action completed successfully.
-- Validate response status and key result fields (IDs, counts, failures).
-- Note any skipped steps and required follow-up.
-
-## Failure classification
-
-- `limitBreachedError` or "breached monitoring usage limit":
-  - classify as monitor quota exhaustion
-  - do not retry monitor execution
-  - recommend Postman CLI
-  - direct the user to Postman monitoring usage dashboard
-- `429` or rate-limited API response:
-  - classify as Postman API rate limiting
-  - recommend backoff and lower request burst
-- collection-run timeout without quota/rate-limit signal:
-  - classify as direct MCP/runtime timeout
-  - do not auto-convert to monitor execution
-  - recommend Postman CLI or smaller-scope rerun
-
-## Output Contract
-```yaml
-POSTMAN_WORKFLOW_RESULT:
-  primary_agent: backend-specialist
-  supporting_agents: [security-auditor?, test-engineer?]
-  primary_skills: [postman]
-  supporting_skills: [api-designer?, test-master?]
-  workspace_context: <string>
-  actions_executed:
-    - action: <string>
-      result_id: <string|null>
-  run_summary:
-    passed: <bool|null>
-    failures: [<string>] | []
-  follow_up_steps: [<string>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/copilot/workflows/qa.md

@@ -1,51 +0,0 @@
----
-command: "/qa"
-description: "Create and execute quality strategy with automation and regression-focused coverage."
-triggers: ["qa", "test", "regression", "automation", "e2e"]
----
-# QA Workflow
-
-# CHANGED: output contract — converted free-form bullets into structured YAML — keeps quality strategy and defect findings machine-readable.
-
-## When to use
-Use this when verification quality and regression prevention are primary concerns.
-
-## Routing
-- Primary specialist: `@qa-automation-engineer`
-- Test strategy support: `@test-engineer`
-- Bug investigation support: `@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.
-
-## Skill Routing
-- Primary skills: `test-master`, `playwright-expert`
-- Supporting skills (optional): `webapp-testing`, `lint-and-validate`
-
-## Workflow steps
-1. Identify risk-heavy user journeys.
-2. Define automation + manual checks where needed.
-3. Execute validation and triage failures.
-4. Report confidence level and remaining gaps.
-
-## Verification
-- Run focused checks/tests for the changed scope.
-- Confirm no regressions in adjacent behavior.
-- Note any gaps that were not validated.
-
-## Output Contract
-```yaml
-QA_WORKFLOW_RESULT:
-  primary_agent: qa-automation-engineer
-  supporting_agents: [test-engineer?, debugger?]
-  primary_skills: [test-master, playwright-expert]
-  supporting_skills: [webapp-testing?, lint-and-validate?]
-  strategy_and_scope: [<string>]
-  automation_coverage_updates: [<string>]
-  defect_findings:
-    - severity: <critical|high|medium|low>
-      summary: <string>
-  confidence: <low|medium|high>
-  residual_risk: [<string>] | []
-```

package/workflows/workflows/agent-environment-setup/platforms/cursor/rules/.cursorrules

@@ -1,134 +0,0 @@
-# .cursorrules - Cubis Foundry Cursor Protocol
-
-This file defines mandatory behavior for Cursor projects installed via `cbx workflows`.
-
-## 1) Platform Paths
-
-- Workflows: `.cursor/workflows`
-- Agents: `.cursor/agents`
-- Skills: `.cursor/skills`
-- Rules file: `.cursorrules`
-
-## Startup Transparency (Required)
-
-Before executing workflows, agents, or code edits, publish a short `Decision Log` that is visible to the user:
-
-1. Rule file(s) read at startup (at minimum `.cursorrules`, plus any additional rule files loaded).
-2. Workflow decision (`/workflow` or direct mode) and why it was chosen.
-3. Agent routing decision (`@agent` or direct mode) and why it was chosen.
-4. Skill loading decision (skill names loaded) and why they were chosen.
-
-If routing changes during the task, publish a `Decision Update` before continuing.
-Keep this user-visible summary concise and factual; do not expose private chain-of-thought.
-
-## 2) Smart Skill Selection (TIER 0)
-
-Before starting ANY task, the agent MUST:
-
-1.  **Analyze** the user's request against the keywords in `.cursor/skills/skills_index.json`.
-2.  **Select** the most relevant skill(s) if a strong match is found.
-3.  **Load** the selected skill's `SKILL.md` using `view_file` **BEFORE** proceeding.
-4.  **Announce** the selection: "I am loading the `[Skill Name]` skill to handle your request."
-
-## 3) Skill Loading Policy
-
-## MCP-first Skill Discovery Order (Required)
-
-1. Use `skill_search` first to narrow candidate skills.
-2. Use `skill_browse_category` second to inspect category-level candidates.
-3. Use `skill_get` only for final selected skills that must be loaded.
-4. Keep pointer-first flow; avoid loading full skill text prematurely.
-
-## Skill Log Completion Block (Required)
-
-After finishing skill selection/loading, publish:
-
-- `selected_skills`: skill IDs selected for the task
-- `loaded_skills`: skill IDs loaded via `skill_get`
-- `skipped_skills`: considered but not loaded
-
-## Context Budget Block (Required, Estimated)
-
-Immediately after the Skill Log block, publish estimated budget fields:
-
-- `full_catalog_est_tokens`
-- `loaded_est_tokens`
-- `estimated_savings_tokens`
-- `estimated_savings_percent`
-
-Mark all context/token values as deterministic estimates (not provider metering).
-
-1.  Load only skills needed for the active request.
-2.  Prefer progressive disclosure: start from `SKILL.md`, then specific sections.
-3.  Keep context lean; avoid loading unrelated skill documents.
-4.  If a mapped skill is missing, continue with best fallback and state it.
-
-After the skill log is complete, append the Context Budget block in the same response/update.
-
-## 4) Request Classifier
-
-1. Question/explanation requests: answer directly.
-2. Survey/intel requests: inspect and summarize before editing.
-3. Simple code changes: minimal edits with focused verification.
-4. Complex code/design changes: plan first, then implement and verify.
-
-## 5) Agent Routing Policy
-
-Use the best specialist first:
-
-- Backend/API/database: `@backend-specialist`, `@database-architect`
-- Frontend/UI: `@frontend-specialist`
-- Mobile: `@mobile-developer`
-- Security: `@security-auditor`, `@penetration-tester`
-- DevOps/release: `@devops-engineer`
-- Testing/QA: `@test-engineer`, `@qa-automation-engineer`
-- Debugging/performance: `@debugger`, `@performance-optimizer`
-- Cross-domain orchestration: `@orchestrator`
-
-## 6) Socratic Gate (Before Complex Work)
-
-Before multi-file or architecture-impacting changes, ask targeted questions when requirements are unclear:
-
-1. Goal and success criteria
-2. Constraints and compatibility requirements
-3. Validation expectations (tests, lint, release checks)
-
-## 7) Quality and Safety Gates
-
-1.  Do not run destructive actions without explicit user confirmation.
-2.  Keep diffs small and reversible when possible.
-3.  Verify behavior with focused checks before finalizing.
-4.  State what was not validated.
-
-## 8) CBX Maintenance Commands
-
-Use these commands to keep this setup healthy:
-
-- Install/update bundle:
-  `cbx workflows install --platform cursor --bundle agent-environment-setup --scope global --overwrite`
-- Rebuild managed routing block:
-  `cbx workflows sync-rules --platform cursor --scope project`
-- Diagnose setup issues:
-  `cbx workflows doctor cursor --scope project`
-
-## 9) Managed Section Contract
-
-1. Preserve all user content outside managed markers.
-2. Do not manually edit content between managed markers.
-3. `cbx workflows sync-rules` is the source of truth for the managed block.
-
-<!-- cbx:workflows:auto:start platform=cursor version=1 -->
-
-## CBX Workflow Routing (auto-managed)
-
-Use the following workflows proactively when task intent matches:
-
-- No installed workflows found yet.
-
-Selection policy:
-
-1. Match explicit slash command first.
-2. Else match user intent to workflow description and triggers.
-3. Prefer one primary workflow; reference others only when needed.
-
-<!-- cbx:workflows:auto:end -->

package/workflows/workflows/agent-environment-setup/platforms/cursor/skills/accessibility/SKILL.md

@@ -1,105 +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)
-
-## References
-
-Load detailed guidance only when needed.
-
-| File | Load when |
-| --- | --- |
-| `references/a11y_checklist.md` | Running an accessibility review or validating a widget/screen against the full checklist |
-
-## Templates
-
-- `focus_form` - Form with proper focus management
-- `semantics_icon_button` - Icon button with semantic labels

package/workflows/workflows/agent-environment-setup/platforms/cursor/skills/accessibility/references/a11y_checklist.md

@@ -1,21 +0,0 @@
-# Accessibility checklist (OneUp HR)
-
-## Labels & semantics
-- [ ] Every button has a clear label (or Semantics label)
-- [ ] Icon-only buttons have Tooltip + Semantics
-- [ ] Images have alt/semantic labels if meaningful
-
-## Text scaling
-- [ ] No overflow at large text sizes
-- [ ] Avoid fixed heights for text containers
-- [ ] Use flexible layouts
-
-## Focus & keyboard (desktop)
-- [ ] Tab order is logical
-- [ ] Focus visible
-- [ ] Dialogs trap focus appropriately
-- [ ] Escape closes dialogs if expected
-
-## Color & contrast
-- [ ] Don’t rely on color alone for status
-- [ ] Contrast acceptable for text on backgrounds

package/workflows/workflows/agent-environment-setup/platforms/cursor/skills/accessibility/steering/a11y_checklist.md

@@ -1,21 +0,0 @@
-# Accessibility checklist (OneUp HR)
-
-## Labels & semantics
-- [ ] Every button has a clear label (or Semantics label)
-- [ ] Icon-only buttons have Tooltip + Semantics
-- [ ] Images have alt/semantic labels if meaningful
-
-## Text scaling
-- [ ] No overflow at large text sizes
-- [ ] Avoid fixed heights for text containers
-- [ ] Use flexible layouts
-
-## Focus & keyboard (desktop)
-- [ ] Tab order is logical
-- [ ] Focus visible
-- [ ] Dialogs trap focus appropriately
-- [ ] Escape closes dialogs if expected
-
-## Color & contrast
-- [ ] Don’t rely on color alone for status
-- [ ] Contrast acceptable for text on backgrounds

package/workflows/workflows/agent-environment-setup/platforms/cursor/skills/accessibility/templates/focus_form.md

@@ -1,18 +0,0 @@
-```
-// templates/focus_form.tmpl
-//
-// Ensure predictable focus order in a form.
-
-Widget a11yForm({required List<Widget> fields, required Widget actions}) {
-  return FocusTraversalGroup(
-    policy: OrderedTraversalPolicy(),
-    child: Column(
-      children: [
-        ...fields,
-        const SizedBox(height: 16),
-        actions,
-      ],
-    ),
-  );
-}
-```

package/workflows/workflows/agent-environment-setup/platforms/cursor/skills/accessibility/templates/semantics_icon_button.md

@@ -1,23 +0,0 @@
-```
-// templates/semantics_icon_button.tmpl
-//
-// Wrap icon-only buttons with Semantics + Tooltip.
-
-Widget a11yIconButton({
-  required String label,
-  required VoidCallback onPressed,
-  required IconData icon,
-}) {
-  return Semantics(
-    button: true,
-    label: label,
-    child: Tooltip(
-      message: label,
-      child: IconButton(
-        onPressed: onPressed,
-        icon: Icon(icon),
-      ),
-    ),
-  );
-}
-```

package/workflows/workflows/agent-environment-setup/platforms/cursor/skills/api-designer/SKILL.md

@@ -1,96 +0,0 @@
----
-name: "api-designer"
-description: "Use when defining or reviewing external API contracts, OpenAPI specifications, resource models, pagination, versioning, or error response standards. Do not use for pure database design, implementation-only handler work, or framework-specific backend setup."
----
-
-
-# API Designer
-
-# CHANGED: description — added a sharper trigger boundary and explicit non-goals — reduces false-positive invocation.
-# CHANGED: references section — normalized to explicit Load When guidance with platform-safe relative paths — prevents speculative sidecar loading.
-# CHANGED: related powers cleanup — removed power-era section — keeps this skill canonical and platform-safe.
-
-## 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
-
-## When Not to Use This Skill
-
-- Pure database schema, indexing, or migration work without an API contract change
-- Framework-only implementation tasks such as wiring handlers, middleware, or DI containers
-- Internal refactors that do not change request/response 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
-
-## References
-
-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