Epic Notes prompts — 2 November 2026
Use the blog chapter sequence and the named VS Code window. Plan first; approve, then Build.

BASELINE
Objective: establish a trustworthy starting point for the Epic Notes lab
and save a local preparation checkpoint before application changes.

Constraints: work in this prepared VS Code checkout with synthetic data.
Read AGENTS.md. Do not edit application code, read .env or credentials,
install tools, change global settings or push. Keep normal approvals on.
The checkpoint may contain only AGENTS.md, opencode.json and workshop/.
Use lab/notes and this commit's demo identity: Workshop Learner,
learner@example.test; do not change global Git identity.

Inspect the repository instructions and available capabilities first.
Choose the tools and checks needed to confirm the upstream, starting
state and documented test baseline. Explain your choices and stop
for approval. Then execute the approved plan, report actual commands,
exit codes and test totals, and show the final working-tree state.
If the preparation branch/checkpoint already exists, inspect and reuse
it; do not recreate it or reset work. Report any changes from that
starting point. Stop on setup errors before creating a new checkpoint.

MAP
Objective: understand how creating and editing a note works so we can
decide where a small change belongs.

Constraints: inspect this existing VS Code project read-only. Read
AGENTS.md; do not edit, install, read .env or credentials, or use
subagents. Keep normal command approvals enabled.

Inspect the repository and available capabilities. Choose how to find
the relevant behavior. Explain the flow, validation, persistence and
ownership rules using actual file references. Say what is public,
what you could not confirm and what you would inspect next.
Do not propose new tooling before checking what is already available.

PLAN
Objective: help people find note titles within the selected person's
notes list. Keep the existing global user search unchanged.

Success: English title substrings match without case sensitivity;
surrounding search spaces are ignored; blank input shows all of that
person's notes. Show a useful no-match state. Clear restores the list
and empties the input. Other people's notes must not enter this list.

Constraints: stay in the prepared VS Code project and existing stack.
Preserve public reading and restricted editing. No new dependencies,
schema or lockfile changes, paid services, installs or deployment.
Read AGENTS.md. Keep the existing permission controls.

Inspect the code and your available tools before recommending an
approach. Choose the implementation and verification tools, explain
why they fit, and identify the smallest scope of files. Ground your
choices in this repo; do not assume a tool is connected or available.
If a capability is missing, explain the need and pause. Ask about
decisions that affect the outcome. Stop after the plan for review.

BUILD
Objective: deliver the title-filter behavior in our approved plan
with evidence that it works.

Constraints: stay within the approved scope and tool choices in this
VS Code checkout. Preserve reading/editing rules and existing behavior.
No dependencies, schema or lockfile changes, installs, commits or
publishing. Keep normal edit and command approvals enabled.

Implement the approved plan. Choose meaningful checks for matching,
no match, blank input, Clear resetting the input, and owner exclusion.
Use the repo's documented verification gates as well as your focused
checks. Repair failures caused by your work without weakening checks.
If the evidence calls for a different tool or wider scope, explain
why and wait for approval. Report changed paths, actual command/exit-code
results, coverage and gaps. Leave a handoff for a fresh reviewer.
Do not claim browser work you did not perform.

CORRECT
Objective: bring the current change back within our agreed task.

Constraints: preserve the required behavior and existing checks.
No lint suppressions, weaker tests or unrelated changes.

Inspect the actual difference from the approved plan. Propose the
smallest correction and choose how to verify it using the available
tools. Explain why it fits, then wait before making the correction.

TEST
Objective: produce evidence that detects this reported defect before
fixing it: a note with three spaces as its title is saved when its
content is non-empty.

Expected behavior: reject blank/whitespace-only titles, remove outer
spaces from valid titles, and retain the 100-character limit after
normalization. Valid content and owner edits still work; forged edits
to another owner's note are denied without changing persisted data.

Constraints: keep application code unchanged in this stage. Use the
existing test setup and synthetic local test data. No dependencies,
schema, authentication changes, .env reads, commits or publishing.
Read AGENTS.md and keep normal approvals enabled.

Inspect the relevant code and available tools. Propose how to reproduce
the defect and which tests would detect it. Explain the choice and
stop for approval. Then write and execute the approved checks, show
the relevant failing assertion, and stop before fixing the app.
A setup or syntax error is not the defect failure we need.

FIX
Objective: make the demonstrated title defect satisfy the agreed
behavior: reject blank/whitespace-only titles, normalize outer spaces
and keep the 100-character limit after normalization.

Constraints: preserve content, normal saves and ownership rules.
Keep the regression tests unchanged. No dependencies, schema or
lockfile changes, installs, .env reads, commits or publishing.
Work in this VS Code checkout with normal approvals enabled.

Inspect the failing evidence and relevant code. Choose the smallest
repair and suitable verification tools; explain why and wait for
approval. Then implement it, run the regression checks and documented
project gates, and repair any new failures without weakening checks.
Report the focused diff, commands, exit codes, totals and remaining
gaps. Distinguish observed browser behavior from unverified behavior.

REVIEW
Objective: independently assess whether the current Epic Notes change
satisfies the acceptance cases and is ready for the learner to evaluate.

Constraints: this is a fresh, read-only review in VS Code. Read AGENTS.md.
Do not edit source, tests, config or instructions, read .env, install,
commit or deploy. Tests may use synthetic test data; do not seed,
reset or migrate the application database. Keep normal approvals on.

Inspect the actual working-tree state, uncommitted changes and new
untracked tests. If workshop-start exists, also review
git diff workshop-start...HEAD: the integrated features are committed.
If it is absent in a fresh optional comparison, say so and review the
actual candidate diff instead. Do not create or invent the marker.
Do not rely on the writer's summary. Check the filter behavior,
Clear resetting the input, title validation and existing edit denial.
Look for weakened checks, unrelated changes and coverage gaps.

Choose inspection and verification tools from those actually available.
Explain the approach and stop for approval before executing checks.
Include the repo's documented test, type, lint and diff-cleanliness
gates. Then report actual commands, exit codes and totals. Give each
concrete finding a severity, file/line evidence and proposed fix.
Say if there are no concrete findings. Do not invent a defect or
claim a browser check you could not perform.

EVIDENCE
Objective: give me enough evidence to decide whether the change
meets our approved requirement.

Constraints: preserve the agreed scope, tools and permission controls
in VS Code. Do not edit unrelated files, read .env, install, commit
or publish. Do not weaken any check or claim unperformed work.

State the requirement, changed paths and reason for each file.
Use actual verification output; if it is missing or stale, propose
the checks you need and run them after approval. Include the project's
documented gates, command exit codes, totals, pre-existing warnings
and coverage gaps. Give the local route and actions I can evaluate
in VS Code's preview. Mark unexercised UI behavior unverified.

REPAIR
Objective: resolve this concrete review finding:
[paste the finding and its file/line evidence]

Constraints: preserve the other accepted behavior, tests and scope.
No lint suppressions, weaker tests, new dependencies, installs, .env
reads, commits or publishing. Work in VS Code with normal approvals.

Inspect the finding and actual code. Choose the smallest correction
and tools to demonstrate it is resolved. Explain your plan and wait.
After approval, implement and execute the relevant checks and project
gates. Report actual results and remaining uncertainty.

TRANSFER
Objective: help me scope this small change in an existing codebase:
[describe the user outcome and observable success cases]

Constraints: [approved environment, data access, budget and boundaries].
Stay in VS Code. Read the project instructions. Do not edit, install,
migrate data or deploy while planning. Do not access credentials.

Inspect the current behavior and available capabilities first.
Choose an approach and the tools needed, based on the repository.
Explain why they fit, the smallest file scope and how to demonstrate
success. Identify assumptions, missing access and external services.
Ask about decisions that affect the outcome. Stop for plan review.

WORKTREES
Objective: prepare this clean Epic Notes checkpoint for two independent
jobs: a note-title filter and a blank-title fix. Keep the coordinator
checkout unchanged so we can integrate the results later.

Constraints: use the supplied workshop/add-worktrees.mjs helper from
this repository root. It creates lab/filter in ../epic-filter and
lab/title in ../epic-title, with separate dependencies and synthetic
SQLite databases. This setup is explicitly allowed to install the
pinned dependencies and seed those two new local databases. Do not
read or copy .env, touch another project, push, deploy, or overwrite
an existing branch/folder. Keep normal command approvals on.

Inspect Git status, the helper, current branch, existing worktrees and
workshop-start tag first. If the two prepared worktrees and tag already
exist, verify their paths, branches and expected starting commit; use
them without rerunning setup. If all are absent and the preparation
checkpoint is clean, explain the setup and resource requirements,
stop for approval, then run the helper once. Report actual worktree
paths and branch/commit IDs, and stop. If only part exists, stop and
diagnose rather than rerunning or overwriting anything.
If setup fails partway, preserve both folders and diagnose the first
error. Do not rerun blindly or remove a worktree containing work.

TEST-PROOF
Objective: show that our title regression tests can detect the actual
blank-title defect, rather than just producing a green test count.

Constraints: work only in lab/title in this VS Code window. Preserve
the approved tests. Do not alter authentication, dependencies, schema,
lockfiles or real data. No installs, .env reads, commits or deployment.
Use the original implementation first. If it is already repaired,
propose one exact temporary change to the title rule and its exact
restoration; wait for approval before making that change. Keep normal
command approvals. Never use a blanket reset or restore.

Inspect the implementation and tests. Choose the focused check that
would detect this defect and explain why. After approval, run it
against the original/broken rule: show the failing behavioral assertion
and exit code. A syntax error is not a successful demonstration.
If you temporarily changed the rule, restore only that exact change,
rerun the same checks, and show the source diff is back to its prior
state. Report what the tests prove and what they do not cover.

EXPERIMENT
Objective: repair the demonstrated Epic Notes title defect using the
same regression checks as a fixed evaluator.

Success: reject whitespace-only titles; trim outer spaces on valid
titles; apply the 100-character limit after trimming. Preserve valid
content, owner edits and other-user denial without data changes.

Constraints: work only in lab/title. Freeze the approved evaluator
tests before the first attempt: record their paths and hashes, then
do not edit them. Change only +shared/note-editor.tsx. No dependencies,
schema, lockfile, authentication or permission changes; no .env reads,
installs, commits, publishing or subagents. Keep normal approvals.
Budget: 10 minutes and at most two candidate repairs, one at a time.
Stop early when the focused checks pass. Never weaken the evaluator.

Inspect the failure and available tools. Propose your first hypothesis,
the smallest change and how you will measure it. Stop for approval.
Then implement one candidate and run the frozen focused tests.
Record the hypothesis, diff, command, exit code, pass/fail counts and
evaluator hashes. If it fails, explain the failure before proposing
one different candidate within the remaining budget. Stop if blocked.
After a pass, run the documented project gates and hand off for fresh
review. Say what remains unverified. Do not invent a second attempt
when the first already meets the requirement.

INTEGRATE
Objective: bring our accepted filter and title-fix work together in
the coordinator checkout, then demonstrate that both still work.

Constraints: coordinator is lab/notes in epic-stack. Inspect branch and
worktree status first. Do not edit another session's uncommitted work.
No pushes, installs, new dependencies, .env reads or deployment.
Normal approvals remain on. You may propose named-file local commits
on lab/filter and lab/title and a local merge after I approve the
exact file lists and messages. Use the disposable repository-only
author identity from the workshop, not global Git configuration.
Do not commit database, environment or generated files. If a merge
conflicts, stop and explain the conflict before changing files.

Inspect the two branch diffs and acceptance evidence. Propose the
smallest integration sequence, get approval, then integrate the
accepted commits. Run the full tests, types, lint and diff checks.
Show the actual resulting branch/commit, changed paths and output.
Stop for a fresh read-only review. Give me the filter, title and
ownership cases to evaluate in VS Code's integrated browser.

OPTIONAL
Objective: complete this optional Epic Notes exercise:
[paste one outcome and its acceptance cases]

Constraints: use the existing VS Code project and approved capabilities.
Preserve the finished core lab, ownership, validation and normal
permissions. Synthetic data only. No installs, new service accounts,
.env reads, paid services, commits or deployment without approval.

Inspect the repo and your available capabilities before choosing an
approach or tools. Explain the smallest scope and evidence needed;
stop for approval. If a capability is missing, explain the need first.
Then implement or investigate, run relevant checks, and hand off for
a fresh review. Give me a result I can evaluate in VS Code. Label
unperformed checks and uncertain conclusions honestly.

