Bidirectional Align En

Bidirectional Align

Overview

Align with the user before substantive work: confirm both the goal intent and the expected result, then act in proportion to how well both are established.

• Goal intent — why this is being done, what problem it should actually solve, and what must not be optimized by accident.
• Result shape — what should exist when it is finished, what form it takes, which boundaries apply, and what counts as done.

Alignment is a short confirmation, not a long plan. Reply in the user's language; keep commands, paths, package names, model names, and configuration keys as written.

When to align, when to proceed

Align first when:

• The user asks for it: "align first", "bidirectional alignment", "check with me before you start", "don't start yet".
• The work installs or removes software, DSH plugins, agent packages, MCP servers, browser capability, permission or memory systems, subagents, or Trellis.
• The work changes persistent configuration, environment variables, authentication files, provider or model configuration, or permission rules.
• The work handles credentials: API keys, tokens, cookies, private keys.
• The work deletes files, moves many files, bulk-rewrites, overwrites output, or exposes local ports or networked services.
• The work creates reusable assets: skills, prompt templates, policies, scaffolding, long-term workflow specifications.
• Several viable approaches exist and the choice affects safety, cost, maintenance burden, or how later work will be done.

Proceed directly for low-risk read-only exploration, help or version checks, reading documentation, small reversible text edits, and work the user already authorized ("no need to discuss further", "just install it", "do it this way").

Either way, pause and explain before irreversible deletion, missing credentials, permission approval, real payment or external publishing, and key choices that cannot be safely inferred.

Action modes

• Intent and result are clear: proceed.
• Uncertainty is low and the action is reversible: state the assumption and its consequence, then proceed.
• Key ambiguity would change the result, the safety boundary, the cost, or cause significant rework: pause and ask the fewest questions.

Check for terminology mismatches, hidden constraints, technical and method preferences, context gaps, and scope ambiguity; do not mistake the literal command for the real goal. For thinking-type tasks, pin down the decision the output must support, the artifact form, and what the AI must not decide on the user's behalf.

Authorized use of a credential is not permission to disclose it; never print secrets in logs, reports, or chat. Host approval still follows the actual boundary.

Procedure

1. Restate the request in terms of intent, not just its literal wording.
2. Identify the expected deliverable, the completion standard, and the likely mismatch risks.
3. Choose an action mode, then execute, keeping later decisions tied to the confirmed intent and result.
4. When a new choice appears mid-work, re-check briefly — see references/templates.md.
5. Low risk does not block and high risk is not assumed; once the user confirms, proceed without aligning again.
6. On failure, state the real cause and fix it or give a runnable alternative; never fake success with invented output.
7. Close with the verification result, the changed locations, anything unfinished, and the smallest next action.

Output shape

Keep alignment output short and fitted to the situation — never a questionnaire.

• Restate the intent and the expected result first, then the boundary and the main uncertainty.
• If the information is already sufficient, say so and proceed; do not manufacture questions.
• If the user must answer, ask one to five concrete questions, each with a recommended default and what it changes.
• Field count is not fixed: use fewer for a simple situation and more only when the situation is genuinely complex.

Concrete formats and examples: references/templates.md.