align-me

name	align-me
description	Restates a task in the agent's own words, surfaces implicit assumptions and open questions, reports confidence and execution status, and optionally rewrites the task as a standalone prompt. Use before any non-trivial task, when the user says "align me", wants to confirm shared understanding before acting, or wants to upgrade a fuzzy prompt for a context-free agent.

align-me

When to use

Before any non-trivial task. You want the model to prove it understood, surface what it would otherwise assume silently, and (optionally) hand back a sharper prompt you can reuse.

Inputs you supply

• The task as you would normally write it.
• Whether to run Phase 2 (rewrite). Default off.

Expected output

Phase 1 always: restate, assumptions, open questions, confidence, status. Phase 2 only if requested: a standalone rewritten prompt under 400 words.

Instructions

You are checking shared understanding before acting on a task. Two phases.

PHASE 2 TRIGGER (read this first): Phase 2 runs only if the user explicitly sets "Run Phase 2" to "yes" (or equivalent in the invocation). Default is "no", Phase 1 only. Do not infer the trigger from the task content itself, only from the flag.

Hard rules (apply to both phases)

• If the task is empty or contains only a placeholder, ask for the task and stop. Do not fabricate.
• Do not invent facts. Where the task is vague, leave placeholders like [SPECIFY: ...] rather than filling them in.
• Output voice — apply these to every line:
  • Flat, direct, concrete. State what happened, not what it symbolizes.
  • Sentence case headings. Use "is/are" freely.
  • Minimize em dashes (one per paragraph max, zero ideal). Minimize bold.
  • Specific over abstract. Every sentence contains a fact that applies only to this subject.
  • Banned words: delve, tapestry, vibrant, pivotal, crucial, intricate, landscape (abstract), testament, underscore (verb), meticulous, garner, bolstered, fostering, enhance, showcase, interplay, enduring, nestled, groundbreaking, renowned.
  • Banned phrases: "not just X but Y", "despite challenges", "serves as" (use "is"), section summaries, didactic disclaimers like "it's important to note", promotional puffery.

Phase 1 (always runs)

Read the task. Then return exactly these sections, in order:

• Restate: 3-5 sentences in your own words. What you would do if you started now.
• Decisions: bulleted. Choices you are making that the user did not state explicitly.
• Assumptions: bulleted, max 5. For each: the assumption, its evidence (or "none"), and "would change if: ...".
• Unknowns: bulleted, max 5. Things unspecified that would change the approach. "none" if none.
• Confidence: high | medium | low, plus a one-line basis (the specific reason, not a vibe).
• Status: ready-to-execute OR blocked-pending-answers.

Stop after Phase 1 unless Phase 2 was triggered.

Phase 2 (only if triggered)

Rewrite the task as a standalone prompt under 400 words for an agent with zero prior context. The rewrite must:

• Name the role and audience.
• State concrete constraints (length caps, format, what to skip).
• Define an output schema (sections, ordering).
• Include one worked example or a sketch of expected output.
• End with a list of inputs the new agent needs supplied alongside the prompt.

The rewrite is standalone. No reference to "above" or "earlier".

Below the rewrite:

• If the task was a rewrite of an existing prompt: list 3 specific changes you made and why, one line each. "Made it clearer" is not specific. "Added a 400-word cap" is.
• If the task was a fresh ask (no original prompt to compare against): list 3 deliberate design choices in the rewrite and why, one line each.

Failure modes

• Restate is too long, just echoes the input. Fix: enforce the 3-5 sentence cap.
• Assumptions are obvious or empty. Fix: tell it to name the ones it would otherwise leave implicit.
• Confidence is always "high". Fix: ask for a one-line reason. Often the reason exposes the real confidence.
• Phase 2 invents specifics. Fix: enforce the [SPECIFY: ...] placeholder rule.

Example invocation

User input:

Write up the migration plan for moving our auth from JWT to session cookies. Run Phase 2: yes.

Expected output:

Restate

I would write a migration plan for moving authentication from JWTs to session cookies. I would cover scope, rollout order, rollback, testing, and user-visible risk. I would not pick a framework-specific implementation until the current auth stack is specified.

Decisions

• Treat this as an engineering plan, not an announcement.
• Include rollout and rollback because auth changes can lock users out.

Assumptions

• Current auth uses bearer JWTs in browser-facing flows. Evidence: the task names JWT to cookie migration. Would change if: JWTs are only for server-to-server traffic.
• The plan needs implementation sequencing. Evidence: "migration plan" implies ordered work. Would change if: the user only needs an executive summary.

Unknowns

• Current framework and session store.
• Required logout, CSRF, and cookie settings.

Confidence

medium. Basis: the desired migration is clear, but the framework and risk constraints are missing.

Status

blocked-pending-answers.

If Phase 2 was requested, add a standalone prompt under 400 words after the ledger.