I built QualityLayer to get a plan, build and independent review loop into OpenCode
For bigger changes I kept hitting the same problem with coding agents. I typed a request, got a large diff back, and spent the evening working out which decisions the agent had made for me. The agent that wrote the code was also the one telling me it was done.
So I moved my own judgment to two points. Before any code exists, the agent asks me a few questions, each with a recommended answer, until "done" is a numbered list I can check. Then it writes a plan as a Markdown file in the repo, and I approve it.
After that it builds in small slices, each starting with a failing test. Agents that did not write the code check the result against every point of that list and show me the evidence, like command output or screenshots. I approve the finished change, and only then does it open a pull request. It never merges.
In OpenCode you start it with /ql <request>, and it uses the model you already have configured. Plans and evidence stay as Markdown files in your repo.
maxritter/qualitylayer
I'm the developer. I'd like to hear how others here handle review on bigger OpenCode changes.
2 points
@dipenvaja I stopped reading the diff first. I review the agent's plan before any code exists, and a second agent that didn't write the change checks the diff against that plan. By the time I read the code it's mostly confirming. I built QualityLayer for this: maxritter/qualitylayer
1 like · 6 views
Even the best coding models don't build software the way an experienced engineer would. Plan modes aren't visual or collaborative either.
QualityLayer puts the engineer back in the loop of your coding agent. Check it out on GitHub: maxritter/qualitylayer t.co
5 views
QualityLayer: put the engineer back in the loop of your coding agent
I use plan mode in Claude Code, Codex and Cursor for small changes. The agent reads the relevant code and asks me a couple of questions. Then it writes a plan.
For a change that touches one or two files, that's all I need. For bigger changes plan mode keeps letting me down, and it's always for the same reasons.
Only I can see the plan
The first is that the plan is chat text in my session, and I'm the only person who sees it. Plan modes are neither collaborative nor visual.
That sounds abstract until the change touches the payment code. A colleague of mine knows that code much better than I do. They could look at the plan and say "not there" before the agent puts the new logic in the wrong place.
They never get that chance, because the plan only exists in my chat with the agent.
Long text hides the structure
The second is length. A long text plan hides its structure.
When the plan wires two modules together the wrong way, that wrong dependency is a sentence somewhere in paragraph four, and I read straight past it. In a diagram I would see the same mistake in seconds.
!The same wrong dependency shown twice. On the left it is one sentence in paragraph four of a text plan. On the right it is a red dashed arrow in a small module diagram, easy to spot.
The plan as a shared document
I believe the future is humans and agents working together, with everybody becoming a manager of agents. That only works if the people who know the users and the codebase can see the plan while changing direction is still easy.
A private conversation between me and a model doesn't give them that.
So in QualityLayer the plan is a document in the repo. Each engineering decision gets two sentences. Parts with several moving pieces get a diagram, because that's where wrong dependencies show up.
The agent marks the items it was unsure about, so I read those first. I can comment on any part of the plan and the agent answers in the document.
When the plan is right I approve it, and the build doesn't start before that.
!Side by side comparison. Plan mode: chat text in my session that only I see, not visual, with the structure hidden in long text. A document in the repo: a diagram, decisions with an unsure marker, a colleague's comment saying not there, and an Approve Plan button.
Bringing in the team
The team part is what fixes the payment problem. I can share a plan and ask one colleague about one specific decision.
They answer in the QualityLayer App, or they let their own agent draft an answer and send it after they've read it.
People without an account, a designer or a product manager for example, can join through a guest link. For product people there is a Product level. There the plan shows what changes for users first and keeps the engineering detail one click away.
After the approval
Once I approve the plan, the agent builds it in small slices, and each slice starts with a failing test.
When the build is done, an agent that didn't write the code checks every point we agreed on and shows me the evidence.
At Review I approve the finished change and QualityLayer opens the pull request. It never merges anything.
The plan and the evidence stay in the repo, so whoever reviews the pull request can read why the change looks the way it does.
!The seven QualityLayer steps in a row: Discuss, Research, Plan, Outline, Implement, Verify, Review. At Plan I approve the plan before any code exists. At Review I approve the finished change, and QualityLayer opens the pull request but never merges it.
Try part of it with any agent
You can get part of this today with any agent and no extra tool:
1. Ask it to write the plan as a Markdown file with a Mermaid diagram for each decision.
2. Commit it and open a pull request that contains only the plan.
3. Ask the person who knows the risky part of the code to comment on it.
It takes a few minutes, and their comments arrive before a single line of the change exists.
QualityLayer runs with Claude Code, Codex, OpenCode, Pi, Cursor, Grok and Antigravity. What I want from it is to be an engineer again, with my attention on the decisions while the agent does the typing.
maxritter/qualitylayer
QualityLayer: agree what done means before the agent writes code
Coding agents write most of my code now, and the code itself is rarely the problem.
Even the best models don't build software the way an experienced engineer would. They don't know the users, and they don't know what the team considers good design.
An engineer settles those questions before writing anything. An agent guesses and keeps going.
A small task that showed me the problem
I saw this most clearly on a small task. I asked an agent to add CSV export to a reports page, and it wrote the whole thing without asking me a single question.
Then I read the diff and found out what it had decided for me:
- whether the file contains only what's filtered on the page or everything
- what happens when someone exports 50,000 rows
- which columns end up in the file
Each of those depends on who uses the report. The agent just chose something and moved on.
Moving the decisions to the start
Working decisions back out of a diff is the slowest part of working with agents for me. So I moved them to the start.
Before the agent writes any code, we agree on a numbered list of results. The change counts as done when every one of them holds. I call the list "Done means".
It works with any agent, with or without a tool.
Let the agent ask the questions
I let the agent do most of the work. In plan mode in Claude Code or Codex I give it something like this:
Read the code that this change touches. Then ask me up to six questions
that decide how the change behaves. For each question, give your
recommended answer. After my answers, write a numbered "Done means" list.
Each item must be a result a person can check on the running program.
The recommended answers are what makes this fast. I accept most of them with one keystroke.
The two or three I change are the decisions that needed an engineer. I make them now, before any code exists.
What the list looked like for the export
For the export, the list looked like this:
1. The reports page shows an "Export CSV" button next to the filters.
2. The file contains the rows that match the current filters, in the current sort order.
3. The columns match the visible table columns, with the same headers.
4. An export of 50,000 rows finishes while the page stays responsive.
5. The existing PDF export keeps working.
!The Done means list for the CSV export as a numbered checklist with five items. Item 5, the existing PDF export keeps working, is highlighted as the one people skip.
I can check each line myself in a minute. "Export works" would be useless as an item, because it doesn't say which behavior to look at.
Item 5 is the one people skip. I care about it most, because agents break nearby things quietly. Every list I write names something that has to keep working.
For a bug I use four parts:
1. the steps that trigger it
2. what happens
3. what should happen
4. what the fix must not change
Checking it with a session that didn't write the code
The list pays off a second time after the build. I open a new session that hasn't seen any of the work and give it the list. Then I ask it to check one point at a time on the running program:
For each item in Done means, run the program or the tests and show me
the evidence: command output, a screenshot or a file. If you cannot check
an item, say so and tell me what I need to do to check it myself.
It has to be a new session. The session that wrote the code knows what it meant to do, and it tends to report that instead of what the code actually does.
A fresh session only has the list and the program in front of it.
What comes back is a short report with evidence for each point. I read that first. When I open the diff afterwards, I already know where to look.
!Example report from the fresh session for the CSV export. Each point has its evidence next to it. One point is open, with a note on how I can check it myself.
What QualityLayer does with it
I built QualityLayer around this list. Its Discuss step runs this conversation for every change, and the list goes into the plan I approve before any code exists.
After the build, in the Verify step, an agent that didn't write the code checks every point and shows me the evidence. Anything it can't check stays open, and I look at it myself at Review.
!Flow from Discuss to the Done means list, to the build session and then to a fresh session that checks each point. Review comes last. The session that wrote the code never checks it.
The list is a Markdown file in the repo. It works with Claude Code, Codex, OpenCode, Pi and others.
Staying the engineer
I think everybody who writes software is turning into a manager of agents. This list is how I stay the engineer in that setup. I make the calls and check the results, and the agent does the typing.
You don't need my tool for any of it, though. Write the list before your next change and check the result against it.
I'd be curious whether it changes how you review.
maxritter/qualitylayer
QualityLayer: put the engineer back in the loop of Claude Code
I use Claude Code for most of my work, and for small changes plan mode is fine. For anything bigger, I noticed I had stopped being an engineer. I typed a request, got a large diff back, and spent the evening working out which decisions Claude had made for me.
The models are great. They still don't build software the way an experienced engineer would. They don't know the users, the history of the codebase or the taste of the team. People know that. Plan mode doesn't bring that knowledge in, because it's neither collaborative nor visual. The plan is a chat message only I can see, so nobody else can weigh in.
In my view the future is humans and agents working together, and everybody becomes a manager of agents. A chat box isn't enough for that.
QualityLayer is how I work with Claude Code now. Every change goes through seven steps: Discuss, Research, Plan, Outline, Implement, Verify and Review.
Claude first asks me a few questions, each with its recommended answer, until the goal is clear. Separate sessions read the code without seeing my request. Then Claude writes the plan as a document in the repo. A colleague and I can comment on it, and I approve it before any code exists.
After that, Claude builds in small slices, each starting with a failing test. An agent that didn't write the code checks the result against what the agent and I agreed, and shows me the evidence. I approve, and it opens a pull request. It never merges.
Two things surprised me while building it. Research that doesn't see the request is far less optimistic about the existing code. And two approvals turned out to be the right number for me. When I approved every step, I stopped reading.
What I want from all of this is to be an engineer again: deciding, reviewing and steering while Claude does the typing.
maxritter/qualitylayer
I'm the developer. If you tried spec-driven setups with Claude Code and dropped them, I'd really like to know what made you stop.
1 comment
QualityLayer: put the engineer back in the loop of your coding agent
My side projects are mostly built by coding agents now. They write code fast, but even the best models don't build software like an experienced engineer would. They miss what people know: the users, the codebase, the architecture, the taste of the team. Plan modes don't help much, because they're neither collaborative nor visual. The plan sits in a chat only I can see, and I kept spending evenings reading diffs to find out what the agent had decided for me.
I think the future is humans and agents working together. Everybody becomes a manager of agents.
So I turned my setup into QualityLayer. It wraps the agent you already use (Claude Code, Codex, OpenCode, Pi, Cursor, Grok or Antigravity) in seven steps: Discuss, Research, Plan, Outline, Implement, Verify and Review. I approve the plan before any code exists. The agent builds in small slices, and an agent that did not write the code checks the result against what the agent and I agreed.
The point is to get people back to being engineers: deciding, reviewing and steering while the agent does the typing.
maxritter/qualitylayer
I'm the developer. If you tried spec-driven setups on your own projects and dropped them, what made you stop?
1 comment
QualityLayer: put the engineer back in the loop of Codex
Codex is fast. Even with the best models, though, it doesn't build software the way an experienced engineer would. It doesn't know my users, my architecture or why the code looks the way it does. Codex plan mode asks good questions, but it's neither collaborative nor visual. The plan stays in my terminal, so nobody else can weigh in.
In my view the future is humans and agents working together, and everybody ends up as a manager of agents.
QualityLayer runs inside Codex, and every change goes through seven steps: Discuss, Research, Plan, Outline, Implement, Verify and Review. Codex writes the plan as a document in the repo that a colleague and I can comment on. I approve it before any code exists.
Then Codex builds in small slices, each starting with a failing test. A second Codex session without the build history checks the result against what the agent and I agreed, with output and screenshots. If Claude Code is installed too, Claude can check what Codex built.
The point is to be an engineer again: deciding, reviewing and steering while Codex does the typing.
maxritter/qualitylayer
I'm the developer. If you tried spec-driven workflows with Codex and went back to plain prompts, what pushed you back?
4 comments
QualityLayer: put the engineer back in the loop of OpenCode
The models you can run in OpenCode keep getting better. Even the best of them still don't build software like an experienced engineer would. They miss what people know: who the users are, how the codebase grew, what the team considers good architecture. Plan modes don't close that gap. They're neither collaborative nor visual, and the plan sits in a chat only I can see.
I think the future is humans and agents working together. Everybody becomes a manager of agents.
QualityLayer is how I plan, build and check changes in OpenCode. Every change goes through seven steps: Discuss, Research, Plan, Outline, Implement, Verify and Review. The agent first asks me what "fixed" means. I approve the plan before any code exists. Then it builds in small slices, and an agent that didn't write the code checks the result against what the agent and I agreed.
It uses the model you have configured in OpenCode. Plans and evidence are Markdown files in your repo.
The point is to be an engineer again: deciding, reviewing and steering while the agent does the typing.
maxritter/qualitylayer
I'm the developer. If you tried spec-driven setups in OpenCode and dropped them, what made you stop?
4 points · 2 comments
Mentions
I built QualityLayer to get a plan, build and independent review loop into OpenCode For bigger changes I kept hitting the same problem with coding agents. I typed a request, got a large diff back, and spent the evening working out which decisions the agent had made for me. The agent that wrote the code was also the one telling me it was done. So I moved my own judgment to two points. Before any code exists, the agent asks me a few questions, each with a recommended answer, until "done" is a numbered list I can check. Then it writes a plan as a Markdown file in the repo, and I approve it. After that it builds in small slices, each starting with a failing test. Agents that did not write the code check the result against every point of that list and show me the evidence, like command output or screenshots. I approve the finished change, and only then does it open a pull request. It never merges. In OpenCode you start it with /ql <request>, and it uses the model you already have configured. Plans and evidence stay as Markdown files in your repo. maxritter/qualitylayer I'm the developer. I'd like to hear how others here handle review on bigger OpenCode changes.
@dipenvaja I stopped reading the diff first. I review the agent's plan before any code exists, and a second agent that didn't write the change checks the diff against that plan. By the time I read the code it's mostly confirming. I built QualityLayer for this: maxritter/qualitylayer
Even the best coding models don't build software the way an experienced engineer would. Plan modes aren't visual or collaborative either. QualityLayer puts the engineer back in the loop of your coding agent. Check it out on GitHub: maxritter/qualitylayer t.co
QualityLayer: put the engineer back in the loop of your coding agent I use plan mode in Claude Code, Codex and Cursor for small changes. The agent reads the relevant code and asks me a couple of questions. Then it writes a plan. For a change that touches one or two files, that's all I need. For bigger changes plan mode keeps letting me down, and it's always for the same reasons. Only I can see the plan The first is that the plan is chat text in my session, and I'm the only person who sees it. Plan modes are neither collaborative nor visual. That sounds abstract until the change touches the payment code. A colleague of mine knows that code much better than I do. They could look at the plan and say "not there" before the agent puts the new logic in the wrong place. They never get that chance, because the plan only exists in my chat with the agent. Long text hides the structure The second is length. A long text plan hides its structure. When the plan wires two modules together the wrong way, that wrong dependency is a sentence somewhere in paragraph four, and I read straight past it. In a diagram I would see the same mistake in seconds. !The same wrong dependency shown twice. On the left it is one sentence in paragraph four of a text plan. On the right it is a red dashed arrow in a small module diagram, easy to spot. The plan as a shared document I believe the future is humans and agents working together, with everybody becoming a manager of agents. That only works if the people who know the users and the codebase can see the plan while changing direction is still easy. A private conversation between me and a model doesn't give them that. So in QualityLayer the plan is a document in the repo. Each engineering decision gets two sentences. Parts with several moving pieces get a diagram, because that's where wrong dependencies show up. The agent marks the items it was unsure about, so I read those first. I can comment on any part of the plan and the agent answers in the document. When the plan is right I approve it, and the build doesn't start before that. !Side by side comparison. Plan mode: chat text in my session that only I see, not visual, with the structure hidden in long text. A document in the repo: a diagram, decisions with an unsure marker, a colleague's comment saying not there, and an Approve Plan button. Bringing in the team The team part is what fixes the payment problem. I can share a plan and ask one colleague about one specific decision. They answer in the QualityLayer App, or they let their own agent draft an answer and send it after they've read it. People without an account, a designer or a product manager for example, can join through a guest link. For product people there is a Product level. There the plan shows what changes for users first and keeps the engineering detail one click away. After the approval Once I approve the plan, the agent builds it in small slices, and each slice starts with a failing test. When the build is done, an agent that didn't write the code checks every point we agreed on and shows me the evidence. At Review I approve the finished change and QualityLayer opens the pull request. It never merges anything. The plan and the evidence stay in the repo, so whoever reviews the pull request can read why the change looks the way it does. !The seven QualityLayer steps in a row: Discuss, Research, Plan, Outline, Implement, Verify, Review. At Plan I approve the plan before any code exists. At Review I approve the finished change, and QualityLayer opens the pull request but never merges it. Try part of it with any agent You can get part of this today with any agent and no extra tool: 1. Ask it to write the plan as a Markdown file with a Mermaid diagram for each decision. 2. Commit it and open a pull request that contains only the plan. 3. Ask the person who knows the risky part of the code to comment on it. It takes a few minutes, and their comments arrive before a single line of the change exists. QualityLayer runs with Claude Code, Codex, OpenCode, Pi, Cursor, Grok and Antigravity. What I want from it is to be an engineer again, with my attention on the decisions while the agent does the typing. maxritter/qualitylayer
QualityLayer: agree what done means before the agent writes code Coding agents write most of my code now, and the code itself is rarely the problem. Even the best models don't build software the way an experienced engineer would. They don't know the users, and they don't know what the team considers good design. An engineer settles those questions before writing anything. An agent guesses and keeps going. A small task that showed me the problem I saw this most clearly on a small task. I asked an agent to add CSV export to a reports page, and it wrote the whole thing without asking me a single question. Then I read the diff and found out what it had decided for me: - whether the file contains only what's filtered on the page or everything - what happens when someone exports 50,000 rows - which columns end up in the file Each of those depends on who uses the report. The agent just chose something and moved on. Moving the decisions to the start Working decisions back out of a diff is the slowest part of working with agents for me. So I moved them to the start. Before the agent writes any code, we agree on a numbered list of results. The change counts as done when every one of them holds. I call the list "Done means". It works with any agent, with or without a tool. Let the agent ask the questions I let the agent do most of the work. In plan mode in Claude Code or Codex I give it something like this: Read the code that this change touches. Then ask me up to six questions that decide how the change behaves. For each question, give your recommended answer. After my answers, write a numbered "Done means" list. Each item must be a result a person can check on the running program. The recommended answers are what makes this fast. I accept most of them with one keystroke. The two or three I change are the decisions that needed an engineer. I make them now, before any code exists. What the list looked like for the export For the export, the list looked like this: 1. The reports page shows an "Export CSV" button next to the filters. 2. The file contains the rows that match the current filters, in the current sort order. 3. The columns match the visible table columns, with the same headers. 4. An export of 50,000 rows finishes while the page stays responsive. 5. The existing PDF export keeps working. !The Done means list for the CSV export as a numbered checklist with five items. Item 5, the existing PDF export keeps working, is highlighted as the one people skip. I can check each line myself in a minute. "Export works" would be useless as an item, because it doesn't say which behavior to look at. Item 5 is the one people skip. I care about it most, because agents break nearby things quietly. Every list I write names something that has to keep working. For a bug I use four parts: 1. the steps that trigger it 2. what happens 3. what should happen 4. what the fix must not change Checking it with a session that didn't write the code The list pays off a second time after the build. I open a new session that hasn't seen any of the work and give it the list. Then I ask it to check one point at a time on the running program: For each item in Done means, run the program or the tests and show me the evidence: command output, a screenshot or a file. If you cannot check an item, say so and tell me what I need to do to check it myself. It has to be a new session. The session that wrote the code knows what it meant to do, and it tends to report that instead of what the code actually does. A fresh session only has the list and the program in front of it. What comes back is a short report with evidence for each point. I read that first. When I open the diff afterwards, I already know where to look. !Example report from the fresh session for the CSV export. Each point has its evidence next to it. One point is open, with a note on how I can check it myself. What QualityLayer does with it I built QualityLayer around this list. Its Discuss step runs this conversation for every change, and the list goes into the plan I approve before any code exists. After the build, in the Verify step, an agent that didn't write the code checks every point and shows me the evidence. Anything it can't check stays open, and I look at it myself at Review. !Flow from Discuss to the Done means list, to the build session and then to a fresh session that checks each point. Review comes last. The session that wrote the code never checks it. The list is a Markdown file in the repo. It works with Claude Code, Codex, OpenCode, Pi and others. Staying the engineer I think everybody who writes software is turning into a manager of agents. This list is how I stay the engineer in that setup. I make the calls and check the results, and the agent does the typing. You don't need my tool for any of it, though. Write the list before your next change and check the result against it. I'd be curious whether it changes how you review. maxritter/qualitylayer
QualityLayer: put the engineer back in the loop of Claude Code I use Claude Code for most of my work, and for small changes plan mode is fine. For anything bigger, I noticed I had stopped being an engineer. I typed a request, got a large diff back, and spent the evening working out which decisions Claude had made for me. The models are great. They still don't build software the way an experienced engineer would. They don't know the users, the history of the codebase or the taste of the team. People know that. Plan mode doesn't bring that knowledge in, because it's neither collaborative nor visual. The plan is a chat message only I can see, so nobody else can weigh in. In my view the future is humans and agents working together, and everybody becomes a manager of agents. A chat box isn't enough for that. QualityLayer is how I work with Claude Code now. Every change goes through seven steps: Discuss, Research, Plan, Outline, Implement, Verify and Review. Claude first asks me a few questions, each with its recommended answer, until the goal is clear. Separate sessions read the code without seeing my request. Then Claude writes the plan as a document in the repo. A colleague and I can comment on it, and I approve it before any code exists. After that, Claude builds in small slices, each starting with a failing test. An agent that didn't write the code checks the result against what the agent and I agreed, and shows me the evidence. I approve, and it opens a pull request. It never merges. Two things surprised me while building it. Research that doesn't see the request is far less optimistic about the existing code. And two approvals turned out to be the right number for me. When I approved every step, I stopped reading. What I want from all of this is to be an engineer again: deciding, reviewing and steering while Claude does the typing. maxritter/qualitylayer I'm the developer. If you tried spec-driven setups with Claude Code and dropped them, I'd really like to know what made you stop.
QualityLayer: put the engineer back in the loop of your coding agent My side projects are mostly built by coding agents now. They write code fast, but even the best models don't build software like an experienced engineer would. They miss what people know: the users, the codebase, the architecture, the taste of the team. Plan modes don't help much, because they're neither collaborative nor visual. The plan sits in a chat only I can see, and I kept spending evenings reading diffs to find out what the agent had decided for me. I think the future is humans and agents working together. Everybody becomes a manager of agents. So I turned my setup into QualityLayer. It wraps the agent you already use (Claude Code, Codex, OpenCode, Pi, Cursor, Grok or Antigravity) in seven steps: Discuss, Research, Plan, Outline, Implement, Verify and Review. I approve the plan before any code exists. The agent builds in small slices, and an agent that did not write the code checks the result against what the agent and I agreed. The point is to get people back to being engineers: deciding, reviewing and steering while the agent does the typing. maxritter/qualitylayer I'm the developer. If you tried spec-driven setups on your own projects and dropped them, what made you stop?
QualityLayer: put the engineer back in the loop of Codex Codex is fast. Even with the best models, though, it doesn't build software the way an experienced engineer would. It doesn't know my users, my architecture or why the code looks the way it does. Codex plan mode asks good questions, but it's neither collaborative nor visual. The plan stays in my terminal, so nobody else can weigh in. In my view the future is humans and agents working together, and everybody ends up as a manager of agents. QualityLayer runs inside Codex, and every change goes through seven steps: Discuss, Research, Plan, Outline, Implement, Verify and Review. Codex writes the plan as a document in the repo that a colleague and I can comment on. I approve it before any code exists. Then Codex builds in small slices, each starting with a failing test. A second Codex session without the build history checks the result against what the agent and I agreed, with output and screenshots. If Claude Code is installed too, Claude can check what Codex built. The point is to be an engineer again: deciding, reviewing and steering while Codex does the typing. maxritter/qualitylayer I'm the developer. If you tried spec-driven workflows with Codex and went back to plain prompts, what pushed you back?
QualityLayer: put the engineer back in the loop of OpenCode The models you can run in OpenCode keep getting better. Even the best of them still don't build software like an experienced engineer would. They miss what people know: who the users are, how the codebase grew, what the team considers good architecture. Plan modes don't close that gap. They're neither collaborative nor visual, and the plan sits in a chat only I can see. I think the future is humans and agents working together. Everybody becomes a manager of agents. QualityLayer is how I plan, build and check changes in OpenCode. Every change goes through seven steps: Discuss, Research, Plan, Outline, Implement, Verify and Review. The agent first asks me what "fixed" means. I approve the plan before any code exists. Then it builds in small slices, and an agent that didn't write the code checks the result against what the agent and I agreed. It uses the model you have configured in OpenCode. Plans and evidence are Markdown files in your repo. The point is to be an engineer again: deciding, reviewing and steering while the agent does the typing. maxritter/qualitylayer I'm the developer. If you tried spec-driven setups in OpenCode and dropped them, what made you stop?