Skill: oscraters/intent-align (version 2.0.0)

--- name: intent-align description: "Intent-alignment orchestration for OpenClaw agent teams across diverse host environments. Use when work must stay anchored to user goals while allowing flexible execution: (1) coding with repos/PRs/issues, (2) multi-phase delivery with checkpoints, (3) multi-agent or multi-repo coordination, (4) evolving requirements needing structured re-alignment and user clarification loops." --- # Intent-Align v2 Core Keep execution aligned to user intent while preserving agent autonomy. ## Quick Start 1. Read [references/core-contract.md](references/core-contract.md). 2. Create alignment hub from [references/alignment-hub-template.md](references/alignment-hub-template.md). 3. Run Intent Quality Gate before planning. 4. Select adapters from [references/adapters/](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/core-contract.md) - [references/alignment-hub-template.md](references/alignment-hub-template.md) - [references/realignment-protocol.md](references/realignment-protocol.md) - [references/verification-gates.md](references/verification-gates.md) - [references/capability-taxonomy.md](references/capability-taxonomy.md) ## Adapter Selection Use only adapters needed for the task: - [references/adapters/github.md](references/adapters/github.md) - [references/adapters/local-repo.md](references/adapters/local-repo.md) - [references/adapters/tracker-generic.md](references/adapters/tracker-generic.md) - [references/adapters/adapter-template.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.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: suspicious | SkillSpector: clean (LOW)