@cubis/foundry 0.3.10

package/Ai Agent Workflow/powers/accessibility/POWER.md

@@ -0,0 +1,103 @@
+---
+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/Ai Agent Workflow/powers/accessibility/SKILL.md

@@ -0,0 +1,103 @@
+---
+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/Ai Agent Workflow/powers/accessibility/steering/a11y_checklist.md

@@ -0,0 +1,21 @@
+# 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/Ai Agent Workflow/powers/accessibility/templates/focus_form.md

@@ -0,0 +1,18 @@
+```
+// 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/Ai Agent Workflow/powers/accessibility/templates/semantics_icon_button.md

@@ -0,0 +1,23 @@
+```
+// 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/Ai Agent Workflow/powers/api-designer/POWER.md

@@ -0,0 +1,108 @@
+---
+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  | `steering/rest-patterns.md`  | Resource design, HTTP methods, HATEOAS      |
+| Versioning     | `steering/versioning.md`     | API versions, deprecation, breaking changes |
+| Pagination     | `steering/pagination.md`     | Cursor, offset, keyset pagination           |
+| Error Handling | `steering/error-handling.md` | Error responses, RFC 7807, status codes     |
+| OpenAPI        | `steering/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/Ai Agent Workflow/powers/api-designer/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: "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."
+---
+
+
+# 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  | `steering/rest-patterns.md`  | Resource design, HTTP methods, HATEOAS      |
+| Versioning     | `steering/versioning.md`     | API versions, deprecation, breaking changes |
+| Pagination     | `steering/pagination.md`     | Cursor, offset, keyset pagination           |
+| Error Handling | `steering/error-handling.md` | Error responses, RFC 7807, status codes     |
+| OpenAPI        | `steering/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