It doesn't work so well in my experience. I am currently wrapping (or asking the LLM to wrap) the commit message prompt in a script call.

   1. the LLM is instructed on how to write a commit message and never include co-authorship
   2. the LLM is asked to produce a commit message
   3. the LLM output is parsed by a script which removes co-authorship if the LLM chooses to include it nevertheless

Also for future reference, Copilot - specifically - includes a configuration flag to toggle the co-authorship (see `copilot help config`):

> `includeCoAuthoredBy`: whether to instruct the agent to add a Co-authored-by trailer to git commits; defaults to `true`.

This means that, if you don't explicitely configure otherwise, the LLM is specifically instructed to include co-authorship in its higher level instructions.

Actually what it seems to tackle at its core is discoverability. Which should be built in in each MCP server as it's not that difficult, instead, we see MCP servers with 50+ methods.

Much easier:

    { action: 'help' }

    { action: 'projects.help' }

    { action: 'projects.get', payload: { id: xxxx-xx-x } }

And you get the very same discoverability.

There are other interesting capabilities though, like built in permissions based on HTTP verb, that might be useful to someone.

The issue here is the row based format. You simply can't filter on arbitrary columns with that. Either use an external warehouse or a columnar plug-in like Timescale.

I am creating AI coding framework (a set of skills and scripts, really), since it seems a lot of them don't support copilot.

I don't think what I am doing is really original, but it's shaping nicely.

I am working on:

- feature folders (one folder per feature, with changelog, issues, summaries etc)

- coworkers (cli-agents, with session management)

- agents intra-response messaging

In general the goal is forcing Claude to behave, which is quite ambitious :).

I am already doing that. For performance, I am just caching the latest explanation alongside the code.

The patterns in the article might be a starter, but there's so much more to cover:

agents role (Orchestrator, QA etc.), agents communication, thinking patterns, iteration patterns, feature folders, time-aware changelog tracking, prompt enforcing, real time steering.

We might really need a public Wiki for that (C2 [1] style)

[1]: https://wiki.c2.com/

Starred.

I am looking to that exact concept - for a different mean - to develop my agent orchestration hobby project.

LLM working in a «feature folder» where it stores change-logs, documentation, summaries, requirements, attachments, and so on. What I will be looking into very soon, is also storing the session id, for summarisation, history context, and so on.

I will definitely steal some concept from your project.

Glad it might be of use to you, but for your project, that case, a project from someone else (https://github.com/matt1398/claude-devtools) might be able to give you even more for inspiration :). Good luck with your project!

For Claude the most pollution usually comes from Claude itself.

It's worth noting thet just by setting the right tone of voice, choosing the right words, and instructing it to be concise, surgical in what it says and writes, things change drastically - like night and day.

It then starts obeying, CRITICALs are barely needed anymore and the docs it produces are tidy and pretty.

Value makes the world a better place, not profits per-se. Sometimes the two things coincide, sometimes they don't.

For some reason I made my own skills framework.

The LLM instructed to run the initialization script as the first thing, before reasoning about the use request (this proved tricky to achieve). The scripts greps the content matter out of the skill files, along with the file path.

I have no clue if this outperforms an embedded index.