align
- Repo stars 8
- License Apache-2.0
- Author repo controlkeel
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
Call
ck_contextto load current session state, domain pack, and any prior goals or decisions already recorded.Call
ck_memory_searchwith the user's stated goal to surface prior aligned work on the same area before asking redundant questions.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.
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?
After each resolved decision, call
ck_memory_recordwith typedecisionto persist it. Future agents resuming this work will recover these without asking again.When alignment is complete, call
ck_goal(mode:record, horizon:session) to record the aligned goal with its acceptance criteria and touched layers.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).
- If the work is multi-layer and will need decomposition → activate
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_goalrecord with: objective, acceptance criteria, touched layers, known constraints, explicit assumptions, open unknowns. - One or more
ck_memory_recordentries (type:decision) for each resolved design choice. - A clear recommendation on whether to proceed to
plan-sliceor directly tock_review_submit.
Additional resources
- For the full governed workflow, see references/workflow.md
- Fluxly category
- Engineering
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 94 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @aryaminus · Apache-2.0
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Plug-and-play
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Unspecified
- Detected file/system behavior
-
- Read-only
- Detected network behavior
- Local-only
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. Call ckcontext to load current session state, domain pack, and any prior goals or decisions already recorded. Call ckmemorysearch with the user's stated goal to surface prior aligned work on the same area before asking redundant questions.
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…
At the end of this skill: A ckgoal record with: objective, acceptance criteria, touched layers, known constraints, explicit assumptions, open unknowns. One or more ckmemoryrecord entries (type: decision) for each resolved design choice.
For the full governed workflow, see references/workflow.md
# 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?
… Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Protocol → Non-negotiable rules → What you produce → Additional resources
terms -> shared design concept · one question at a time · What · Why · Who · Layers · Acceptance criteria · Edge cases
files/cmd -> ckcontext · ckmemorysearch · ckmemoryrecord · decision · ckgoal · record · session · plan-slice
body sha256 -> 6e2e06774329
Decide Fit First
Design Intent
How To Use It
Boundaries And Review