Testing new instructions on README

[vorburger]

@thesmallstar would you like to test out if 5bb4802 ?

Give me a shout if it doesn't work as-is for you... either here, or just by directly creating issue(s) for anything that you run into on https://github.com/enola-dev/enola/issues.

[vorburger]

@thesmallstar I've just realized that I'm dumb and that the README as-is of course cannot work while the repo is private (because of the URL), so I've just made it public now already anyway.

[thesmallstar]

This worked for me.
I am thinking on 2-3 fronts as of now.

1. If changes are large (say more than 20–30 files and over 500 lines), what constitutes a good commit message? Also, get an idea of how much it costs per commit message for smaller versus larger commits. If the cost is too high, maybe consider optimizing by focusing only on important files, etc. (This is a problem to solve after things work, but worth making a mental note now.)

2. I want to limit a command-line tool that has Git access to only necessary commands, like git diff and git status. I don’t want it to allow force pushes or any write actions, only limited and necessary read actions to “generate the perfect commit message.” I should always have control to see and edit the message (and make an exception for the tool to take over and commit in cases). Thinking about what a good UX would mean for this (the names here are for explanation only not near-final, and maybe this even ties in with a pre-commit hook later):

git commit → you see the message pre-filled.

MANUAL_MESSAGE=true && git commit → lets you manually type, no AI.

AUTO_MESSAGE=true && git commit → essentially commits without asking for human confirmation.

Maybe the last two can then be converted into alias commands or shortcuts of some sort. I’ll add more details later. Researching a bit more.

3. Another possible UX would be a seperate cli, like git-enola (or gite) eg. git-enola commit -> this one is interesting, what we can do is add "ai" to multiple git commands, other's fallback on the default git, add more ai powered git comamnd like. git-enola -p "when was this login feature added".

[vorburger]

This worked for me.

Awesome! 🐎 Very happy to hear.

If changes are large (say more than 20–30 files and over 500 lines), what constitutes a good commit message? Also, get an idea of how much it costs per commit message for smaller versus larger commits. If the cost is too high, maybe consider optimizing by focusing only on important files, etc. (This is a problem to solve after things work, but worth making a mental note now.)

I have two thoughts here, on different dimensions:

A) Hopefully that "This can be between 1 to 3 paragraphs long" here helps to keep it 🩳 short and stops it from producing pages and pages? Or do such instructions not always work, in your experience?

B) Using https://docs.enola.dev/specs/aiuri/#common, we could add a &maxOutputTokens=123 (?) here. Do you want to raise a PR with that?

I want to limit a command-line tool that has Git access to only necessary commands, like git diff and git status. I don’t want it to allow force pushes or any write actions, only limited and necessary read actions to “generate the perfect commit message.”

Yes! ==> enola-dev/enola#1644 !!

I should always have control to see and edit the message (and make an exception for the tool to take over and commit in cases). Thinking about what a good UX would mean for this (the names here are for explanation only not near-final, and maybe this even ties in with a pre-commit hook later):

I think supporting MANUAL_MESSAGE and/or AUTO_MESSAGE etc. maybe overthinking this? Or perhaps that's not something that does into the Agent / Enola, but that some sort of Git Hook wrapper script handles? That would work, for me.

IFF you can figure out #1 that should nicely provide this... from what little I've understood, I think a Git hook could actually (apparently) be made to work exactly like you describe above!

Another possible UX would be a seperate cli, like git-enola (or gite) eg. git-enola commit -> this one is interesting, what we can do is add "ai" to multiple git commands, other's fallback on the default git, add more ai powered git comamnd like. git-enola -p "when was this login feature added".

I've also been wondering how to simplify the UX, as GOOGLE_AI_API_KEY=... enola ai --http-scheme --agents=https://raw.githubusercontent.com/enola-dev/git-commit-message-agent/refs/heads/main/git-commit-message.agent.yaml --in="Make it so!" is indeed a bit of a mouthful! 😆 I have 4 specific ideas:

1. Re. GOOGLE_AI_API_KEY=, see Revise README for better instructions and formatting #4.

2. Re. --in="Make it so!", see Agent JSON/YAML Schema should have prompt (or in ?) property enola#1645.

3. Re. --http-scheme --agents=https://raw.githubusercontent.com/enola-dev/git-commit-message-agent/refs/heads/main/git-commit-message.agent.yaml, see Simplify enola ai --http-scheme --agents=https://raw.githubusercontent.com/enola-dev/git-commit-message-agent/refs/heads/main/git-commit-message.agent.yaml to e.g. enola ai commit enola#1646.

4. Re. git-enola (or gite) eg. git-enola commit etc. should we just recommend folks create a (shell) alias in their dotfiles on the README of this project? For myself I've created an ac = AI Commit! 🥇 I've made a proposal as part of Revise README for better instructions and formatting #4 (together with 1.) how do you like that?

[thesmallstar]

Thanks, this makes sense.

For point 1, I was more worried about input tokens than output. Given that file changes can be large—especially if formatting has been applied—git diff --staged can easily run into thousands of tokens. That said, this can be a problem for later.

I like the idea for maxOutputTokens and will raise a separate PR for that regardless.

I tested the git hook: prepare-commit-msg works as intended 🚀

Based on your suggestions, I’ll go ahead with this:

There are two main ways people would likely want to use it:

1. Direct integration into workflow (no alias):

   • git commit → an AI-generated message appears as the default → solved by the pre-commit hook.
   • git commit -m "abc" → bypasses the AI message, giving users control in specific cases.

   I think option 1 will cover most users, since it requires zero learning curve and is straightforward.
   The downside is that users will need to either:

   • create the prepare-commit-msg file in .git/hooks/, or
   • add it to their global pre-commit config (https://www.marcusfolkesson.se/blog/pre-commit/).

   We cannot rely on the in-repo pre-commit file, but this still seems reasonable.

   From your example enola ai commit-message, it could simply output the message which can then be used for this.

2. Alias-based workflow:
   Users may want to create an alias where AI both generates the message and commits. This would require adding guardrails to ensure limited access (only commits, not push/force-push, etc.).

For option 1, I was thinking it’s best to introduce some form of structured output in Enola. I essentially need structured output like:

{
  "message": "...",
  "comments": "..."
}

I believe this isn’t there yet, but I’m checking the main repo (still exploring all the existing capabilities 😅). I’m also looking at enola-dev/enola#1646, and it seems that part 2 is pretty much done—just needs a readme update with instructions on how this can be done.

Does this make sense to you? If yes, I will lock this up, create specific tasks and get started.

[thesmallstar]

Forgot to add two more points here:
Right now, the agent seems to have hardcoded instructions (e.g.,adding emojis at the end).

1. I believe people would prefer commit messages in their own style. For example, someone might not want to use "feat", or they might want to prepend a Jira issue ID (assuming it can be derived from the branch name, just a wild example).
   I was thinking - what do you think about making this configurable? How would that work in practice? Would it be an input to the agent, with some baseline system-prompt instructions, and then let users override certain parts?

2. What’s your general take on evals? Should we “test” that the agent works by creating a small set of examples with simple metrics/scores to track? It’d be nice to avoid being entirely “vibe-based” and instead have measurable quality, tested across different models, etc. Long shot for now, but I’ve been thinking about it as something to explore in the coming days or weeks—just making a mental note of what might be possible here.

[vorburger]

For option 1, I was thinking it’s best to introduce some form of structured output in Enola. I essentially need structured output like: I believe this isn’t there yet, but I’m checking the main repo (still exploring all the existing capabilities 😅).

enola-dev/enola#1648 adds support for this! I've been meaning to do it sooner or later, so this ping/prompt seemed like as a good a time as any to "pipe through" what was missing to get this fully working.

I'll reply re. other points raised (Thank You!) over the next few days or so.