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.

Columnar solves some query patterns but treating row format as a dealbreaker for top-k is an overreach. For modest-to-mid datasets with the right index Postgres handles top-k on composite keys well, especially if reads aren't scanning millions of rows or you can fit hot columns in memory.

If latency really matters and you are working with large datasets, columnar extensions help, but they come with operational overhead and can limit transactional features, so it's usually better to stick with row-based unless you have a clear need.

My apologies, the article was talking about 100M-rows datasets so I presumed that was the scenario.

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.

Most often product development involves a lot of legacy. In consultancy you get to start from scratch at least every once in a while.