# Intent Framed Agent

> Frames coding-agent work sessions with explicit intent capture and drift monitoring. Use when a session transitions from planning/Q&A to implementation for coding tasks, refactors, feature builds, bug fixes, or other multi-step execution where scope drift is a risk.

- Skill: `pskoett-pskoett-ai-skills/intent-framed-agent` (Agent Skill)
- Install (CLI): `npx skillmds add pskoett-pskoett-ai-skills/intent-framed-agent`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pskoett-pskoett-ai-skills/intent-framed-agent/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: pskoett (https://skillmd.com/u/pskoett-pskoett-ai-skills)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/pskoett-pskoett-ai-skills/intent-framed-agent

---


# Intent Framed Agent

## Install

```bash
gh skill install pskoett/pskoett-skills
```

```bash
gh skill install pskoett/pskoett-skills intent-framed-agent
```

Fallback using the Agent Skills CLI:

```bash
npx skills add pskoett/pskoett-skills/skills/intent-framed-agent
```

## Purpose

This skill turns implicit intent into an explicit, trackable artifact at the
moment execution starts. It creates a lightweight intent contract, watches for
scope drift while work is in progress, and closes each intent with a short
resolution record.

## Scope (Important)

Use this skill for coding tasks only. It is designed for implementation work
that changes executable code.

Do not use it for general-agent activities such as:
- broad research
- planning-only conversations
- documentation-only work
- operational/admin tasks with no coding implementation

For trivial edits (for example, simple renames or typo fixes), skip the full
intent frame.

## Trigger

Activate at the planning-to-execution transition for non-trivial coding work.

Common cues:
- User says: "go ahead", "implement this", "let's start building"
- Agent is about to move from discussion into code changes

## Workflow

### Phase 1: Intent Capture

At execution start, emit:

```markdown
## Intent Frame #N

**Outcome:** [One sentence. What does done look like?]
**Approach:** [How we will implement it. Key decisions.]
**Constraints:** [Out-of-scope boundaries.]
**Success criteria:** [How we verify completion.]
**Estimated complexity:** [Small / Medium / Large]
```

Rules:
- Keep each field to 1-2 sentences.
- Reuse current approval when an approved plan or explicit instruction to
  proceed already covers the frame's outcome, approach, constraints, and
  success criteria. Emit the frame for traceability and continue.
- Ask `Does this capture what we are doing? Anything to adjust before I start?`
  only when no current approval exists, the frame adds a material decision or
  assumption, or scope/constraints changed.
- Do not proceed while a material decision remains unresolved.

### Phase 2: Intent Monitor

During execution, monitor for drift at natural boundaries:
- before touching a new area/file
- before starting a new logical work unit
- when current action feels tangential

Drift examples:
- work outside stated scope
- approach changes with no explicit pivot
- new features/refactors outside constraints
- solving a different problem than the stated outcome

When detected, emit:

```markdown
## Intent Check #N

This looks like it may be moving outside the stated intent.

**Stated outcome:** [From active frame]
**Current action:** [What is happening]
**Question:** Is this a deliberate pivot or accidental scope creep?
```

If the user already directed the pivot, update the active intent frame and
continue under the enduring constraints. Otherwise ask whether the apparent
pivot is intentional. If not, return to the original scope.

### Phase 3: Intent Resolution

When work under the active intent ends, emit:

```markdown
## Intent Resolution #N

**Outcome:** [Fulfilled / Partially fulfilled / Pivoted / Abandoned]
**What was delivered:** [Brief actual output]
**Pivots:** [Any acknowledged changes, or None]
**Open items:** [Remaining in-scope items, or None]
```

Resolution is preferred but optional if the session ends abruptly.

## Multi-Intent Sessions

One session can contain multiple intent frames.

Rules:
1. Resolve current intent before opening the next.
2. If user changes direction mid-task, resolve current intent as
   `Abandoned` or `Pivoted`, then open a new frame.
3. Drift checks always target the currently active frame.
4. Number frames sequentially within the session (`#1`, `#2`, ...).
5. Enduring constraints carry forward; frame-local choices do not. User
   prohibitions, safety/privacy limits, authorization boundaries, repository
   restrictions, and explicit "do not" instructions remain active until the
   user revokes them. A local implementation choice carries forward only when
   the new outcome still depends on it; otherwise restate it or ask.

## Entire CLI Integration

Entire CLI: https://github.com/entireio/cli

When tool access is available, detect Entire at activation:

```bash
entire status 2>/dev/null
```

- If it succeeds and the active host adapter records conversation lifecycle
  events, mention that intent records are expected in the session transcript.
  Do not infer complete transcript coverage from `entire status`; inspect the
  available session/checkpoint state before relying on it for
  `learning-aggregator --deep`.
- If unavailable/failing, continue silently. Do not block execution and do not
  nag about installation.

Copilot/chat fallback:
- If command execution is unavailable, skip detection and continue with the
  same intent workflow in chat output.

### How intent frames become learning signals

When the active host adapter captures message events, each Intent Frame and
Intent Check is available in Entire's session transcript. At cadence,
`learning-aggregator --deep` can read the available transcripts and extract:

- Frames that were resolved as `Abandoned` or `Pivoted` → potential planning
  gaps
- Drift signals that repeatedly fire in similar contexts → potential scope
  definition issues
- Constraint violations detected by drift checks → patterns for promotion to
  project instruction files

You do not need to do anything special for this — the intent blocks are
structured (`## Intent Frame #N`, `## Intent Check`, `## Intent Resolution`),
which makes them parseable from the transcript.

## Guardrails

- Keep it lightweight; avoid long prose.
- Do not over-trigger on trivial tasks.
- Do not interrupt on every small step.
- Treat acknowledged pivots as valid.
- Preserve exact structured block headers/fields for parseability.

## Interoperability with Other Skills

Use this skill as the front-door alignment layer for non-trivial coding work:
1. `plan-interview` (optional, for requirement shaping)
2. `intent-framed-agent` (execution contract + scope drift monitoring)
3. `context-surfing` (optional context-quality monitoring for Large,
   Long-running, or explicitly context-sensitive execution)
4. `simplify-and-harden` (post-completion quality/security pass)
5. `self-improvement` (capture recurring patterns and promote durable rules)

### Relationship with context-surfing

When `context-surfing` is activated, both skills are live during execution.
They monitor different failure modes:

- **intent-framed-agent** monitors *scope* drift — is the agent doing the right
  thing? It fires structured Intent Checks when work moves outside the stated
  outcome.
- **context-surfing** monitors *context quality* drift — is the agent still
  capable of doing it well? It fires when the agent's own coherence degrades
  (hallucination, contradiction, hedging).

They are complementary, not redundant. An agent can be perfectly on-scope while
its context quality degrades. Conversely, scope drift can happen with perfect
context quality. Intent Checks continue firing alongside context-surfing's wave
monitoring.

**Precedence rule:** If both skills fire simultaneously (an Intent Check and a
context-surfing drift exit at the same time), the drift exit takes precedence.
Degraded context makes scope checks unreliable — resolve the context issue
first, then resume scope monitoring in the next session.

**Cadence separation:** Intent Checks fire at scope boundaries — before
touching a new area/file, before starting a new logical work unit, when the
current action feels tangential. Context-surfing's pre-commit anchor check
fires at side-effecting-action moments — specific tool calls, writes,
commits, commit-level output. Don't run both in the same beat: if an Intent
Check has just fired and resolved cleanly, the next side-effecting action
inside the same work unit doesn't need a fresh anchor check — you already
re-grounded.

### What this skill produces

- **Intent frame artifact** — consumed by context-surfing as part of the wave
  anchor and copied verbatim into handoff files on drift exit.
- **Intent resolution** — signals task completion, which triggers
  simplify-and-harden.
- **Drift observations** — scope drift patterns can be logged to
  self-improvement as learnings if they recur.

