@cubis/foundry 0.3.32 → 0.3.34

package/workflows/powers/postman/SKILL.md

@@ -1,240 +1,18 @@
 ---
 name: "postman"
-description: "Automate API testing and collection management with Postman - create workspaces, collections, environments, and run tests programmatically"
+description: "Compatibility wrapper skill. Canonical MCP skill moved to mcp/skills/postman."
+metadata:
+  deprecated: true
+  replaced_by: "postman"
+  moved_to: "mcp/skills/postman/SKILL.md"
+  removal_target: "v0.6.0"
 ---
 
+# postman (Compatibility Wrapper)
 
-# Onboarding
+This legacy workflow-path skill is kept for backward compatibility.
 
-Before proceeding, validate that the user has completed the following steps before using this power.
+Canonical MCP skill path:
+- mcp/skills/postman/SKILL.md
 
-## Step 1
-
-Generate and maintain `cbx_config.json` as the only Postman configuration source (workspace: `./cbx_config.json`, global: `~/.cbx/cbx_config.json`). Use named profiles in `postman.profiles` and choose `postman.activeProfileName`. Use env-first authentication by default: keep `apiKey` as `null`, set `apiKeyEnvVar` to `POSTMAN_API_KEY` (or another profile alias), and read the key from environment variables. Only store `apiKey` inline when the user explicitly requests file-based key storage. Keep workspace selection in the active profile `workspaceId` (`null` when unknown).
-
-## Step 2
-
-Create a hook that runs anytime the source code or configuration file has been changed. Save the hook in .kiro/hooks/hookname.kiro.hook. Example hook format. Please update the patterns to match the project's file structure.
-
-```json
-{
-  "enabled": true,
-  "name": "API Postman Testing",
-  "description": "Monitors API source code changes across multiple programming languages and automatically runs Postman collection tests to validate functionality",
-  "version": "1",
-  "when": {
-    "type": "fileEdited",
-    "patterns": [
-      "*.js",
-      "*.ts",
-      "*.py",
-      "*.java",
-      "*.cs",
-      "*.go", 
-      "*.rs",
-      "*.php",
-      "*.rb",
-      "*.kt",
-      "*.swift",
-      "*.scala",
-      "package.json",
-      "requirements.txt",
-      "Pipfile",
-      "pom.xml",
-      "build.gradle",
-      "*.csproj",
-      "go.mod",
-      "Cargo.toml",
-      "composer.json",
-      "Gemfile",
-      "build.sbt",
-      "openapi.yaml",
-      "openapi.yml",
-      "swagger.yaml",
-      "swagger.yml",
-      "api.yaml",
-      "api.yml"
-    ]
-  },
-  "then": {
-    "type": "askAgent",
-    "prompt": "API source code or configuration has been modified. Please retrieve the contents of the .postman.json file. If the file does not exist or is empty, create a Postman collection for the API. If it exists, get the collection ID and run the collection, showing me the results and propose fixes for any errors found."
-  }
-}
-```
-# Overview
-
-Automate API testing and collection management with Postman. Create workspaces, collections, environments, and run tests programmatically.
-
-**Authentication**: Env-first via `cbx_config.json` + profile env alias (default `POSTMAN_API_KEY`); inline `apiKey` is optional.
-
-## Available MCP Servers
-
-### postman
-**Package:** `@postman/postman-mcp-server`
-**Connection:** SSE-based MCP server
-**Authentication:** Postman API key via Bearer token
-**Mode:** Minimal (40 essential tools) - Default configuration
-**Endpoint:** https://mcp.postman.com/minimal
-
-**Note:** This power connects to Postman's hosted MCP server via SSE. To enable Full mode (112 tools) for advanced collaboration and enterprise features, change the URL to `https://mcp.postman.com/full`.
-
-**Available Tools (40 in Minimal Mode):**
-
-**Workspace Management:**
-- `createWorkspace` - Create a new workspace
-- `getWorkspace` - Get workspace details
-- `getWorkspaces` - List all accessible workspaces
-- `updateWorkspace` - Update workspace properties
-
-**Collection Management:**
-- `createCollection` - Create a new API collection
-- `getCollection` - Get detailed collection information
-- `getCollections` - List all collections in a workspace
-- `putCollection` - Replace/update entire collection
-- `duplicateCollection` - Create a copy of a collection
-- `createCollectionRequest` - Add a request to a collection
-- `createCollectionResponse` - Add a response example to a request
-
-**Environment Management:**
-- `createEnvironment` - Create a new environment
-- `getEnvironment` - Get environment details
-- `getEnvironments` - List all environments
-- `putEnvironment` - Replace/update entire environment
-
-**Mock Server Management:**
-- `createMock` - Create a mock server
-- `getMock` - Get mock server details
-- `getMocks` - List all mock servers
-- `updateMock` - Update mock server configuration
-- `publishMock` - Make mock server public
-
-**API Specification Management:**
-- `createSpec` - Create a new API specification
-- `getSpec` - Get specification details
-- `getAllSpecs` - List all specifications
-- `getSpecDefinition` - Get complete spec definition
-- `updateSpecProperties` - Update spec metadata
-- `createSpecFile` - Add a file to a spec
-- `getSpecFile` - Get a specific spec file
-- `getSpecFiles` - List all files in a spec
-- `updateSpecFile` - Update a spec file
-
-**Code Generation & Sync:**
-- `generateCollection` - Generate collection from API spec
-- `generateSpecFromCollection` - Generate spec from collection
-- `getGeneratedCollectionSpecs` - Get specs generated from a collection
-- `getSpecCollections` - Get collections generated from a spec
-- `syncCollectionWithSpec` - Sync collection with its spec
-- `syncSpecWithCollection` - Sync spec with its collection
-
-**Testing & Execution:**
-- `runCollection` - Execute a collection with automated tests
-
-**User & Metadata:**
-- `getAuthenticatedUser` - Get current user information
-- `getTaggedEntities` - Get entities by tag
-- `getStatusOfAnAsyncApiTask` - Check async task status
-- `getEnabledTools` - List available tools by mode
-
-## Tool Usage Examples
-
-```javascript
-// Create workspace
-mcp_postman_createWorkspace({
-  "workspace": { "name": "My API Project", "type": "personal" }
-})
-
-// Create collection
-mcp_postman_createCollection({
-  "workspace": "workspace-id",
-  "collection": {
-    "info": {
-      "name": "User API",
-      "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
-    }
-  }
-})
-
-// Create environment
-mcp_postman_createEnvironment({
-  "workspace": "workspace-id",
-  "environment": {
-    "name": "Local",
-    "values": [
-      { "key": "base_url", "value": "http://localhost:3000", "enabled": true }
-    ]
-  }
-})
-
-// Run collection
-mcp_postman_runCollection({
-  "collectionId": "collection-id",
-  "environmentId": "environment-id"
-})
-```
-
-## Workflows
-
-**Project Setup:**
-```javascript
-const { workspace } = await mcp_postman_createWorkspace({ "workspace": { "name": "Project", "type": "personal" }})
-const { collection } = await mcp_postman_createCollection({ "workspace": workspace.id, "collection": { "info": { "name": "API", "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json" }}})
-const { environment } = await mcp_postman_createEnvironment({ "workspace": workspace.id, "environment": { "name": "Local", "values": [{ "key": "base_url", "value": "http://localhost:3000", "enabled": true }]}})
-// Save IDs to .postman.json
-```
-
-**Generate from OpenAPI:**
-```javascript
-const { spec } = await mcp_postman_createSpec({ "workspaceId": "workspace-id", "name": "API Spec", "type": "OPENAPI:3.0", "files": [{ "path": "openapi.yaml", "content": "..." }]})
-const result = await mcp_postman_generateCollection({ "specId": spec.id, "elementType": "collection", "name": "Generated Collection" })
-```
-
-**Automated Testing:**
-```javascript
-const { workspaces } = await mcp_postman_getWorkspaces()
-const { collections } = await mcp_postman_getCollections({ "workspace": workspaces[0].id })
-const { environments } = await mcp_postman_getEnvironments({ "workspace": workspaces[0].id })
-for (const collection of collections) {
-  await mcp_postman_runCollection({ "collectionId": collection.uid, "environmentId": environments[0]?.id })
-}
-```
-
-## Best Practices
-
-- Store workspace/collection/environment IDs in `.postman.json`
-- Use environment variables for different contexts (local/staging/production)
-- Add post-request test scripts for validation
-- Organize requests in folders
-- Run collections before deployment
-- Ensure API server is running before tests
-
-## Troubleshooting
-
-**"Collection not found"**: Call `getCollections` to verify ID and permissions
-
-**"Environment not found"**: Call `getEnvironments` with correct workspace ID
-
-**Test failures**: Verify API server running, check environment variables (base_url, api_key), review test scripts
-
-**"Invalid API key"**: Generate new key at postman.com Settings → API Keys, verify permissions
-
-## Configuration
-
-**MCP Configuration (Minimal mode - 40 tools):**
-```json
-{
-  "mcpServers": {
-    "postman": {
-      "url": "https://mcp.postman.com/minimal",
-      "headers": {
-        "Authorization": "Bearer ${POSTMAN_API_KEY}"
-      }
-    }
-  }
-}
-```
-
-**Full mode (112 tools):** Change URL to `https://mcp.postman.com/full`
-
-**API Key Permissions:** Workspace management, collection read/write, environment read/write, collection runs
+Install MCP skills with: cbx workflows install --include-mcp

package/workflows/powers/python-patterns/POWER.md

@@ -2,443 +2,23 @@
 ---
 inclusion: manual
 name: python-patterns
-description: Python development principles and decision-making. Framework selection, async patterns, type hints, project structure. Teaches thinking, not copying.
-allowed-tools: Read, Write, Edit, Glob, Grep
+description: "Compatibility alias skill. Deprecated: use python-pro."
+metadata:
+  deprecated: true
+  replaced_by: python-pro
+  removal_target: v0.6.0
 ---
 
 # Python Patterns
 
-> Python development principles and decision-making for 2025.
-> **Learn to THINK, not memorize patterns.**
+## Compatibility Alias
 
----
-
-## ⚠️ How to Use This Skill
-
-This skill teaches **decision-making principles**, not fixed code to copy.
-
-- ASK user for framework preference when unclear
-- Choose async vs sync based on CONTEXT
-- Don't default to same framework every time
-
----
-
-## 1. Framework Selection (2025)
-
-### Decision Tree
-
-```
-What are you building?
-│
-├── API-first / Microservices
-│   └── FastAPI (async, modern, fast)
-│
-├── Full-stack web / CMS / Admin
-│   └── Django (batteries-included)
-│
-├── Simple / Script / Learning
-│   └── Flask (minimal, flexible)
-│
-├── AI/ML API serving
-│   └── FastAPI (Pydantic, async, uvicorn)
-│
-└── Background workers
-    └── Celery + any framework
-```
-
-### Comparison Principles
-
-| Factor | FastAPI | Django | Flask |
-|--------|---------|--------|-------|
-| **Best for** | APIs, microservices | Full-stack, CMS | Simple, learning |
-| **Async** | Native | Django 5.0+ | Via extensions |
-| **Admin** | Manual | Built-in | Via extensions |
-| **ORM** | Choose your own | Django ORM | Choose your own |
-| **Learning curve** | Low | Medium | Low |
-
-### Selection Questions to Ask:
-1. Is this API-only or full-stack?
-2. Need admin interface?
-3. Team familiar with async?
-4. Existing infrastructure?
-
----
-
-## 2. Async vs Sync Decision
-
-### When to Use Async
-
-```
-async def is better when:
-├── I/O-bound operations (database, HTTP, file)
-├── Many concurrent connections
-├── Real-time features
-├── Microservices communication
-└── FastAPI/Starlette/Django ASGI
-
-def (sync) is better when:
-├── CPU-bound operations
-├── Simple scripts
-├── Legacy codebase
-├── Team unfamiliar with async
-└── Blocking libraries (no async version)
-```
-
-### The Golden Rule
-
-```
-I/O-bound → async (waiting for external)
-CPU-bound → sync + multiprocessing (computing)
-
-Don't:
-├── Mix sync and async carelessly
-├── Use sync libraries in async code
-└── Force async for CPU work
-```
-
-### Async Library Selection
-
-| Need | Async Library |
-|------|---------------|
-| HTTP client | httpx |
-| PostgreSQL | asyncpg |
-| Redis | aioredis / redis-py async |
-| File I/O | aiofiles |
-| Database ORM | SQLAlchemy 2.0 async, Tortoise |
-
----
-
-## 3. Type Hints Strategy
-
-### When to Type
-
-```
-Always type:
-├── Function parameters
-├── Return types
-├── Class attributes
-├── Public APIs
-
-Can skip:
-├── Local variables (let inference work)
-├── One-off scripts
-├── Tests (usually)
-```
-
-### Common Type Patterns
-
-```python
-# These are patterns, understand them:
-
-# Optional → might be None
-from typing import Optional
-def find_user(id: int) -> Optional[User]: ...
-
-# Union → one of multiple types
-def process(data: str | dict) -> None: ...
-
-# Generic collections
-def get_items() -> list[Item]: ...
-def get_mapping() -> dict[str, int]: ...
-
-# Callable
-from typing import Callable
-def apply(fn: Callable[[int], str]) -> str: ...
-```
-
-### Pydantic for Validation
-
-```
-When to use Pydantic:
-├── API request/response models
-├── Configuration/settings
-├── Data validation
-├── Serialization
-
-Benefits:
-├── Runtime validation
-├── Auto-generated JSON schema
-├── Works with FastAPI natively
-└── Clear error messages
-```
-
----
-
-## 4. Project Structure Principles
-
-### Structure Selection
-
-```
-Small project / Script:
-├── main.py
-├── utils.py
-└── requirements.txt
-
-Medium API:
-├── app/
-│   ├── __init__.py
-│   ├── main.py
-│   ├── models/
-│   ├── routes/
-│   ├── services/
-│   └── schemas/
-├── tests/
-└── pyproject.toml
-
-Large application:
-├── src/
-│   └── myapp/
-│       ├── core/
-│       ├── api/
-│       ├── services/
-│       ├── models/
-│       └── ...
-├── tests/
-└── pyproject.toml
-```
-
-### FastAPI Structure Principles
-
-```
-Organize by feature or layer:
-
-By layer:
-├── routes/ (API endpoints)
-├── services/ (business logic)
-├── models/ (database models)
-├── schemas/ (Pydantic models)
-└── dependencies/ (shared deps)
-
-By feature:
-├── users/
-│   ├── routes.py
-│   ├── service.py
-│   └── schemas.py
-└── products/
-    └── ...
-```
-
----
-
-## 5. Django Principles (2025)
-
-### Django Async (Django 5.0+)
-
-```
-Django supports async:
-├── Async views
-├── Async middleware
-├── Async ORM (limited)
-└── ASGI deployment
-
-When to use async in Django:
-├── External API calls
-├── WebSocket (Channels)
-├── High-concurrency views
-└── Background task triggering
-```
+This skill is deprecated and kept for backward compatibility.
 
-### Django Best Practices
+Use `python-pro` as the canonical skill.
 
-```
-Model design:
-├── Fat models, thin views
-├── Use managers for common queries
-├── Abstract base classes for shared fields
-
-Views:
-├── Class-based for complex CRUD
-├── Function-based for simple endpoints
-├── Use viewsets with DRF
-
-Queries:
-├── select_related() for FKs
-├── prefetch_related() for M2M
-├── Avoid N+1 queries
-└── Use .only() for specific fields
-```
-
----
-
-## 6. FastAPI Principles
-
-### async def vs def in FastAPI
-
-```
-Use async def when:
-├── Using async database drivers
-├── Making async HTTP calls
-├── I/O-bound operations
-└── Want to handle concurrency
-
-Use def when:
-├── Blocking operations
-├── Sync database drivers
-├── CPU-bound work
-└── FastAPI runs in threadpool automatically
-```
-
-### Dependency Injection
-
-```
-Use dependencies for:
-├── Database sessions
-├── Current user / Auth
-├── Configuration
-├── Shared resources
-
-Benefits:
-├── Testability (mock dependencies)
-├── Clean separation
-├── Automatic cleanup (yield)
-```
-
-### Pydantic v2 Integration
-
-```python
-# FastAPI + Pydantic are tightly integrated:
-
-# Request validation
-@app.post("/users")
-async def create(user: UserCreate) -> UserResponse:
-    # user is already validated
-    ...
-
-# Response serialization
-# Return type becomes response schema
-```
-
----
-
-## 7. Background Tasks
-
-### Selection Guide
-
-| Solution | Best For |
-|----------|----------|
-| **BackgroundTasks** | Simple, in-process tasks |
-| **Celery** | Distributed, complex workflows |
-| **ARQ** | Async, Redis-based |
-| **RQ** | Simple Redis queue |
-| **Dramatiq** | Actor-based, simpler than Celery |
-
-### When to Use Each
-
-```
-FastAPI BackgroundTasks:
-├── Quick operations
-├── No persistence needed
-├── Fire-and-forget
-└── Same process
-
-Celery/ARQ:
-├── Long-running tasks
-├── Need retry logic
-├── Distributed workers
-├── Persistent queue
-└── Complex workflows
-```
-
----
-
-## 8. Error Handling Principles
-
-### Exception Strategy
-
-```
-In FastAPI:
-├── Create custom exception classes
-├── Register exception handlers
-├── Return consistent error format
-└── Log without exposing internals
-
-Pattern:
-├── Raise domain exceptions in services
-├── Catch and transform in handlers
-└── Client gets clean error response
-```
-
-### Error Response Philosophy
-
-```
-Include:
-├── Error code (programmatic)
-├── Message (human readable)
-├── Details (field-level when applicable)
-└── NOT stack traces (security)
-```
-
----
-
-## 9. Testing Principles
-
-### Testing Strategy
-
-| Type | Purpose | Tools |
-|------|---------|-------|
-| **Unit** | Business logic | pytest |
-| **Integration** | API endpoints | pytest + httpx/TestClient |
-| **E2E** | Full workflows | pytest + DB |
-
-### Async Testing
-
-```python
-# Use pytest-asyncio for async tests
-
-import pytest
-from httpx import AsyncClient
-
-@pytest.mark.asyncio
-async def test_endpoint():
-    async with AsyncClient(app=app, base_url="http://test") as client:
-        response = await client.get("/users")
-        assert response.status_code == 200
-```
-
-### Fixtures Strategy
-
-```
-Common fixtures:
-├── db_session → Database connection
-├── client → Test client
-├── authenticated_user → User with token
-└── sample_data → Test data setup
-```
-
----
-
-## 10. Decision Checklist
-
-Before implementing:
-
-- [ ] **Asked user about framework preference?**
-- [ ] **Chosen framework for THIS context?** (not just default)
-- [ ] **Decided async vs sync?**
-- [ ] **Planned type hint strategy?**
-- [ ] **Defined project structure?**
-- [ ] **Planned error handling?**
-- [ ] **Considered background tasks?**
-
----
-
-## 11. Anti-Patterns to Avoid
-
-### ❌ DON'T:
-- Default to Django for simple APIs (FastAPI may be better)
-- Use sync libraries in async code
-- Skip type hints for public APIs
-- Put business logic in routes/views
-- Ignore N+1 queries
-- Mix async and sync carelessly
-
-### ✅ DO:
-- Choose framework based on context
-- Ask about async requirements
-- Use Pydantic for validation
-- Separate concerns (routes → services → repos)
-- Test critical paths
-
----
+## Migration
 
-> **Remember**: Python patterns are about decision-making for YOUR specific context. Don't copy code—think about what serves your application best.
+1. Replace direct references to `python-patterns` with `python-pro`.
+2. Apply the full workflow from `python-pro` for new work.
 ````