@cubis/foundry 0.3.11 → 0.3.13

package/Ai Agent Workflow/powers/find-bugs/POWER.md

@@ -0,0 +1,78 @@
+````markdown
+---
+inclusion: manual
+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.
+````

package/Ai Agent Workflow/powers/fix-review/POWER.md

@@ -0,0 +1,262 @@
+````markdown
+---
+inclusion: manual
+name: fix-review
+description: Verify remediation commits against security audit findings and confirm fixes without introducing regressions.
+allowed-tools:
+  - Read
+  - Write
+  - Grep
+  - Glob
+  - Bash
+  - WebFetch
+---
+
+# Fix Review
+
+Differential analysis to verify commits address security findings without introducing bugs.
+
+## When to Use
+
+- Reviewing fix branches against security audit reports
+- Validating that remediation commits actually address findings
+- Checking if specific findings (TOB-XXX format) have been fixed
+- Analyzing commit ranges for bug introduction patterns
+- Cross-referencing code changes with audit recommendations
+
+## When NOT to Use
+
+- Initial security audits (use audit-context-building or differential-review)
+- Code review without a specific baseline or finding set
+- Greenfield development with no prior audit
+- Documentation-only changes
+
+---
+
+## Rationalizations (Do Not Skip)
+
+| Rationalization | Why It's Wrong | Required Action |
+|-----------------|----------------|-----------------|
+| "The commit message says it fixes TOB-XXX" | Messages lie; code tells truth | Verify the actual code change addresses the finding |
+| "Small fix, no new bugs possible" | Small changes cause big bugs | Analyze all changes for anti-patterns |
+| "I'll check the important findings" | All findings matter | Systematically check every finding |
+| "The tests pass" | Tests may not cover the fix | Verify fix logic, not just test status |
+| "Same developer, they know the code" | Familiarity breeds blind spots | Fresh analysis of every change |
+
+---
+
+## Quick Reference
+
+### Input Requirements
+
+| Input | Required | Format |
+|-------|----------|--------|
+| Source commit | Yes | Git commit hash or ref (baseline before fixes) |
+| Target commit(s) | Yes | One or more commit hashes to analyze |
+| Security report | No | Local path, URL, or Google Drive link |
+
+### Finding Status Values
+
+| Status | Meaning |
+|--------|---------|
+| FIXED | Code change directly addresses the finding |
+| PARTIALLY_FIXED | Some aspects addressed, others remain |
+| NOT_ADDRESSED | No relevant changes found |
+| CANNOT_DETERMINE | Insufficient context to verify |
+
+---
+
+## Workflow
+
+### Phase 1: Input Gathering
+
+Collect required inputs from user:
+
+```
+Source commit:  [hash/ref before fixes]
+Target commit:  [hash/ref to analyze]
+Report:         [optional: path, URL, or "none"]
+```
+
+If user provides multiple target commits, process each separately with the same source.
+
+### Phase 2: Report Retrieval
+
+When a security report is provided, retrieve it based on format:
+
+**Local file (PDF, MD, JSON, HTML):**
+Read the file directly using the Read tool. Claude processes PDFs natively.
+
+**URL:**
+Fetch web content using the WebFetch tool.
+
+**Google Drive URL that fails:**
+See `references/report-parsing.md` for Google Drive fallback logic using `gdrive` CLI.
+
+### Phase 3: Finding Extraction
+
+Parse the report to extract findings:
+
+**Trail of Bits format:**
+- Look for "Detailed Findings" section
+- Extract findings matching pattern: `TOB-[A-Z]+-[0-9]+`
+- Capture: ID, title, severity, description, affected files
+
+**Other formats:**
+- Numbered findings (Finding 1, Finding 2)
+- Severity-based sections (Critical, High, Medium, Low)
+- JSON with `findings` array
+
+See `references/report-parsing.md` for detailed parsing strategies.
+
+### Phase 4: Commit Analysis
+
+For each target commit, analyze the commit range:
+
+```bash
+# Get commit list from source to target
+git log <source>..<target> --oneline
+
+# Get full diff
+git diff <source>..<target>
+
+# Get changed files
+git diff <source>..<target> --name-only
+```
+
+For each commit in the range:
+1. Examine the diff for bug introduction patterns
+2. Check for security anti-patterns (see `references/bug-detection.md`)
+3. Map changes to relevant findings
+
+### Phase 5: Finding Verification
+
+For each finding in the report:
+
+1. **Identify relevant commits** - Match by:
+   - File paths mentioned in finding
+   - Function/variable names in finding description
+   - Commit messages referencing the finding ID
+
+2. **Verify the fix** - Check that:
+   - The root cause is addressed (not just symptoms)
+   - The fix follows the report's recommendation
+   - No new vulnerabilities are introduced
+
+3. **Assign status** - Based on evidence:
+   - FIXED: Clear code change addresses the finding
+   - PARTIALLY_FIXED: Some aspects fixed, others remain
+   - NOT_ADDRESSED: No relevant changes
+   - CANNOT_DETERMINE: Need more context
+
+4. **Document evidence** - For each finding:
+   - Commit hash(es) that address it
+   - Specific file and line changes
+   - How the fix addresses the root cause
+
+See `references/finding-matching.md` for detailed matching strategies.
+
+### Phase 6: Output Generation
+
+Generate two outputs:
+
+**1. Report file (`FIX_REVIEW_REPORT.md`):**
+
+```markdown
+# Fix Review Report
+
+**Source:** <commit>
+**Target:** <commit>
+**Report:** <path or "none">
+**Date:** <date>
+
+## Executive Summary
+
+[Brief overview: X findings reviewed, Y fixed, Z concerns]
+
+## Finding Status
+
+| ID | Title | Severity | Status | Evidence |
+|----|-------|----------|--------|----------|
+| TOB-XXX-1 | Finding title | High | FIXED | abc123 |
+| TOB-XXX-2 | Another finding | Medium | NOT_ADDRESSED | - |
+
+## Bug Introduction Concerns
+
+[Any potential bugs or regressions detected in the changes]
+
+## Per-Commit Analysis
+
+### Commit abc123: "Fix reentrancy in withdraw()"
+
+**Files changed:** contracts/Vault.sol
+**Findings addressed:** TOB-XXX-1
+**Concerns:** None
+
+[Detailed analysis]
+
+## Recommendations
+
+[Any follow-up actions needed]
+```
+
+**2. Conversation summary:**
+
+Provide a concise summary in the conversation:
+- Total findings: X
+- Fixed: Y
+- Not addressed: Z
+- Concerns: [list any bug introduction risks]
+
+---
+
+## Bug Detection
+
+Analyze commits for security anti-patterns. Key patterns to watch:
+- Access control weakening (modifiers removed)
+- Validation removal (require/assert deleted)
+- Error handling reduction (try/catch removed)
+- External call reordering (state after call)
+- Integer operation changes (SafeMath removed)
+- Cryptographic weakening
+
+See `references/bug-detection.md` for comprehensive detection patterns and examples.
+
+---
+
+## Integration with Other Skills
+
+**differential-review:** For initial security review of changes (before audit)
+
+**issue-writer:** To format findings into formal audit reports
+
+**audit-context-building:** For deep context when analyzing complex fixes
+
+---
+
+## Tips for Effective Reviews
+
+**Do:**
+- Verify the actual code change, not just commit messages
+- Check that fixes address root causes, not symptoms
+- Look for unintended side effects in adjacent code
+- Cross-reference multiple findings that may interact
+- Document evidence for every status assignment
+
+**Don't:**
+- Trust commit messages as proof of fix
+- Skip findings because they seem minor
+- Assume passing tests mean correct fixes
+- Ignore changes outside the "fix" scope
+- Mark FIXED without clear evidence
+
+---
+
+## Reference Files
+
+For detailed guidance, consult:
+
+- **`references/finding-matching.md`** - Strategies for matching commits to findings
+- **`references/bug-detection.md`** - Comprehensive anti-pattern detection
+- **`references/report-parsing.md`** - Parsing different report formats, Google Drive fallback
+````

package/Ai Agent Workflow/powers/fix-review/SKILL.md

@@ -89,7 +89,7 @@ Read the file directly using the Read tool. Claude processes PDFs natively.
 Fetch web content using the WebFetch tool.
 
 **Google Drive URL that fails:**
-See `steering/report-parsing.md` for Google Drive fallback logic using `gdrive` CLI.
+See `references/report-parsing.md` for Google Drive fallback logic using `gdrive` CLI.
 
 ### Phase 3: Finding Extraction
 
@@ -105,7 +105,7 @@ Parse the report to extract findings:
 - Severity-based sections (Critical, High, Medium, Low)
 - JSON with `findings` array
 
-See `steering/report-parsing.md` for detailed parsing strategies.
+See `references/report-parsing.md` for detailed parsing strategies.
 
 ### Phase 4: Commit Analysis
 
@@ -124,7 +124,7 @@ git diff <source>..<target> --name-only
 
 For each commit in the range:
 1. Examine the diff for bug introduction patterns
-2. Check for security anti-patterns (see `steering/bug-detection.md`)
+2. Check for security anti-patterns (see `references/bug-detection.md`)
 3. Map changes to relevant findings
 
 ### Phase 5: Finding Verification
@@ -152,7 +152,7 @@ For each finding in the report:
    - Specific file and line changes
    - How the fix addresses the root cause
 
-See `steering/finding-matching.md` for detailed matching strategies.
+See `references/finding-matching.md` for detailed matching strategies.
 
 ### Phase 6: Output Generation
 
@@ -218,7 +218,7 @@ Analyze commits for security anti-patterns. Key patterns to watch:
 - Integer operation changes (SafeMath removed)
 - Cryptographic weakening
 
-See `steering/bug-detection.md` for comprehensive detection patterns and examples.
+See `references/bug-detection.md` for comprehensive detection patterns and examples.
 
 ---
 
@@ -254,6 +254,6 @@ See `steering/bug-detection.md` for comprehensive detection patterns and example
 
 For detailed guidance, consult:
 
-- **`steering/finding-matching.md`** - Strategies for matching commits to findings
-- **`steering/bug-detection.md`** - Comprehensive anti-pattern detection
-- **`steering/report-parsing.md`** - Parsing different report formats, Google Drive fallback
+- **`references/finding-matching.md`** - Strategies for matching commits to findings
+- **`references/bug-detection.md`** - Comprehensive anti-pattern detection
+- **`references/report-parsing.md`** - Parsing different report formats, Google Drive fallback

package/Ai Agent Workflow/powers/flutter-code-reviewer/POWER.md

@@ -1,4 +1,6 @@
+````markdown
 ---
+inclusion: manual
 name: "flutter-code-reviewer"
 displayName: "Flutter/Dart Code Reviewer"
 description: "Perform strict, actionable code reviews for Flutter/Dart projects enforcing architecture boundaries, Riverpod patterns, testing, and performance"
@@ -183,3 +185,4 @@ See: `steering/testing_expectations.md`
 ## Templates
 
 - `review_response.md` - Code review response template
+````

package/Ai Agent Workflow/powers/flutter-expert/POWER.md

@@ -1,4 +1,6 @@
+````markdown
 ---
+inclusion: manual
 name: "flutter-expert"
 displayName: "Flutter Expert"
 description: "Flutter app architecture coordinator for Clean Architecture projects; delegates state, routing, persistence, testing, and security to specialized skills"
@@ -52,10 +54,10 @@ It defines architecture boundaries and routes implementation details to speciali
 
 Use these only for high-level guidance in this skill:
 
-- `steering/project-structure.md`
-- `steering/widget-patterns.md`
-- `steering/performance.md`
-- `steering/engineering-principles.md`
+- `references/project-structure.md`
+- `references/widget-patterns.md`
+- `references/performance.md`
+- `references/engineering-principles.md`
 
 For Riverpod and GoRouter implementation details, use `riverpod-3` and `gorouter-restoration` directly.
 
@@ -66,3 +68,4 @@ flutter --version
 flutter analyze
 flutter test
 ```
+````

package/Ai Agent Workflow/powers/flutter-expert/SKILL.md

@@ -52,10 +52,10 @@ It defines architecture boundaries and routes implementation details to speciali
 
 Use these only for high-level guidance in this skill:
 
-- `steering/project-structure.md`
-- `steering/widget-patterns.md`
-- `steering/performance.md`
-- `steering/engineering-principles.md`
+- `references/project-structure.md`
+- `references/widget-patterns.md`
+- `references/performance.md`
+- `references/engineering-principles.md`
 
 For Riverpod and GoRouter implementation details, use `riverpod-3` and `gorouter-restoration` directly.
 

package/Ai Agent Workflow/powers/flutter-security-reviewer/POWER.md

@@ -1,4 +1,6 @@
+````markdown
 ---
+inclusion: manual
 name: "flutter-security-reviewer"
 displayName: "Flutter/Dart Security Reviewer"
 description: "Review Flutter/Dart code for security vulnerabilities: secure storage, network hardening, log redaction, and data protection"
@@ -202,3 +204,4 @@ logger.info('User login successful: userId=${user.id}');
 ## Templates
 
 - `security_review_response.md` - Security review report template
+````

package/Ai Agent Workflow/powers/flutter-test-master/POWER.md

@@ -1,4 +1,6 @@
+````markdown
 ---
+inclusion: manual
 name: "flutter-test-master"
 displayName: "Flutter Test Master"
 description: "Comprehensive Flutter testing guide covering unit tests, widget tests, integration tests, golden tests, and Riverpod provider testing with mocktail"
@@ -523,3 +525,4 @@ patrol test
 patrol test -d <device_id>
 patrol test --dart-define=TEST_EMAIL=user@test.com
 ```
+````