One small app.
A useful handoff.

STEP 01

Try the app first.

Open the live Reading Queue, add two public links, mark one as read and try the Unread filter. Export JSON downloads the whole active queue, including read links hidden by the filter.

This is a disposable demo. Your browser receives a random HttpOnly cookie identifying a queue of up to 20 links. Links expire within 24 hours; expired rows are removed on writes and by a daily cleanup. It is not account-authenticated private storage. Use public example URLs only. Cookie loss loses access; there is no cross-device sync or recovery.

STEP 02

Run the starter locally.

You need Git, Node.js 22 or later, npm, and Codex or Claude Code for the context exercise. CI uses Node 24. A Cloudflare account is needed only if you choose to deploy your own copy.

Clone the example and create a working branch from the starter tag. The starter already supports adding, reading, filtering and deleting links; JSON export is the pending change.

git clone https://github.com/jaredchu/context-docs-example-reading-queue.git
cd context-docs-example-reading-queue
git switch -c try-export tutorial-start
npm ci
npm run db:local
npm run dev

Open the localhost URL printed by Wrangler. Keep that terminal running; use a second terminal for tests and Git. Local D1 data is stored under the ignored .wrangler/ directory. It is separate from the public demo and your remote database.

Prompt: Run the starter

Confirm this is the Reading Queue example folder. Install its locked npm dependencies, apply only local D1 migrations, run the existing tests, and start the local dev server. Report the local URL and any failures. Do not create cloud resources or deploy.

Expected result: The baseline app works locally and the baseline test result is recorded honestly.

Check: Open the printed localhost URL and inspect the test output. No remote resource is required.

STEP 03

Inspect the existing context setup.

If the two skills are not installed, follow the installation guide first. This example does not install or update them for you. Open the cloned example folder in your coding agent. Name the adoption skill once here. The later prompts are ordinary work requests: the loaded project rule owns ongoing maintenance.

Run $adopt-context-docs in Codex or /adopt-context-docs in Claude Code. The starter already has a context entry point and maintenance rule: check that adoption reuses that setup; decline a second layout. For your own unconfigured project, adoption can establish those pieces.

Inspect AGENTS.md, the Claude import, and project context. Check git status --short and inspect the adoption diff. The marker records adoption intent. Verify which instruction file your client actually loads; presence alone does not establish automatic loading. Keep optional logging off for this exercise.

Prompt: Adopt once

Use adopt-context-docs to inspect and reuse this project’s existing context documents and maintenance rule. Preserve the current layout, decisions and evidence. Keep optional logging off. Show which instructions should load in this client and any loading uncertainty. Do not deploy or change global settings.

Expected result: One reused context entry point and maintenance rule, with configuration and loading kept distinct.

Check: Inspect AGENTS.md, CLAUDE.md and the resulting diff; no duplicate layout or logging setup.

STEP 04

Follow the sources, then audit.

The entry point should give the purpose, current state, unfinished work and next action. Follow its links to decisions, the export requirement, code and tests. You do not need to paste a previous chat.

An audit reports findings; a separate maintenance request authorizes repairs. Do not count an audit as a successful implementation or turn a proposal into an approved owner decision.

To check that the audit left files unchanged, compare file contents before and after, not only git status --short categories: a file already marked modified can change again without its status changing. Start from a clean checkout, or before the audit save the git diff output plus copies or checksums of already-modified and relevant untracked files outside the checkout, then compare afterwards. git diff shows tracked changes only; status lists untracked files without comparing their contents and omits ignored files.

Prompt: Audit without edits

Audit this project’s saved context against its README, linked decisions, export requirement, source and tests. Report concrete inaccuracies, unsupported claims and missing next steps with source locations. Leave files unchanged.

Expected result: Source-linked findings with no file edits.

Check: Compare before/after diffs or snapshots of the files in scope; unchanged status alone is not enough.

STEP 05

Make the next change explicit.

The worked requirement is small: export every active link in the current browser's queue as JSON, regardless of the selected filter. Do not export cookie values, session identifiers or database/account metadata. An empty queue should export {"schema_version":1,"items":[]}. A failed fetch must show an error without downloading a file.

The implementation team selected this exercise. The requirement file is its source; it is not a transcript of an owner request. The decision to export the whole queue, rather than only filtered rows, belongs in the decision note with its rationale. No schema change or new cloud service is needed.

The linked main-branch requirement and decision include October 26 wording clarifications. The retained starter and completed tags keep their original documents. Use the versioned empty shape above; the decision clarification explains why changing a UI filter does not change export scope.

Prompt: Scope the feature

Plan the pending JSON export change using the existing requirement. Identify the affected code and meaningful tests. Preserve whole-queue export regardless of the UI filter, browser isolation and expiry. Explain any unresolved decision. Do not implement or deploy yet.

Expected result: A bounded export plan using the requirement already in the repository.

Check: The plan preserves privacy boundaries and requires no schema change or new service.

STEP 06

Leave a useful handoff.

The loaded maintenance rule is intended to guide updates after meaningful work without naming the skill each time. An explicit handoff request is still useful when you are about to stop. Before changing code, ask for a focused context update. Preserve the baseline's check results with their actual scope; do not describe the pending export as complete.

Review the diff. A useful handoff says that CRUD and filtering exist, export is pending, the full active queue is required, and the next step is implementation plus export tests. Test counts and results must come from your run, not this tutorial.

Prompt: Prepare the handoff

Save the agreed export plan and next action in the existing project documents. Preserve the requirement, decision authority and source links. Separate implemented behavior, checks actually run and pending work; keep the existing progress view current. Do not implement export or deploy.

Expected result: A concise handoff that keeps export pending and names its next action.

Check: Read the context diff; no claimed check may exceed the observed result.

STEP 07

Resume in a fresh session.

Start a new agent session in the same example folder. Use a supported client and confirm the intended project. The ordinary prompt below does not name the skill or ask for a documentation update. Check the resulting Markdown diff; if it is missed, retain that outcome. Explicitly asking the agent to read the entry point is a fallback when loading is unconfirmed.

A genuinely new conversation can test the handoff immediately; no waiting period is needed. Native memory, such as Claude Code auto memory or Codex memories, can also contribute to what a fresh session knows. Keep your usual settings for ordinary use. For a diagnostic exercise, record your client's memory and instruction-loading settings and inspect which sources the agent actually read.

The agent still needs to inspect implementation details. Saved context provides a starting point and source map; it does not replace code review, testing or deployment authorization. When two sessions share a document, agree on one writer.

Prompt: Implement in a fresh session

Implement the pending JSON export feature using the existing requirements. Preserve the temporary demo’s browser isolation and expiry behavior. Verify the change with the available local tests. Do not install packages, deploy, provision services, publish, or change files outside this project.

Expected result: Export is implemented and relevant context reflects the meaningful change.

Check: Inspect both code and Markdown diffs. If maintenance is missed, report the miss and ask for a focused repair.

STEP 08

Verify behavior and the saved state.

npm test
npx wrangler deploy --dry-run --outdir .local/build
git diff --check
git diff

The API suite uses workerd and a local D1 database. These are application checks, not an evaluation of Context Docs. In your browser, add two links, mark one read, select Unread and export: the downloaded JSON should include both links. Use a separate browser context to check queue isolation. Test an empty queue and simulate a failed export request: show an error and produce no file.

After verification, review the context diff. Does it say what changed, cite the tests actually run, preserve decisions and remaining limits, and give the next action? Keep detailed diagnostic output out of shared context unless the next reader needs it.

Prompt: Verify the result

Verify the export acceptance criteria and relevant existing behavior. Run the local tests and deployment dry run. Check the browser download, full-queue behavior under filtering, an empty queue and a failed request. Report what actually passed, failures and what remains untested. Do not deploy.

Expected result: Check results are separate from assumptions and untested behavior.

Check: Inspect the downloaded JSON and confirm a failed request produces no file.

STEP 09

Compare with the completed example.

Stop your dev server before switching revisions. To inspect the reference solution without replacing your work:

git diff tutorial-start..tutorial-complete -- src public tests docs

The completed tag shows the app and its updated context together. Compare meaning and acceptance criteria, not exact model wording. These authored Git snapshots demonstrate a workflow; no controlled fresh-session performance study or savings claim is made.

Prompt: Review the handoff

Review the implementation and saved project context together against the export requirement. Check retained decisions, evidence, remaining limits and the next action. Compare with the completed example if useful. Report findings without editing files or deploying.

Expected result: A review covering app behavior and whether the saved handoff remains useful.

Check: Resolve verified findings; preserve uncertainty and existing evidence.

STEP 10

Deploy your own fork, if you want.

Local practice ends with a tested change and a reviewed handoff. Deployment is a separate choice. Follow the example's deployment instructions to fork it, choose a unique Worker name and create your own D1 database. Workers serves the static UI and API; D1 persists the temporary queue. R2 adds no useful behavior for these URL records, so it is omitted.

The repository includes a GitHub Actions workflow: test pull requests without deployment credentials; on code pushes to main, test, apply migrations, deploy and verify the live commit. Configure your own account/database variables and dedicated deployment token in GitHub. Never copy a local OAuth login token or use the maintainer's database. Documentation-only record commits do not trigger another deployment.

Check Cloudflare's current GitHub Actions guide and D1 migration guidance. Quotas and account billing still apply. Stored-row caps do not bound traffic or total usage; this is a teaching sandbox with no production abuse protection.

Prompt: Deploy your own fork

Deploy my own reviewed Reading Queue fork to my selected Cloudflare account. First confirm the repository, unique Worker name and database; ask for any missing target information. Use a dedicated deployment token stored as a GitHub secret, with the required account and database variables. Run checks before publishing, then verify the live commit and app behavior. Never reuse the maintainer’s database or copy a local OAuth token into CI.

Expected result: Your own fork deploys automatically from trusted main-branch code after passing tests.

Check: Compare the live revision with the commit and exercise your own sandbox. This step authorizes real cloud changes only when you choose to run it.

STEP 11

Know what this example demonstrates.

You have exercised adoption/reuse, a source-linked entry point, a decision and scoped requirement, a concise progress view, read-only audit, meaningful maintenance and an explicit new-session handoff. Git retains the two revisions. Optional event logging stays off; not every project needs a journal.

Context Docs supplies reusable maintenance guidance for this work. A carefully maintained README, native agent instructions or built-in memory may already be enough for your project. The extra convention is useful when repeated sessions need to preserve project facts, decisions and unfinished work with traceable sources. See the fit and tradeoffs comparison.