Added GitHub issue and ClickUp task synchronization (lazy) to a fork

[Jason-Abbott]

I’d be happy to contribute this back but it seems a bit contrary to the beans ethos. If you or your LLM want a working sample to chew on: https://github.com/toba/beans

One rough edge I see yet is Claude sometimes treats my prompt for subtasks as a blocking relation and other times as a child relation, which look pretty different in ClickUp.

[hmans]

I'd love to hear more about these types of integrations and how people use them! At the moment my stance on these is to defer them to agents; my hypothesis is that you should be able to tell an agent to synchronize your beans with your preferred issue tracking service, and it should be able to do this quite reliably, assuming the necessary MCPs/CLIs/skills are configured, but I haven't tested this hypothesis so far for the simple and boring reason that I don't use any external issue trackers in my projects.

Generally speaking I would prefer to keep Beans focused and simple, but I'd be happy to explore a "subcommand plugin" style system where

• a separate codebase produces eg. a beans-github CLI
• with its own commands becoming available as beans github <...> (like Git does it)
• and injecting its own prompt instructions into beans prime

This would allow people to explore extensions to Beans without the code having to live in the Beans repo and executable itself.

[Jason-Abbott]

I like keeping beans simple as they are. I switched from beads to beans for that reason. I hope to get rid of my bean fork.

After getting an integration working, I saw all I really needed was some additional bean frontmatter: ID of the external issue and last synced_at. I didn’t test to see if beans would “mind” seeing additional frontmatter so maybe I could have a separate tool adding and reading those extra values. I also didn’t look to see if there’s already a bean command to grab beans JSON (or something) so the separate tool doesn’t need to rewrite the searching/parsing bits.

This comment turned into me thinking out loud, erasing what I wrote and starting again a few times. 🙂

If beans support those couple things — tolerating other frontmatter (not removed when updating a bean) and commands other tools can use to fetch structured data — then I wouldn’t personally have enthusiasm for a formal plugin and subcommand system.

[hmans]

I'm planning support for "custom properties". I haven't fully sketched these out, but the overall idea is to let you configure a schema of custom properties in your .beans.yml where for each property you can define:

• the property name
• the property type
• a textual description of the property

These will then be injected into the prompt generated by beans prime to give agents some additional information on how they are used. Integrating Beans with eg. GitHub Issues should then theoretically only be a prompt like use the github_issue_id custom property to store the ID of the linked GitHub issue away.

Happy to hear your thoughts!

[hmans]

PS. since I eventually need to move some stuff to this repo's issues section, I will probably be able to dogfood this stuff directly, too.

[Jason-Abbott]

That’ll be perfect for my use-case. I just vibed out a tool that uses the standard beans, no fork, to do a ClickUp sync. I found the frontmatter currently does get replaced so had to track with a separate .json file, but otherwise it was pretty easy. I look forward to getting rid of that and using custom fields.

I stuck it over here https://github.com/STR-Consulting/bean-me-up