The bundling is pretty interesting, does this also work on repo level? e.g. I have added some sales skills into our company brain, but for sessions that others would do, if they are not doing sales related tasks, they would not require any of it. But I still want to be able to directly invoke one of my sales related skills directly.

yes :) you can pick the path it should run on or invoke in a path that has .claude or .agents as a subfolder, it will then auto-detect and allow you to write collections (bundles).

One of the things that was most challenging and still rough around the edges are backfills. Doing a BC breaking schema change in a chain of materialized view and repopulating can take a week or more for a big dataset. So having stable tooling to help guide that change was super helpful for some of our past migrations.

Does this mean, that the full node compatibility purely depends on oxc for transpiling? So oxc compatibility = nub compatibility?

How does this integrate with Git? is the CRDT stack mainly for syncronizing locally? and then "snapshotted" into git? Or how would the team collaboration part of this work?

Git is used for the "auto-sync" and sharing functionality. Uses GitHub as the source of truth for the content.

Currently the CRDT is local and is used so that agents can edit the markdown concurrently with the user, and the user can edit it via the WYSWIG editor or the raw markdown editor. CRDT powers the live indicators, etc.

CRDT and git are reconciled so that git stays as the canotical version history.

so if I understand you correctly crdt is not used to collaborate in realtime with other human beings? instead we need to sync via git?

Currently yes. We'll be exposing a centralized CRDT server option in near future.

yes we had to tune the claude.md and the skill trigger quite a bit, to get it much better. But to be honest also 4.6 did improve it quite a bit. Did you run into your issues under 4.5 or 4.6?

I was using Sonnet 4.6 since it was a menial task

Team of 4 engineers, 1 data & business person, 1 design engineer.

I would say roughly equal amount of sessions between them (very roughly)

Also maybe 40% of coding sessions in large brownfield project. 50% greenfield, and remaining 10% non coding tasks.

1. can only partly be answered, because we can only capture the "edits" that are prompted, vs manual ones. 2. for us actually all of them, since we do everything with ai, and invest heavily and continously, to just reduce the amount of iterations we need on it 3. thats a good one, we dont have anything specific for debugging yet, but it might be an interesting class for a type of session.

the skill usage was one of these "I am wondering about...." things, and we just prompted it into the dashboard to undertand it. We have some of these "hunches" where its easier to analyze having sessions from everyone together to understand similarities as well as differences. And we answered a few of those kinda one off questions this way. Ongoing, we are also using a lot our "learning" tracking, which is not really usable right now, because it integrates with a few of our other things, but we are planning to release it also soon. Also the single session view sometimes helps to debug a sessions, and then better guide a "learning". So its a mix of different things, since we have multiple projects, we can even derive how much we are working on each project, and it kinda maps better than our Linear points :)

We used it across the team, and when you want to bring metrics together across multiple people, its easier on a server, than local.

Cool, whats the link? We have some learnings, especially in the "Skill guiding" part of our example.