agent-driven configuration
Tell temper how you work.
temper has a configuring agent built in. Describe your process in your own words, or point it at a document. It asks what it needs, proposes the settings, and names whatever it can’t do yet.
How it goes
- You describe it.
In a chat: your own words, a pasted text, or the path of a document in an adopted repository.
- It asks.
One question at a time, until it can propose. It reads your current settings first.
- It proposes.
One proposal, split into what temper will enforce and what your agents will follow, with what the change does to running work.
- An owner decides.
Accept it, reject it with a reason, or ask for a change. A rejection goes back to the agent as your words, and it revises.
What a proposal looks like
Changes are grouped by what you know, in your words, with the settings’ whole values underneath.
Illustrative. The names are made up, the shape is the real one.
Enforced, or followed
The agent puts one test to each sentence you say: would temper’s engine act differently without it? If the sentence changes what temper wakes, schedules, permits, pays for, lands or holds, it’s structure, and becomes settings. If only the agent reading it would act differently, it’s a rule, and stays as text your runs read.
| You say | Kind | Where it goes |
|---|---|---|
| “Producers run on the faster model” | enforced | each role’s model |
| “Changes into a goal’s branch land with no CI” | enforced | a landing rule for goal branches |
| “One of us approves everything on main” | enforced | an approval in a landing rule |
| “Push early, and finish with what you left” | followed | the coding agent’s instructions |
| “Never fix what you don’t own” | followed | instructions: authority is per repository, not per path |
Where temper’s model has a mechanism, the agent offers to turn a rule into structure, and says what each choice guarantees. You choose. A rule is never made structure behind your back, and what’s guaranteed is never confused with what depends on agents behaving.
Four stops on the dial
The home page shows four ways of working. They’re examples, not modes: each is just settings, and anything in between is too.
| Pair | Team | Stock | As fabrig builds itself | |
|---|---|---|---|---|
| Work starts from | a chat | a chat | a chat or a goal | a person’s design draft |
| Review | you | an agent, then a person | an agent | tests, tiers, the goal’s full gate |
| main asks for | CI, up to date, approval | CI, up to date, agent’s review, approval | CI, up to date, agent’s review | CI, up to date |
| A person decides | every landing | every landing | what agents ask | goals, and what’s passed up |
| Models | one is enough | one, or one per role | your first configured | one per role, chosen per change |
| Suits | a repository still earning trust | a team that wants sign-off | a disciplined repository | a very high bar, many changes at once |
Why you can trust the result
- It changes nothing itself. Its tools are reads and one proposal, under the same role checks a person has. Only an owner’s decision changes settings.
- Members ask, owners decide. A member’s configuring chat proposes as an owner’s does, and the proposal waits in an owner’s inbox.
- A change is one decision. A set of settings is checked whole against the revision it was made from, and refused as stale if another is current. After a crash the old revision holds or the new one does, never a mix.
- The result is ordinary. Settings are versioned records you can list, read and compare, value by value.
- Running work keeps what it started with. Accepting restarts nothing, and new work follows the change. You can move running work at its next run. What a task may do is never pinned: rules and policies apply to every decision.
- Going back is a proposal too. Restoring a revision is another reviewed change, never a silent rollback.
What it won’t do
- Pretend. What temper can’t model, it says, and offers the nearest setting, never a stand-in presented as the real thing. Two approvals for one path is an example: landing rules cover branches and repositories, not paths.
- Touch the machine. A provider, a forge, a listener, a worker or a limit needs a restart and belongs to whoever runs the deployment. It says so rather than proposing it.
- Design your process. It runs the process you describe. Whether that process is a good one, or your repository is ready for it, stays your call.
- Run on the playground’s scripted model. It needs a real model, so sign one in first.
How it’s tested
On a box that holds no recipe, it’s told only “set this project up the way these documents describe”, the documents being fabrig’s own process. Its proposal is then checked obligation by obligation, by code: each setting must hold its value, and each gap must be named. A model reads the accepted instructions against the process’s rules. Then a draft is carried from intake to landing under what it proposed.
Ask it anything
It also explains. It answers from your settings and from the documentation built into the binary, and describes the settings back to you as a workflow. That makes it the fastest way in: you can skip the docs and ask.
- “What happens when I start a goal?”
- “Why did the tester run on that model?”
- “Describe how this project runs, as a workflow.”
Start
In the browser, choose Tell temper how you work, then review the proposal on its own page. Every act a page offers, a command offers too: