golem-cc 2.0.0 → 2.1.0

package/commands/golem/security.md

@@ -0,0 +1,204 @@
+---
+name: golem:security
+description: Run automated security scans
+allowed-tools: [Read, Bash, Write]
+---
+
+<objective>
+Run automated security tooling to detect vulnerabilities before code review. Uses gitleaks (secrets), semgrep (SAST), pnpm audit (dependencies), and trivy (containers).
+</objective>
+
+<context>
+Current ticket:
+```bash
+TICKET_ID=$(basename "$(pwd)" | grep -oE '(INC|SR)-[0-9]+' || echo "")
+echo "Ticket: ${TICKET_ID:-none}"
+```
+
+Check available tools:
+```bash
+echo "Checking security tools..."
+which gitleaks && gitleaks version || echo "gitleaks: NOT INSTALLED"
+which semgrep && semgrep --version || echo "semgrep: NOT INSTALLED"
+which trivy && trivy --version || echo "trivy: NOT INSTALLED"
+pnpm --version && echo "pnpm: OK" || echo "pnpm: NOT INSTALLED"
+```
+</context>
+
+<process>
+
+## Phase 1: Pre-flight
+
+Check which security tools are available. Not all are required - run what's available.
+
+Required tools and install commands:
+- **gitleaks**: `brew install gitleaks` or `go install github.com/gitleaks/gitleaks/v8@latest`
+- **semgrep**: `brew install semgrep` or `pip install semgrep`
+- **trivy**: `brew install trivy` or `curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh`
+- **pnpm**: `npm install -g pnpm`
+
+## Phase 2: Run Security Scans
+
+Run each available tool and capture results:
+
+### 2.1 Secrets Scan (gitleaks)
+```bash
+if command -v gitleaks &> /dev/null; then
+  echo "=== SECRETS SCAN (gitleaks) ==="
+  if [ -f .gitleaks.toml ]; then
+    gitleaks detect --config .gitleaks.toml --no-git -v 2>&1
+  else
+    gitleaks detect --no-git -v 2>&1
+  fi
+  echo "Exit code: $?"
+fi
+```
+
+Scans for:
+- API keys (AWS, GCP, Azure, Stripe, etc.)
+- Private keys (RSA, SSH, PGP)
+- Database connection strings with passwords
+- OAuth/JWT tokens
+- Hardcoded credentials
+
+### 2.2 SAST Scan (semgrep)
+```bash
+if command -v semgrep &> /dev/null; then
+  echo "=== SAST SCAN (semgrep) ==="
+  semgrep scan --config auto --json 2>&1 | head -200
+  echo "Exit code: $?"
+fi
+```
+
+Scans for OWASP Top 10:
+- A01: Broken Access Control
+- A02: Cryptographic Failures
+- A03: Injection (SQL, XSS, Command)
+- A04: Insecure Design
+- A05: Security Misconfiguration
+- A06: Vulnerable Components
+- A07: Authentication Failures
+- A08: Data Integrity Failures
+- A09: Logging Failures
+- A10: SSRF
+
+### 2.3 Dependency Scan (pnpm audit)
+```bash
+if [ -f package.json ]; then
+  echo "=== DEPENDENCY SCAN (pnpm audit) ==="
+  pnpm audit --json 2>&1 | head -100
+  echo "Exit code: $?"
+fi
+```
+
+Checks against:
+- National Vulnerability Database (NVD/CVE)
+- GitHub Advisory Database
+- npm Security Advisories
+
+### 2.4 Container Scan (trivy)
+```bash
+if command -v trivy &> /dev/null && command -v docker &> /dev/null; then
+  # Check for local image or Dockerfile
+  if docker images --format "{{.Repository}}" 2>/dev/null | head -1 | grep -q .; then
+    echo "=== CONTAINER SCAN (trivy) ==="
+    IMAGE=$(docker images --format "{{.Repository}}:{{.Tag}}" 2>/dev/null | head -1)
+    trivy image --severity HIGH,CRITICAL "$IMAGE" 2>&1 | head -100
+    echo "Exit code: $?"
+  elif [ -f Dockerfile ]; then
+    echo "=== DOCKERFILE SCAN (trivy) ==="
+    trivy config Dockerfile 2>&1
+    echo "Exit code: $?"
+  else
+    echo "=== CONTAINER SCAN: SKIPPED (no image or Dockerfile) ==="
+  fi
+fi
+```
+
+Scans for:
+- OS package vulnerabilities
+- Application dependencies in image
+- Dockerfile misconfigurations
+
+## Phase 3: Generate Report
+
+Write `.golem/SECURITY_REPORT.md`:
+
+```markdown
+# Security Scan Report
+
+**Generated:** {ISO timestamp}
+**Ticket:** {TICKET_ID}
+
+## Summary
+
+| Scan | Status | Findings |
+|------|--------|----------|
+| Secrets (gitleaks) | {PASS/FAIL/SKIPPED} | {count} |
+| SAST (semgrep) | {PASS/FAIL/SKIPPED} | {count} |
+| Dependencies (pnpm) | {PASS/FAIL/SKIPPED} | {high}/{critical} |
+| Container (trivy) | {PASS/FAIL/SKIPPED} | {count} |
+
+## Verdict
+
+{PASS | FAIL | PARTIAL}
+
+---
+
+## Findings
+
+### Secrets
+{details or "No secrets detected"}
+
+### SAST
+{details or "No vulnerabilities detected"}
+
+### Dependencies
+{details or "No vulnerable dependencies"}
+
+### Container
+{details or "No container vulnerabilities"}
+
+---
+
+## Next Steps
+
+{If FAIL: list what needs to be fixed}
+{If PASS: "Ready for code review - run /golem:review"}
+```
+
+## Phase 4: Verdict
+
+**PASS**: All scans passed (or skipped due to missing tools)
+- Announce ready for review
+- Suggest running `/golem:review`
+
+**FAIL**: Any scan found issues
+- List critical findings
+- Block until fixed
+- Do NOT proceed to review
+
+**PARTIAL**: Some tools missing
+- Warn about missing coverage
+- Suggest installing missing tools
+- Allow proceeding with caution
+
+</process>
+
+<success_criteria>
+- [ ] Available security tools identified
+- [ ] Secrets scan completed (if gitleaks available)
+- [ ] SAST scan completed (if semgrep available)
+- [ ] Dependency scan completed (if package.json exists)
+- [ ] Container scan completed (if applicable)
+- [ ] Report generated at .golem/SECURITY_REPORT.md
+- [ ] Clear verdict provided
+</success_criteria>
+
+<important>
+- This is READ-ONLY - do not fix issues, just report them
+- Any secrets found are CRITICAL - must be rotated immediately
+- High/Critical dependency vulns should block merge
+- Missing tools should trigger a warning, not a failure
+- Container scan only runs if image exists or Dockerfile present
+</important>

package/commands/golem/spec.md

@@ -1,11 +1,11 @@
 ---
 name: golem:spec
 description: Build project specs through guided conversation
-allowed-tools: [Read, Write, Glob, Grep, Bash, AskUserQuestion]
+allowed-tools: [Read, Write, Glob, Grep, Bash, AskUserQuestion, Task]
 ---
 
 <objective>
-Guide the user through a structured conversation to define requirements for the current ticket/issue and generate spec files. This creates the foundation for the implementation plan and build loop.
+Spawn an agent team to explore requirements from multiple angles, challenge assumptions, and generate robust specs. The team synthesizes findings into spec files that form the foundation for planning and building.
 </objective>
 
 <execution_context>
@@ -32,57 +32,91 @@ Project structure:
 ```bash
 if [ -f package.json ]; then echo "Node/TypeScript project"; head -30 package.json; fi
 if [ -f pyproject.toml ]; then echo "Python project"; head -30 pyproject.toml; fi
+if [ -f Cargo.toml ]; then echo "Rust project"; head -30 Cargo.toml; fi
 ```
 </context>
 
 <process>
 
-## Phase 1: Ticket Context
+## Phase 1: Gather Initial Context
 
-If we're in a ticket worktree:
-1. Read the Fresh ticket description and Gitea issue
-2. Summarize what the user/reporter is asking for
-3. Ask clarifying questions about the actual need
+Before spawning the team, gather baseline information:
 
-If NOT in a ticket worktree:
-1. Ask: "What are you building? What problem does this solve?"
-2. Offer to create a ticket: "Should I create a Fresh ticket and Gitea issue for this work?"
+1. If in a ticket worktree: read the ticket description
+2. If NOT in a ticket worktree: ask what we're building
+3. Get a rough sense of scope and purpose
 
-## Phase 2: Requirement Extraction
+## Phase 2: Spawn Spec Team
 
-Understand the scope:
-1. **What's the actual problem?** - Not the solution, the problem
-2. **Who's affected?** - Users, internal, integrations?
-3. **What's the minimum viable fix/feature?** - v1 scope
-4. **What's explicitly NOT in scope?** - Boundaries
+Create an agent team with three specialized teammates:
 
-Use `AskUserQuestion` for concrete choices, open questions for exploration.
+```
+Create an agent team to explore requirements for this feature/fix.
+Spawn three teammates:
+
+1. **UX Advocate** - Focuses on user experience and usability:
+   - Who are the users?
+   - What's their workflow?
+   - What's the simplest interface that solves the problem?
+   - Where will users get confused or frustrated?
+
+2. **Architect** - Focuses on technical design:
+   - What's the system architecture?
+   - How does this fit into existing code?
+   - What are the technical constraints?
+   - What are the integration points?
+
+3. **Devil's Advocate** - Actively challenges assumptions:
+   - "Do we actually need this?"
+   - "What's the simplest thing that could work?"
+   - "What happens when X fails?"
+   - "Why not use existing solution Y?"
+
+   Rules for Devil's Advocate:
+   - Must articulate WHY something is problematic
+   - Must propose a concrete alternative
+   - Must back down when concern is adequately addressed
+   - Goal is better thinking, not blocking progress
+
+Have them explore the problem space simultaneously, share findings,
+and challenge each other's assumptions. The debate should surface
+requirements we'd otherwise miss.
+```
+
+## Phase 3: Team Exploration
 
-## Phase 3: Topic Decomposition
+Let the team explore these questions:
 
-Extract distinct "topics of concern":
-1. Based on what you learned, propose 1-5 topics
-   - Each topic should pass the "no AND test"
-   - Good: "input validation", "error handling", "API response format"
-   - Bad: "validation and error handling" (split these)
+### UX Advocate investigates:
+- What's the actual problem users face?
+- What's the minimum viable solution?
+- What edge cases will users encounter?
+- What error states need handling?
 
-2. Ask if any topics should be added, removed, or split
+### Architect investigates:
+- What existing code/patterns can we reuse?
+- What new components are needed?
+- What are the dependencies?
+- What technical constraints exist?
 
-## Phase 4: Spec Generation
+### Devil's Advocate challenges:
+- Is this feature actually necessary?
+- Are we overengineering?
+- What's the cost of NOT doing this?
+- What simpler alternatives exist?
 
-For each topic, have a focused mini-conversation:
+## Phase 4: Synthesize Findings
 
-1. **Requirements**: Ask 2-4 targeted questions:
-   - What MUST it do?
-   - What SHOULD it do if time allows?
-   - What must it NOT do?
-   - Technical constraints?
+After team exploration, synthesize into topics:
 
-2. **Tests**: What tests must pass for this to be considered done?
+1. Review findings from all three perspectives
+2. Identify 1-5 distinct topics of concern
+3. Each topic should pass the "no AND test"
+4. Resolve any conflicts between teammates
 
-3. **Write File**: Save to `.golem/specs/{topic-name}.md`
+## Phase 5: Generate Spec Files
 
-### Spec File Format
+For each topic, write to `.golem/specs/{topic-name}.md`:
 
 ```markdown
 # {Topic Name}
@@ -110,22 +144,22 @@ Ticket: {INC-XXXX} (if applicable)
 
 ## Tests
 - {Test description} → expects {outcome}
-- {Test description} → expects {outcome}
 
 ## Technical Notes
-{Implementation hints, constraints, or decisions}
+{Implementation hints, constraints, decisions}
+
+## Considered Alternatives
+{What the Devil's Advocate proposed and why we did/didn't take it}
 ```
 
-## Phase 5: Operational Setup
+## Phase 6: Operational Setup
 
-After all specs are written:
+After specs are written:
 
 1. Create `.golem/specs/` directory if needed
 2. Write each spec file
 3. Detect or ask for test/build/lint commands
-4. Write `.golem/AGENTS.md`
-
-### AGENTS.md Format
+4. Write `.golem/AGENTS.md`:
 
 ```markdown
 # Operational Guide
@@ -154,16 +188,15 @@ Branch: {branch-name}
 <!-- Updated during build iterations -->
 ```
 
-## Phase 6: Sync & Completion
+## Phase 7: Cleanup & Completion
 
-1. Update the ticket status to "spec" in Fresh and Gitea:
+1. Clean up the agent team
+2. Update ticket status:
    ```bash
    golem-api ticket:status $TICKET_ID spec --note "Specs complete"
    ```
-
-2. Summarize what was created
-
-3. Show next steps:
+3. Summarize what was created
+4. Show next steps:
    ```
    Specs complete! Next steps:
    1. Review .golem/specs/ and adjust if needed
@@ -174,10 +207,20 @@ Branch: {branch-name}
 </process>
 
 <success_criteria>
-- [ ] Ticket context incorporated
-- [ ] User requirements fully captured
+- [ ] Agent team explored requirements from 3 perspectives
+- [ ] Devil's advocate challenged assumptions
+- [ ] Conflicts resolved through discussion
 - [ ] Each topic has a separate spec file
 - [ ] Tests defined in each spec
+- [ ] Alternatives considered and documented
 - [ ] AGENTS.md exists with operational commands
-- [ ] Ticket status synced to Fresh/Gitea
+- [ ] Team cleaned up
+- [ ] Ticket status synced
 </success_criteria>
+
+<important>
+- The Devil's Advocate must be ACTIVE, not passive criticism
+- All three perspectives should contribute to final specs
+- Document "Considered Alternatives" so we remember why we chose this path
+- Clean up the team when done
+</important>

package/golem/prompts/PROMPT_build.md

@@ -1,67 +1,71 @@
-# Build Mode
+# Build Lead Mode
 
-You are in BUILD MODE. Implement ONE task from the plan, then exit.
+You are the BUILD LEAD. You orchestrate the build process but do NOT implement tasks yourself.
 
-## Phase 0: Orient
+## Your Role
 
-Study these files to understand context:
-- @.golem/specs/* - All specification files
-- @.golem/AGENTS.md - Operational commands (test/build/lint)
-- @.golem/IMPLEMENTATION_PLAN.md - Current task list
+- Spawn builder teammates for each task (one at a time)
+- Monitor their progress
+- Handle blockers and failures
+- Keep the user informed
+- Commit and squash when appropriate
 
-## Phase 1: Select Task
+## The Loop
 
-1. Read .golem/IMPLEMENTATION_PLAN.md
-2. Identify current stage
-3. Pick the first incomplete task (marked `- [ ]`) in that stage
-4. Do NOT assume something is not implemented - search first
+For each task:
 
-## Phase 2: Implement
+1. **Announce** the task to the user
+2. **Spawn** a builder teammate with fresh context
+3. **Monitor** the builder's progress
+4. **Handle** success (commit) or failure (surface to user)
+5. **Continue** to next task or **squash** at stage end
 
-1. Search codebase to understand existing patterns
-2. Make the required changes
-3. Follow existing code patterns exactly
-4. Write tests alongside implementation
-5. Keep changes minimal and focused
+## Builder Teammate Prompt Template
 
-## Phase 3: Validate (Backpressure)
+When spawning a builder:
 
-Run commands from .golem/AGENTS.md in order. ALL must pass:
-1. Tests
-2. Type check (if configured)
-3. Lint (if configured)
+```
+You are a builder. Complete this ONE task, then shut down.
 
-If ANY fails: fix the issue, then re-run ALL validation from the beginning.
+TASK: {task title}
+FILES: {expected files}
+NOTES: {implementation hints}
+TESTS: {what tests verify this}
 
-## Phase 4: Simplify
+WORKFLOW:
+1. Write tests first (red phase)
+2. Implement minimum code to pass tests (green phase)
+3. Run validation gates from .golem/AGENTS.md
+4. If gates fail: fix and retry (up to 3 attempts)
+5. Simplify code
+6. Re-run validation
+7. Report: SUCCESS or BLOCKED with reason
 
-After tests pass:
-1. Apply code-simplifier rules to modified files
-2. Re-run all validation
-3. Skip if no safe simplifications found
+DO NOT commit or modify the plan - the lead handles that.
+If stuck, report BLOCKED immediately. Do not spin.
+```
 
-## Phase 5: Complete
+## Handling Blockers
 
-1. Update .golem/IMPLEMENTATION_PLAN.md - mark task `- [x]`
-2. Update .golem/AGENTS.md learnings if you discovered something useful
-3. Commit with WIP message:
-   ```bash
-   git add -A
-   git commit -m "wip: {task description} [{TICKET_ID}]"
-   ```
+When a builder reports BLOCKED:
+- Surface immediately to the user
+- Present options (skip, retry with guidance, wait for fix)
+- Do NOT auto-retry
+- The user has visibility and can help
 
-## Phase 6: Stage Completion
+## User Commands
 
-Check if current stage is complete (all tasks marked `[x]`):
-- If yes: inform user, suggest running `golem squash` to squash commits
-- If no: inform user of remaining tasks in stage
+The user can say:
+- **skip** - Skip blocked task
+- **retry** - Try the task again
+- **stop** - Pause the build
+- **status** - Show progress
 
-## Phase 999: Critical Rules
+## Critical Rules
 
-- Complete ONE task only per iteration
-- Do NOT skip validation - all gates must pass
-- Do NOT assume code doesn't exist - always search first
-- Trust the tests - passing = correct
-- Exit after committing so next iteration gets fresh context
-- Each task = WIP commit
-- Each stage = squashed commit (done by CLI)
+- You are the LEAD - delegate, don't implement
+- Each builder gets fresh context (one task, then shutdown)
+- Surface blockers immediately
+- Keep user informed at every step
+- Handle commits and plan updates yourself
+- Squash at stage completion

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "golem-cc",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "description": "Personal agentic workflow: Freshworks ↔ Gitea ↔ Local development",
   "repository": {
     "type": "git",