A skeletal plan is a partially specified, abstract plan generated early in the HTN planning process. It contains high-level, compound tasks that have not yet been fully decomposed into executable primitive tasks. This intermediate representation serves as a scaffold, outlining the intended structure and order of operations while leaving specific implementation details to be resolved through subsequent task decomposition and plan refinement steps.
Glossary
Skeletal Plan

What is a Skeletal Plan?
A skeletal plan is a core intermediate structure in Hierarchical Task Network (HTN) planning, representing a partially specified sequence of actions that requires further refinement.
The primary function of a skeletal plan is to guide the search for a complete solution by committing to a high-level strategy before filling in low-level details. It is produced by applying decomposition methods to the initial goal tasks, creating a network of subtasks with ordering constraints. The planner then iteratively refines this skeleton by decomposing remaining abstract tasks until only directly executable actions remain, resulting in a solution plan.
Key Characteristics of a Skeletal Plan
A skeletal plan is a core intermediate artifact in HTN planning, representing a partially specified solution that requires further refinement. It bridges the gap between an abstract goal and a fully executable sequence of actions.
Partial Specification
A skeletal plan is defined by its incompleteness. It contains abstract tasks (compound tasks) that have not yet been decomposed into primitive, executable actions. This distinguishes it from a solution plan, which is fully grounded. The planner's job is to iteratively refine this skeleton through task decomposition until no abstract tasks remain.
Hierarchical Structure
The plan explicitly maintains the parent-child relationships from the decomposition process. This is often visualized as a decomposition tree. This structure is crucial for:
- Traceability: Understanding which high-level goal a specific action serves.
- Replanning: If execution fails, the planner can backtrack to a higher-level abstract task and try an alternative method.
- Explanation: Providing a rationale for why certain actions are included.
Foundation for Refinement
The skeletal plan is the starting point for plan refinement. The planner selects an abstract task, finds an applicable decomposition method whose preconditions are satisfied, and replaces the abstract task with the method's subtask network. This process repeats in a depth-first (like SHOP) or other search order until the plan is fully primitive.
Contains Constraints
Beyond tasks, a skeletal plan encodes critical constraints that must be preserved during refinement:
- Ordering Constraints: Temporal relations (e.g., Task A before Task B).
- Causal Links: Protect a condition achieved by one task for use by another.
- Variable Bindings: Parameters of abstract tasks may be partially bound. These constraints guide and prune the search space during subsequent decomposition.
State-Dependent Validity
The validity of a skeletal plan is contingent on the current world state. An abstract task may have multiple possible decomposition methods; the choice depends on which method's preconditions hold. A change in the world state can invalidate the chosen decomposition path, necessitating replanning from a point higher in the hierarchy.
Efficiency in Search
Generating a skeletal plan early allows the HTN planner to commit to a high-level strategy before detailing all low-level actions. This hierarchical search is often more efficient than flat state-space planning (like STRIPS) for complex domains, as it uses the domain's task library to prune vast areas of the search space that don't conform to sensible task decomposition.
How Skeletal Plans Work in HTN Planning
A skeletal plan is a partially specified, intermediate blueprint generated during Hierarchical Task Network (HTN) planning. It contains abstract, non-primitive tasks that require further decomposition before execution.
A skeletal plan is a partially specified, intermediate blueprint generated during Hierarchical Task Network (HTN) planning. It contains abstract, non-primitive tasks that require further decomposition before execution. This structure emerges early in the planning process as the planner begins to apply decomposition methods to high-level goal tasks, creating a framework of compound tasks and ordering constraints without yet resolving all details to the level of primitive actions.
The planner refines this skeletal structure through plan refinement, recursively decomposing each abstract task using applicable methods until only primitive tasks (executable actions) remain. This hierarchical approach allows for efficient search by postponing low-level decisions and enables the reuse of proven high-level strategies encoded in the task library. The final output is a fully instantiated, executable solution plan derived from the initial skeletal blueprint.
Frequently Asked Questions
A skeletal plan is a core concept in Hierarchical Task Network (HTN) planning, representing a partially specified blueprint for achieving a goal. This FAQ addresses common technical questions about its structure, generation, and role in autonomous agent systems.
A skeletal plan is a partially specified, abstract plan generated during the early or intermediate stages of Hierarchical Task Network (HTN) planning. It contains high-level compound tasks that have not yet been fully decomposed into primitive tasks (executable actions). Think of it as an architectural blueprint where the main structural components are defined, but the specific wiring and plumbing details are not yet filled in.
For example, in a logistics domain, a skeletal plan for "Deliver Package" might contain the abstract tasks [Navigate to District, Acquire Package, Finalize Delivery]. Each of these is a compound task requiring further decomposition by HTN methods before the plan becomes a concrete sequence of actions like [Turn left on Oak St., Pick up item #123, Obtain recipient signature].
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
A skeletal plan exists within the broader framework of Hierarchical Task Network (HTN) planning. These related concepts define the components and processes that interact with a skeletal plan during its creation, refinement, and execution.
Hierarchical Task Network (HTN)
A planning formalism where the solution is generated by recursively decomposing high-level, abstract tasks into networks of smaller subtasks using decomposition methods. This process continues until only primitive tasks (directly executable actions) remain. HTNs are the overarching architecture within which a skeletal plan is created and refined.
Compound Task
A high-level, abstract task in an HTN that cannot be executed directly. It must be decomposed into a network of subtasks using an applicable method. In a skeletal plan, many nodes are compound tasks awaiting further refinement. Examples include AssembleProduct or DiagnoseSystemFault.
Primitive Task
A task that corresponds directly to an executable action or operator in the planning domain. It has defined preconditions and effects. The goal of refining a skeletal plan is to replace all abstract compound tasks with a sequence of primitive tasks. Examples include PickUp(Screwdriver) or SendAPIRequest(/api/validate).
Method (HTN)
A schema that defines one possible way to decompose a specific compound task into a network of subtasks. A method includes:
- Task Head: The compound task it decomposes.
- Preconditions: Logical conditions required for this decomposition to be valid.
- Subtasks: The network of (compound or primitive) tasks that implement the head. Planners choose among applicable methods to refine a skeletal plan.
Plan Refinement
The iterative process in HTN planning of replacing abstract tasks in a skeletal plan with more concrete subtasks. This involves:
- Selecting an abstract (compound) task in the current plan.
- Choosing an applicable method for that task.
- Replacing the task with the method's subtask network. This loop repeats until the plan contains only executable primitive actions.
Decomposition Tree
A tree structure that visually represents the complete hierarchical breakdown of a high-level goal task into its constituent primitive actions. It is the fully-expanded record of all plan refinement steps. The root is the initial goal, internal nodes are compound tasks and methods, and leaves are primitive tasks. A skeletal plan corresponds to a partially expanded decomposition tree.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us