Teleological Pre-Inference¶
Recover the completion object, assumptions, purpose, constraints, and definition of done before an agent starts solving.
Use this when a request is ambiguous, strategic, architectural, delegated, or easy to satisfy literally while missing its purpose. Skip it for settled factual questions and simple one-step edits.
Full Skill¶
Copy this entire block into SKILL.md.
---
name: teleological-pre-inference
description: Use when the user gives an ambiguous, architectural, strategic, specification, delegation, audit, planning, or intent-parsing request and the agent should clarify the real task before answering, coding, or delegating. Run this before solutioning when literal compliance might miss the user’s actual goal.
---
# Teleological Pre-Inference
Use this skill to convert a messy request into a causally aligned task definition before planning, implementation, delegation, or review.
## When To Use
Use this skill when one or more of these are true:
1. The request is ambiguous, layered, or carries multiple possible completion objects.
2. The user is asking for architecture, specifications, contracts, plans, audits, prioritization, or delegation.
3. The work could consume significant time or branch the project in a lasting direction.
4. A worker or subagent may be asked to act autonomously.
5. The user explicitly asks to parse intent, think through assumptions, define teleological ground, binding constraints, or definition of done.
6. The obvious answer may satisfy the wording while failing the real goal.
Do not use this skill for trivial factual questions or simple one-step edits where the task is already unambiguous.
## Core Rule
Do not answer the request directly first.
First, redefine the task through the protocol below.
Only then answer, plan, delegate, or implement.
## Protocol
Work in this order.
### 0. Completion Object Recovery
If the user omitted `Completion object` and started at assumptions, infer it first.
Ask:
- What entity needs to change?
- What state should it be in when the work is complete?
This inferred completion object becomes step 1 for the rest of the protocol.
### 1. Assumptions
Ask:
- What hidden premises is this request standing on?
- Which assumptions would materially change the answer if false?
Surface assumptions explicitly rather than silently inheriting them.
### 2. Teleological Ground
Ask:
- What is this actually for?
- What would count as failure even if the request were followed literally?
This step protects against literal compliance without causal advancement.
### 3. Binding Constraints
Ask:
- What follows from the teleological ground that rules options out before solutioning?
- What boundaries must hold for the result to be valid?
Use constraints to eliminate invalid approaches early.
### 4. Definition Of Done
Ask:
- What does success look like in externally verifiable terms?
- What could a reviewer observe without relying on intent or narrative?
Define success as a real-world condition, not just a spec-shaped phrase.
### 5. Literal-Following Check
Ask:
- If a worker did exactly this task as written, would it causally advance the real goal?
- Or would it merely look compliant?
If literal following would miss the real goal, revise the task before proceeding.
## Output Shape
Emit the result in this structure:
## Completion Object
...
## Assumptions
...
## Teleological Ground
...
## Binding Constraints
...
## Definition Of Done
...
## Literal-Following Check
...
## Response
...
The `Response` section should only come after the protocol is complete.
## Operating Rules
1. Prefer explicit task redefinition over clever interpretation.
2. Treat ambiguity as a signal to clarify the task model, not as license to improvise.
3. Keep the protocol concise but real. Do not pad it with generic prose.
4. If the task is architectural or strategic, bias toward surfacing teleology before proposing solutions.
5. If the task will be delegated, derive the worker scope from the binding constraints rather than the surface wording alone.
6. When useful, restate the real question in one sentence before answering.
7. If the user already supplied part of the protocol, complete the missing pieces instead of ignoring their frame.
## Failure Modes To Avoid
Do not:
1. Use the protocol as empty formatting.
2. Jump to solutions before defining the completion object.
3. Treat “what was asked” as identical to “what is actually for”.
4. Give a definition of done that can only be checked by rereading the spec.
5. Delegate work whose literal wording would not causally advance the real goal.
## Typical Use Cases
Use this skill before:
1. Writing specs or contracts.
2. Designing architecture.
3. Creating work plans or dependency chains.
4. Assigning work to subagents or workers.
5. Auditing whether completed work matches intent.
6. Evaluating whether a branch, repo, or handoff is the right continuation lane.
## Standard
The protocol is successful only if it changes what the agent does next in a way that better aligns execution to the user’s real goal.
Install¶
The installer writes to $CODEX_HOME/skills when CODEX_HOME is set and otherwise uses ~/.codex/skills.
Short Prompt¶
Use this when you want the protocol without installing the skill:
Before responding, run teleological pre-inference.
1. Completion object:
What entity needs to change, and what state should it be in when complete?
2. Assumptions:
What hidden premises is this request standing on?
3. Teleological ground:
What is this actually for?
What would count as failure even if the request were followed literally?
4. Binding constraints:
What follows from that ground that rules options out before solutioning?
5. Definition of done:
What would a reviewer observe if the work were genuinely complete?
6. Literal-following check:
Would doing exactly what was asked causally advance the real goal,
or only look compliant?
Then proceed.
Worked Example¶
Request
Literal answer
Teleological recovery
Completion object: the car needs to become clean.
Binding constraint: the car itself must reach the car wash.
Literal-following check: walking the person there leaves the car at home.
Answer
The distance heuristic was locally plausible but irrelevant to the object that needed to move.
Related Writing¶
A Guide to Meta-Prompting for Agents in 2026 develops the motivating failure case and the difference between prompting tricks and specifying the purpose of the work.
Continue with Teleology-Preserving Planning when the task is understood but a plausible plan may still lose the point.
Metadata¶
{
"name": "Teleological Pre-Inference",
"slug": "teleological-pre-inference",
"category": "Reasoning Protocol",
"operation": ["clarify", "constrain", "define"],
"artifact": "Task contract",
"interaction_mode": "Before planning or execution",
"status": "Public",
"license": "MIT",
"models_tested": ["GPT-5 class workflows", "Codex workflows"],
"source": "Personal workflow",
"last_reviewed": "2026-07-09"
}
License¶
MIT License.