# Align

> Interview the user about their goal before any plan or code. Reach shared understanding of what, why, which layers, success criteria, and unknowns. Feed the result into plan-slice or ck_review_submit.

- Skill: `aryaminus/align` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aryaminus/align`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aryaminus/align/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: aryaminus (https://skillmd.com/u/aryaminus)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aryaminus/align

---


# Align Skill

Reach a **shared design concept** with the user before any plan or code is written. The most expensive misalignment is the one caught after implementation — catch it here instead.

## Protocol

1. Call `ck_context` to load current session state, domain pack, and any prior goals or decisions already recorded.
2. Call `ck_memory_search` with the user's stated goal to surface prior aligned work on the same area before asking redundant questions.
3. Ask the user **one question at a time**. For each question, provide your recommended answer so the user can confirm, adjust, or replace it — never leave them staring at a blank.
4. Work through the alignment tree in this order:

   **What** — What is the exact outcome? What is explicitly out of scope?
   **Why** — What problem does this solve? What is the success signal?
   **Who** — Who uses the result? Which roles, systems, or integrations are affected?
   **Layers** — Which system layers does this touch? (schema, services, APIs, UI, infra, third-party) Record each touched layer explicitly — this drives vertical slice decomposition later.
   **Acceptance criteria** — What does "done" look like? What would a failing test catch? Reframe vague requirements into concrete, testable conditions.
   **Edge cases** — What breaks if inputs are invalid, empty, or unexpected?
   **Constraints** — Budget, timeline, tech stack limits, compliance requirements, or must-not-change areas.
   **Assumptions** — What are you assuming about the environment, tech stack, data sources, or integrations? Surface these explicitly before proceeding.
   **Unknowns** — What do you not know yet? What needs a spike or research before implementation starts?

5. After each resolved decision, call `ck_memory_record` with type `decision` to persist it. Future agents resuming this work will recover these without asking again.
6. When alignment is complete, call `ck_goal` (mode: `record`, horizon: `session`) to record the aligned goal with its acceptance criteria and touched layers.
7. Tell the user the alignment is complete and recommend the next step:
   - If the work is multi-layer and will need decomposition → activate `plan-slice`.
   - If the work is a single small change that fits in one task → proceed to `ck_review_submit` (plan_phase: `narrowed_decision`).

## Non-negotiable rules

- Never skip alignment and go straight to planning or code, even for "small" tasks. A missed constraint at this stage compounds into blocked findings or rework later.
- Do not produce a plan, PRD, or code during this skill. The output is a recorded goal and a set of decisions — nothing else.
- If the user says "just do it," record what you know so far, note the unknowns explicitly, and move forward — but surface the open questions as warnings so they can surface as findings if they bite later.
- Planning is always human-in-the-loop. The agent asks; the human decides. Never answer your own alignment questions and continue as if the human agreed.

## What you produce

At the end of this skill:
- A `ck_goal` record with: objective, acceptance criteria, touched layers, known constraints, explicit assumptions, open unknowns.
- One or more `ck_memory_record` entries (type: `decision`) for each resolved design choice.
- A clear recommendation on whether to proceed to `plan-slice` or directly to `ck_review_submit`.

## Additional resources

- For the full governed workflow, see [references/workflow.md](references/workflow.md)

