Inferensys

Glossary

Skeletal Plan

A skeletal plan is a partially specified plan, often generated early in Hierarchical Task Network (HTN) planning, that contains abstract tasks requiring further decomposition into primitive actions.
Product manager reviewing autonomous task execution dashboard on laptop, completed tasks visible, casual work session.
HIERARCHICAL TASK NETWORKS

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.

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.

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.

HIERARCHICAL TASK NETWORKS

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.

01

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.

02

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.
03

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.

04

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.
05

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.

06

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.

CORE CONCEPT

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.

SKELETAL PLAN

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].

Prasad Kumkar

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.