enso-methodBLOCK

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: assumptions-document-feedback
description: Process stakeholder feedback on assumptions documents — incorporate corrections, validations, and partial answers while keeping the project moving forward.
---

# Assumptions Document Feedback Processing

Guidelines for incorporating stakeholder feedback on assumptions documents.

**Related skill**: See `assumptions-document-writing` for creating assumptions documents and full ID system details. **When this skill requires creating new assumptions** (e.g., to fill gaps from partial feedback), load and follow the writing skill — it defines the ID system, format, and the filter for what belongs in an assumptions document vs. elsewhere.

---

## What Is This Skill?

This skill helps process stakeholder feedback on assumptions and incorporate that feedback into the assumptions document in a way that **keeps the project moving forward**.

The core philosophy: **Never block waiting for perfect answers.** Stakeholder feedback often comes back incomplete, partial, or delayed. Instead of waiting for clarification, update what you can with confidence, make reasonable assumptions for the gaps, and note what still needs validation. This ensures progress continues even when stakeholders take days or weeks to respond.

---

## When to Use

Use this skill when:

- You receive stakeholder feedback on an assumptions document (email, Slack, meeting notes)
- Feedback is a mix of clear answers, partial answers, and corrections
- You need to update the assumptions document while maintaining its utility

---

## Core Principles

### 1. Always Move Forward — Never Block

The assumptions document exists to **unblock development**, not to achieve perfect validation. When processing feedback:

- **Clear answers**: Update the assumption and increase confidence
- **Partial answers**: Incorporate what's known, **make your own assumption for the gaps** (don't leave questions for stakeholders)
- **Corrections**: Update with the corrected information, **and assume forward on any new gaps the correction introduces**
- **No response on an item**: Keep the existing assumption (it was our best guess)

**Never generate "follow-up questions" as a deliverable.** Follow-up questions create blocking dependencies — you're waiting on an email instead of making progress. Instead, for every gap, make your best assumption using existing context (code, docs, domain knowledge, reasoning). The user can asynchronously validate assumptions with stakeholders without being blocked.

A partial answer is better than waiting for a complete one. An assumption is better than a question.

### 2. Preserve the Assumptions Format

When updating, maintain the assumptions document structure:
- **Preserve assumption IDs** — IDs use format `CATEGORY-NNN` (e.g., `DATA-001`, `AUTH-002`) and are permanent — never change, never reuse, gaps are expected when assumptions are validated
- Keep the assumption as a specific, implementable statement
- Update confidence levels based on new evidence
- Adjust impact ratings if the feedback changes our understanding
- Update the "Confirm or Correct" options if the original options were wrong
- Mark assumptions as VALIDATED when you have clear confirmation
- When moving to Validated Assumptions table, include the original ID

### 3. Evidence-Based Updates

For each piece of feedback:
- Note the source (e.g., "Per the stakeholder's email 2026-03-12")
- Quote relevant portions when helpful
- Distinguish between explicit answers vs. inferred answers
- If feedback is ambiguous, state your interpretation and mark it as still needing confirmation

### 4. Confidence Graduation Threshold

When an assumption reaches **≥95% confidence** — whether through stakeholder feedback, code analysis, or strong domain reasoning — it graduates from the assumptions document into the requirements (PRD/Technical Design). It's no longer an assumption; it's a decision. Don't leave high-confidence items lingering as "pending" when you're effectively certain.

### 5. Don't Downgrade Confidence Without Cause

If stakeholder feedback is silent on an assumption, that's not evidence against it. Don't lower confidence just because something wasn't explicitly confirmed. Lower confidence only when:
- Feedback contradicts your assumption
- Feedback reveals complexity you hadn't considered
- Feedback indicates the assumption is in the wrong direction

**The reverse case is not a feedback-processing step.** If, while applying a reply, you find
evidence that a ruling the stakeholder has *already given* is wrong — measured data the ruling
predates, a source they never saw — do not fold a silent correction into the update. That is a
**reopening**, governed by Gate 3 in `assumptions-document-writing`: the original ID comes back
into the body with a reopening marker, and the ruling and the new evidence sit side by side. The
build proceeds on the revised answer, exactly like every other entry — what the reopened form
changes is visibility, not the green light. The one thing the new evidence never buys is
graduation under Principle 4: the PRD and Technical Design keep the decision recorded as the
stakeholder's until they revise it, however confident the evidence.

### 6. Re-Shape Every Entry You Touch — Don't Just Append

Feedback rounds are how entries turn into walls of text. Each round bolts on a corrected statement, a stakeholder quote, and an interpretation note, and after three rounds the current answer is buried mid-block. Whenever you update an entry, re-shape the **whole** entry per Principle 8 ("Shape Every Entry for a Scan") in `assumptions-document-writing`: bold the decision-carrying numbers and terms, cap paragraphs at 2-3 lines, front-load the operative words of the assumption as it now stands.

**Re-shaping reorganizes; it never trims.** The stakeholder's quoted words and the full evidence trail survive verbatim — Principle 5 of the writing skill still wins. For one round on a short entry, layer 

BLOCKgrade D · trust 69/100 Do not install this without reading the findings. The audit found something that could harm you or your machine.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (3)

one** — never tell the user the chat will resume on its own.

- **If the user says to stop** at any pause, run Phase 5 as a stopped run. The report's header reads `=== Autonomous PRD Refinement Stopped ===`, its Final round line gives the reason it stopped, its

- Manually, in the same chat, when the user says "should we refactor this?", "clean this up", or "run the refactor pass"

Gates applied: instruction_override, no_behavioural_pass.