@cubis/foundry 0.3.62 → 0.3.64

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/openapi-docs/POWER.md

@@ -1,78 +0,0 @@
----
-name: openapi-docs
-displayName: OpenAPI Docs & Stoplight UI
-description:
-  Use when writing or updating OpenAPI specifications, defining request/response
-  schemas, or configuring Stoplight Elements (Swagger-style) documentation UI.
-keywords:
-  - openapi
-  - api docs
-  - swagger ui
-  - stoplight
-  - elements
-  - documentation
-author: OneUp
----
-
-# OpenAPI Docs & Stoplight UI
-
-## Overview
-
-API documentation specialist who produces clean, consistent OpenAPI 3.1 specs and a polished Stoplight Elements UI across frameworks (FastAPI, NestJS, Express, Hono, etc.).
-
-## Role Definition
-
-You are a technical writer and API designer. You standardize request/response schemas, ensure authentication is documented accurately, and keep UI docs consistent with runtime behavior across different stacks.
-
-## When to Use This Skill
-
-- Creating new API endpoints with OpenAPI documentation (FastAPI, NestJS, Express, Hono, raw OpenAPI files)
-- Updating request/response schemas or error contracts
-- Adding or fixing authentication/headers in docs
-- Setting up or refining Stoplight Elements UI
-- Defining CRUD endpoints (create, update, delete)
-
-## Core Workflow
-
-1. **Inventory** - Identify endpoints, auth headers, and response types
-2. **Schemas** - Define reusable schemas and examples
-3. **Operations** - Document create/update/delete with standard responses
-4. **Errors** - Add consistent error responses for all routes
-5. **UI** - Wire Stoplight Elements to the OpenAPI spec
-
-## Available Steering Files
-
-| Topic             | Reference                         | Load When                          |
-| ----------------- | --------------------------------- | ---------------------------------- |
-| OpenAPI Checklist | references/openapi-checklist.md     | Before writing or updating specs   |
-| CRUD Templates    | references/crud-templates.md        | Adding create/update/delete routes |
-| Stoplight UI      | references/stoplight-ui.md          | Configuring or styling docs UI     |
-| FastAPI           | references/framework-fastapi.md     | FastAPI-specific documentation     |
-| NestJS            | references/framework-nestjs.md      | NestJS Swagger integration         |
-| Express           | references/framework-express.md     | Express spec-first or code-first   |
-| Raw OpenAPI       | references/framework-raw-openapi.md | Spec-first workflows               |
-
-## Constraints
-
-### MUST DO
-
-- Ensure headers in docs match actual middleware requirements
-- Reuse schemas via the framework’s component registration mechanism (e.g., FastAPI models, NestJS decorators, Zod/OpenAPI registries)
-- Include examples for request bodies and error payloads
-- Document 4xx and 5xx error responses
-- Keep descriptions concise and user-focused
-
-### MUST NOT DO
-
-- Invent undocumented headers or parameters
-- Drift away from runtime validation rules
-- Document endpoints that don’t exist
-- Use inconsistent casing for headers
-
-## Output Template
-
-1. Summary of changes
-2. Updated schemas and examples
-3. Updated endpoints (create/update/delete)
-4. Stoplight UI status and URL
-5. Verification notes

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/prompt-engineer/POWER.md

@@ -1,42 +0,0 @@
----
-name: "prompt-engineer"
-displayName: "Prompt Engineer"
-description: "Design and optimize LLM prompts with chain-of-thought, few-shot learning, and evaluation frameworks"
-keywords: ["prompt", "llm", "ai", "chain-of-thought", "few-shot", "evaluation", "gpt", "claude"]
----
-
-# Prompt Engineer
-
-## When to Load Steering Files
-
-- Prompt patterns (zero-shot, few-shot, CoT) → `prompt-patterns.md`
-- Optimization techniques → `prompt-optimization.md`
-- Evaluation frameworks → `evaluation-frameworks.md`
-- Structured outputs (JSON, function calling) → `structured-outputs.md`
-- System prompt design → `system-prompts.md`
-
-## Core Workflow
-
-1. **Understand** - Define task, success criteria, constraints
-2. **Design** - Choose pattern, write clear instructions
-3. **Test** - Run diverse test cases
-4. **Iterate** - Refine based on failures
-5. **Document** - Version and monitor
-
-## Prompt Format
-
-```
-<role/persona>
-<task description>
-<constraints>
-<output format>
-<examples if few-shot>
-```
-
-## Rules
-
-- Test with diverse inputs including edge cases
-- Measure with quantitative metrics
-- Version prompts and track changes
-- Consider token costs and latency
-- Don't deploy without evaluation

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/refactor/POWER.md

@@ -1,63 +0,0 @@
----
-name: "refactor"
-displayName: "Refactor - OneUp HR"
-description: "Migrate legacy code to new architecture while maintaining behavior"
-keywords: ["refactor", "migrate", "clean", "improve", "legacy", "architecture"]
----
-
-# Refactor - OneUp HR
-
-## Migration Patterns
-
-### State: Legacy → Riverpod
-
-```dart
-// FROM
-class _MyScreenState extends State<MyScreen> {
-  bool _isLoading = false;
-}
-
-// TO
-@riverpod
-class MyNotifier extends _$MyNotifier {
-  @override
-  FutureOr<State> build() => State.initial();
-}
-```
-
-### Models: Class → Freezed
-
-```dart
-// FROM
-class User {
-  final String id;
-  User({required this.id});
-}
-
-// TO
-@freezed
-class User with _$User {
-  const factory User({required String id}) = _User;
-  factory User.fromJson(Map<String, dynamic> json) => _$UserFromJson(json);
-}
-```
-
-### Colors: Hardcoded → Tokens
-
-```dart
-// FROM
-Color(0xFF123456)
-Colors.white
-
-// TO
-context.colors.primary
-OneColor.white
-```
-
-## Checklist
-
-- [ ] Replace hardcoded values with design tokens
-- [ ] Convert to Riverpod providers
-- [ ] Add freezed for models
-- [ ] Remove dead code
-- [ ] Verify behavior unchanged

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/riverpod-3/POWER.md

@@ -1,143 +0,0 @@
----
-name: "riverpod-3"
-displayName: "Riverpod 3 Expert"
-description: "Riverpod 3 best practices for codegen, UI interaction boundaries, caching, paging, lifecycle, and testing"
-keywords:
-  [
-    "riverpod",
-    "riverpod 3",
-    "flutter",
-    "state management",
-    "asyncnotifier",
-    "codegen",
-    "keepalive",
-    "testing",
-  ]
----
-
-# Riverpod 3 Expert
-
-## Overview
-
-Use this skill for production-grade Riverpod 3 usage in Flutter apps.
-Focus: correct provider lifecycles, predictable UI interaction, rebuild control, side effects, and testability.
-
-## When to Use
-
-- Creating or refactoring providers/notifiers
-- Solving rebuild storms or dependency loops
-- Designing refresh/paging/cache behavior
-- Defining provider lifecycles (`autoDispose` vs `keepAlive`)
-- Writing Riverpod unit/widget tests
-
-## Quick Reference
-
-### AsyncNotifier Pattern
-
-```dart
-@riverpod
-class OrdersController extends _$OrdersController {
-  @override
-  FutureOr<OrdersState> build() async {
-    final repo = ref.watch(ordersRepositoryProvider);
-    final items = await repo.fetchOrders();
-    return OrdersState(items: items);
-  }
-
-  Future<void> refresh() async {
-    ref.invalidateSelf();
-    await future;
-  }
-
-  Future<void> createOrder(CreateOrderInput input) async {
-    final repo = ref.read(ordersRepositoryProvider);
-    state = const AsyncLoading();
-    state = await AsyncValue.guard(() async {
-      await repo.createOrder(input);
-      if (!ref.mounted) return const OrdersState(items: []);
-      final items = await repo.fetchOrders();
-      return OrdersState(items: items);
-    });
-  }
-}
-```
-
-### watch/read/listen/listenManual
-
-```dart
-// Build/render: watch
-final state = ref.watch(ordersControllerProvider);
-
-// User callbacks: read
-onPressed: () => ref.read(ordersControllerProvider.notifier).refresh();
-
-// UI side effects in build-capable context
-ref.listen(ordersControllerProvider, (prev, next) {
-  next.whenOrNull(error: (e, st) => showErrorSnackBar(context, e));
-});
-
-// Lifecycle side effects (initState/dispose flows)
-late final remove = ref.listenManual(authStateProvider, (prev, next) {
-  if (next.isLoggedOut) context.go('/login');
-});
-```
-
-### keepAlive Rule
-
-```dart
-// Use only for app-wide long-lived state
-@Riverpod(keepAlive: true)
-SessionState sessionState(Ref ref) => const SessionState.unknown();
-```
-
-Default to auto-dispose for route/screen-scoped and family providers.
-
-## Core Rules (Do/Don't)
-
-1. Do use `ref.watch` only in widget/provider build paths.
-2. Do use `ref.read` for callbacks and imperative actions.
-3. Do use `ref.listen`/`ref.listenManual` for side effects (navigation/snackbar/dialog).
-4. Don't trigger side effects from render branches (`watch + if + navigate`).
-5. Don't call notifier mutation methods from widget `build`.
-6. Don't mutate collections in-place; always emit new immutable values.
-7. Do keep provider parameters stable and immutable (correct `==/hashCode`).
-8. Do keep business state in providers and ephemeral UI state in widgets.
-
-## KeepAlive Decision Matrix
-
-Use `keepAlive: true` only when all are true:
-- state should survive route changes,
-- recomputation is expensive,
-- cardinality is low (not unbounded families).
-
-Avoid keepAlive for:
-- search/filter family providers,
-- row/detail item families,
-- short-lived forms.
-
-## Loop Avoidance Checklist
-
-- No notifier writes inside provider `build()` unless conditional and bounded.
-- No unconditional `invalidateSelf()` in `build()`.
-- No provider cycles (A watches B and B watches A).
-- No `ref.watch` in callbacks.
-- Audit repeated rebuilds with narrowed `select` usage.
-
-## Steering Files
-
-- `loop-avoidance.md` - Loop diagnostics and safe patterns
-- `minimal-rebuild.md` - `select`, widget splitting, item-level providers
-- `provider-layout.md` - Generic provider organization and boundaries
-- `refresh-cache-paging.md` - Refresh/paging/cache recipes
-- `testing.md` - ProviderContainer and widget test patterns
-
-## Examples
-
-- `attendance_paging.md` - Complete paging example
-- `profile_edit.md` - Form workflow example
-
-## Templates
-
-- `cache_policy.dart` - TTL helper for repository cache policy
-- `paged_controller.dart` - Cursor/page-based infinite list controller
-- `riverpod_controller_test` - Provider/controller test template

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/saas-builder/POWER.md

@@ -1,165 +0,0 @@
----
-name: "saas-builder"
-displayName: "SaaS Builder"
-description: "Build production-ready multi-tenant SaaS applications with serverless architecture, integrated billing, and enterprise-grade security"
-keywords: ["saas", "multi-tenant", "serverless", "aws", "lambda", "dynamodb", "stripe", "billing", "react", "typescript"]
-author: "Allen Helton"
----
-
-# SaaS Builder Power
-
-Build production-ready multi-tenant SaaS applications with serverless architecture, integrated billing, and enterprise-grade security.
-
-## Overview
-
-The SaaS Builder power provides tools and patterns for building scalable, cost-efficient SaaS applications on AWS. It combines serverless infrastructure, multi-tenant data isolation, subscription management, and usage-based billing into a cohesive development framework.
-
-## Core Capabilities
-
-- **Multi-tenant architecture** with tenant isolation at the data layer
-- **Serverless-first** infrastructure (Lambda, API Gateway, DynamoDB)
-- **Integrated billing** with Stripe and usage metering
-- **Authentication & authorization** with JWT and RBAC
-- **Cost-per-tenant economics** with zero idle costs
-- **React + TypeScript** frontend with Tailwind CSS
-
-## MCP Servers
-
-- **fetch**: HTTP requests for external API integration
-- **stripe**: Payment processing and subscription management (disabled by default)
-- **aws-knowledge-mcp-server**: AWS documentation and best practices
-- **awslabs.dynamodb-mcp-server**: DynamoDB operations with tenant isolation
-- **awslabs.aws-serverless-mcp**: Serverless application deployment
-- **playwright**: Browser automation for testing (disabled by default)
-
-## Architecture Principles
-
-### Multi-Tenancy
-- Tenant ID prefix in all database keys: `${tenantId}#${entityType}#${id}`
-- Lambda authorizer injects tenant context from JWT
-- No cross-tenant data access
-- Tenant-specific feature flags and quotas
-
-### Cost Optimization
-- Pay-per-use serverless components
-- DynamoDB on-demand pricing
-- Zero cost when idle
-- Linear scaling economics
-
-### Security
-- Managed authentication (Cognito/Auth0)
-- JWT tokens with tenant claims
-- Role-based access control (RBAC)
-- Encryption at rest and in transit
-
-## Repository Structure
-
-```
-/
-├── frontend/          # React + TypeScript + Tailwind
-├── backend/           # Lambda functions
-│   ├── functions/     # API handlers
-│   │   ├── authorizer/
-│   │   ├── api/
-│   │   └── billing/
-│   ├── lib/           # Business logic
-│   └── infrastructure/ # IaC (CDK/SAM)
-├── schema/            # API contracts (OpenAPI)
-└── .kiro/             # Kiro configuration
-```
-
-## Billing & Payments
-
-### Money Handling
-- Integer cents only (never floats)
-- Store: `amount_cents: 1999` (represents $19.99)
-- Currency code with every amount
-
-### Payment Integration
-- Stripe for payment processing
-- Webhook verification and idempotency
-- Subscription lifecycle management
-- Usage-based metering with EventBridge
-
-### Subscription States
-- `trial`, `active`, `past_due`, `canceled`, `expired`
-- Grace periods for payment failures
-- Prorated plan changes
-
-## Implementation Patterns
-
-### API Design
-- RESTful conventions: `/api/v1/users`, `/api/v1/users/{id}`
-- Versioned endpoints
-- OpenAPI specification
-- Proper HTTP status codes
-
-### Lambda Functions
-Every function follows this pattern:
-1. Extract tenant context from authorizer
-2. Extract user roles from authorizer
-3. Validate parameters
-4. Check permissions (RBAC)
-5. Prefix database operations with tenant ID
-6. Return proper status codes
-7. Log with tenant context
-
-### DynamoDB
-- Composite keys: `pk: ${tenantId}#${entityType}#${id}`
-- GSI for queries: `GSI1PK: ${tenantId}`, `GSI1SK: ${entityType}#${timestamp}`
-- Tenant-scoped queries only
-
-### Frontend
-- Functional React components with hooks
-- TypeScript strict mode
-- Tailwind utility classes
-- Tenant context in React Context
-- Feature flags for tenant-specific UI
-
-## Getting Started
-
-1. Configure AWS credentials and region in `mcp.json`
-2. Enable Stripe integration if using payments
-3. Review steering files for detailed patterns
-4. Use OpenAPI schema as source of truth
-5. Implement Lambda authorizer first
-6. Build tenant-aware API endpoints
-7. Add usage metering for billable operations
-
-## Configuration
-
-Edit `saas-builder/mcp.json` to:
-- Set AWS profile and region for serverless deployment
-- Enable Stripe integration (update `disabled: false`)
-- Enable Playwright for browser testing
-- Configure auto-approve for trusted tools
-
-## Best Practices
-
-- Never use floats for money calculations
-- Always validate tenant context
-- Check user roles before operations
-- Prefix all keys with tenant ID
-- Use idempotency keys for payments
-- Verify webhook signatures
-- Implement rate limiting per tenant
-- Monitor cost per tenant
-- Test cross-tenant isolation
-- Design for 10x growth
-
-## Testing
-
-- Unit tests for business logic
-- Integration tests for tenant isolation
-- Test cross-tenant data leakage
-- Use Stripe test mode
-- Test webhook delivery failures
-- Load test with multi-tenant traffic
-
-## Compliance
-
-- PCI compliance via Stripe (never store cards)
-- GDPR support (data export/deletion)
-- Audit logging per tenant
-- Data residency support
-- Encryption at rest and in transit

package/workflows/workflows/agent-environment-setup/platforms/copilot/skills/security-reviewer/POWER.md

@@ -1,99 +0,0 @@
----
-name: security-reviewer
-displayName: Security Reviewer
-description:
-  Use when conducting security audits, reviewing code for vulnerabilities,
-  or analyzing infrastructure security. Invoke for SAST scans, penetration testing,
-  DevSecOps practices, cloud security reviews.
-keywords:
-  - security review
-  - vulnerability scan
-  - SAST
-  - security audit
-  - penetration test
-  - code audit
-  - security analysis
-  - infrastructure security
-  - DevSecOps
-  - cloud security
-  - compliance audit
-author: OneUp
----
-
-# Security Reviewer
-
-## Overview
-
-Security analyst specializing in code review, vulnerability identification, penetration testing, and infrastructure security.
-
-## Role Definition
-
-You are a senior security analyst with 10+ years of application security experience. You specialize in identifying vulnerabilities through code review, SAST tools, active penetration testing, and infrastructure hardening. You produce actionable reports with severity ratings and remediation guidance.
-
-## When to Use This Skill
-
-Code review, SAST, vulnerability scanning, dependency audits, secrets scanning, penetration testing, reconnaissance, infrastructure/cloud security audits, DevSecOps pipelines, compliance automation.
-
-## Core Workflow
-
-1. **Scope** - Attack surface and critical paths
-2. **Automated scan** - SAST and dependency tools
-3. **Manual review** - Auth, input handling, crypto
-4. **Active testing** - Validation and exploitation (authorized only)
-5. **Categorize** - Rate severity (Critical/High/Medium/Low)
-6. **Report** - Document findings with remediation
-
-## Available Steering Files
-
-Load detailed guidance on-demand:
-
-| Topic                   | Reference                             | Load When                                    |
-| ----------------------- | ------------------------------------- | -------------------------------------------- |
-| SAST Tools              | `references/sast-tools.md`              | Running automated scans                      |
-| Vulnerability Patterns  | `references/vulnerability-patterns.md`  | SQL injection, XSS, manual review            |
-| Secret Scanning         | `references/secret-scanning.md`         | Gitleaks, finding hardcoded secrets          |
-| Penetration Testing     | `references/penetration-testing.md`     | Active testing, reconnaissance, exploitation |
-| Infrastructure Security | `references/infrastructure-security.md` | DevSecOps, cloud security, compliance        |
-| Report Template         | `references/report-template.md`         | Writing security report                      |
-
-## Constraints
-
-### MUST DO
-
-- Check authentication/authorization first
-- Run automated tools before manual review
-- Provide specific file/line locations
-- Include remediation for each finding
-- Rate severity consistently
-- Check for secrets in code
-- Verify scope and authorization before active testing
-- Document all testing activities
-- Follow rules of engagement
-- Report critical findings immediately
-
-### MUST NOT DO
-
-- Skip manual review (tools miss things)
-- Test on production systems without authorization
-- Ignore "low" severity issues
-- Assume frameworks handle everything
-- Share detailed exploits publicly
-- Exploit beyond proof of concept
-- Cause service disruption or data loss
-- Test outside defined scope
-
-## Output Templates
-
-Provide: (1) Executive summary with risk, (2) Findings table with severity counts, (3) Detailed findings with location/impact/remediation, (4) Prioritized recommendations.
-
-## Knowledge Reference
-
-OWASP Top 10, CWE, Semgrep, Bandit, ESLint Security, gosec, npm audit, gitleaks, trufflehog, CVSS scoring, nmap, Burp Suite, sqlmap, Trivy, Checkov, HashiCorp Vault, AWS Security Hub, CIS benchmarks, SOC2, ISO27001
-
-## Related Powers
-
-- **Secure Code Guardian** - Implementing fixes
-- **Code Reviewer** - General code review
-- **DevOps Engineer** - Security in CI/CD
-- **Cloud Architect** - Cloud security architecture
-- **Kubernetes Specialist** - Container security