Start with the job to be done

The working assignment is to plan and ship a personal knowledge assistant in staged, testable layers for a mentor or hiring manager reviewing engineering judgment. That sentence is narrower than “use Capstone roadmap.” It identifies a deliverable and a reviewer. Write a definition of done with three layers: the output must satisfy the audience's need; factual or functional claims must be traceable; and a named person must own the final decision. One evolving codebase tells a stronger story than twelve unrelated labs. Every layer must improve a user outcome and leave evidence that the improvement is real.

Start by separating tasks. The model may draft, classify, transform, compare, or suggest. It may not silently approve, publish, grade, deploy, cite, or consent on someone's behalf. For this assignment the authoritative material is one user problem, success metric, constraints, architecture sketch, milestone dependencies, evaluation set, risk register, and weekly capacity. Anything absent from those inputs is either an explicit assumption or an unanswered question.

Use this prompt as a realistic starting contract:

Turn this capstone goal into six two-week milestones: an assistant answers questions from my approved notes with citations. Sequence API, structured output, retrieval, citations, tools, memory, evals, injection defense, tracing, retries, deploy, and monitoring. For each milestone define a demo, test, dependency, risk, and stop rule. Do not pretend all layers fit at once.

Notice what the prompt does: it states the setting, limits the output, names forbidden behavior, and requests evidence that can be reviewed. It does not ask the model to “make it amazing.” If a constraint matters, make it testable. Replace “be accurate” with a source boundary, formula check, test command, rights ledger, or approval step.

A useful response would look like this: A dependency-aware roadmap that ships a narrow cited-answer slice early, then adds quality and operational layers behind explicit gates. That description is intentionally observable. “Looks good” is not acceptance. The operator must demo each milestone against golden tasks, inspect citations, run eval gates, test hostile inputs, review traces, exercise retries, and rehearse rollback. Keep the source material beside the draft so review means comparison, not memory.

Run the work through scope → vertical slice → ground → evaluate → harden → deploy → monitor. Stop when an authoritative input is missing, a high-risk claim lacks evidence, private material cannot be safely removed, or the proposed action exceeds the permission granted. Escalation is successful workflow behavior, not model failure.

Common framing mistakes are building twelve disconnected demos; adding memory before correctness; no eval baseline; hidden infrastructure work; deploying without tracing or rollback. Prevent them by writing a one-paragraph job card: user, decision, deliverable, source of truth, constraints, reviewer, and stop condition. This card becomes the anchor for every later prompt.