Start

---
name: start
description: Start a Microsoft Dynamics 365 Business Central AL extension project with the OnlyCopilotFans (OCPF) BC Agentic Development Framework - the one launching point for every journey. Guides the choice between Build-a-Feature (quick customizations in minutes, no steps, six short documents), Full (a complete app or solution end to end, three models, the full document and testing trail - the recommended journey), and Lite (updating an existing app or a new app without a large footprint, one model, fewer steps), always in that order, offers to analyze and document an undocumented existing app first, installs the latest runbook into the project (Full and Lite) and begins the routine, whose first step asks every setup question back to back and then connects Microsoft's AL tools with nothing to install in its setup batch. On a project that already follows the framework it offers status, an update check, or building a feature in that project. Use when the user asks to "start a Business Central project", "start a BC extension", "use the OCPF framework", "set up the agentic development framework", "kick off an AL project", "add a table to my extension", "build a feature", or runs /ocpf-bc:start (optionally with "full", "lite", or "feature").
---

# Start an OCPF BC Agentic Development Framework project

This skill is the **one launching point** for every journey the framework offers. It automates
the framework's manual setup: download the runbook, rename it to `CLAUDE.md` or
`.github/copilot-instructions.md`, put everything else the framework keeps under
`ocpfFramework/`, and begin. It adds three things on top:
- it helps choose **Build-a-Feature, Full, or Lite** — Full recommended, always listed in that order (Ops § Journeys),
- it offers to **analyze and document an existing, undocumented app first** (the `analyze` skill),
- it always installs the **latest** published runbook (Full and Lite; Build-a-Feature has none),
- the routine's first step connects the AL tools with nothing to install, in its setup batch.

It never overwrites an existing file.

Repository: `https://github.com/ajansari/ocpfBcAgenticDevFramework` (default branch `main`).

**Framework ref.** Every URL below names the `main` branch. When the environment variable
`OCPF_FRAMEWORK_REF` is set and not empty (the framework's pre-release channel, Ops § Plugin —
for testing an unreleased branch or tag on a real project), substitute its value for `main` in
every `raw.githubusercontent.com` and `api.github.com` URL of this repository and in `git
ls-remote … refs/heads/<ref>` (`refs/tags/<ref>` for a tag), write that value as `ref` in the
marker (Step 6), and say in one line which ref was fetched. Never ask the human to set it.

Throughout, when you need the human to **decide** something, use the harness's selectable options
mechanism, with the recommended option first and a short reason on each: `AskUserQuestion` in
Claude Code, the `askQuestions` tool in GitHub Copilot Chat in VS Code, or `ask_user` in GitHub
Copilot CLI (its choice questions take no typed answer, so add an *I'll type it* choice where a
typed answer is possible). Ordinary progress updates are plain messages.

## Step 1: Work out where you're running

Decide which of these applies before asking anything:

- **Project mode.** You can read and write files in a local or cloud workspace, for example Claude
  Code, GitHub Copilot in VS Code, Copilot CLI, or a cloud coding session. Continue with Step 2.
- **Documents mode.** You can't write into a code project, for example Claude Chat, or Claude Cowork
without a connected project folder. Skip to
  [Documents mode](#documents-mode-no-code-project) at the end.

## Step 2: Check the folder

1. Confirm the workspace root with the human if it's unclear. It should be the AL project's root:
   a folder with `app.json`, or an empty or new folder for a new extension.
2. **Already set up?** Look for `ocpfFramework/framework.json` (or the older `.ocpf/framework.json`),
   or a `CLAUDE.md`, `.github/copilot-instructions.md`, `ocpfFramework/BC_App_Build_Routine_Agent.md`,
   or `ocpfFramework/LITE_BC_App_Build_Routine_Agent.md` (in the root on a pre-5.0.0.0 project)
   whose first lines contain `# BC App Build Routine`. If found, this project already follows the
   framework. **Don't start Full or Lite again.** Tell the human which edition and version it is
   on — and, when `ocpfFramework/customSkills.json` exists, run the Custom Skills check first
   (`ocpf-skills --check --project <root>` — the helper in `ocpfFramework/scripts/`, else this
   plugin's `skills/skill-load/scripts/` copy placed there first; Ops § Custom Skills → 5): **a block is reported before
   the menu and nothing below runs until it is resolved** through the `skill-load` skill's per-issue
   boxes. Then ask, through the options mechanism, one question with four choices:
   - **Status** — where the project stands (the `status` skill);
   - **Check for a framework update** (the `update-framework` skill);
   - **Build a feature in this project** — one object or a few, now, without touching the
     project's steps or documents: invoke the `build-a-feature` skill, which reads the
     project's parameters and appends its own table to `ProjectProgress.md`. On a marker whose
     `edition` is already `feature`, this is the recommended first option and continues the
     previous session;
   - **Load a custom skill into this project** — a third-party skill made for this framework, from
     a folder, a zip, a GitHub repository, a bcskills.ai slug, or a `skillslocation.md` (the
     `skill-load` skill; Ops § Custom Skills). Since 6.0.0.0.
   Nothing else; skip the rest of this skill.
2a. **An existing extension that never used the framework?** `app.json` exists and there is no
   marker and no runbook. Say what you found (name, publisher, ID ranges from `app.json`; how
   many objects under `src/`; whether a package exists; whether any `docs/`, README, or
   `requirements/existing/` explains it) — **flagging a template placeholder as the AL template's
   default, not a fact** (`ALProject1`, `Default publisher`, `1.0.0.0` with no package,
   `50100–50149`; Ops § Intake → *Forbidden sources*). **If the app has real objects and no usable
   documentation, ask first, one box** (Ops § Existing Apps): **Analyze and document the app first
   (recommended — one run, 10 to 30 minutes, into `requirements/existing/`)** / *Skip — I know this
   app, choose a journey*. On the first, invoke the `analyze` skill and stop here; it hands back to
   this skill when the human is ready. Otherwise go to Step 3, where Full is the recommended journey as always; the human takes
   Build-a-Feature when they want one more object or a quick change. **Do not call the file's version "installed":** an AL: Go!
   scaffold says `1.0.0.0` with only `HelloWorld.al` and no package, and every journey treats
   that as a *new* app that starts at `0.0.0.1` — the new-or-existing question (intake 4b) is
   asked by the journey, never answered from the file. Full and Lite stay available.

## Step 3: Choose the journey

Ask the human to choose. **Full is the recommended journey** and is marked *(recommended)*; the
human takes Build-a-Feature or Lite when the work is a quick customization or a modest update —
**the choice is about the kind of work, not a file count** (Ops § Journeys). If you don't know
enough, ask about the work first: a complete solution, an update or a modest new app, or a quick
customization. One question, three options **in this fixed order — Build-a-Feature, Full
(recommended), Lite** — an explicit exception to the recommended-first rule, each described in
these terms:

- **Build-a-Feature — quick customizations, in minutes.** Extend a table or a page, a processing
  report, a table and its pages, an API page or query, a role center, an enum, a codeunit, a
  permission set: a tactical change when time is of the essence. **Not vibe-coding** — the
  Standards Guide, the patterns library, and the analyzers govern every file, the record is kept,
  the dashboard is live — but lean on documentation: no design documents or test scripts; six short
  documents in a flat `docs/`, written as the work happens. It builds what is asked for, not a
  holistic solution, which makes it right for a PoC for a demo or a prototype that a Full or Lite
  project can later turn into a solution. Usually 10–20 minutes; at published API rates most builds
  cost $1–5. One model does everything; the dashboard shows one row per object. The one to take
  whenever the request names one object or a few.
- **Full (recommended) — a complete app or solution end to end, or a major overhaul of a big existing app.** A
  detailed review of the requirements, an FRD, a TDD and a Sanity Check, a build plan, a gap-fit
  test, a graded code review, full documentation, a user guide, testing guides, and automated test
  scripts, in 14 steps. Three models — Main, Reasoning, and Light (the plugin's `ocpf-reasoning` and
  `ocpf-light` sub-agents) — for the highest-quality outcome, so it is the slowest of the three: at
  least three to four hours end to end, longer for an extensive app, plus the human's own review
  time — and still far less than a development team needs. Also the journey for AppSource. Both
  editions generate code with the `ocpf-generator` sub-agent, one per batch, in parallel, and run
  the `ocpf-reviewer` pre-review before the first package.
- **Lite — updating an existing app, or a new app without a large footprint.** One Main model does
  everything, in 7 steps, with leaner documents (a Design Doc, Docs, a Test Script). Still a
  reliable agentic engineering process with quality outcomes — faster, cheaper, and with less detail
  than Full. One to two hours depending on complexity.

Say once, when `requirements/` is empty: *the more well-formed and documented your idea, the faster
the first stage goes — put requirements in `requirements/` (`.md` recommended; Word, PDF, and
images work too) and an app icon in `images/`; every journey reads them at its first step.* The
journey's kickoff asks the same thing as its last box when the folder is still empty (Ops § Intake
→ *The kickoff boxes*, K14), so the human can act on it rather than scroll past it.

Mention that nothing is lost by switching later: Lite's `DesignDoc.md` and `ChangeLog.md` carry
straight over into the full framework, and a Build-a-Feature extension is an existing app to
Lite's Step 1 or Full's PRE-01. A project follows one of Full or Lite, never both; Build-a-Feature
can run **on** a Full or Lite project later through Step 2's third choice.

If the human invoked the skill with `full`, `lite`, or `feature`, confirm that choice instead of
asking from scratch.

**Custom Skills loaded before this point** (`ocpfFramework/customSkills.json` exists — the human ran
`/ocpf-bc:skill-load` first, as the framework recommends): the journey question's text names, per
option, any loaded skill that journey would exclude (*contoso_patterns is made for Full and Lite —
Build-a-Feature would block on it*), and the moment the journey is chosen the agent writes
`edition` to the marker and runs `ocpf-skills --check` again (Ops § Custom Skills → 5): a block is
resolved through the `skill-load` skill's per-issue boxes **before** the runbook is placed or the
Build-a-Feature skill is invoked. Nothing starts on a blocked set.

**Build-a-Feature chosen → invoke the `build-a-feature` skill now and stop here.** Its Part 1
and Part 2 do the whole setup that journey needs (companions, marker with `"edition":
"feature"`, notifications, identity, dashboard, model, AL tools, symbols, the feature table).
Steps 4–9 below are Full and Lite only: there is no runbook to place, no changelog, no step
files, and no routine to begin.

## Step 4: Choose where the runbook goes

Ask which AI tools will work on this project. Pre-select the one you're running in.

| Choice | File placed |
|---|---|
| Claude Code | `CLAUDE.md` in the project root |
| GitHub Copilot | `.github/copilot-instructions.md` |
| Both | Both files, identical copies |

**Never overwrite.** If a target file already exists and isn't this runbook, stop and ask:

- **For `CLAUDE.md`:**
  - **Recommended:** save the runbook as `ocpfFramework/BC_App_Build_Routine_Agent.md` (or
    `ocpfFramework/LITE_BC_App_Build_Routine_Agent.md`). Then add one line,
    `@ocpfFramework/BC_App_Build_Routine_Agent.md` (the matching filename), at the top of the
    existing `CLAUDE.md`. Claude Code imports the referenced file. Nothing of the framework's goes
    in the project root besides `CLAUDE.md` itself.
  - **Alternative:** cancel and let the human sort out the existing file.
- **For `.github/copilot-instructions.md`:**
  - **Recommended:** save the runbook as `.github/instructions/ocpf-framework.instructions.md`, with
    this frontmatter added above the runbook text so Copilot applies it to every request:
    ```
    ---
    applyTo: "**"
    ---
    ```
  - **Alternative:** cancel.

## Step 5: Get the latest runbook

**Tell the human what you're doing.** Fetch from GitHub first; the copies bundled in this plugin
are only a fallback.

1. **Fetch the chosen edition and its changelog** from the default branch — **and, in the same
   batch, everything the runbook's first step reads before its first question** (Rule 6f; Ops §
   Intake → *The kickoff boxes*): the step files, the document templates, both companion guides
   (Step 6 item 2a names where each goes), so that the first step finds them on disk and asks
   its kickoff without a fetch between questions:

   | Edition | Runbook | Changelog |
   |---|---|---|
   | Full | `https://raw.githubusercontent.com/ajansari/ocpfBcAgenticDevFramework/main/fullVersion/BC_App_Build_Routine_Agent.md` | `https://raw.githubusercontent.com/ajansari/ocpfBcAgenticDevFramework/main/fullVersion/RunbookChangelog.md` |
   | Lite | `https://raw.githubusercontent.com/ajansari/ocpfBcAgenticDevFramework/main/liteVersion/LITE_BC_App_Build_Routine_Agent.md` | `https://raw.githubusercontent.com/ajansari/ocpfBcAgenticDevFramework/main/liteVersion/LITE_RunbookChangeLog.md` |

   Download the files **byte for byte**, with a terminal tool such as `curl -fsSL <url> -o <file>`
   where one is available. Don't retype or summarize them. A summarizing web-fetch tool isn't
   acceptable for writing the runbook file. Download straight to the final paths from Step 6, or,
   if you download to temporary files first, move them into place and delete the temporaries.
   Leave no stray files in the project.
2. **Record the commit** the files came from. Use
   `git ls-remote https://github.com/ajansari/ocpfBcAgenticDevFramework refs/heads/main`, or
   `https://api.github.com/repos/ajansari/ocpfBcAgenticDevFramework/commits/main` (the `sha`
   field). If neither works, record `unknown`.
3. **Read the version** from the runbook's `**Version:**` line near the top.
4. **If GitHub isn't reachable**, or the download is empty or doesn't start with
   `# BC App Build Routine`:
   - use the bundled copies in this skill's `references/` folder (same filenames),
   - and **tell the human plainly**, naming the bundled version from its `**Version:**` line. For
     example: "GitHub wasn't reachable, so I used the runbook bundled with the plugin, version X.
     Once you're online, the framework will offer any newer version."

   Never proceed silently on a bundled copy.

## Step 6: Place the files

The layout is fixed (Ops § Project Setup, Full Operating Rule 9, Lite's header note): the project
root holds `app.json`, `.gitignore`, `CLAUDE.md`, `.github/`, `.claude/`, `.vscode/`, `.alpackages/`,
`Translations/`, `src/`, `docs/`, `requirements/`, `outputAppPackage/`, `ProjectProgress.md`, and
**`ocpfFramework/`** — everything the framework fetches or keeps goes under that one folder.
Nothing else in the root.

1. **Runbook:** write the runbook to the file(s) chosen in Step 4 — `CLAUDE.md` and/or
   `.github/copilot-instructions.md`; the Step 4 alternatives when a file already existed
   (`ocpfFramework/BC_App_Build_Routine_Agent.md` with the `@ocpfFramework/…` import line, or
   `.github/instructions/ocpf-framework.instructions.md`).
2. **Changelog:** write it to `ocpfFramework/RunbookChangelog.md` (Full) or
   `ocpfFramework/LITE_RunbookChangeLog.md` (Lite). The runbook expects it there; the schematics,
   when placed, go beside it as `ocpfFramework/RunbookSchematics.md` / `LITE_RunbookSchematics.md`.
2a. **Step files, templates, guides, patterns, scripts:** since Full v4.0.0.0 / Lite v3.0.0.0 the
   runbook is a short core plus one file per step. The runbook fetches them itself at its first
   step, with the guides, all under `ocpfFramework/` (Ops § Fetched Companions has the file lists:
   `fullVersion/steps/` or `liteVersion/steps/` into `ocpfFramework/runbookSteps/`, the repository's
   `documentTemplates/` into `ocpfFramework/documentTemplates/`, the Standards Guide — from its own
   repository `ajansari/ocpfBCALStandards` at the tag named in the framework's
   `standardsGuide/README.md`, fetched beside it — into `ocpfFramework/standardsGuide/`, the
   Operations Guide into `ocpfFramework/opsGuide/`, the patterns
   library into `ocpfFramework/patterns/`; this plugin's scripts into `ocpfFramework/scripts/`; all
   gitignored). The OnlyBCFans BC Copilot Blueprint (`ajansari/obcfBCCopilotBlueprint`) is fetched
   later, only when the intake records a Business Central Copilot feature, into a sibling folder
   outside the project root (Ops § Fetched Companions); it is not bundled here. If GitHub is unreachable then, the bundled copies are in this skill's
   `references/steps/full/` and `references/steps/lite/`, and in the `documents` skill's `references/`.
   **Since 6.0.0.0 the same fetch brings `opsGuide/extensionPoints.json` → `ocpfFramework/extensionPoints.json`**
   (gitignored with the guides; the bundled copy is the `skill-load` skill's `references/extensionPoints.json`)
   — the machine-readable list of the moments a Custom Skill may plug into (Ops § Custom Skills → 2).
2b. **`ocpfFramework/README.md`:** write these six lines, exactly, so anyone opening the folder
   knows what it is:
   ```
   # ocpfFramework
   This folder belongs to the OCPF BC Agentic Development Framework, which built this project.
   Everything in it is fetched or generated by the framework: guides, step files, templates, patterns, scripts, and its marker.
   Never edit anything here by hand; the framework's update step refetches it, and a hand edit is lost on the next update.
   Per-developer files (usage, prices, notifications, Copilot settings) live in state/ and are never committed.
   Framework repository: https://github.com/ajansari/ocpfBcAgenticDevFramework
   ```
3. **Marker:** create `ocpfFramework/framework.json`:
   ```json
   {
     "framework": "OCPF BC Agentic Development Framework",
     "edition": "full | lite",      // "feature" is written by the build-a-feature skill, never here
     "runbookVersion": "<from the **Version:** line>",
     "source": "github | plugin-bundle",
     "repository": "https://github.com/ajansari/ocpfBcAgenticDevFramework",
     "ref": "main",                 // or the value of OCPF_FRAMEWORK_REF when it was set
     "commitSha": "<sha or unknown>",
     "fetchedAt": "<ISO 8601 timestamp>",
     "placedAs": ["CLAUDE.md", ".github/copilot-instructions.md"],
     "changelogFile": "ocpfFramework/RunbookChangelog.md | ocpfFramework/LITE_RunbookChangeLog.md",
     "pluginVersion": "<version from this plugin's .claude-plugin/plugin.json, or unknown>",
     "declinedUpdateVersion": null,
     "alMcp": "not-checked",
     "layout": "ocpfFramework-1",
     "tooling": {}
   }
   ```
   `layout` names the project layout this marker was written for (`ocpfFramework-1`: the layout
   above; its absence means the pre-5.0.0.0 layout, which `update-framework` migrates). `tooling`
   is filled by Ops § Tooling Checks when the runbook checks mermaid and PowerShell 7
   (`"mermaid": "npx-cached | installed | unavailable"`, `"pwsh": "5.1 | 7.x | unavailable"`);
   it starts empty.
   The plugin manifest is two folders above this skill's own folder (`../../.claude-plugin/plugin.json`).
   This marker is what turns on the runbook's plugin-only behavior (ALL ALONG → OCPF Plugin): the
   once-per-session update check, the Standards Guide fallback, the one-step AL tool setup, and
   the `documents` and `usage` skills.
4. **Don't touch `.gitignore` here.** The runbook asks the human about framework files at intake
   (full §1.8, Lite Step 1) and applies the answer to the runbook, the project-local sub-agent
   definitions, and `ocpfFramework/` as a whole — by exact name, verified with `git check-ignore`
   (Ops § Repository Hygiene has the block; `ocpfFramework/state/` and the fetched subfolders are
   always ignored whatever the answer).

## Step 7: Connect the AL tools — in the first step's setup batch, not here

**Since 5.10.0.0 this does not run between the journey choice and the first question.** The
runbook's first step connects the AL tools in its setup batch, after the kickoff's last box
(Ops § Intake → *The kickoff boxes*), so the human answers every setup question in one run and
waits once. Leave `alMcp` at `not-checked` for the runbook's step to fill; the rest of this
section is what that batch does. Follow the `al-mcp-setup` skill. It connects Microsoft's AL tools **with nothing to install**,
using the AL Language extension already on the machine:
- **In GitHub Copilot Chat,** the extension's built-in tools are already there.
- **Elsewhere,** it says what it's doing (no question — connecting the tools is the agent's job),
  then registers the extension's bundled AL MCP Server for the project.

The batch records the outcome in `ocpfFramework/framework.json` (`alMcp`); if the human postpones it
there, or the batch skips the skill for any reason, the batch sets `"alMcp": "deferred"` so the
marker never stays at `not-checked`. Never install anything or ask the human to edit `PATH` or a shell profile here
(runbook Operating Rule 6d).

## Step 8: Mention staying up to date

Once, briefly:
- Each session, the framework checks GitHub for a newer runbook and asks before applying it; the
  update refetches everything under `ocpfFramework/` (never edit that folder by hand).
- Plugin updates depend on the tool. In Claude Code, auto-update for third-party marketplaces is
  off by default: `/plugin` → **Marketplaces** → `onlycopilotfans` → **Enable auto-update**. In
  VS Code's Copilot Chat, plugins update with extension auto-update. In Copilot CLI, run
  `copilot plugin update ocpf-bc`.

Don't change the human's editor or tool settings yourself unless they ask you to. Choosing a
notification kind at the runbook's first step counts as asking, for the settings that kind needs.

## Step 9: Begin the routine

1. **Read the placed runbook in full now.** A `CLAUDE.md` or `copilot-instructions.md` written
   mid-session may not auto-load until the next session.
2. **Follow it from the first step:** PRE-01 for Full, Step 1 for Lite. This is exactly what the
   manual "Getting started prompt" does. **The first step opens with the kickoff** (runbook Rule
   6f; Ops § Intake → *The kickoff boxes*): every setup question back to back — the working
   language, how to be notified (this plugin's `notifications` skill applies the answer in the
   batch), the identity and Deployment Target, countries and approvers, which models do the work
   (Full six questions, Lite two, after the one-sentence High-effort warning), the Copilot session
   settings, naming and ID ranges, languages, `.gitignore`, and where the requirements are — then
   one setup batch with no question, then one setup-done box. Use this plugin's `roles` skill in
   its apply-only mode in that batch: it writes project-local copies of this plugin's sub-agents
   carrying the chosen model and
   effort — `ocpf-light` and `ocpf-reasoning` in Full, and `ocpf-generator` and `ocpf-reviewer` in
   both editions (both on the Main model; one generator per batch, in parallel, at Full Step 06 /
   Lite Step 4; the reviewer's pre-review before the first package at Full Step 07 / Lite Step 5) —
   which the runbook delegates to in the background; the bundled ones carry no model (Ops § Roles
   → *Enforcement*). It works the same in Claude Code (VS Code or CLI) and GitHub Copilot (VS Code
   or CLI). Every document the routine produces goes in `docs/<phase folder>/`; both editions keep
   `ProjectProgress.md` in the root (Lite seeds it at Step 1, like Full at PRE-01) with the step
   table and the usage table, and record usage at every step boundary (`/ocpf-bc:usage --step <id>`).
2a. **Set expectations, once, in two sentences** (the README's *What to expect* section says the same):
   the first hour is interactive — the routine asks everything it needs up front, back to back,
   like a kickoff meeting with a development team, then sets the project up in one go and only
   then reads the requirements — and from the DESIGN phase on (Full Step 02, Lite Step 2) the
   human can step away and come back when notified to approve or answer. With Claude Code and the
   *Claude app* notification, they can answer from the phone.
2b. **GitHub Copilot in use?** The runbook's first step also asks the two Copilot session-settings
   questions — the agent-mode request limit (150 / 100 / default) and tool approvals (ask each
   time / allow the framework's commands / allow everything) — and writes `.vscode/settings.json`
   (Ops § Asking and Approvals → *GitHub Copilot session settings*).
2c. **Note the dashboard.** PRE-01 / Lite Step 1 creates `ProjectDashboard.html` (project root, tracked) in
   its setup batch after the kickoff's last box, from the complete `app.json` written there, opens it,
   installs its hooks, and asks the one explanation question in the setup-done box — the `dashboard`
   skill does it (`/ocpf-bc:dashboard`). Don't create it here; the runbook's step owns the moment.
3. **Note the two companion guides.** The runbook fetches both at that first step: the **Standards
   Guide** — standalone at `ajansari/ocpfBCALStandards`, at the pinned tag — into
   `ocpfFramework/standardsGuide/` with the framework's prelude `README.md` beside it, and the
   **Operations Guide** into `ocpfFramework/opsGuide/` (each with a `SNAPSHOT.json`). If GitHub is
   unreachable, use the copies bundled with this plugin — the Standards Guide in the `al-standards`
   skill's `references/`, the Operations Guide in this skill's `references/` — and say which
   versions were used, as the runbook's ALL ALONG → OCPF AL Development Standards Guide describes.

## Documents mode (no code project)

On Claude Chat or Claude Cowork, the framework's BUILD and PROVE phases
aren't possible. There's no AL compiler, VS Code project, or Git. Say so plainly, then offer the
part that is:

1. **Choose the edition** (Step 3). Build-a-Feature and the `analyze` skill need a code
   workspace, so they are not available here; say so and offer Full or Lite's DEFINE and DESIGN
   work instead.
2. **Get the runbook text and both companions:** fetch them (Step 5) if the environment can reach
   GitHub, otherwise use the bundled copies and name their versions — the runbook and the
   **Operations Guide** in this skill's `references/`, the **Standards Guide** in the `al-standards`
   skill's `references/`. DEFINE and DESIGN need them: the intake questions, the roles question, and
   the asking rules are **Ops §** sections, and the AL rules are **Standards §**. Say that nothing
   can be written to disk here, so the guides are read, not installed.
3. **Work DEFINE and DESIGN with the human, following the runbook's rules:**
   - **Full:** PRE-01 through Step 04: problem statement, gap analysis, project parameters, FRD,
     TDD, Sanity Check.
   - **Lite:** Steps 1–2: parameters and `DesignDoc.md`.
   The Human and AI Effort Estimates belong to the same pass as the TDD / Design Doc; the AI
   estimate needs fetched prices, so say it will be priced once the project is in a code workspace.
4. **Produce each document as a file** the human can save or download from Claude.
5. **Explain the hand-off.** In a VS Code AL project, run this skill again; it detects nothing is
   set up yet. Put the saved documents where the runbook expects them — `docs/1-define/` for the
   problem statement and parameters, `docs/2-design/` for the FRD, TDD, Sanity Check, Design Doc,
   and estimates — before continuing from the next step.