QuestLog CLI — Implementation Session Prompt

# QuestLog CLI — Implementation Session Prompt

> Copy everything below the horizontal rule into a new GitHub Copilot chat session.
> This prompt is self-contained and works for every task across all phases.
> It reads the status file, determines what to do, presents a plan, waits for
> approval, implements, updates status, and commits.

---

You are implementing changes to **QuestLog CLI** in the repository at
`c:\src\questlog`.

## Step 1 — Determine the current task

Read `_design/cli/status.md`.

- Scan the **Task registry** table top-to-bottom.
- The **current task** is the first row whose Status is `pending`.
- If no rows have `pending` status, report "All tasks are complete." and stop.
- Note the task ID (e.g. `1.2`) and its description.

## Step 2 — Determine the phase plan file

The task ID format is `<phase>.<task>` (e.g. `1.2` → phase 1, task 2).

- Look up the phase in the **Phase index** table in `status.md`.
- Note the plan file path listed there (e.g. `_design/cli/phase-1.md`).

## Step 3 — Read the project context

Read `_design/cli/QUICKSTART.md` if it exists — this is the generated
current-state snapshot of the codebase. Then read `_design/cli/context.md`.

These files explain the project conventions, key file paths, and patterns that
every implementation session must understand before touching any code.

## Step 4 — Read the task plan section

Read the phase plan file identified in Step 2.

Find the section whose heading matches the current task ID (e.g. `## Task 1.2`).
It contains:
- **Target file(s)** — exact repo-relative paths to edit
- **What to change** — the exact strings to find and their replacements
- **Acceptance criteria** — what must be true after the edit

## Step 5 — Read the target file(s)

Read the full content of every file listed under **Target file** in the task section.
Understand the surrounding code before making any edit.

## Step 5.5 — Verify external APIs (if applicable)

If the task involves calling third-party library APIs, verify the function
signatures, parameter names, and return types against the library's current
documentation before proceeding.

Check `_design/cli/QUICKSTART.md` for a **Reference links** section
listing documentation URLs for the project's key libraries.

**How to verify:** For each library call in the task plan, compare:
- Function/method name and import path
- Parameter names, order, and types
- Return type and structure
- Any deprecated alternatives that the task plan might be using

This rule applies to **every** third-party library, not just those listed in
Reference links. If a task plan uses any external API, check the docs.

If the real API differs from what the task plan describes, **stop and report
the discrepancy** — do not silently adapt.

If the task does not involve third-party APIs, skip this step.

## Step 6 — Present implementation plan and wait for approval

Before making any edit, reply with a concise implementation plan: