@cubis/foundry 0.3.66 → 0.3.68

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/feature-forge/references/ears-syntax.md

@@ -1,99 +0,0 @@
-# EARS Syntax
-
-## EARS Format
-
-Easy Approach to Requirements Syntax for clear, unambiguous requirements.
-
-### Basic Pattern
-
-```
-While <precondition>, when <trigger>, the system shall <response>.
-```
-
-### Pattern Types
-
-**Ubiquitous (Always True)**
-```
-The system shall [action].
-```
-Example: The system shall encrypt all passwords using bcrypt.
-
-**Event-Driven**
-```
-When [trigger], the system shall [action].
-```
-Example: When the user clicks "Submit", the system shall save the form data.
-
-**State-Driven**
-```
-While [state], the system shall [action].
-```
-Example: While the user is logged in, the system shall display the dashboard.
-
-**Conditional (Most Common)**
-```
-While [state], when [trigger], the system shall [action].
-```
-Example: While the cart contains items, when the user clicks "Checkout", the system shall navigate to the payment page.
-
-**Optional**
-```
-Where [feature enabled], the system shall [action].
-```
-Example: Where two-factor authentication is enabled, the system shall require a verification code.
-
-## Examples by Domain
-
-### Authentication
-
-```markdown
-**FR-AUTH-001**: Login
-While credentials are valid, when POST /auth/login is called,
-the system shall return JWT access token (15min) and refresh token (7d).
-
-**FR-AUTH-002**: Invalid Login
-When invalid credentials are provided,
-the system shall return 401 and increment failed login counter.
-
-**FR-AUTH-003**: Account Lockout
-While failed login count exceeds 5, when login is attempted,
-the system shall reject the attempt and require password reset.
-```
-
-### E-commerce
-
-```markdown
-**FR-CART-001**: Add to Cart
-While user is logged in, when they click "Add to Cart",
-the system shall add the item and update the cart badge count.
-
-**FR-CART-002**: Apply Coupon
-While the cart contains items, when a valid coupon code is applied,
-the system shall reduce the total by the discount amount.
-
-**FR-ORDER-001**: Checkout
-While payment method is valid, when user confirms order,
-the system shall create order, charge payment, and send confirmation email.
-```
-
-### Data Management
-
-```markdown
-**FR-EXPORT-001**: CSV Export
-While user has data access permission, when they click "Export",
-the system shall generate a CSV file and initiate download.
-
-**FR-DELETE-001**: Soft Delete
-When a resource is deleted,
-the system shall set deleted_at timestamp instead of removing the record.
-```
-
-## Quick Reference
-
-| Type | Structure | Use When |
-|------|-----------|----------|
-| Ubiquitous | shall [action] | Always applies |
-| Event | When [X], shall | On trigger |
-| State | While [X], shall | Continuous state |
-| Conditional | While [X], when [Y], shall | State + trigger |
-| Optional | Where [X], shall | Feature flag |

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/feature-forge/references/interview-questions.md

@@ -1,150 +0,0 @@
-# Interview Questions
-
-## PM Hat Questions
-
-Focus on user value and business goals.
-
-| Area | Questions |
-|------|-----------|
-| **Problem** | What problem does this solve? Who experiences this problem? How often? |
-| **Users** | Who are the target users? What are their goals? Technical level? |
-| **Value** | How will users benefit? What's the business value? ROI? |
-| **Scope** | What's in scope? What's explicitly out of scope? MVP vs full version? |
-| **Success** | How will we measure success? Key metrics? |
-| **Priority** | Is this a must-have, should-have, or nice-to-have? |
-
-### Example PM Questions
-
-```markdown
-For a "User Export" feature:
-- Who needs to export data and why?
-- What format do they need (CSV, JSON, Excel)?
-- How much data? 100 rows or 1 million?
-- Is this for compliance (GDPR) or convenience?
-- How often will this be used?
-- What's the deadline?
-```
-
-## Dev Hat Questions
-
-Focus on technical feasibility and edge cases.
-
-| Area | Questions |
-|------|-----------|
-| **Integration** | What systems does this touch? APIs, databases, services? |
-| **Security** | Authentication required? Data sensitivity (PII, PCI)? |
-| **Performance** | Expected load? Response time requirements? Async OK? |
-| **Edge Cases** | What happens when X fails? Empty states? Limits? |
-| **Data** | What's stored? Retention period? Backup needs? |
-| **Dependencies** | External services? Rate limits? Costs? |
-
-### Example Dev Questions
-
-```markdown
-For a "User Export" feature:
-- What fields to include? Are any sensitive (passwords, tokens)?
-- Max export size? Need streaming or background job?
-- Should include soft-deleted records?
-- What happens if export fails midway?
-- File retention - how long to keep generated files?
-- Need progress indicator for large exports?
-```
-
-## Tool Usage: AskUserQuestions
-
-Use `AskUserQuestions` when questions have a finite set of likely answers. Use open-ended follow-up when answers are unbounded.
-
-### When to Use Structured Options
-
-| Question Pattern | Example | Options Style |
-|-----------------|---------|---------------|
-| Priority/ranking | "Is this must-have or nice-to-have?" | Single select: Must-have, Should-have, Nice-to-have |
-| Format selection | "What export format?" | Multi-select: CSV, JSON, Excel, PDF |
-| Scope decisions | "MVP or full version?" | Single select: MVP, Full, Phased |
-| Yes/No with nuance | "Auth required?" | Single select: Public, Authenticated, Role-based |
-
-### When to Use Open-Ended
-
-- "Describe the user journey in your own words"
-- "What problem does this solve?"
-- "Walk me through the workflow"
-
-### Example: Structured Elicitation
-
-For a "User Export" feature, batch related choices:
-
-**Question 1** (header: "Export scope"):
-"What data should users be able to export?"
-Options: "Own data only", "Team data", "Organization-wide", multi-select enabled
-
-**Question 2** (header: "Format"):
-"Which export formats should be supported?"
-Options: "CSV", "JSON", "Excel (.xlsx)", "PDF", multi-select enabled
-
-**Question 3** (header: "Priority"):
-"How critical is this feature?"
-Options: "Must-have (blocking)", "Should-have (important)", "Nice-to-have (future)"
-
----
-
-## Interview Flow
-
-### Phase 1: Discovery
-Use open-ended questions to understand the problem space:
-1. "Tell me about this feature in your own words"
-2. "What problem are we solving?"
-
-Then use `AskUserQuestions` to narrow down:
-- Target users (single select from identified personas)
-- Usage frequency (Daily, Weekly, Monthly, Rarely)
-- Priority (Must-have, Should-have, Nice-to-have)
-
-### Phase 2: Details
-Use `AskUserQuestions` for scope and constraint decisions:
-- Scope: MVP vs Full vs Phased (single select)
-- Key capabilities (multi-select from discovered items)
-
-Then open-ended: "Walk me through the user journey"
-
-### Phase 3: Edge Cases
-Use `AskUserQuestions` for technical trade-offs:
-- Error handling approach (Retry, Fail fast, Queue, Notify)
-- Data limits (multi-select thresholds)
-
-Then open-ended: "What happens when [X] fails?"
-
-### Phase 4: Validation
-Present spec summary, then use `AskUserQuestions`:
-- "Does this capture your requirements?" (Yes / Needs changes / Major gaps)
-- Per-requirement priority confirmation if needed
-
-## Multi-Agent Pre-Discovery
-
-For features spanning multiple domains, launch Task subagents with relevant skills **before** starting the interview. This front-loads technical context so the interview focuses on decisions rather than exploration.
-
-### Pattern: Parallel Skill-Invoked Discovery
-
-```
-User request: "I need a feature that does X"
-
-Before interview, launch subagents in parallel:
-- Task(subagent_type="general-purpose"): Invoke architecture-designer skill to assess system impact
-- Task(subagent_type="general-purpose"): Invoke security-reviewer skill to identify auth/data concerns
-- Task(subagent_type="Explore"): Search codebase for existing patterns related to the feature
-
-Collect subagent findings → Use them to inform interview questions
-```
-
-This ensures the Feature Forge interview starts with concrete technical context rather than assumptions.
-
----
-
-## Quick Reference
-
-| Phase | Focus | Tool |
-|-------|-------|------|
-| Pre-Discovery | Technical context | Task subagents with skills |
-| Discovery | Problem, users, value | Open-ended → AskUserQuestions |
-| Details | Journey, scope, constraints | AskUserQuestions → Open-ended |
-| Edge Cases | Failures, limits, security | AskUserQuestions → Open-ended |
-| Validation | Summary, gaps | AskUserQuestions |

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/feature-forge/references/pre-discovery-subagents.md

@@ -1,54 +0,0 @@
-# Pre-Discovery with Subagents
-
-For features spanning multiple domains (auth, database, UI, etc.) that need front-loaded technical context before the Feature Forge interview.
-
-## Overview
-
-For features spanning multiple domains, you can accelerate discovery by launching Task subagents with relevant skills BEFORE starting the Feature Forge interview. This front-loads technical context so the interview focuses on decisions rather than exploration.
-
-## When to Use
-
-- Feature touches 3+ distinct system layers (e.g., auth, database, UI)
-- Codebase is unfamiliar or underdocumented
-- You need concrete technical facts before asking requirements questions
-- Stakeholder time is limited and you want to minimize back-and-forth
-
-## When NOT to Use
-
-- Feature is well-scoped to a single domain
-- You already have deep codebase knowledge
-- Requirements are purely business/UX (no technical exploration needed)
-
-## Pattern
-
-```
-1. Identify domains the feature touches
-2. Launch parallel Task subagents with relevant skills:
-   - Architecture Designer → existing patterns and constraints
-   - Framework Expert → current implementation details
-   - Security Reviewer → security requirements and risks
-3. Collect findings from all subagents
-4. Begin Feature Forge interview with technical context loaded
-5. Focus interview on decisions, trade-offs, and requirements
-```
-
-## Example
-
-For a "user profile with avatar upload" feature:
-
-```
-Task subagent 1 (Architecture Designer):
-  "Analyze the current user model, storage patterns, and image handling in this codebase"
-
-Task subagent 2 (Security Reviewer):
-  "What security concerns exist for file upload in this stack?"
-
-Task subagent 3 (Framework Expert):
-  "How does this project handle API endpoints and file storage?"
-```
-
-Results feed into the Feature Forge interview, so questions like "Where should we store avatars?" come with context about existing patterns.
-
-## Integration with Interview Questions
-
-See `interview-questions.md` for the full multi-agent discovery pattern and how subagent findings map to interview categories.

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/feature-forge/references/specification-template.md

@@ -1,103 +0,0 @@
-# Specification Template
-
-## Full Template
-
-```markdown
-# Feature: [Name]
-
-## Overview
-[2-3 sentence description of the feature and its value to users]
-
-## Functional Requirements
-
-### FR-001: [Requirement Name]
-While <precondition>, when <trigger>, the system shall <response>.
-
-### FR-002: [Requirement Name]
-While <precondition>, when <trigger>, the system shall <response>.
-
-## Non-Functional Requirements
-
-### Performance
-- Response time: < 200ms p95
-- Throughput: 1000 requests/minute
-- Data volume: Up to 1M records
-
-### Security
-- Authentication: JWT required
-- Authorization: Role-based (admin, user)
-- Data protection: PII encrypted at rest
-
-### Scalability
-- Concurrent users: 10,000
-- Peak load handling: Auto-scale to 3x
-- Data retention: 90 days
-
-## Acceptance Criteria
-
-### AC-001: [Scenario Name]
-Given [context/precondition]
-When [action taken]
-Then [expected result]
-
-### AC-002: [Scenario Name]
-Given [context/precondition]
-When [action taken]
-Then [expected result]
-
-## Error Handling
-
-| Error Condition | HTTP Code | User Message |
-|-----------------|-----------|--------------|
-| Invalid input | 400 | "Please check your input" |
-| Unauthorized | 401 | "Please log in to continue" |
-| Forbidden | 403 | "You don't have permission" |
-| Not found | 404 | "Resource not found" |
-| Conflict | 409 | "This already exists" |
-
-## Implementation TODO
-
-### Backend
-- [ ] Create database migration for X table
-- [ ] Implement X service with Y method
-- [ ] Add API endpoint POST /api/x
-- [ ] Add input validation schema
-- [ ] Add authorization check
-
-### Frontend
-- [ ] Create X component
-- [ ] Add form with validation
-- [ ] Implement API integration
-- [ ] Add loading/error states
-- [ ] Add success feedback
-
-### Testing
-- [ ] Unit tests for X service
-- [ ] Integration tests for API endpoint
-- [ ] E2E test for complete user flow
-
-## Out of Scope
-- [Feature/capability explicitly not included]
-- [Future enhancement to consider later]
-
-## Open Questions
-- [ ] [Question needing stakeholder input]
-- [ ] [Technical decision pending]
-```
-
-## Save Location
-
-Save as: `specs/{feature_name}.spec.md`
-
-## Required Sections Checklist
-
-| Section | Purpose | Required |
-|---------|---------|----------|
-| Overview | Quick understanding | Yes |
-| Functional Requirements | What it does | Yes |
-| Non-Functional Requirements | How well it does it | Yes |
-| Acceptance Criteria | How to verify | Yes |
-| Error Handling | Failure cases | Yes |
-| Implementation TODO | Action items | Yes |
-| Out of Scope | Prevent scope creep | Recommended |
-| Open Questions | Track decisions | As needed |

package/workflows/workflows/agent-environment-setup/platforms/claude/skills/find-bugs/SKILL.md

@@ -1,75 +0,0 @@
----
-name: find-bugs
-description: Find bugs, security vulnerabilities, and code quality issues in local branch changes. Use when asked to review changes, find bugs, security review, or audit code on the current branch.
----
-
-# Find Bugs
-
-Review changes on this branch for bugs, security vulnerabilities, and code quality issues.
-
-## Phase 1: Complete Input Gathering
-
-1. Get the FULL diff: `git diff $(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')...HEAD`
-2. If output is truncated, read each changed file individually until you have seen every changed line
-3. List all files modified in this branch before proceeding
-
-## Phase 2: Attack Surface Mapping
-
-For each changed file, identify and list:
-
-* All user inputs (request params, headers, body, URL components)
-* All database queries
-* All authentication/authorization checks
-* All session/state operations
-* All external calls
-* All cryptographic operations
-
-## Phase 3: Security Checklist (check EVERY item for EVERY file)
-
-* [ ] **Injection**: SQL, command, template, header injection
-* [ ] **XSS**: All outputs in templates properly escaped?
-* [ ] **Authentication**: Auth checks on all protected operations?
-* [ ] **Authorization/IDOR**: Access control verified, not just auth?
-* [ ] **CSRF**: State-changing operations protected?
-* [ ] **Race conditions**: TOCTOU in any read-then-write patterns?
-* [ ] **Session**: Fixation, expiration, secure flags?
-* [ ] **Cryptography**: Secure random, proper algorithms, no secrets in logs?
-* [ ] **Information disclosure**: Error messages, logs, timing attacks?
-* [ ] **DoS**: Unbounded operations, missing rate limits, resource exhaustion?
-* [ ] **Business logic**: Edge cases, state machine violations, numeric overflow?
-
-## Phase 4: Verification
-
-For each potential issue:
-
-* Check if it's already handled elsewhere in the changed code
-* Search for existing tests covering the scenario
-* Read surrounding context to verify the issue is real
-
-## Phase 5: Pre-Conclusion Audit
-
-Before finalizing, you MUST:
-
-1. List every file you reviewed and confirm you read it completely
-2. List every checklist item and note whether you found issues or confirmed it's clean
-3. List any areas you could NOT fully verify and why
-4. Only then provide your final findings
-
-## Output Format
-
-**Prioritize**: security vulnerabilities > bugs > code quality
-
-**Skip**: stylistic/formatting issues
-
-For each issue:
-
-* **File:Line** - Brief description
-* **Severity**: Critical/High/Medium/Low
-* **Problem**: What's wrong
-* **Evidence**: Why this is real (not already fixed, no existing test, etc.)
-* **Fix**: Concrete suggestion
-* **References**: OWASP, RFCs, or other standards if applicable
-
-If you find nothing significant, say so - don't invent issues.
-
-Do not make changes - just report findings. I'll decide what to address.