Steps Reference

Field-by-field reference for building Steps: name, description, instructions, frameworks, and checklists.

A Step is one stage of a Thinking Path. This guide covers every step-level field.

For path-level fields and the graph view, see Thinking Paths Reference.

All examples use the Software Decision Walkthrough: Define the problem → Evaluate the options → Make a recommendation.

Creating a step

Open your saved path from the Thinking Paths tab. Click the + button in the sidebar.

Name

Short verb phrase describing the analytical action. Shown in the graph and sidebar.

Good: "Define the problem", "Evaluate the options", "Make a recommendation"

Weak: "Step 1", "Options", "Evaluation"

SLAN generates the step ID from the name: "Define the problem" becomes step-define-the-problem.

Description

One-line subtitle shown in the graph. The reader should understand the step's purpose without clicking into it.

Example:

  • Step 1: Articulate the problem the software must solve and define success criteria.
  • Step 2: Apply the Build vs. Buy framework to assess capability and cost.
  • Step 3: State and justify a Build or Buy recommendation.

Instructions

Full directions for what the learner should do at this step, written in Markdown. Use the Maximize button for a full-screen editor and the Edit/View toggle to preview.

The quality of your instructions determines the quality of the assistant's coaching. A step that says "evaluate the options" with no further detail produces surface-level responses.

Include: the specific deliverable, coaching notes, which frameworks to apply and in what order, common mistakes to watch for, and what counts as incomplete input.

Example (Step 2):

Apply the Build vs. Buy Software Decision framework.

Guide the learner through both required inputs:

  • Internal Build Capability: Does the team have the technical skills and bandwidth to build and maintain this? Yes or No.
  • Estimated Build Cost: Total projected cost including development, testing, and first-year maintenance.

Then ask the learner to identify at least one buy option with a cost estimate.

Common mistakes:

  • Cost estimates that only include development (missing testing and maintenance)
  • "We could probably figure it out" treated as confirmed capability. Push for a clear yes or no.
  • Missing the buy-side comparison entirely

Click Select Frameworks to link Framework(s) from your course library.

A step with no frameworks runs on instructions alone. This works for context-gathering steps (like "Define the problem"), but most analytical steps should link at least one. When a step has multiple frameworks, the assistant applies them in listed order.

Example: Build vs. Buy Software Decision is linked to Step 2 only. Steps 1 and 3 are instruction-driven.

Checklist

Conditions the assistant checks before advancing the learner. Click Add Checklist Item for each one.

Strong items are specific and verifiable ("the learner has identified at least two constraints"), aligned with instructions, and limited to 3 to 6 per step. More than 8 suggests the step is doing too much.

Weak items like "The analysis is complete" or "The learner has answered" give the assistant nothing to verify.

Example:

Step 1:

  • The learner has written a clear problem statement with success criteria.

Step 2:

  • The learner has assessed internal build capability (yes or no).
  • The learner has estimated the total build cost including development, testing, and maintenance.
  • The learner has identified at least one buy option with a cost estimate.

Step 3:

  • The learner has stated a clear recommendation: Build or Buy.
  • The justification paragraph covers capability, cost, and strategic fit.

Click Create Step to save.

Common mistakes

No frameworks and vague instructions. Link a framework and write specific instructions. "Evaluate the options" alone produces generic coaching.

Tautology checklists. "The learner has completed the analysis" is not verifiable. Name what you want the assistant to check.

Steps that do too much. One analytical objective per step. If you're combining problem definition with option evaluation, split them.

Next

To attach your path to a Nudge assistant and deploy, see Use a Thinking Path.