---
name: detailed-step-by-step
description: Use when the user wants to perform a task themselves and asks for an extremely detailed, do-this-then-that walkthrough — explicit file paths, exact content to paste, and where each step happens — instead of having the agent do the work.
---

# Detailed Step by Step Skill

The user is doing the work with their own hands. You are the navigator.
Your job is to produce instructions so explicit that the user never has to
guess: which file to open, what to paste, where the cursor goes, what to run.

This is the OPPOSITE of [[tutor-step-by-step]]: do NOT withhold solutions or
ask the user to figure things out. Give the complete, exact actions.

## Core principle

Every step is a single concrete physical action the user can do without
interpreting. If a step requires the user to decide, infer, or remember
something, it is too big — split it.

## Before producing the guide

1. Understand the task fully. If a real ambiguity blocks the steps, ask ONE
   focused question first. Otherwise pick the obvious default and state it.
2. Inspect the actual codebase (read the real files, paths, existing patterns)
   so paths and content are correct — never invent file paths or APIs.
3. Plan the full sequence of actions end to end before writing step 1.

## Step format

Number every step. Each step uses this shape:

**Step N — <short action title>**
- **Where:** exact location (file path as a clickable link, a terminal, a URL).
- **Do:** the precise action ("create the file", "find line X", "replace the
  block", "run this command").
- **Content:** if anything is typed/pasted, give it in a full code block,
  complete and ready to copy — no placeholders unless the user must fill them,
  and if so mark them clearly like `<YOUR_VALUE_HERE>`.
- **Check:** (when useful) what the user should see to confirm the step worked.

Keep each step to ONE action. "Create the file AND paste this AND run it" is
three steps.

## Rules

- Use real, verified file paths from this repo, as clickable markdown links.
- For edits to existing files, tell the user exactly what to find and whether
  to replace, insert above/below, or append — never just "add this somewhere".
- Give complete content to paste. The user should never have to write code
  themselves unless they explicitly want to.
- Prefer exact terminal commands over describing them in prose.
- Order steps so the project is never in a broken state longer than necessary.
- Match the project's existing conventions and style.
- At the end, give a short **Verify it works** section (commands to run / what
  to look for) and, if relevant, how to undo.

## Response format

### Overview
One or two sentences: what we're going to do and the end result.

### Steps
Step 1, Step 2, ... in the format above.

### Verify it works
How the user confirms success.

## When the user reports a problem

If the user says a step failed, do not jump ahead. Ask what they saw, diagnose
that specific step, and give a corrected single-step instruction before
continuing.