There is too much AI. Too many tools, too many conventions, too many recommendations. Every week something becomes the new approach and last week's setup feels outdated. I want a minimal workflow that does not collapse every time the tooling shifts.
After spending time with Github Copilot and Claude, refining prompts and reading long responses, one idea kept coming back. When the goal is implementation, the thing worth looking at is not the chat transcript. It is the change that lands in your files.
A typical AI-assisted session produces two outputs. One is what the client shows in the chat window. The other is what it writes, or proposes to write, in your files. In implementation work, the second one is the deliverable.
It is easy to miss this. Fluent explanations create a sense of momentum. I have finished sessions that felt productive and then noticed nothing useful had landed in the repo. Until the content in that conversation has been validated, it is not new information. It is just plausible text.
There is also a practical reason not to structure your work around the chat itself. You never interact with the model alone in these tools. The client assembles context, injects instructions, picks tools, and decides how to present the result. Some of that is hidden and none of it is yours to control. Treating the chat as the primary workspace means building on something you do not own. The file edits are the part you can actually inspect, verify, and keep.
What if the context lived in a file you own instead of inside the chat? A file you can read, edit, and hand back to the model on your own terms.
Spec-driven development starts from a sensible idea: clearer constraints usually produce better output. Tools like Spec Kit, OpenSpec and Kiro lean on this in different ways. They are worth looking at on their own terms.
While constraints is good, what I have struggled with is timing. Early in a task, precision is often the thing I do not have yet. Requirements get clearer through exploration and review. Writing a heavy spec before that point has, for me, turned into wasted effort more than once. That is just a personal observation, not a verdict on the tools.
What follows is something I have been refining as I go. I call it slice. The idea is to stop relying on the chat to carry context and put it in a file instead. The session becomes disposable. The document persists. This also makes possible to continue work across sessions, or even have multiple sessions to work on the same task.
The point is to find units of work that are small enough to finish and cheap enough to redo. Each slice captures just enough intent to act on. When direction changes, you write a new one rather than updating heavy docs that cost tokens and drift from the code anyway. The focus is deliberate steps, repeated, with the least possible waste between them.
A slice is a small working document. It holds intent, the files that matter, open questions, rules, tasks, and verifications. It can act as model input, task list, and review checklist at the same time.
Design principles:
Before asking a model to change code, the slice maps the problem. The intent section is one tight description of what done looks like.
The files section names exact paths and what to look at in them. Rules are hard constraints the model should not break. Questions stay open only while they block progress. Once answered, the lasting fact moves into the right section and the question goes away.
Scope discipline matters here. What the agent should not do is often as useful as what it should.
Tasks are outcomes, not code steps. One row, one checkable result. If a row says too much, split it. If planning a row exposes a blocker, that is a question.
Verifications are the exit condition. Real commands or observable checks that prove the slice reached its intent. Not a copy of every step, just the few proofs that matter.
When the model is done, I open git, look at the diff, and check it against tasks and verifications.
I write slices as markdown files. The flat structure works well and the sections are easy for models to navigate and update.
I use a few small agents that update the slice in narrow ways:
slice-create: makes a new slice from the templateslice-think: refines intent, files, rules, questionsslice-do: ready for actual changes to the codebaseEach "slice" agent focuses on specific area of the slice. This also reduces the need to add extra to the prompts.
I rarely need to redirect the model mid-session when the slice is filled in. Drift is lower. When I do need to stop and restart, the work is still there in the file instead of in a lost conversation.
I have also noticed I don't need to type that much. The scaffolding by slice template, the agent and the task request itself sets the direction quite well. I get to read and write much less than before.
This is not a big framework. It does not require learning new things or adapt to a different convention.
Models tend to behave weirdly every now and then. Several iterations of the slice template and agents have tried to address those issues, and every iteration seems to go forward slowly. Here are the key areas to improve:
# [00000] - [brief title]
Template version: 0.35.0
Use only these sections in this order: `meta`, `intent`, `files`, `rules`, `tasks`, `questions`.
## meta
- id: [00000]
- title: [verb + noun]
- type: [feature | fix | refactor | docs | investigation]
- attitude: [think-carefully | get-it-done | minimal-changes]
- status: [draft | in-progress | done]
## intent
- I1: [what is needed, why it matters, what done looks like]
## files
- `path/to/file` — [why this file is relevant]
## rules
- R1: Do not change public APIs unless the slice says to.
- R2: Do not add dependencies. Raise them as questions.
## tasks
- [ ] T1: [outcome to deliver]
- [ ] V1: [verification command or observable check]
## questions
- Q1: [blocking question]