Intent Align

Intent-alignment orchestration for OpenClaw agent teams across diverse host environments. Use when work must stay anchored to user goals while allowing flexi...

Intent-Align v2 Core

Keep execution aligned to user intent while preserving agent autonomy.

Quick Start

1. Read references/core-contract.md.
2. Create alignment hub from references/alignment-hub-template.md.
3. Run Intent Quality Gate before planning.
4. Select adapters from references/adapters/.
5. Execute phases with realignment and verification gates.

Workflow Contract

1. Build intent_snapshot and run intent_lint (see core contract).
2. Ask for strictness mode and scope overrides (project/repo/workflow/task).
3. Resolve effective strictness by precedence: task > workflow > repo > project > default.
4. Evaluate ambiguity action using severity + strictness + risk class.
5. Generate phase plan and Mermaid diagram with explicit dependencies and gates.
6. Bind available adapters through capability_matrix.
7. Execute phase-by-phase.
8. Before phase start, run Pre-Execution Clarification Gate.
9. On each phase end, run verification gates (including output conformance) and update drift evidence.
10. If intent or constraints change, apply intent_delta and re-plan only impacted phases.
11. Close with final alignment report and open ambiguity list (if any).

Autonomy Levels

• 1 Strict: Require user confirmation before each phase start.
• 2 Balanced: Require user confirmation at phase end or any critical drift.
• 3 Aggressive: Auto-continue on low drift; require confirmation on major deltas.
• 4 Exploratory: Continue with log-only check-ins unless risk or ambiguity threshold is exceeded.

Override rule: high-risk ambiguity is never advisory-only; enforce at least soft_gate. Strictness rule: strictness mode controls whether ambiguities block or proceed with guardrails.

Required References

• references/core-contract.md
• references/alignment-hub-template.md
• references/realignment-protocol.md
• references/verification-gates.md
• references/capability-taxonomy.md

Adapter Selection

Use only adapters needed for the task:

• references/adapters/github.md
• references/adapters/local-repo.md
• references/adapters/tracker-generic.md
• references/adapters/adapter-template.md

If no adapter can satisfy a required capability:

1. Generate an ad-hoc adapter spec from adapter-template.md.
2. Add provenance metadata (created_by, created_at, environment_assumptions, tool_access_required).
3. Validate required fields before use.
4. Register the new adapter in capability_matrix.adapters_selected.
5. Continue in degraded mode only if validation fails or auth/capability remains unavailable.

Anti-Bloat Rules

• Keep core contract tool-agnostic.
• Do not add tracker- or host-specific logic to core files.
• Add a new adapter only for a proven capability gap.
• Keep schemas single-source; do not duplicate fields across files.
• Tie each new feature to one concrete failure mode and one test scenario.
• Generate ad-hoc adapters only for current task scope; do not pre-generate broad catalogs.
• Use canonical capability IDs first; extend only when needed via namespaced custom IDs.

Edge Cases

• Multi-repo: maintain one hub with per-repo adapter bindings and dependency graph.
• Non-git prototype: use local artifacts and explicit acceptance criteria checkpoints.
• Team swarm: assign owner per phase and keep decision log in hub.