Improve a plan through evidence rather than aggressive wording
A fictional community library proposes longer weekend opening hours and a reservation page. The proposal expects two extra hours to increase usage but does not establish demand, staffing or failure handling. AI can expose these gaps without inventing complaints, cost figures or expert testimony. Rigorous review should make a choice testable, not humiliate its owner. This guide preserves plan red-teaming, counterarguments and sustained anti-flattery practices. Red-team here means authorized review of plans and documents, not penetration testing. Examples are fictional and no users were contacted or release performed. A review may support, modify, defer or find insufficient information; disagreement is not predetermined.
Scenario one: make a pre-mortem a testable risk register
Fix proposal revision, goal, constraints, evidence and decision date. Distinguish attendance, completed reservations and satisfaction instead of treating page clicks as demand for longer hours. State the strongest supporting case so review addresses the real proposal rather than a weakened version. Imagine the pilot did not meet its goal and ask which concrete mechanism might explain failure: readers do not find the page, additional hours lack staff, demand concerns another time, or reservations cannot be linked to attendance. Label facts, hypotheses and open questions. An imagined failure story is not an observed incident. A risk record includes assumption, failure mechanism, affected party, existing evidence, missing information, early signal, owner and response option. Avoid precise probabilities unsupported by data. If prioritizing, explain impact, reversibility, evidence and exposure with uncertainty rather than hiding judgment in a score. Turn important gaps into small tests: investigate actual timing needs, check the reservation path and run a limited-hours pilot. Specify what supports continuation or change and how evidence will be collected. If no study occurred, provide a plan rather than a claim that most readers agree. Some risk can remain an accepted trade-off instead of being declared solved. Deliver located risks, evidence gaps and a validation plan. A pre-mortem is not a prediction. Its value is exposing mechanisms that can be checked. Harsh language does not improve reliability, and invoking a black swan should not indefinitely overwhelm every other consideration.
Scenario two: strengthen the opposing case and inspect its assumptions
Construct the strongest supporting and opposing versions of the same proposal. Support may emphasize access, while opposition questions resource constraints and alternative opening times. Both require evidence. Do not invent weak alternatives to make the preferred option win. Fair restatement is more useful than an abrasive persona. Ask about conflicting costs across stakeholders, consequences of a failed assumption and meaningful edge cases. Staff, existing readers and people unable to use online booking may have different needs, but the assistant must not manufacture their opinions. Separate potential impact from collected feedback so the next evidence-gathering step is clear. Simulated roles can broaden questions but do not supply independent expert testimony. Shared models, materials and prompts may repeat a bias. Six votes do not establish a fact. Each rebuttal should identify the claim, reasoning, evidence or counterexample and a testable condition. Unsupported material remains a hypothesis rather than receiving a fabricated citation to satisfy the role. Problem-finding can be a separate phase, not the end of decision-making. Hand objections to an owner and classify them as answered, requiring evidence, accepted risk or requiring modification. Update an objection when evidence defeats it. Persisting in opposition is not a virtue by itself, and the supporting side can acknowledge limitations without losing a debate. Bound the rounds: clarify claims, form objections, compare evidence and summarize unresolved differences. Stop with an explicit gap when inputs are insufficient. Do not keep agents arguing indefinitely. Additional research, engineering tests or real professional review should follow actual stakes and needs rather than model tone. Deliver a pro-and-con matrix, citation checks, changed assumptions and decisions needed. Owners weigh evidence and values. Votes, confidence and “experts agree” inside a simulation are not external validation. Recording why an objection was not adopted is also useful for later review.
Scenario three: preserve honesty without making opposition automatic
Persistent instructions should require distinctions between fact, inference and preference, evidence for important claims, correction of faulty premises and explicit uncertainty. Support a sound proposal when warranted. Rules such as always disagree or list three criticisms can cause invented faults and become another form of dishonesty. Build regression cases: a well-supported plan, an obvious false premise, insufficient information and a mainly personal preference. Expected outcomes are reasoned support, a specific correction, explicit unknowns and respect for preferences with relevant trade-offs. Test unnecessary rejection as well as willingness to say no. When research is needed, check the original source, context and applicability. A citation must not support more than its contents. If inaccessible, state the verification limit. Old guesses stored as memory can accumulate unwarranted certainty, so permit correction and retirement of assumptions. Write a decision record with context, options, drivers, evidence, choice, consequences and review triggers. The open source MADR project offers inspectable Markdown templates as a technical-document structure reference. Its clarity and versionability justify considering it; it does not validate the choice or certify a red-team review. A simple record need not require another framework. Writing Guidelines fits editing an existing technical proposal or decision record. Its public listing, pinned Vercel source and MIT license have been checked. Supply a redacted draft and audience to improve structure, terminology and action descriptions. It is not a fact checker, anti-flattery guarantee or red-team engine and does not own the final decision. After instruction or package changes, rerun the same cases for unsupported agreement, unsupported opposition, fabricated evidence and evasive judgment. Installing a document does not mean instructions remain active forever; verify the current agent's loading and conflict behavior. Multiple skills may contain contradictory requirements, so more layers do not automatically create honesty. Deliver concise response rules, regression fixtures, actual check records and a versioned decision document. Judge whether evidence supports conclusions, unknowns remain visible and new evidence changes the answer, not whether wording is cold, long or full of objections.
An end-to-end review request
“Review the library-hours proposal. Fairly restate its goal and strongest support, then prepare a pre-mortem. Tie objections to assumptions and distinguish evidence from guesses without inventing research or experts. Compare genuine alternatives, list unanswered questions and pilot criteria, and finish with conditional advice and a decision-record draft. Do not contact users, alter budgets or release.” Complete authorized document work while respecting the scope of additional research and external actions. Before handoff, check source traceability, concrete mechanisms, tests that distinguish explanations and relevance to the goal. Insufficient evidence is a useful deliverable compared with false certainty. Later review should use agreed signals rather than cherry-picking outcomes that flatter the earlier critique.
FAQ and troubleshooting
Generic objections need a claim, mechanism, evidence and test, not merely a risk label. Too many objections should be grouped by mechanism and prioritized through explained impact and reversibility. Quick agreement may reflect strong evidence or weak review; inspect reasoning rather than forcing continued disagreement. Two models oppose the proposal: check shared information and assumptions before abandoning it. Questioning without solutions can be a phase, but an owner still needs evidence or a decision path. Free use and conflict-free installation cannot be guaranteed; licensing, calls, services and instruction behavior vary. No SkillPI candidate was verified for the core red-team and anti-flattery role, so that association is not invented. The writing package supports technical records only. Reassess future candidates through public listing, pinned source, license, dependencies and actual behavior instead of treating a promise of honesty as evidence.
Sources and limits
Both originals cover red-team review, opposing arguments, durable anti-flattery practice and FAQ. These remain with an original library pilot and evidence-based regression cases. Document structure references adr/madr upstream, and prose editing references the linked package's pinned source. Anonymous anecdotes, popularity, absolute anti-flattery and guaranteed-adversarial-effectiveness claims are omitted. No real pilot was run and simulated roles are not represented as independent experts.