applicable method, instantiates it to decompose the task into subtasks, and then chooses and instantiates methods to decompose the subtasks even further, as illustrated in Figure 2.

If the plan later turns out to be infeasible, the planning system will need to backtrack and try other methods.

HTN methods generally describe the "standard operating procedures" that one would normally use to perform tasks in some domain (e.g., see Figure 1) Most HTN practitioners would argue that such representations are more appropriate **for many real-world domains**
than are classical planning operators, as they better characterize the way that users think about problems.

Like most other HTN planners, SHOP2 is "hand-tailorable:" its planning engine is domain-independent, but the HTN methods may be domain-specific, and the planner can be customized to work in different problem domains by giving it different sets of HTN
methods. The ability to use domain-specific problem-solving knowledge can dramatically improve a planner's performance, and sometimes make the difference between solving a problem in exponential time and solving it in polynomial time (e.g., Gupta & Nau, 1992; Slaney & Thi´ebaux, 2001). In experimental studies (e.g., Nau et al., 1999, 2001; Bacchus & Kabanza, 2000), hand-tailorable planners have quickly solved planning problems orders of magnitude more complicated than those typically solved by "fully automated" planning systems in which the domain-specific knowledge consists only of the planning operators.

## 3. Features Of Shop2

This section describes SHOP2's planning algorithm and some **of SHOP2's distinctive features.**

## 3.1 Basic Elements Of A Domain Description

A *domain description* **is a description of a planning domain, consisting of a set of methods,** operators, and axioms. Below we describe each of these briefly; additional details appear in Section 4.

## 3.1.1 Tasks

A *task* **represents an activity to perform. Syntactically, a task consists of a** *task symbol* followed by a list of arguments. A task may be either primitive or *compound***. A primitive**
task is one that is supposed to be accomplished by a planning operator: the task symbol is the name of the planning operator to use, and the task's arguments are the parameters for the operator. A compound task is one that needs to be decomposed into smaller tasks using a method; any method whose head unifies with the task symbol and its arguments may potentially be applicable for decomposing the task. The **details are discussed in the** following subsections.

## 3.1.2 Operators

Each operator indicates how a primitive task can be performed. The operators are very similar to PDDL operators: each operator o **has a** *head* head(o**) consisting of the operator's**
name and a list of parameters, a *precondition* expression pre(o**) indicating what should be**