@cubis/foundry 0.3.10

package/Ai Agent Workflow/powers/architecture-designer/steering/nfr-checklist.md

@@ -0,0 +1,115 @@
+# Non-Functional Requirements Checklist
+
+> Reference for: Architecture Designer
+> Load when: Gathering system requirements
+
+## NFR Categories
+
+### Scalability
+
+| Question | Common Targets |
+|----------|----------------|
+| Expected concurrent users? | 100 / 1K / 10K / 100K |
+| Requests per second? | 10 / 100 / 1000 / 10000 |
+| Data volume? | GB / TB / PB |
+| Growth rate? | 10% / 50% / 100% per year |
+| Peak vs average load? | 2x / 5x / 10x |
+
+### Performance
+
+| Question | Common Targets |
+|----------|----------------|
+| API response time? | < 100ms / 200ms / 500ms p95 |
+| Page load time? | < 1s / 2s / 3s |
+| Database query time? | < 10ms / 50ms / 100ms |
+| Batch processing throughput? | 1K / 10K / 100K records/hour |
+
+### Availability
+
+| Target | Downtime/Year | Use Case |
+|--------|---------------|----------|
+| 99% | 3.65 days | Internal tools |
+| 99.9% | 8.76 hours | Business apps |
+| 99.95% | 4.38 hours | E-commerce |
+| 99.99% | 52.6 minutes | Financial systems |
+| 99.999% | 5.26 minutes | Life-critical |
+
+### Security
+
+| Question | Considerations |
+|----------|----------------|
+| Authentication required? | JWT, OAuth, SAML, MFA |
+| Authorization model? | RBAC, ABAC, ACL |
+| Data sensitivity? | Public, internal, confidential, PII |
+| Compliance requirements? | GDPR, HIPAA, PCI DSS, SOC 2 |
+| Encryption needs? | At rest, in transit, end-to-end |
+
+### Reliability
+
+| Question | Considerations |
+|----------|----------------|
+| Acceptable data loss? | RPO: 0 / 1hr / 24hr |
+| Recovery time target? | RTO: 1hr / 4hr / 24hr |
+| Backup frequency? | Real-time / hourly / daily |
+| Disaster recovery? | Single region / multi-region |
+
+### Maintainability
+
+| Question | Considerations |
+|----------|----------------|
+| Deployment frequency? | Daily / weekly / monthly |
+| Deployment strategy? | Blue-green, canary, rolling |
+| Monitoring requirements? | Logs, metrics, traces, alerts |
+| On-call requirements? | 24/7, business hours |
+
+### Cost
+
+| Question | Considerations |
+|----------|----------------|
+| Infrastructure budget? | $/month, $/user, $/request |
+| Operational budget? | FTE for maintenance |
+| Cost optimization? | Reserved instances, spot instances |
+| Cost alerts? | Thresholds for notification |
+
+## Template
+
+```markdown
+## Non-Functional Requirements
+
+### Performance
+- API response time: < 200ms p95
+- Page load time: < 2s
+- Database query time: < 50ms
+
+### Scalability
+- Concurrent users: 10,000
+- Requests per second: 1,000
+- Data volume: 1TB
+
+### Availability
+- Target: 99.9% (8.76 hours/year downtime)
+- RPO: 1 hour
+- RTO: 4 hours
+
+### Security
+- Authentication: JWT with refresh tokens
+- Authorization: Role-based (admin, user, guest)
+- Compliance: GDPR, SOC 2
+
+### Observability
+- Logging: Structured JSON to ELK
+- Metrics: Prometheus + Grafana
+- Tracing: OpenTelemetry
+- Alerts: PagerDuty integration
+```
+
+## Quick Reference
+
+| Category | Key Metric |
+|----------|------------|
+| Performance | Response time (p95) |
+| Scalability | Concurrent users, RPS |
+| Availability | Uptime percentage |
+| Reliability | RPO, RTO |
+| Security | Compliance requirements |
+| Cost | $/month budget |

package/Ai Agent Workflow/powers/architecture-designer/steering/system-design.md

@@ -0,0 +1,103 @@
+# System Design Template
+
+> Reference for: Architecture Designer
+> Load when: Designing new systems
+
+## Design Template
+
+```markdown
+# System: {System Name}
+
+## Requirements
+
+### Functional
+- [What the system must do]
+- [Core features and capabilities]
+
+### Non-Functional
+- **Performance**: Response time < 200ms p95
+- **Availability**: 99.9% uptime (8.76 hours downtime/year)
+- **Scalability**: Support 10,000 concurrent users
+- **Security**: PCI DSS compliance required
+
+### Constraints
+- Budget: $X/month for infrastructure
+- Timeline: MVP in 3 months
+- Team: 5 backend, 3 frontend engineers
+
+## High-Level Architecture
+
+```
+┌─────────────┐     ┌─────────────┐     ┌─────────────┐
+│   Client    │────▶│  API Gateway │────▶│  Service    │
+│   (Web)     │     │   (Kong)    │     │  (Node.js)  │
+└─────────────┘     └─────────────┘     └─────────────┘
+                           │                   │
+                           ▼                   ▼
+                    ┌─────────────┐     ┌─────────────┐
+                    │    Auth     │     │  Database   │
+                    │  (Auth0)    │     │ (PostgreSQL)│
+                    └─────────────┘     └─────────────┘
+```
+
+## Component Details
+
+### API Layer
+- Technology: Node.js with Express/NestJS
+- Responsibilities: Request routing, validation, auth
+- Scaling: Horizontal via load balancer
+
+### Data Layer
+- Primary: PostgreSQL (transactions, relationships)
+- Cache: Redis (sessions, hot data)
+- Storage: S3 (files, images)
+
+### External Services
+- Auth: Auth0 (SSO, MFA)
+- Email: SendGrid (transactional)
+- Monitoring: Datadog (APM, logs)
+
+## Key Decisions
+
+| Decision | Rationale |
+|----------|-----------|
+| PostgreSQL over MongoDB | Relational data, ACID needed |
+| Redis for caching | Sub-ms latency required |
+| Auth0 over custom | Reduce security risk |
+
+## Scaling Strategy
+
+### Current (MVP)
+- Single region deployment
+- 2 API instances behind ALB
+- Single RDS instance
+
+### Future (10x growth)
+- Multi-region with CDN
+- Auto-scaling API (2-10 instances)
+- RDS read replicas
+
+## Security Considerations
+- All traffic over TLS 1.3
+- JWT tokens with 15-min expiry
+- Rate limiting: 100 req/min per user
+- WAF for common attacks
+
+## Failure Modes
+
+| Failure | Impact | Mitigation |
+|---------|--------|------------|
+| DB down | Full outage | Multi-AZ failover |
+| Cache down | Degraded perf | Fallback to DB |
+| Auth down | No new logins | Cache valid tokens |
+```
+
+## Quick Reference
+
+| Section | Key Questions |
+|---------|---------------|
+| Requirements | What must it do? How well? |
+| Architecture | What components? How connected? |
+| Decisions | Why these choices? |
+| Scaling | How to grow? |
+| Failures | What can break? How to recover? |

package/Ai Agent Workflow/powers/ask-questions-if-underspecified/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: ask-questions-if-underspecified
+description: Clarify requirements before implementing. Use when serious doubts arise.
+---
+
+# Ask Questions If Underspecified
+
+## When to Use
+
+Use this skill when a request has multiple plausible interpretations or key details (objective, scope, constraints, environment, or safety) are unclear.
+
+## When NOT to Use
+
+Do not use this skill when the request is already clear, or when a quick, low-risk discovery read can answer the missing details.
+
+## Goal
+
+Ask the minimum set of clarifying questions needed to avoid wrong work; do not start implementing until the must-have questions are answered (or the user explicitly approves proceeding with stated assumptions).
+
+## Workflow
+
+### 1) Decide whether the request is underspecified
+
+Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear:
+- Define the objective (what should change vs stay the same)
+- Define "done" (acceptance criteria, examples, edge cases)
+- Define scope (which files/components/users are in/out)
+- Define constraints (compatibility, performance, style, deps, time)
+- Identify environment (language/runtime versions, OS, build/test runner)
+- Clarify safety/reversibility (data migration, rollout/rollback, risk)
+
+If multiple plausible interpretations exist, assume it is underspecified.
+
+### 2) Ask must-have questions first (keep it small)
+
+Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work.
+
+Make questions easy to answer:
+- Optimize for scannability (short, numbered questions; avoid paragraphs)
+- Offer multiple-choice options when possible
+- Suggest reasonable defaults when appropriate (mark them clearly as the default/recommended choice; bold the recommended choice in the list, or if you present options in a code block, put a bold "Recommended" line immediately above the block and also tag defaults inside the block)
+- Include a fast-path response (e.g., reply `defaults` to accept all recommended/default choices)
+- Include a low-friction "not sure" option when helpful (e.g., "Not sure - use default")
+- Separate "Need to know" from "Nice to know" if that reduces friction
+- Structure options so the user can respond with compact decisions (e.g., `1b 2a 3c`); restate the chosen options in plain language to confirm
+
+### 3) Pause before acting
+
+Until must-have answers arrive:
+- Do not run commands, edit files, or produce a detailed plan that depends on unknowns
+- Do perform a clearly labeled, low-risk discovery step only if it does not commit you to a direction (e.g., inspect repo structure, read relevant config files)
+
+If the user explicitly asks you to proceed without answers:
+- State your assumptions as a short numbered list
+- Ask for confirmation; proceed only after they confirm or correct them
+
+### 4) Confirm interpretation, then proceed
+
+Once you have answers, restate the requirements in 1-3 sentences (including key constraints and what success looks like), then start work.
+
+## Question templates
+
+- "Before I start, I need: (1) ..., (2) ..., (3) .... If you don't care about (2), I will assume ...."
+- "Which of these should it be? A) ... B) ... C) ... (pick one)"
+- "What would you consider 'done'? For example: ..."
+- "Any constraints I must follow (versions, performance, style, deps)? If none, I will target the existing project defaults."
+- Use numbered questions with lettered options and a clear reply format
+
+```text
+1) Scope?
+a) Minimal change (default)
+b) Refactor while touching the area
+c) Not sure - use default
+2) Compatibility target?
+a) Current project defaults (default)
+b) Also support older versions: <specify>
+c) Not sure - use default
+
+Reply with: defaults (or 1a 2a)
+```
+
+## Anti-patterns
+
+- Don't ask questions you can answer with a quick, low-risk discovery read (e.g., configs, existing patterns, docs).
+- Don't ask open-ended questions if a tight multiple-choice or yes/no would eliminate ambiguity faster.

package/Ai Agent Workflow/powers/atlassian-mcp/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: atlassian-mcp
+description: Use when querying Jira issues, searching Confluence pages, creating tickets, updating documentation, or integrating Atlassian tools via MCP protocol.
+license: MIT
+metadata:
+  author: https://github.com/Jeffallan
+  version: "1.0.0"
+  domain: platform
+  triggers: Jira, Confluence, Atlassian, MCP, tickets, issues, wiki, JQL, CQL, sprint, backlog, project management
+  role: expert
+  scope: implementation
+  output-format: code
+  related-skills: mcp-developer, api-designer, security-reviewer
+---
+
+# Atlassian MCP Expert
+
+Senior integration specialist with deep expertise in connecting Jira, Confluence, and other Atlassian tools to AI systems via Model Context Protocol (MCP).
+
+## Role Definition
+
+You are an expert in Atlassian MCP integration with mastery of both official and open-source MCP servers, JQL/CQL query languages, OAuth 2.0 authentication, and production deployment patterns. You build robust workflows that automate issue triage, documentation sync, sprint planning, and cross-tool integration while respecting permissions and maintaining security.
+
+## When to Use This Skill
+
+- Querying Jira issues with JQL filters
+- Searching or creating Confluence pages
+- Automating sprint workflows and backlog management
+- Setting up MCP server authentication (OAuth/API tokens)
+- Syncing meeting notes to Jira tickets
+- Generating documentation from issue data
+- Debugging Atlassian API integration issues
+- Choosing between official vs open-source MCP servers
+
+## Core Workflow
+
+1. **Select server** - Choose official cloud, open-source, or self-hosted MCP server
+2. **Authenticate** - Configure OAuth 2.1, API tokens, or PAT credentials
+3. **Design queries** - Write JQL for Jira, CQL for Confluence, test filters
+4. **Implement workflow** - Build tool calls, handle pagination, error recovery
+5. **Deploy** - Configure IDE integration, test permissions, monitor rate limits
+
+## Reference Guide
+
+Load detailed guidance based on context:
+
+| Topic | Reference | Load When |
+|-------|-----------|-----------|
+| Server Setup | `steering/mcp-server-setup.md` | Installation, choosing servers, configuration |
+| Jira Operations | `steering/jira-queries.md` | JQL syntax, issue CRUD, sprints, boards |
+| Confluence Ops | `steering/confluence-operations.md` | CQL search, page creation, spaces, comments |
+| Authentication | `steering/authentication-patterns.md` | OAuth 2.0, API tokens, permission scopes |
+| Common Workflows | `steering/common-workflows.md` | Issue triage, doc sync, sprint automation |
+
+## Constraints
+
+### MUST DO
+- Respect user permissions and workspace access controls
+- Validate JQL/CQL queries before execution
+- Handle rate limits with exponential backoff
+- Use pagination for large result sets (50-100 items per page)
+- Implement error recovery for network failures
+- Log API calls for debugging and audit trails
+- Test with read-only operations first
+- Document required permission scopes
+
+### MUST NOT DO
+- Hardcode API tokens or OAuth secrets in code
+- Ignore rate limit headers from Atlassian APIs
+- Create issues without validating required fields
+- Skip input sanitization on user-provided query strings
+- Deploy without testing permission boundaries
+- Update production data without confirmation prompts
+- Mix different authentication methods in same session
+- Expose sensitive issue data in logs or error messages
+
+## Output Templates
+
+When implementing Atlassian MCP features, provide:
+1. MCP server configuration (JSON/environment vars)
+2. Query examples (JQL/CQL with explanations)
+3. Tool call implementation with error handling
+4. Authentication setup instructions
+5. Brief explanation of permission requirements
+
+## Knowledge Reference
+
+Atlassian MCP Server (official), mcp-atlassian (sooperset), atlassian-mcp (xuanxt), JQL (Jira Query Language), CQL (Confluence Query Language), OAuth 2.1, API tokens, Personal Access Tokens (PAT), Model Context Protocol, JSON-RPC 2.0, rate limiting, pagination, permission scopes, Jira REST API, Confluence REST API