align
- Repo stars 8
- License Apache-2.0
- Author updated Live
- Author repo controlkeel
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @aryaminus · Apache-2.0
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: align
description: Interview the user about their goal before any plan or code. Reach shared understanding of what…
category: engineering
runtime: no special runtime
---
# align output preview
## PART A: Task fit
- Use case: 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..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Protocol / Non-negotiable rules / What you produce” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “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.”.
- **02** When the source has headings, the agent prioritizes “Protocol / Non-negotiable rules / What you produce” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Protocol / Non-negotiable rules / What you produce”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: align
description: Interview the user about their goal before any plan or code. Reach shared understanding of what…
category: engineering
source: aryaminus/controlkeel
---
# align
## When to use
- Interview the user about their goal before any plan or code. Reach shared understanding of what, why, which layers, su…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Protocol / Non-negotiable rules / What you produce” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "align" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Protocol / Non-negotiable rules / What you produce
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}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
Decide Fit First
Design Intent
How To Use It
Boundaries And Review