skills/nau-au-kuter-2003-shop2/SKILL.md
SHOP2 hierarchical task network planner for automated planning through recursive task decomposition
npx skillsauth add curiositech/windags-skills nau-au-kuter-2003-shop2Install this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Plan tasks in execution order to transform exponential state-space reasoning into linear complexity. With known current state, you can trivially call external functions and make decisions based on actual conditions, not possibility spaces.
Represent domain knowledge as methods that capture how experts solve problems. A method says "to accomplish X in situation Y, do subtasks A, B, C in that order"—transforming search problems into procedure selection.
Work at the highest abstraction level possible. Planning "transport-person" is tractable; planning 200 atomic movements from first principles is not. Decompose only when necessary for current execution.
IF domain has established expert procedures
→ Encode as HTN methods with preconditions
→ Use sort-by heuristics for method selection
ELSE IF domain requires learning/discovery
→ Start with learned policies
→ Migrate successful patterns to methods over time
ELSE IF procedures vary significantly by context
→ Use conditional methods with situation-specific preconditions
→ Maintain method libraries organized by context types
IF execution order determinable at planning time
→ Use ordered decomposition for simple state reasoning
→ Maintain definite current state, not possibility sets
ELSE IF tasks genuinely independent and parallelizable
→ Use partial-order planning
→ Accept cost of tracking state uncertainty
ELSE IF complex reasoning needed (temporal, probabilistic)
→ First try state augmentation (add timestamps, probabilities)
→ Only build specialized reasoning engines if augmentation insufficient
IF domain description differs from execution environment
→ Maintain automated translation layer
→ Validate translation with small test cases
ELSE IF execution failures occur frequently
→ Check specification-vs-execution gap first
→ Verify operator effects match actual execution results
ELSE IF performance inadequate
→ Add domain-specific methods to baseline capabilities
→ Profile for exponential search patterns
IF domain experts exist and procedures are established
→ Hand-code methods encoding expert knowledge
→ Accept "cheating" vs pure learning for 2x performance gain
ELSE IF domain exploratory or procedures unknown
→ Use automated learning with PDDL operators
→ Plan to migrate learned patterns to explicit methods
ELSE IF mixed domain (some known procedures, some discovery)
→ Hybrid: methods for known procedures, learning for novel situations
→ Automated promotion of successful learned patterns to methods
Detection Rule: Planner generates syntactically valid plans that fail during execution Symptom: Plans look correct, execute incorrectly, consistent failure pattern across similar problems Diagnosis: Hand-written HTN methods contain logical errors—wrong preconditions, incorrect effect specifications, missing edge cases Fix: Systematic testing of methods on small instances; automated validation tools; pair programming for method development
Detection Rule: Mysterious planning failures on problems that should be solvable Symptom: PDDL operators work in other planners but SHOP2 translation produces poor performance or invalid plans Diagnosis: Gap between what operators specify and how tasks are actually accomplished; missing procedural knowledge Fix: Manual enhancement of auto-translated domains; encode expert procedures as methods; validate translation with domain experts
Detection Rule: Planning time grows exponentially with problem size; solver times out on medium instances Symptom: Planner explores vast numbers of decompositions; thrashes between similar partial plans; memory usage grows uncontrollably Diagnosis: Missing domain-specific methods cause fall-back to inefficient search; no heuristic guidance for method selection Fix: Add methods that encode standard procedures; implement sort-by heuristics; profile search patterns to identify missing knowledge
Detection Rule: Planner backtracks excessively between competing valid decompositions Symptom: Multiple methods applicable to same task; solver oscillates between options; search depth grows without progress Diagnosis: Methods lack sufficient specificity in preconditions; competing heuristics without clear priority ordering Fix: Refine method preconditions for better context sensitivity; implement preference ordering; add meta-methods for method selection
Detection Rule: Complex optimization produces worse results than simple heuristic approaches Symptom: Sophisticated search algorithms underperform greedy method selection; optimal planning fails on problems simple heuristics solve Diagnosis: Over-investment in search sophistication without adequate domain knowledge; treating domain expertise as "cheating" Fix: Encode domain heuristics first; start with simple greedy search; add sophistication only when domain knowledge insufficient
Scenario: Design coordination system for multi-agent document generation (research, outline, draft, review, edit).
Novice Approach: Create agents for each subtask, use message passing for coordination, track all possible states.
Expert HTN Analysis:
Method: generate-document
Preconditions: topic assigned, no existing document
Decomposition: research-topic, create-outline, draft-sections, review-draft, finalize-document
Key Decision: Use ordered decomposition with known handoff points rather than tracking all possible agent interaction states. Reduces complexity from O(n!) to O(n).
Trade-off Navigated: Accept constraint of sequential high-level phases (can't start drafting before research) to gain tractable coordination. Allow parallelism within phases via state augmentation.
Scenario: Plan multi-day conference setup with limited staff, equipment conflicts, vendor dependencies.
Novice Approach: Model as constraint satisfaction problem with all resources, times, dependencies as variables.
Expert HTN Analysis:
Method: setup-conference-day
Preconditions: venue confirmed, staff assigned, equipment list finalized
Decomposition: setup-venue, test-av-systems, prepare-catering, brief-staff
Sort-by: critical-path-first (AV failures block everything)
Key Decision: Encode conference management expertise as methods rather than discovering optimal schedules through search. Expert procedures handle 95% of situations; search only needed for novel constraints.
Alternative Considered: Pure optimization approach would find "optimal" schedules but miss critical dependencies that conference experts know (e.g., catering setup must happen after final headcount, not at optimal resource utilization time).
Task Planning Completeness:
Domain Knowledge Coverage:
Performance and Scalability:
Correctness and Robustness:
Don't Use HTN Planning For:
Delegate Instead:
HTN Is For: Complex tasks with established procedures, where expert knowledge exists about how to accomplish goals, and where the challenge is selecting and orchestrating appropriate methods rather than discovering optimal solutions from first principles.
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.