← Sprint sync, 2026-08-04

Prompt 2: rewrite the tutorials

projects/dkr-agency/concept-space-2026-08-01-video-corpus/manus-pack/PROMPT-2-REWRITE-TUTORIALS.md

Tutorial specification

This document is the full specification for writing a tutorial against this system. It is addressed to the agent doing the writing. Read it in full before writing anything, and keep it open while you work.

It applies to new videos and to redoing any tutorial produced before 2026-08-02.

Write a tutorial for each video I give you. A tutorial here is a set of steps a person can run on this machine today against the system described in GROUND-TRUTH-2026-08-01.md. Anything else is not a tutorial.

Ground every step in the real system

Draw only on the components below. They are the whole list. If a step needs something that is not here, the step does not exist, and you should say so instead of writing it.

Running today:

Prototype: Trailblazer (environment mapping and intent modelling) and the DKR agent that links new notes and raises legibility.

Specified and unbuilt: the monorepo (apps/, modules/, engines/, interfaces/, registries/, intake/, gates/, .github/), with seed files ready at projects/shur/dev-sprint-1/monorepo-seed/ including gates/route-gate.py whose self-test passes 13 of 13 with no model calls; the delivery grammar Route = Channel x Form x Reader x Action with the gating fields attenuates and evidence; the registries at v0, holding 12 channels, 20 forms of which 11 are built, and 1 reader, with zero route declarations existing as files; Jira, which has no instance at all; and the repository inside the shuriq-lab GitHub organization, which holds zero repositories and has no chosen name.

Follow the corrected tutorials in this pack

The 21 files in tutorials/ are the pattern. Two more exist and were held back from this pack, which tutorials/WITHHELD.md records. Read at least these three before writing:

Match their register: second person, imperative step titles, short sentences, commands in fenced bash blocks with the cd to the vault included where it matters.

Never describe an unbuilt thing in the present tense

This is the rule that separates a usable tutorial from the ones I am replacing.

Every tutorial ends with a real check

Close each tutorial with a ## Verify it worked section. It contains commands that run today against files that exist, and for each one a stated expectation. A check that cannot fail is not a check. Prefer checks that catch the specific mistake the tutorial invites, and say which check matters most and why.

Acceptable checks: a grep that must return zero matches, a re-run of an idempotent tool that must report no writes, a curl with -o /dev/null -w "%{http_code}" against a URL in the component list, a file existence test, a self-test with a known pass count.

Say plainly when a video does not apply

Some videos have no actionable application here. When that is true, say it in the opening paragraph, explain in one section what the video argues, explain in one section why it does not transfer, and stop. A short honest tutorial is the correct output. Padding a video into invented steps is the failure mode I am correcting, and it is worse than a half-page answer.

Writing rules

Follow the rules in Prompt 1 exactly: zero em-dashes, full ISO dates, no "not X, but Y" inversion, no banned term from the list, one thought per sentence, each point made once, no self-reference, no unexpanded internal code. Before you return anything, run your own pass against the banned-term list in Prompt 1 and report the count of hits you fixed.

Where a banned word appears inside a verbatim external title, a filename that exists, or a literal string a reader must copy, keep it and list it in a grammar-allow.txt beside your output, with a comment saying why each line is there and that it is pending my authorisation.

Return format

Return one Markdown file per video, named <video_number>-<slug>.md, with this frontmatter shape:

---
created: 2026-08-01
modified: 2026-08-01
type: strategy_doc
doc_type: tutorial
status: draft
origin: claude-code-terminal
project: dkr-agency
organization: [sense-collective, shur-agency]
style_guide: google-developer
reader: "a one-line description of the specific person who runs this"
video_number: 103
video_title: "Google's Open Knowledge Format (OKF)"
source_tutorial: "manus guided_tours/getting_started_instructions_103.md, rewritten 2026-08-01"
tags: [tutorial, concept-space, okf]
---

Set created and modified to the date you write the file, in full ISO form. Write reader as a description of a person and a task. Never write reader: internal. Keep style_guide: google-developer, because tutorials are technical documentation and follow Google developer documentation style.

Use type: strategy_doc with doc_type: tutorial, exactly as written above. There is no tutorial value in the artifact type registry, and inventing one breaks about 40 Bases dashboards that read these schemas. The doc_type field is the established discriminator.

Then an H1 that states the outcome as an action, such as "Turn a vault folder into an OKF bundle". Then two or three sentences saying what the tutorial does and who it is for. Then the steps. Then ## Verify it worked.