Files
gastown/.beads/formulas/mol-polecat-shiny.formula.toml
Steve Yegge 91236ea268 feat: Add polecat workflow quality levels (basic/shiny/chrome)
Three pre-baked polecat workflows with increasing rigor:
- mol-polecat-basic: 3 steps, for trivial P4 fixes
- mol-polecat-shiny: 6 steps, standard quality with design/review
- mol-polecat-chrome: 16 steps, max rigor with strategic context reading,
  triple code review, and decomposed implementation phases

Added --quality (-q) flag to gt sling as shorthand:
  gt sling gt-abc gastown -q basic   # quick fix
  gt sling gt-abc gastown -q shiny   # standard
  gt sling gt-abc gastown -q chrome  # max rigor

Chrome explicitly requires reading ~/gt/docs/hop/CONTEXT.md and
~/gt/docs/PRIMING.md before design begins.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2025-12-29 23:19:32 -08:00

179 lines
4.3 KiB
TOML

description = """
Standard quality polecat workflow with design and review phases.
Engineer in a Box - the canonical right way for most work. Design before you
code. Review before you ship. Test before you submit.
## When to Use
- P2/P3 features and bugs
- New functionality
- Refactoring work
- Any non-trivial change
## Phases
1. **Preflight** - Load context, understand assignment
2. **Design** - Think before you code
3. **Implement** - Write the code
4. **Review** - Self-review your changes
5. **Test** - Run tests, verify coverage
6. **Postflight** - Submit and signal done
"""
formula = "mol-polecat-shiny"
type = "workflow"
version = 1
[[steps]]
id = "preflight"
title = "Load context and verify assignment"
description = """
Initialize your session and understand your assignment.
```bash
gt prime # Load role context
bd prime # Load beads context
gt mol status # Check your hook
bd show {{issue}} # Full issue details
gt mail inbox # Check for additional context
```
Understand:
- What exactly needs to be done?
- What files are likely involved?
- Are there dependencies or blockers?
- What does "done" look like?
If blocked or unclear, mail Witness immediately.
**Exit criteria:** You understand the work and can begin."""
[[steps]]
id = "design"
title = "Design {{feature}}"
needs = ["preflight"]
description = """
Think carefully about architecture BEFORE writing code.
Consider:
- How does this fit into the existing system?
- What are the edge cases?
- What could go wrong?
- Is there a simpler approach?
- What existing patterns should you follow?
Write a brief design note (can be in your head or as a comment):
- Approach: <how you'll solve it>
- Files: <what you'll modify>
- Risks: <what might go wrong>
**Exit criteria:** You have a clear plan before touching code."""
[[steps]]
id = "implement"
title = "Implement {{feature}}"
needs = ["design"]
description = """
Write the code following your design.
Working principles:
- Follow existing codebase conventions
- Make atomic, focused commits
- Keep changes scoped to the assigned issue
- Don't gold-plate or scope-creep
```bash
# Commit frequently:
git add <files>
git commit -m "<type>: <description> ({{issue}})"
```
If you find unrelated bugs, file a bead - don't fix them in this branch.
**Exit criteria:** Implementation complete, all changes committed."""
[[steps]]
id = "review"
title = "Review implementation"
needs = ["implement"]
description = """
Self-review your changes before running tests.
```bash
git diff origin/main...HEAD # All changes vs main
git log --oneline origin/main..HEAD # All commits
```
Check for:
| Category | Look For |
|----------|----------|
| Bugs | Off-by-one, null handling, edge cases |
| Security | Injection, auth bypass, exposed secrets |
| Style | Naming, formatting, code organization |
| Completeness | Missing error handling, incomplete paths |
| Cruft | Debug prints, commented code, TODOs |
Fix issues found - don't just note them.
**Exit criteria:** Changes are clean and ready for testing."""
[[steps]]
id = "test"
title = "Test {{feature}}"
needs = ["review"]
description = """
Run tests and verify coverage.
```bash
go test ./... # Full test suite
```
**ALL TESTS MUST PASS.** Do not proceed with failures.
If tests fail:
- Read the failure carefully
- If your change caused it: fix it
- If pre-existing: file a bead, but you still need green tests
New features should have tests. Bug fixes should have regression tests.
```bash
# Build check
go build ./...
```
**Exit criteria:** All tests pass, new code has appropriate coverage."""
[[steps]]
id = "postflight"
title = "Submit for merge"
needs = ["test"]
description = """
Clean up and submit.
```bash
# Verify clean state
git status # Should be clean
git stash list # Should be empty
# Push branch
git push -u origin $(git branch --show-current)
# Close issue
bd close {{issue}} --reason "Implemented: {{feature}}"
bd sync
# Signal done
gt done
```
Witness will verify, send to merge queue, and terminate your session.
**Exit criteria:** Witness takes over from here."""
[vars]
[vars.issue]
description = "The issue ID assigned to this polecat"
required = true
[vars.feature]
description = "The feature being implemented"
required = true