AI Workflow
Why AI Needs a Reviewer Willing to Tell You the Uncomfortable Truth
What diss-me taught me about turning sharp criticism into an AI workflow that helps rough ideas become buildable plans.
The real danger is not a bad idea. It is agreement that arrives too early.
An unfinished idea tends to receive the same easy response: “That sounds good.” It is not a conclusion, but it can quickly start behaving like one.
An unclear goal, a missing use case, and unresolved trade-offs can all hide behind a few encouraging words. The problem is not that the first version is rough. It is allowing the idea to advance before it has been tested.
AI is particularly good at producing smooth responses. It can complete the tone, expand the feature list, and explain why a proposal might work.
Without deliberate constraints, the conversation begins to confuse “we kept talking” with “we thought this through.” A useful review should expose what is most likely to make the proposal fail before more time is committed.
Sharp is not the same as useful
Being sharp does not mean raising the volume or disguising a personal attack as skepticism. Useful criticism identifies a concrete defect and connects it to the next decision.
Instead of saying “this feature is terrible,” ask what goal it serves, where a user would abandon it, and how it connects to the surrounding workflow. The more precise the criticism, the clearer the repair.
That is why the activation boundary of diss-me matters. The Skill appears only when someone explicitly asks for a harsh review. An ordinary conversation should not suddenly turn into an attack.
The stricter mode starts only when the user asks for honest criticism. That condition leaves control with the person who brought the idea and gives the sharper tone a legitimate context.
Turn criticism into an executable workflow
If criticism is only emotional release, it leaves nothing behind except frustration. diss-me turns review into a sequence that can advance a design: locate the largest risks, decide one point at a time, and preserve confirmed choices.
The goal is not to answer everything in one pass. It is to make the proposal more buildable after every round.
Expose the two or three most dangerous gaps first
When a proposal already exists, the workflow starts with its two or three most serious weaknesses. The goal may be impossible to state in one sentence, or the major parts may not have been listed.
Two required steps may contradict each other, or a decision that controls everything else may still be unresolved. Putting those risks on the table prevents the discussion from polishing details while the foundation remains broken.
Imagine a product that promises to help people maintain habits but never explains when they will use it or what feedback keeps them engaged. That proposal is not ready for a conversation about button colors or page counts.
Raising the root questions first does not reject the direction. It asks the idea to survive the next test of resources, experience, and delivery.
Move one decision at a time
After the opening review, the workflow asks one question and waits for the answer. A long questionnaire may look comprehensive, but it turns the discussion into homework.
Handling one branch at a time makes dependencies visible and allows each answer to change the next question. The workflow is meant to sustain progress, not manufacture pressure.
Order matters. Confirm the audience and objective before choosing the feature boundary, then discuss implementation details.
If an earlier answer changes the premise of a later question, the workflow must adapt instead of mechanically completing a fixed script.
Offer real options and make a recommendation
Every question should include two to four workable options and a clear recommendation. The reviewer should not simply throw “What do you think?” back at the person who asked for help.
A product decision may need feature or technical paths; an article may need structural or argumentative choices. A recommendation does not remove the user’s authority. It exposes the reasoning and the next executable step.
The options also need to represent actual trade-offs. Optimizing for scope, speed, or validation should reveal what each choice sacrifices and what must be added later. Renaming the same answer three times is not a decision.
The user may accept the recommendation or choose another route. What matters is that every choice remains traceable and can lead to the next concrete piece of work.
Turn decisions into a blueprint
Confirmed decisions need to survive the conversation. diss-me maintains DISS_NOTES.md with each choice, its reason, and its place in the sequence. A later session can continue from that record instead of reconstructing the discussion.
When the important branches converge, the notes become a complete checklist, a record of key decisions, and an implementation order from zero to one.
The blueprint should make sense to someone who joins later. It should distinguish confirmed assumptions from rejected alternatives and identify what to validate first.
This is not paperwork for its own sake. It converts conversation into project memory and makes it possible to revisit the right decision when requirements change.
Critique the proposal, not the person
Strict standards belong on the work, not on someone’s identity. A reviewer can point out a missing boundary condition or an unsupported assumption without portraying the author as incapable.
This distinction is more than politeness. When the problem is observable and editable, people can add information, change a choice, and keep collaborating.
An AI workflow also needs a stopping condition
A review should not continue forever. diss-me stops when it has produced an actionable blueprint. It does not silently move into coding or implementation.
That stopping condition makes “review complete” observable and prevents the assistant from sliding from criticism into work the user never authorized. Once the blueprint is ready, starting the build requires a separate, explicit decision.
Try it with one command
With Node.js 18 or later installed, run:
npx diss-me install
The installer detects Claude Code and Codex on Windows and macOS and places the Skill in the appropriate user directory. Git is not required.
See the diss-me repository for installation, diagnostics, and uninstall instructions.
Closing thought
The value of uncomfortable truth is not that it makes a conversation louder. It turns vague approval into decisions that can be tested.
When activation, question pacing, options, records, and a stopping boundary are designed into the workflow, an AI reviewer can stay sharp while still helping an idea become real.