Build a change request app by describing it.
What is changing, what it touches, how risky it is and who signed it off. Here's the prompt and the app it produced.
Ask for it in one go
This is the exact prompt we used. Copy it, change the words that don't match your business, and paste it in.
Manage change requests for our systems. Each change describes what is changing, which system it affects, the risk level, who is doing it and the planned date. It goes from raised to reviewed to approved or rejected, then implemented. Only the change board can approve a high risk change. Show me changes planned for this month and anything still waiting on review.
Built in 42 seconds, from that prompt alone.
What came back
Systems as a real collection
Which system a change affects is a lookup rather than free text, so you can ask what has changed on one system this quarter. Typed system names make that question unanswerable.
A change board with teeth
Approving a high risk change is restricted to the board. The rule sits on the data, so it holds through the API, which is what makes it a control rather than an intention.
Risk charted next to status
Four high risk changes out of nine, shown separately from where each one has got to. That is the view that stops a busy month quietly becoming a risky one.
Change management has a bad name because most of it is theatre. A form nobody reads, an approval nobody withholds, and a record nobody consults until something breaks and everyone wants to know what shipped on Tuesday.
The version worth having is thin. What changed, what it touched, who approved it, and when. Four facts, kept honestly, and the fourth question after an outage becomes answerable in a minute rather than a morning.
Systems as a lookup
We named “which system it affects” in passing. It made Systems a collection, so a change points at a record rather than carrying a typed name.
That is the difference between a log and something you can query. Free text gives you Billing, billing, Billing API and Billing (prod) inside a month, and the question you actually want to ask, what has changed on this system lately, stops having an answer.
Risk charted separately
The dashboard shows risk alongside status rather than folded into it. Four of nine changes are high risk, and they sit at different stages.
That view is the point of the app. A month with plenty of low risk changes is fine. A month with four high risk ones, three still awaiting review, is a conversation to have on the Monday rather than after the weekend.
Nothing needed correcting here. The dashboard counts and groups rather than measuring stored dates against today.
Summary
A change register is four facts kept honestly, and it earns its place the first time somebody asks what shipped before the outage. This took 42 seconds from a paragraph, with systems as a proper lookup and approval of high risk changes restricted to a board. If you want mandatory rollback plans, per-engineer views or post-implementation reviews, those are the next three sentences.
Then change it by asking
The assistant stays with the app after it is built. It proposes each change and a person approves it, so nothing moves on its own.
- Add a rollback plan field that has to be filled in before approval.
- Show each engineer only the changes they are implementing.
- Add a post-implementation review with an outcome.
- Give me changes by system for the last six months.
Frequently asked.
Is this ITIL change management?
It is the shape of it without the ceremony. Raised, reviewed, approved, implemented, with risk and a board. If you need formal CAB scheduling, change models and full ITIL process, this is a starting point rather than a product.
Why make Systems a separate collection?
Because the useful question is not what changed today, it is what has changed on the billing system this quarter. Free text system names cannot answer that, and they diverge within a month.
Can we require a rollback plan?
Yes, by asking. A field that must be filled in before a change can move to approved is a conditional rule, enforced at the data layer, so it cannot be skipped by someone in a hurry.
Does it link changes to incidents?
Not from this prompt. If you already run an incident register, connecting the two is where the value is, because most incidents trace to a change. Ask for the link and it becomes a lookup between the two.
What does it cost?
Snill is free to start for solo operators, with a Pro plan for teams. Your data and the app's full model are yours to export at any time, as CSV or JSON.
Describe it and see
Free to start. The app is generated in about a minute, and you keep changing it in plain language.
Start free