Files
gastown/internal/formula/formulas/mol-polecat-code-review.formula.toml
scout/crew/picard 0be6a39bb7 fix: enforce fresh context between molecule steps
Change molecule step completion instructions to use `gt mol step done`
instead of `bd close`. This ensures polecats get fresh context between
each step, which is critical for multi-step review workflows like
shiny-enterprise where each refinement pass should have unbiased attention.

The `gt mol step done` command already:
1. Closes the step
2. Finds the next ready step
3. Respawns the pane for fresh context

But polecats were being instructed to use `bd close` directly, which
skipped the respawn and let them run through entire workflows in a
single session with accumulated context.

Updated:
- prime_molecule.go: step completion instructions
- mol-polecat-work.formula.toml
- mol-polecat-code-review.formula.toml
- mol-polecat-review-pr.formula.toml

Fixes: hq-0kx7ra
2026-01-25 11:15:29 -08:00

322 lines
8.3 KiB
TOML

description = """
Review code and file beads for issues found.
This molecule guides a polecat through a code review task - examining a portion
of the codebase for bugs, security issues, code quality problems, or improvement
opportunities. The output is a set of beads capturing actionable findings.
## Polecat Contract (Self-Cleaning Model)
You are a self-cleaning worker. You:
1. Receive work via your hook (pinned molecule + review scope)
2. Work through molecule steps using `bd ready` / `gt mol step done <step>`
3. Complete and self-clean via `gt done` (submit findings + nuke yourself)
4. You are GONE - your findings are recorded in beads
**Fresh context:** Each `gt mol step done` respawns your session with fresh context.
This ensures each review step gets unbiased attention.
**Self-cleaning:** When you run `gt done`, you submit your findings, nuke your
sandbox, and exit. There is no idle state. Done means gone.
**Important:** This formula defines the template. Your molecule already has step
beads created from it. Use `bd ready` to find them - do NOT read this file directly.
**You do NOT:**
- Fix the issues yourself (file beads, let other polecats fix)
- Scope creep into unrelated areas
- Wait for someone to act on findings (you're done after filing)
## Variables
| Variable | Source | Description |
|----------|--------|-------------|
| scope | hook_bead | What to review (file path, directory, or description) |
| issue | hook_bead | The tracking issue for this review task |
| focus | hook_bead | Optional focus area (security, performance, etc.) |
## Failure Modes
| Situation | Action |
|-----------|--------|
| Scope too broad | Mail Witness, request narrower scope |
| Can't understand code | Mail Witness for context |
| Critical issue found | Mail Witness immediately, then continue |"""
formula = "mol-polecat-code-review"
version = 1
[[steps]]
id = "load-context"
title = "Load context and understand the review scope"
description = """
Initialize your session and understand what you're reviewing.
**1. Prime your environment:**
```bash
gt prime # Load role context
bd prime # Load beads context
```
**2. Check your hook:**
```bash
gt hook # Shows your pinned molecule and hook_bead
```
The hook_bead describes your review scope. Read the tracking issue:
```bash
bd show {{issue}} # Full issue details
```
**3. Understand the scope:**
- What files/directories are in scope?
- Is there a specific focus (security, performance, correctness)?
- What's the context - why is this review happening?
**4. Locate the code:**
```bash
# If scope is a path:
ls -la {{scope}}
head -100 {{scope}} # Quick look at the code
# If scope is a directory:
find {{scope}} -type f -name "*.go" | head -20
```
**5. Check for recent changes:**
```bash
git log --oneline -10 -- {{scope}}
```
**Exit criteria:** You understand what you're reviewing and why."""
[[steps]]
id = "survey-code"
title = "Survey the code structure"
needs = ["load-context"]
description = """
Get a high-level understanding before diving into details.
**1. Understand the structure:**
```bash
# For a directory:
tree {{scope}} -L 2
# For a file:
wc -l {{scope}} # How big is it?
```
**2. Identify key components:**
- What are the main types/structs?
- What are the public functions?
- What are the dependencies?
**3. Read the tests (if any):**
```bash
find {{scope}} -name "*_test.go" | xargs head -50
```
Tests often reveal intended behavior.
**4. Note initial impressions:**
- Is the code well-organized?
- Are there obvious patterns or anti-patterns?
- What areas look risky?
**Exit criteria:** You have a mental map of the code structure."""
[[steps]]
id = "detailed-review"
title = "Perform detailed code review"
needs = ["survey-code"]
description = """
Systematically review the code for issues.
**Review checklist:**
| Category | Look For |
|----------|----------|
| **Correctness** | Logic errors, off-by-one, nil handling, race conditions |
| **Security** | Injection, auth bypass, secrets in code, unsafe operations |
| **Error handling** | Swallowed errors, missing checks, unclear error messages |
| **Performance** | N+1 queries, unnecessary allocations, blocking calls |
| **Maintainability** | Dead code, unclear naming, missing comments on complex logic |
| **Testing** | Untested paths, missing edge cases, flaky tests |
**Focus on {{focus}} if specified.**
**1. Read through the code:**
```bash
cat {{scope}} # For single file
# Or read files systematically for a directory
```
**2. For each issue found, note:**
- File and line number
- Category (bug, security, performance, etc.)
- Severity (critical, high, medium, low)
- Description of the issue
- Suggested fix (if obvious)
**3. Don't fix issues yourself:**
Your job is to find and report, not fix. File beads.
**Exit criteria:** You've reviewed all code in scope and noted issues."""
[[steps]]
id = "prioritize-findings"
title = "Prioritize and categorize findings"
needs = ["detailed-review"]
description = """
Organize your findings by priority and category.
**Priority levels:**
| Priority | Description | Action |
|----------|-------------|--------|
| P0 | Security vulnerability, data loss risk | Mail Witness immediately |
| P1 | Bug affecting users, broken functionality | File as bug, high priority |
| P2 | Code quality issue, potential future bug | File as task |
| P3 | Improvement opportunity, nice-to-have | File as task, low priority |
**1. Sort your findings:**
Group by priority, then by category.
**2. For P0 issues:**
```bash
gt mail send {{rig}}/witness -s "CRITICAL: Security issue found" -m "Scope: {{scope}}
Issue: {{issue}}
Finding: <description of critical issue>
Location: <file:line>"
```
**3. Prepare bead descriptions:**
For each finding, prepare:
- Clear title
- File/line location
- Description of the issue
- Why it matters
- Suggested fix (if known)
**Exit criteria:** Findings prioritized and ready to file."""
[[steps]]
id = "file-beads"
title = "File beads for all findings"
needs = ["prioritize-findings"]
description = """
Create beads for each finding.
**1. For bugs (P0, P1):**
```bash
bd create --type=bug --priority=1 \
--title="<clear description of bug>" \
--description="Found during code review of {{scope}}.
Location: <file:line>
Issue:
<description>
Impact:
<why this matters>
Suggested fix:
<if known>"
```
**2. For code quality issues (P2, P3):**
```bash
bd create --type=task --priority=2 \
--title="<clear description>" \
--description="Found during code review of {{scope}}.
Location: <file:line>
Issue:
<description>
Suggestion:
<how to improve>"
```
**3. Track filed beads:**
Note each bead ID as you create them.
**4. If no issues found:**
That's a valid outcome! Note that the code review passed.
**Exit criteria:** All findings filed as beads."""
[[steps]]
id = "summarize-review"
title = "Summarize review results"
needs = ["file-beads"]
description = """
Update the tracking issue with review summary.
**1. Create summary:**
```bash
bd update {{issue}} --notes "Code review complete.
Scope: {{scope}}
Focus: {{focus}}
Findings:
- P0 (critical): <count>
- P1 (high): <count>
- P2 (medium): <count>
- P3 (low): <count>
Beads filed:
<list of bead IDs>
Overall assessment:
<brief summary - healthy, needs attention, significant issues, etc.>"
```
**2. Sync beads:**
```bash
bd sync
```
**Exit criteria:** Tracking issue updated with summary."""
[[steps]]
id = "complete-and-exit"
title = "Complete review and self-clean"
needs = ["summarize-review"]
description = """
Signal completion and clean up. You cease to exist after this step.
**Self-Cleaning Model:**
Once you run `gt done`, you're gone. The command:
1. Syncs beads (final sync)
2. Nukes your sandbox
3. Exits your session immediately
**Run gt done:**
```bash
gt done
```
**What happens next (not your concern):**
- Other polecats may be assigned to fix the issues you found
- Witness may escalate critical findings
- The codebase improves based on your findings
You are NOT involved in any of that. You're gone. Done means gone.
**Exit criteria:** Beads synced, sandbox nuked, session exited."""
[vars]
[vars.scope]
description = "What to review - file path, directory, or description"
required = true
[vars.issue]
description = "The tracking issue for this review task"
required = true
[vars.focus]
description = "Optional focus area (security, performance, correctness, etc.)"
required = false