feat: add custom prime template config option

[matleh]

Relates to #65

Summary

• Add templates.prime config option to .beans.yml for overriding the built-in prime document with a custom Go template file
• Custom templates have access to all built-in template variables plus {{.OriginalPrime}} (the fully-rendered built-in prime output)
• Graceful fallback: when a configured template file is missing or has parse errors, beans prime warns on stderr and outputs the built-in prime instead of failing
• beans check validates that the custom prime template file exists when configured

This allows users to add project-specific or agent-specific instructions (like those suggested in #65) without forking the built-in prime template. Users can wrap the original prime with their own additions via {{.OriginalPrime}}, or replace it entirely.

Configuration

beans:
    path: .beans
    prefix: beans-

templates:
    prime: extras/custom-prime.tmpl  # path relative to .beans.yml

Template Variables

Custom templates have access to:

• {{.GraphQLSchema}} - The GraphQL schema
• {{.Types}} - Type configs (name, color, description)
• {{.Statuses}} - Status configs
• {{.Priorities}} - Priority configs
• {{.OriginalPrime}} - The fully-rendered built-in prime output

Example

# Project-Specific Instructions

Custom guidance for this project...

{{.OriginalPrime}}

## Additional Context

More project-specific notes...

Changes

• internal/config/config.go: Add TemplatesConfig struct, Templates field on Config, ResolvePrimeTemplatePath() method
• cmd/prime.go: Extract renderPrime() function, load config, handle custom template with fallback
• cmd/check.go: Validate custom prime template file exists
• cmd/prime_test.go: New test file covering rendering, fallback, all template variables
• internal/config/config_test.go: Tests for path resolution, config loading, save/load round-trip

Design Notes

The templates section is a new top-level config key (separate from beans) to allow future extensibility:

# Future: agent-specific prime templates
templates:
    prime:
        default: extras/custom-prime.tmpl
        claude: extras/claude-specific.tmpl
        opencode: extras/opencode-specific.tmpl

[matleh]

Follow-up consideration: user-global config

We discussed adding support for a user-global config (e.g., ~/.config/beans/config.yml or $XDG_CONFIG_HOME/beans/config.yml) as a future enhancement. This would allow users to set a default custom prime template that applies across all their projects without repeating the config in every .beans.yml.

Rough shape:

• Look for a global config at a well-known path (respecting $XDG_CONFIG_HOME)
• Project .beans.yml overrides the global config (project wins)
• A global templates.prime would apply to all projects unless the project specifies its own
• Merge semantics TBD (simple override per-key? deep merge?)

This is out of scope for this PR but the templates section design accommodates it — a global config could provide default templates while projects override specific ones.

[hmans]

I need to think about this some more.

One important property of beans prime is that it automatically updates -- naturally -- when beans itself is updated. I am worried that custom templates like this would be at odds with this; furthermore, they have some overlap with the option of just letting the user add their own instructions to their agent rules files.

Please allow me some time to ponder this some more.

[isms]

@hmans Just weighing in that the general feature request is important given how opinionated the current beans prime template is. Upgrading quickly showed it was not a perfect fit for some common use cases.

For example:

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

This could contradict workflows where the user wants beans to be more orderly and mostly read instead of an ephemeral scratch pad for session context.

• WHEN COMMITTING: Include both code changes AND bean file(s) in the commit

This contradicts workflows where the user wants beans to be a more ephemeral and local-only memory/context tool.