FYI Claude compared beans with beads

[sotte]

This is no real issue, just a FYI, maybe interesting.

As part of my beans evaluation, I asked claude to do the same tasks with beans and beads (using subagents) and report back to me.

These are the results:

● Done! Evaluation complete with isolated subagents. Here's what was created:

  Reports:
  - /tmp/beans-beads-eval/beads-evaluation.md - 772 lines of detailed Beads testing
  - /tmp/beans-beads-eval/beans-evaluation.md - 1052 lines of detailed Beans testing
  - /tmp/beans-beads-eval/evaluation-report.md - Synthesized comparison

  Key Findings:

  | Tool  | Score  | Strengths                                                                   | Weaknesses                                                                   |
  |-------|--------|-----------------------------------------------------------------------------|------------------------------------------------------------------------------|
  | Beads | 8.5/10 | Hierarchical child IDs (vk5.1), bd ready/bd blocked commands, deep git sync | No native search, can't combine filters, no delete confirmation              |
  | Beans | 9/10   | GraphQL power, native search, human-readable markdown files, delete safety  | No built-in ready command, ID prefix matching broken, steeper learning curve |

  Bottom line: Both are production-ready. Beans edges ahead for flexibility; Beads wins on workflow convenience. The hierarchical child IDs in Beads are particularly elegant (vk5.1, vk5.2, vk5.3 under epic vk5).

Also interesting, maybe even more than the above, how many tokens were used and tool calls were made:

● 2 Task agents finished (ctrl+o to expand)
   ├─ Evaluate Beads CLI tool · 58 tool uses · 37.6k tokens
   │  ⎿  Done
   └─ Evaluate Beans CLI tool · 84 tool uses · 55.3k tokens
      ⎿  Done

---

Prompt:

You are evaluating two CLI-based issue tracking tools: Beads (bd) and Beans.

Your goal: Test both tools through realistic workflows and document your experience.

Setup

You're in a test repository at: /tmp/beans-beads-eval
Both tools are installed and available in PATH.

Process

Run two sequential evaluations. For each tool:

1. Initialize and prime
2. Execute the test scenarios below
3. Document your experience (friction, errors, what worked well)

Evaluation 1: Beads (bd)

cd /tmp/beans-beads-eval/beads-test
bd init
bd prime

Now execute the scenarios below using bd commands. Document everything.

Evaluation 2: Beans

cd /tmp/beans-beads-eval/beans-test
beans init
beans prime

Now execute the same scenarios using beans commands. Document everything.

---

Test Scenarios

Execute these scenarios with each tool. Document: commands used, output, any errors, friction points.

Scenario 1: Basic Task Lifecycle

1. Create a task: "Implement user authentication"
2. List all open tasks
3. Update the task to in_progress status
4. Add a description: "OAuth2 with Google provider"
5. Close the task with a reason
6. Verify it shows as closed

Scenario 2: Dependency Management

1. Create an epic: "Payment System"
2. Create 3 child tasks:
   • "Design payment schema"
   • "Implement Stripe integration"
   • "Write payment tests"
3. Make "Implement Stripe" depend on "Design schema"
4. Make "Write tests" depend on "Implement Stripe"
5. View the dependency tree
6. Find tasks that are "ready" (no blockers)
7. Close the first task, check what becomes ready

Scenario 3: Filtering and Search

1. Create 5 tasks with different priorities (P0-P4)
2. Add labels: "backend", "frontend", "urgent" to various tasks
3. Filter by status
4. Filter by priority
5. Filter by label
6. Search for a keyword in task titles
7. Find all blocked tasks
8. Find all ready tasks

Scenario 4: Agent Workflow Simulation

1. Run the "prime" command and examine the output
2. Create a task based on the prime context
3. Update the task as you "work" on it
4. Add a comment/note to the task
5. Close the task
6. Sync/commit changes (if applicable)

Scenario 5: Edge Cases

1. Try to create a task with special characters in title
2. Create a task with a very long description (500+ chars)
3. Try to close a task that's already closed
4. Try to add a circular dependency
5. Delete a task and verify cleanup

---

Deliverable

After completing both evaluations, create a comparison report:

# Beans vs Beads Hands-On Evaluation

## Summary
[Which tool felt better to use? Why?]

## Scenario Results

### Scenario 1: Basic Task Lifecycle
| Aspect | Beads | Beans |
|--------|-------|-------|
| Commands used | ... | ... |
| Friction points | ... | ... |
| What worked well | ... | ... |

[Repeat for each scenario]

## Command Comparison
| Operation | Beads Command | Beans Command | Notes |
|-----------|---------------|---------------|-------|
| Create task | bd create "title" | beans create "title" | ... |
| List tasks | bd list | beans list | ... |
| ... | ... | ... | ... |

## Key Differences Found
1. ...
2. ...

## Errors Encountered
### Beads
- ...

### Beans
- ...

## Recommendation
[Based on hands-on testing, which tool is better for our workflow and why?]

## Raw Logs
[Include full command output for reference]

Save the report to: /tmp/beans-beads-eval/evaluation-report.md

---

Important Notes

• Run evaluations SEQUENTIALLY (Beads first, then Beans)
• Document EVERYTHING - commands, output, errors, feelings
• Be objective - note both strengths and weaknesses
• If a feature doesn't exist, document that clearly
• Time yourself roughly on each scenario

---

## How to Run This Evaluation

1. Create the test directories:
```bash
mkdir -p /tmp/beans-beads-eval/beads-test
mkdir -p /tmp/beans-beads-eval/beans-test

2. Ensure both tools are installed:

which bd        # Should show path
which beans     # Should show path

3. Start a fresh Claude Code session and paste the prompt above

4. Review the generated evaluation-report.md

[sotte]

Regarding token usage and number of tool calls:

  Beads: 60+ commands, mostly simple CLI flags
  Beans: Similar count but more verbose due to GraphQL

  It's less efficient, not more confusing. Here's why:

  | Issue                 | Beads                 | Beans                                                                                            |
  |-----------------------|-----------------------|--------------------------------------------------------------------------------------------------|
  | Find ready work       | bd ready              | beans query '{ beans(filter: { isBlocked: false, excludeStatus: ["completed"] }) { id title } }' |
  | Find blocked          | bd blocked            | beans query '{ beans(filter: { isBlocked: true }) { ... } }' or beans list --is-blocked          |
  | Add description       | --description="..."   | --body "..." or GraphQL mutation                                                                 |
  | Check active blockers | Automatic in bd ready | Need filtered query: blockedBy(filter: { excludeStatus: ["completed"] })                         |

  Root causes:

  1. Missing convenience commands - No beans ready equivalent forces GraphQL queries for common workflows
  2. GraphQL verbosity - Powerful but takes more keystrokes than CLI flags
  3. Dual interface exploration - Agent tried both approaches to document capabilities

  The Beans CLI itself is fine (beans list --is-blocked works), but it lacks the workflow shortcuts that Beads provides. Beads anticipated "what's ready to work on?" as a first-class use case; Beans leaves that to GraphQL composition.

  TL;DR: Beans trades efficiency for flexibility. Fine for power users who write custom queries, but more friction for the "just show me what's actionable" workflow.

[hmans]

Thanks, that's great input!

Ironically, the beans CLI does have the shorter commands that Claude would prefer to use, but I think my prompt is making it lean a little too hard into GraphQL. Like many other aspects to this project, I will continue to optimize and tweak things where possible.

[sotte]

During usage of beans, I got some errors when claude used the graphql API. Using the simple CLI worked better.

I agree, prime focuses a bit too much on graphql.

[hmans]

Just curious, is this on Opus or on Sonnet? Opus has been pretty good with the GraphQL so far.

But I do agree that simple is better. I will tweak the prompt to focus on the CLI interface and just tell the agent how to get to the GraphQL schema if it needs to do more complex queries.

[sotte]

Can't remember which model. I'm currently cycling through the different models, might even have been haiku. I'll check and report back.

[sotte]

FYI I'm experimenting with this template for prime: CLI first, but mention how to use graphql. Feels decent.

cmd/prompt.tmpl

---

EXTREMELY IMPORTANT: Beans Usage Guide for Agents

This project uses beans, an agentic-first issue tracker. Issues are called "beans" - markdown files with YAML frontmatter stored in .beans/. Use the CLI to manage them.

Always use beans instead of TodoWrite to manage your work and tasks.
Always use beans instead of writing todo lists.

CRITICAL: Track All Work With Beans

BEFORE starting any task:

1. FIRST: Create a bean with beans create "Title" -t <type> -d "Description..." -s in-progress
2. THEN: Do the work
3. FINALLY: Mark completed with beans update <bean-id> -s completed
   • NEVER mark a bean "completed" if it has unchecked todo items!
4. WHEN COMMITTING: Include both code changes AND bean file(s) in the commit

If you identify follow-up work, create a new bean instead of doing it immediately.

Issue Types

{{range .Types}}

• {{.Name}}{{if .Description}}: {{.Description}}{{end}}
  {{- end}}

Statuses

{{range .Statuses}}

• {{.Name}}{{if .Description}}: {{.Description}}{{end}}
  {{- end}}

Priorities

{{range .Priorities}}

• {{.Name}}{{if .Description}}: {{.Description}}{{end}}
  {{- end}}

CLI Reference

Listing beans

beans list                                    # All beans
beans list -s todo -s in-progress             # By status
beans list -t bug -p critical -p high         # By type and priority
beans list -S "search term"                   # Full-text search
beans list --is-blocked                       # Show blocked beans
beans list --parent <id>                      # Children of a bean

Key flags: -s status, -t type, -p priority, -S search, --tag, --json, -q (IDs only)

Viewing a bean

beans show <id>                               # Full details with formatting
beans show <id> --json                        # Machine-readable output

Creating beans

beans create "Title" -t <type> -d "Description" -s <status>
beans create "Fix bug" -t bug -d "Users cannot log in" -s todo

Always specify -t type. Add detailed descriptions with checklists when possible.

Updating beans

beans update <id> -s in-progress              # Change status
beans update <id> --title "New title"         # Change title
beans update <id> --parent <other-id>         # Set parent
beans update <id> --blocking <other-id>       # Add blocking relationship
beans update <id> --remove-parent             # Remove parent

Other commands

• beans delete <id> - Delete a bean
• beans archive - Delete all completed/scrapped beans (only when user asks)
• beans roadmap - Generate markdown roadmap from milestones

Working on a bean

1. Read the bean: beans show <id>
2. Mark in-progress: beans update <id> -s in-progress
3. Follow instructions in the bean body
4. If it has a checklist, update items as you complete them (- [ ] → - [x])
5. Mark completed: beans update <id> -s completed

Relationships

• Parent: beans update <id> --parent <other-id> (hierarchy: milestone → epic → feature → task/bug)
• Blocking: beans update <id> --blocking <other-id> (this bean blocks another)

GraphQL (Advanced)

For complex queries involving relationships, use GraphQL:

# Get bean with relationships
beans query '{ bean(id: "abc") { title parent { title } children { title status } blockedBy { title } } }'

# Find actionable beans (not blocked, not done)
beans query '{ beans(filter: { excludeStatus: ["completed", "scrapped"], isBlocked: false }) { id title } }'

# Full schema reference
beans query --schema

[hmans]

Ha, I was going to do the same thing. Feel free to make a PR, happy to give it a try!

One little comment: I think the prompt should also explicitly mention beans help to get the full CLI docs.

[sotte]

I'll open a PR. Still testing it a bit...

One little comment: I think the prompt should also explicitly mention beans help to get the full CLI docs.

👍

[hmans]

Hi @sotte, I'm going to close this issue because it's not directly actionable. I've also opened the Discussions tab for this project and will direct general feedback/questions/discussion to that. Thanks!

[bman654]

FWIW I bounced hard off of beads because it's workflow was a bit too opinionated. For example I wanted to test it in a throwaway local repo but I couldn't even init beads properly because it insists on pushing to a remote, which I did not even have. And it instructs the agent to commit and push when I want more control over when commit happens.

My initial testing of beans has gone smoothly. None of the above problems. It does exactly what I need - gives Claude a way to manage persistent tasks but leaves me in control of the git workflow.

[cboone]

I think you meant beans in the last paragraph ;)

[cboone]

Completely agree with @bman654 in #29 (comment). beads is interesting, but way too much. beans is much closer to being what I need and nothing more. (Well, I could use a touch more functionality than is currently available, but I'd rather have a touch too little than way too much.)

[raine]

Hi, why is there no beans ready? (Noticed the ticket)