[bredren]

I was thinking this past week I have gotten so lazy w my prompting via CLIs.

Back in the before I had put such discipline into my prompting and supporting context.

Now I’m like, “look here and here and here are some tools, and /skill /skill okay go.”

Or “restate this request in your own words and enrich it as appropriate handling any gaps. Okay go”

[Quothling]

We're also at the point where you can roll out context to your entire organisation. I created an app for our m365 Cowork and deployed it to everyone who develops software. It does a couple of things, but it main knows our compliance policies and can guide developers through writing the documentation needed for NIS2 compliance. It also guardrails against non-approved packages, and helps developers find alternatives, or if none can be reasonably found, how to get a new package/dependency approved (or rejected).

A few months back this would be something every developer kind of did on their own. Maybe they shared skills, we certainly encouraged it and tried to do all the change management things, but nobody really had the same versions of the skills. Which was horrible in the deployment pipelines, something like the compliance documentation often had to go back and forth several times before it could be approved. Now it's just there, for everyone.

In a year or two, I expect a lot of these things to have become even more standardized. So that we don't even really have to build our own apps, but can simply use the ones in the catalog with minimal configuration (and that config will likely only be necessary because I'm from a tiny country that nobody will maintain standards for).

[bredren]

Yes. I worked on two large monorepos, about one quarter per project. Maybe 80+ devs on first, maybe 40+ on second. Both were not sure how to describe this but ultra-high-velocity agentic driven development efforts.

On the first, there were ~no shared skills. There were some requirements set up but they were not minded properly and became stale / ate context for little gain. The hardest hit was in E2E tests which would flake and create long running, too-often failing CI. People would disable them, because they were not reliable and velocity was so high, no one was happy w them.

I maintained my own set of skills and CLIs to back them. I'd share them if they came up but it was like the old days of manage your own stuff. Not much credit for building and sharing devex tooling to the team.

But then on the second one we were in better shape--we had vendoring set up to distro skills automatically.

Before the project was well underway, I put time into understanding how all of our tests aught to be written. Finding the forbidden things, etc, getting review from our best test folks and ultimately landed on a `/test` that routed across all possible test types.

Like night and day. Instead of finding out while trying to get a release out the door that some corner of the project had a handful of flakes, tests were written the right way from the start.

Like, it was beautiful. And I don't think devs noted difference while building. Only that there was an absence of BS in CI.

Hard to quantify the lack of pain, but it was big!

[danielbln]

This made me chuckle because it's so true. So much detailed steering and finagling in the past, now I point the agent to a bunch of information sources, skills, similar repositories that might hold useful input and tell it very roughly what I need and off it goes, I'll grab coffee.

[bredren]

Have you tried this:

   Look here and here and here are some tools, and /skill /skill [repo of folder paths etc] and here is what needs to happen: [stuff].

   ---

   Restate this request in your own words and enrich it as appropriate handling any gaps.

?

It is an ultra-lite way to plan, I suppose.

I like the format because:

    - I still get to put all my thinking into the request but then easily override the instruction
    - It is interesting to see my casual typo-riddled blast professionalized and improved upon.
    - Sometimes it surfaces useful questions that can save some time up front.

I think the models are doing this anyway, but I find the words "enrich" and "gap" are well understood by models and they demonstrate it in the response to the above pattern.

Anyhow, to get back to the point, there are still prompt-level tricks--but ultimately if repeated, should probably also be built into skills themselves!