Use First Draft as one tool for the user's app

CHANGELOG.md

@@ -29,6 +29,23 @@ Entries are newest first. Keep their headings stable. Publish material correctio
 new entries so readers who advanced their checkpoint see them. Entries explain what changed, why, when it applies,
 and any useful small example or verification; they need not reproduce commit logs.
 
+## Pending for 0.8.4
+
+This section is not a dated entry. The plugin 0.8.4 release moves it into that release's dated entry.
+
+- The Skill treats First Draft as one tool for your app instead of assuming it can build whatever you describe.
+  Before the interview the agent takes a quick look at how others build similar apps and uses what it finds to
+  choose better questions and defaults. When feasibility is in question, such as phone sensors, outside data,
+  store rules, or real-time behavior, it researches thoroughly whether the idea is possible and tells you what it
+  found with sources. As soon as it is clear, it says how First Draft helps:
+  plan and Compile the whole app; plan and Compile the backbone, such as accounts, sessions, and lists, while the
+  core, such as real-time sensor advice, is built separately in native Swift or Kotlin; plan only, when you will
+  build in another stack; or not at all, as for a first-person shooter, where it names a game engine and offers
+  First Draft later for accounts, leaderboards, or a website. An app of records and people, such as a family photo
+  feed, gets no talk about fit and starts the interview as before. `implementation-notes.md` and the read-back keep three lists: what First
+  Draft builds, what is built otherwise, and feasibility findings and open questions. The Skill's description now
+  starts from your goal, so it triggers when you ask for help making or planning an app or game.
+
 ## 2026-10-03: An interview that asks your level first
 
 **Skills — released in plugin 0.8.3.** The Skill's interview now follows one order. The agent clarifies your idea,

evals/create-full-stack-app/cases.json

@@ -39,7 +39,7 @@
         "Prioritizes whether one inventory record represents a uniquely identified object, a quantity of interchangeable goods, or both because that answer changes the Entity and Field model.",
         "Keeps its first reply to a small coherent batch of questions chosen for their effect on the first-release graph, access model, or requested clients instead of walking the entire ambiguity matrix.",
         "Leaves consequential unanswered areas open without silently deciding them; it may name deferred examples when that helps but does not satisfy an arbitrary minimum count.",
-        "Keeps this interview evaluation local and does not run plan push, plan status, plan compile, or make a network request before the user answers the consequential opening questions.",
+        "Keeps this interview evaluation local and does not run plan push, plan status, plan compile, or make a First Draft service request before the user answers the consequential opening questions.",
         "Does not claim that one complete candidate Foundation Plan is ready before the user has answered the consequential opening questions."
       ],
       "artifacts": [
@@ -178,7 +178,7 @@
         "Asks once whether it should make the technical decisions for the user, explain them as it goes, or ask about them.",
         "Asks no more than three questions in this opening turn and leaves details such as list fields, deletion, and appearance for later turns.",
         "Does not ask about hosting.",
-        "Runs no plan push, plan status, or plan compile and makes no network request in this opening turn."
+        "Runs no plan push, plan status, or plan compile and makes no First Draft service request in this opening turn; a brief web search for similar apps is expected."
       ]
     },
     {
@@ -218,6 +218,70 @@
         "Does not run plan compile."
       ]
     },
+    {
+      "id": "fit-partial-opening-race-coaching",
+      "should_trigger": true,
+      "prompt": "Help me build an app for hobbyist race car drivers that gives them real-time advice while they drive, using the phone's sensors.",
+      "expectations": [
+        "Before replying, uses its web search tools to check whether the idea is possible, such as phone GPS and motion-sensor rates and accuracy and what the platforms allow while driving, and how existing apps such as lap timers and driver-coaching tools are built.",
+        "Opens the reply with a few lines on what it found, with sources.",
+        "Says in this opening turn, in plain words, that First Draft can build the backbone, such as drivers, cars, tracks, sessions, and laps, but not the real-time sensor reading and advice, which is the core of the idea.",
+        "Names what builds that part and where, such as native Swift or Kotlin added to the generated iPhone or Android project, and says those projects are Hotwire Native shells around the web app.",
+        "Then asks the opening questions, at most three, including once whether it should make the technical decisions, explain them as it goes, or ask about them.",
+        "Runs no plan push, plan status, or plan compile and makes no First Draft service request in this opening turn."
+      ]
+    },
+    {
+      "id": "fit-partial-backbone-plan-race-coaching",
+      "should_trigger": true,
+      "prompt": "Help me build an app for hobbyist race car drivers that gives them real-time advice while they drive, using the phone's sensors. You already researched it, with sources, and said First Draft can build the backbone while the real-time sensor advice is built separately in native code. My answers to your opening questions: drivers sign up and see only their own sessions, I want an iPhone app, I have nothing to share, and make the technical decisions for me.",
+      "expectations": [
+        "Writes a rough Plan for the backbone only, such as a driver Account with cars, tracks, sessions, and laps, and does not model the real-time sensor reading or advice as if First Draft generated it.",
+        "Runs plan push and plan status --wait and reads the matching analysis before asking detailed questions.",
+        "Tells the user in a few plain lines what First Draft will build, what it will not build yet, and what is built otherwise, including that the generated phone apps show only public pages and have no sign-in, so coaching code that saves a driver's laps needs its own sign-in.",
+        "Keeps private access and the requested iPhone app in the Plan instead of making pages public or dropping the client to avoid gaps.",
+        "Writes implementation-notes.md with three lists: what First Draft builds; what is built otherwise, naming the real-time sensor and advice work and where it goes; and feasibility findings and open questions, with sources.",
+        "Does not run plan compile."
+      ]
+    },
+    {
+      "id": "fit-none-first-person-shooter",
+      "should_trigger": true,
+      "prompt": "Help me build a first person shooter.",
+      "expectations": [
+        "Says plainly that First Draft isn't the right tool for the game itself, because the core is a real-time game loop, 3D rendering, and input.",
+        "Names what is, such as a game engine like Unity, Unreal, or Godot, and offers to help with that.",
+        "Mentions that First Draft could later build a part it fits, such as accounts, leaderboards, or a website, if the user wants it.",
+        "Does not ask the First Draft level question or start the First Draft interview.",
+        "Runs no plan init, plan push, plan status, or plan compile and creates no .firstdraft directory."
+      ]
+    },
+    {
+      "id": "fit-full-family-photo-network",
+      "should_trigger": true,
+      "prompt": "Help me build a social network for just my family. It should work and look like Instagram so that it's familiar. This is our first message; do not contact First Draft yet.",
+      "expectations": [
+        "Before replying, takes a brief look with its web search tools, a few searches, at how similar family photo-sharing apps are built: common features, patterns, and pitfalls.",
+        "Does not make any statement about whether First Draft fits, not even that the idea fits; it may mention one or two useful findings, such as a feature most family photo apps share.",
+        "Restates the idea in a sentence and proposes a name.",
+        "Invites materials such as screenshots or an app the user likes, and says none is required.",
+        "Asks once whether it should make the technical decisions for the user, explain them as it goes, or ask about them.",
+        "Asks no more than three questions in this opening turn and leaves photo support and phone-app consequences for the reality check after the user answers.",
+        "Runs no plan push, plan status, or plan compile and makes no First Draft service request in this opening turn."
+      ]
+    },
+    {
+      "id": "fit-plan-only-other-stack",
+      "should_trigger": true,
+      "prompt": "I'm going to build a volunteer shift app for our food bank myself in Django, but I'd like help designing the data first. Coordinators create shifts, and volunteers sign up for them. You already asked your opening questions; my answers: volunteers and coordinators both sign in, I have nothing to share, and make the technical decisions for me.",
+      "expectations": [
+        "Says plainly that First Draft will help with planning only: the Foundation Plan and its analysis help design the data, and its generated Rails app will not be used.",
+        "Writes a Plan for the data model, such as volunteers, coordinators, shifts, and signups, then runs plan push and plan status --wait and uses the matching analysis to check the model.",
+        "Does not dwell on what the Rails Compiler would or would not generate, and asks the remaining data questions one at a time.",
+        "Writes implementation-notes.md with three lists, naming the Django build under what is built otherwise.",
+        "Never runs plan compile and does not offer to Compile."
+      ]
+    },
     {
       "id": "meaning-asked-implementation-by-level",
       "should_trigger": true,

evals/create-full-stack-app/references/candidate-interview-protocol.md

@@ -101,8 +101,9 @@ and deferred questions can be revisited after diagnostics or further dialogue.
 
 Before the first Compile that could start direct retained work or reach Publication, reread the exact staged Plan and
 give a plain-language semantic summary first: application scope; Entities and their material Fields, relationships,
-rules, behavior, and data; surfaces, access, and clients; material assumptions, delegated choices, exclusions, and
-open questions. Then group the gaps by what the user will notice. End with a short technical block: the Plan path
+rules, behavior, and data; surfaces, access, and clients; material assumptions, delegated choices, and exclusions.
+Then group the gaps by what the user will notice, then list what is built outside First Draft and the feasibility
+findings and open questions. End with a short technical block: the Plan path
 and SHA-256, the matching valid AnalysisRun's GapSet digest and record count, and the file holding every ordered
 record. Explain that service gaps were skipped before semantic analysis, target gaps were not fully realized, and
 `valid` applies only to the admitted graph. State the selected completion mode: direct output creates only a

skills/create-full-stack-app/SKILL.md

@@ -1,14 +1,14 @@
 ---
 name: "create-full-stack-app"
-description: "Experimental and in development: Authors and revises First Draft Foundation Plans, submits exact bytes, and requests bounded Rails/iPhone/Android Compile. Preserves identity, state, and provenance. Web Accounts, Policies, protected Scaffolds, and required enums are bounded; arbitrary apps, deployment, iPad, notifications, and broader clients are unavailable."
+description: "Use when someone asks for help making or planning an app or game, even one First Draft may not fit. Experimental: researches whether the idea is possible and how similar things are built, then uses First Draft where it helps: Foundation Plans, analysis, and bounded Rails/iPhone/Android Compile for records, people, permissions, lists, and forms. Says early when First Draft won't cover the core, and what will."
 license: "MIT"
 ---
 
 # Create a Full-Stack App with First Draft
 
-Author and review a coherent Foundation Plan, then Compile through the First Draft service into the current local
-folder. Run and develop the generated app locally. A Codespace is an optional fallback; GitHub publication and native
-preview are optional follow-ups. Compilation does not deploy.
+Use First Draft where it helps the user's app: author and review a Foundation Plan, then Compile through the First
+Draft service into the current local folder. Run and develop the generated app locally; a Codespace, GitHub
+publication, and native preview are optional. Compilation does not deploy.
 
 ## Preserve implementation requirements
 
@@ -58,11 +58,10 @@ For CLI work:
   read [ambiguous mutations](references/diagnostics-and-recovery.md#ambiguous-mutations) only when the named error
   requires it.
 
-The bundled [JSON Schema](references/foundation-plan-0.23.schema.json) is machine-readable validator input, not prose.
-Use a compatible JSON Schema 2020-12 command named by the user, exposed by the project, or found through a
-straightforward check of existing local commands. Pass only its path; never read it end to end. Do not install
-dependencies or add validation/build plumbing solely for this workflow. Otherwise rely on First Draft exact-byte
-diagnostics and say local schema validation was not performed.
+The bundled [JSON Schema](references/foundation-plan-0.23.schema.json) is validator input, not prose: pass only its
+path to a compatible JSON Schema 2020-12 command the user names, the project exposes, or a quick check of existing
+local commands finds; never read it end to end. Install nothing and add no validation plumbing for this. Otherwise
+rely on First Draft exact-byte diagnostics and say local schema validation was not performed.
 
 ## Verify the local capability
 
@@ -126,7 +125,8 @@ reinitialize. Inspect private state only for a recovery check explicitly named i
 
 ## Interview and author incrementally
 
-Start when the user asks for help making an app or invokes `/create-full-stack-app`, and follow the
+Start when the user asks for help making an app or invokes `/create-full-stack-app`. First research the idea and
+[decide how First Draft helps](references/interview.md#start-from-the-users-goal), then follow the
 [interview flow](references/interview.md#interview-flow). Clarify the idea; ask for materials and read them before
 asking more; ask once, "Should I make the technical decisions for you, explain them as I go, or ask you about
 them?" Then ask the product questions that shape the data model, most important first and one decision per turn,
@@ -196,10 +196,10 @@ valid status so the complete GapSet can be reviewed. `plan compile` later repeat
 
 Before the first `plan compile`, complete the modeling guide's
 [candidate reconciliation](references/modeling-guide.md#prepare-the-pre-compile-semantic-read-back), then reread the exact current
-`.firstdraft/foundation-plan.json`. Follow that section's order: a plain-language summary, then the gaps grouped by
-what the user will notice, then a short technical block with the Plan path and SHA-256 and the matching valid run's
-`gap_set_sha256`. Write every ordered GapSet record with all its fields to planning-root `gaps-readback.md` and
-name that file instead of pasting the records into the chat. Use only that attached
+`.firstdraft/foundation-plan.json`. Follow that section's order: a plain-language summary first and a short
+technical block last, with the Plan path and SHA-256 and the matching valid run's `gap_set_sha256`. Write every
+ordered GapSet record with all its fields to planning-root `gaps-readback.md` and name that file instead of pasting
+the records into the chat. Use only that attached
 digest: the CLI validates it against the attached GapSet; never substitute a fixture, historical, or another
 Project's digest. Use current-folder output by default. Select an absent
 `--output <path>` for a requested destination, an ineligible root, or model-only originals when root output was not
@@ -283,9 +283,9 @@ firstdraft_cli() { sh "<skill-dir>/scripts/firstdraft.sh" "$@"; }
 firstdraft_cli compilation download <compilation-id> --output <absent-path>
 ```
 
-Download reads one succeeded Compilation, verifies retained provenance, transport, manifest, paths, modes, and file
-digests, then installs atomically. It never starts or polls work. `--output .` uses the same current-root transaction
-and preconditions as direct Compile; preserve every other existing destination.
+Download reads one succeeded Compilation, verifies it, and installs atomically; it never starts or polls work.
+`--output .` uses the same current-root transaction and preconditions as direct Compile; preserve every other
+existing destination.
 
 ## Recover from failures