[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71RT6MBGJC4QQZBGHF4H1M8":3,"skill-same:01M71RT6MBGJC4QQZBGHF4H1M8":135},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M71RT6MBGJC4QQZBGHF4H1M8","walkthrough",null,"Record a short, narrated, captioned video walkthrough that proves a finished coding task and shows how it behaves, then self-verify the video via vision on extracted frames and publish it as one scrubbable Tailscale link. Use after completing a change\u002Ffix\u002Ffeature on a web project (Next.js\u002FReact etc.) when the user wants visual proof of work, a demo of a user flow, or to avoid manually retesting and watching a long raw screen recording. Triggers on requests like \"record a walkthrough\", \"show me it working\", \"make a demo video of this\", \"prove the feature\", or finishing a UI\u002Froute\u002Fform\u002FAPI change worth demonstrating. Not for walking through a full from-scratch project build.","gongiskhan\u002Fagent-garrison","gongiskhan","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1997392?v=4","01M71RKMFR53TKXE308C22QTNZ","01M71RKMJA57KZHNDCBNKTWZRR",1,"MIT","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[5,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"fix","when","project build","recording","project","self","next","me","route","show","react","short","work","show me","Video","api","publish","demo video","change","2026-11-10 13:02:02",false,"---\nname: walkthrough\ndescription: Record a short, narrated, captioned video walkthrough that proves a finished coding task and shows how it behaves, then self-verify the video via vision on extracted frames and publish it as one scrubbable Tailscale link. Use after completing a change\u002Ffix\u002Ffeature on a web project (Next.js\u002FReact etc.) when the user wants visual proof of work, a demo of a user flow, or to avoid manually retesting and watching a long raw screen recording. Triggers on requests like \"record a walkthrough\", \"show me it working\", \"make a demo video of this\", \"prove the feature\", or finishing a UI\u002Froute\u002Fform\u002FAPI change worth demonstrating. Not for walking through a full from-scratch project build.\n---\n\n# Walkthrough recorder\n\nProduce ONE stitched, captioned MP4 that demonstrates a finished change, then **prove it is correct by viewing extracted frames before handing over**. You cannot watch video — the self-verification loop is mandatory, not optional.\n\n## No terminals on camera — show rendered EVIDENCE, never typing\nA video of a shell being typed into is worthless as proof and unusable in a public walkthrough. **Never record a terminal, a shell prompt, or commands being typed\u002Frun on camera.** The audience is a human who wants to *see the thing work* and, later, a website visitor watching this as a product walkthrough. When the proof lives in a file, an API response, a log, or a command's output, use an **`evidence` segment**: the command (if any) runs OFF-camera and the video shows only the captured **result** as a clean titled panel, with the **proving line highlighted and annotated**. Opening a file and pointing at the line that proves the change is good; recording yourself typing `cat`, `curl`, or `tail` to get there is not. (There is no `terminal` segment anymore — legacy ones auto-migrate to a panel, with a warning.)\n\n## Proof means behavior — test runs are BANNED from camera\nA passing test suite is not proof that anything was implemented, and the user never wants to watch one. **Never show a test runner or test results** — no `npm test`, `vitest`, `jest`, `pytest`, `playwright test`, `go test`, `cargo test`, coverage output, or CI logs, ever, in any beat. `record.mjs` refuses storyboards whose evidence `command` matches a test runner; do not try to work around it. Proof is the feature **visibly doing the thing in the running app**: drive the real UI, show the real data persisting, show the live endpoint's actual response and the real log line in an evidence panel. If you cannot demonstrate the change as observable behavior, say so and ask — do not substitute a test run.\n\n## Two layers of truth (never collapse them)\n- **Functional truth** — Playwright `assert`s during recording confirm the feature actually did the thing (and highlight the asserted element as the \"verified result\" beat); an evidence panel's `highlight.match` is the same kind of check on captured output (the proof string must really be present, or the beat fails). These are inline checks on the live app\u002Freal output — not a test suite, and nothing test-shaped appears on screen.\n- **Communication truth** — you read extracted frames and confirm the video *shows and labels* the right thing. Vision cannot confirm business correctness, so both layers are required. Communication truth is checked TWICE: per-beat (each frame, step 6) **and** holistically (does the whole video tell the real end-to-end story — step 7, the claude-video gate).\n\n## Mode — `marketing` (default) vs `evidence`, selected by parameter, never inferred\nThis skill runs in one of two modes, chosen ONLY by an explicit **`mode`** parameter — it is **never** inferred from the change, the repo, or the caller.\n- **`mode: marketing` (DEFAULT)** — the full storytelling walkthrough described in every step below: story-arc flow selection, 10–20+ beats, 3200–6000 ms holds, intro\u002Foutro title cards, **both** vision gates (per-beat step 6 **and** the holistic claude-video gate step 7), and up to 6 re-records. **A standalone invocation is always marketing** unless the caller explicitly passes `mode: evidence` — standalone behavior is exactly as it is today.\n- **`mode: evidence`** — a lean per-criterion proof pass for an automated build gate (see **Evidence mode** below). **`autothing-walkthrough` ALWAYS passes `mode: evidence`** (plus the slice's acceptance-criteria list); nothing else selects it.\n\nEverything in the **Workflow** below is the marketing default. Evidence mode keeps the same machinery and every honesty rule but overrides only the beats named in **Evidence mode** — the two never mix, and the default is untouched.\n\n## Workflow\n\n### 1. Preflight (first run on a machine)\nRun `scripts\u002Fpreflight.sh`. It checks node\u002Fffmpeg\u002Fplaywright-cli\u002F**claude-video** and reports the Tailscale IP. Install anything missing before continuing. **claude-video (the `\u002Fwatch` skill) is required** — it powers the holistic review gate (step 7); install once with `\u002Fplugin marketplace add bradautomates\u002Fclaude-video` then `\u002Fplugin install watch@claude-video` (or point `WALKTHROUGH_WATCH_PY` at an existing `watch.py`).\n\n### 2. Read project memory\n- Read `.walkthrough\u002Fconfig.json` and `.walkthrough\u002Fnotes.md` in the target repo. If absent, create them from the templates in `references\u002Fstoryboard-schema.md` (ask the user for `baseURL`\u002F`startCommand` if not obvious from `package.json`).\n- **`notes.md` drives flow selection** — honor it (which flows matter, caption language, what to always show, what to avoid on camera).\n\n### 3. Make the app reachable\n- Start the app with `config.startCommand` if it is not already running (background it; never block the terminal; use the project's configured port). Confirm `baseURL` responds.\n- **Auth**: if the app needs login, use a stored session instead of typing credentials on camera. Establish it ONCE, off-camera:\n  `playwright-cli open \u003CbaseURL\u002Flogin>`, drive the login (and any forced password-change) by hand or with playwright-cli, then `playwright-cli state-save .walkthrough\u002Fauth.json`. Reference it as `authState` on the browser segment. Add `auth.json` to `.gitignore`. Never put tokens or `.env` contents in an evidence `command` or its output.\n\n### 4. Choose flows: tell the feature's REAL story, end-to-end\n**A walkthrough is a story, not a screen tour. Show *why the feature exists and how it is actually used*, from the real starting point to the real payoff — the whole arc a developer needs to believe it works.** The arc is almost always: **starting point → the action that exercises the feature → it actually running → the REAL result\u002Fartifact → (where it applies) a follow-up change and its effect.** A video that stops at \"the page renders\" or skips the payoff has failed this step, no matter how clean each frame is.\n\n- **Worked example — a build on Ekoa.** Don't record \"the build page exists.\" Record the journey: **start a new conversation → submit the build request → show the first few seconds while it's building → skip the minutes it churns → show the COMPLETED artifact → make another change → show the change take effect.** That is the story; anything less doesn't show what the feature is *for*. Apply the same arc to any feature: a form → the created record surviving a reload; a router change → the request visibly routed differently; an importer → the imported data rendered.\n- **Long-running operations are first-class — never fake or omit them.** When the feature kicks off something slow (a build, a generation, a job), do NOT cut to a pre-baked result and do NOT sit through dead minutes on camera. Keep ONE live session and either **timelapse** the wait or **cut** it (see step 5: `continue` + `speed` or `waitBefore`, with a \"≈ N min later\" title card). Show enough of the start that the viewer sees it genuinely running, then the genuine finished artifact from that same run.\n- **First, look for a demo the project already ships and prefer it** — a demo\u002Ftour\u002Fshowcase route or hash-route, a `demo`\u002F`seed`\u002F`story`\u002F`tour` script in `package.json`, seeded demo data, a Storybook, a README \"Demo\" section, or a flow named in `.walkthrough\u002Fnotes.md`. If one exists, record THAT exact path. Do not synthesize a generic flow that ignores an obvious built-in demo — the user wants to see the real thing working, not a stand-in.\n- **Default to comprehensive, end-to-end coverage — not a teaser.** Demonstrate the actual feature the task delivered, all the way through, with **real data that persists** (create a record → see it in the list → reload → it survived). Walk **every meaningful state**: empty → action → in-progress → populated → verified. Click into each tab, switch a selector and show the result change, scroll the whole table, drive a second flow if the feature has one. There is **no beat cap and no duration cap** — a thorough walkthrough is commonly 10–20+ beats and several minutes, and that is the goal, not something to trim. A video that \"only proves a page renders\" is a failure of this step.\n- **Organize by `folder`, and make MORE videos.** Set the storyboard's `folder` to the feature area (e.g. `\"model-router\"`, `\"improver\"`, `\"runtime\u002Fcodex\"`). When a topic is broad, record **several focused videos into the same folder** — one clear flow each — rather than one shallow video that skims everything. The gallery groups by `\u003Cproject> \u002F \u003Cfolder>`.\n- **Hold long enough to read.** `hold` defaults to 3200 ms; for dense screens (policy tables, populated lists, JSON output) set `hold` to 4000–6000 so the viewer can actually absorb it. Long single browser segments are fine (up to 600 s; override with `runTimeoutMs`) and read as one real session.\n- In each video include, where the feature allows: a real click, a route\u002Ftab change, a selector change that visibly remaps something, an **evidence panel** proving the live system state (the actual API response, the persisted record in a file, the real server log — captured off-camera, proving line highlighted), and a full e2e flow ending in an asserted\u002Fhighlighted result. Add an intro title card (`reflectFlag: true`) and an outro.\n- **When the proof IS the network traffic** (server-side pagination, a persist POST, a route re-targeting a backend) and the user wants to \"see the network \u002F network tab\", a viewport recording can't show DevTools — attach a browser-segment **`networkPanel`** instead: a live top-right HUD that re-paints each matching `request`\u002F`response` (page\u002Fsize → status\u002Frows) from the real Playwright events. See `references\u002Fstoryboard-schema.md` → \"Network panel\". This is the supported fallback for network-tab requests.\n- **CRITICAL: no terminals, no test runners on camera.** Never record a shell or typing; show a rendered `evidence` panel (off-camera capture, proving line highlighted) instead. And no `npm test`, `vitest`, `jest`, `pytest`, `cargo test`, test output, or CI logs — ever. If the feature can only be \"proven\" by a passing test, ask the user instead of recording the test. The walkthrough must show the feature **visibly doing the thing in the real running app**, not a test passing.\n- Write `storyboard.json` per `references\u002Fstoryboard-schema.md`. For each beat set the exact `caption` and a concrete `expectedScreen` (\"the automations list with a New automation button\") — these become the vision assertions.\n- Order beats so pages that embed a **cross-origin iframe** (e.g. an embedded terminal pane) land last — the caption HUD can intermittently render as an empty gray strip on those pages, and sequencing them last keeps every earlier caption clean.\n- **Settle every freshly-loaded page BEFORE its first caption beat.** On a page that is still loading, the caption HUD can miss the first beat entirely, and fixed-wait beats tend to capture loading states (spinners, skeletons) instead of the ready page. Make a settle action the storyboard default: start each freshly-loaded page with a `waitFor` on a selector that only exists once the page is ready, and only then run the first captioned beat. Prefer selector waits over fixed waits throughout.\n- **Pages with persistent WebSocket connections** (WS-action pages, live-stream views, chat panels) are unreliable recording targets: the open WS connection defeats the between-beat `networkidle` settle, causing empty-output crashes or >120 s hangs. Workaround: pre-seed any needed state via API\u002FHTTP before the recording (avoid WS-action beats entirely where possible), or accept the committed e2e as the gate for WS-heavy flows and record only the HTTP\u002Fstatic surfaces of the same feature.\n\n### 5. Record\n`node scripts\u002Frecord.mjs \u003Cstoryboard.json>` → prints `{ runDir, final, beats, flagged }` and writes `manifest.json` (measured beat→timestamp map) + `pass-record.json`.\n- **Concurrent runs are isolated automatically.** Each run gets its own private playwright-cli daemon namespace (derived from its run dir), so you can record from several sessions\u002Fprojects at once without them tearing down each other's browser. You do not set anything — no `WALKTHROUGH_PW_SESSION`, no `kill-all`. (Never run `playwright-cli kill-all` during a recording: it is machine-wide and will kill every concurrent run's browser.)\n- The recorder automatically shows a **visible cursor + click pulse** at every click\u002Ffill\u002Fhover and **scrolls each target into view before highlighting it** — so the video reads as a real user session and the \"verified result\" box always lands ON the element, never off-screen. You do not author these; do not add them to the storyboard.\n- **Long operations, kept honest in ONE live session** (full schema in `references\u002Fstoryboard-schema.md`):\n  - `continue: true` on a browser segment **reuses the session the previous segment left open** — same page, same live state — so an operation kicked off earlier is still running. (The first segment can't `continue`.)\n  - **Timelapse** the wait: a `continue` segment with `speed: 8` records the real progress, then compresses it 8× (offsets are scaled, so the manifest stays accurate). Pair with a beat `holdUntil: { selector }` that keeps the \"Building…\" caption rolling until the completion signal appears.\n  - **Cut** the wait: a `continue` segment with `waitBefore: { selector }` waits for completion OFF-camera (unrecorded), then rolls on the finished result. Bridge the jump with a `title` card like `\"≈ 3 minutes later\"`.\n  - Bump `runTimeoutMs` (and the `waitFor`\u002F`holdUntil` `timeout`) above the real operation time for genuinely long builds.\n\n### 6. Extract frames + VISION-VERIFY (the gate — do not skip)\n`node scripts\u002Fextract_frames.mjs \u003CrunDir>` → one frame per beat at its measured midpoint (`frames\u002Findex.json` lists each frame with its `expectCaption`\u002F`expectScreen`).\n\nThen **Read every beat frame** and assert, per beat, concretely:\n- the caption reads exactly `expectCaption` and is legible, AND\n- the screen matches `expectScreen` (name the specific thing you see — \"the automations list with a New automation button\", not \"looks right\").\n- for `expectFailure` beats: confirm the failure is shown distinctly (red \"FAILED\" caption) and the run is flagged. A correctly-shown failure **passes** — do not try to \"repair\" it.\n\nOn any mismatch: identify the failing beat, diagnose the cause (caption text, a missing `waitFor`, a wrong selector, an unsettled animation, timing), fix the storyboard, **re-record**, re-extract, re-verify. Add `--interval` on a re-run if you need frames between beats to localize a problem.\n\n**Retry ceiling**: max 3 attempts on the same beat, max 6 re-records total (shared with step 7). If still failing, STOP — write `STUCK.md` in the runDir with the failing frame path, the expected vs. observed, and what you tried, and ask the user. Never hand over while any expected caption or screen is unverified, and never fake success.\n\nWhen all beats pass, proceed to the holistic gate (step 7) — **do not set `verifiedAt` yet.**\n\n### 7. Holistic video review — the SECOND gate (claude-video; do not skip)\nThe per-beat gate proves each frame is right; it cannot tell whether the **whole video shows the real feature end-to-end** (the step-4 arc). This gate does — by actually watching the finished video.\n\n`node scripts\u002Freview_video.mjs \u003CrunDir>` → locates claude-video, ingests `final.mp4` (silent → `--no-whisper`) into `\u003CrunDir>\u002Fwatch\u002F`, and prints a strict 5-point rubric plus the frames the tool produced.\n\nThen **Read those frames in order and answer the rubric**: does the video show the real starting point, the action, it actually running, the REAL result, and (where it applies) a follow-up change? What essential part of the story is missing or only implied? Any dead\u002Fblank\u002Fbroken stretches or success-faked failures?\n- **PASS** only if a developer who never saw this feature would, from this video alone, understand what it does and see it genuinely working end-to-end.\n- **FAIL** → treat it exactly like a failed beat: name the gap (a missing arc step, a skipped payoff, an unshown follow-up change, a dead stretch), **re-plan the storyboard** (add\u002Fextend the flow — often a `continue` result\u002Fchange segment or a long-op timelapse), **re-record, re-verify both gates.** Same retry ceiling as step 6.\n\nOnly when BOTH gates pass, set `verifiedAt` (ISO timestamp) in `pass-record.json`.\n\n### 8. Publish\nEnsure the gallery server is running: `node scripts\u002Fserve.mjs` (binds to the Tailscale IP, supports range\u002Fscrubbing). It prints `{ url }`. The gallery is a single page: it groups runs by `\u003Cproject> \u002F \u003Cfolder>`, shows real video thumbnails (ffmpeg, cached as `thumb.jpg` per run) with formatted dates, and supports live **search**, **sort**, project\u002Fstatus **filters**, and a group toggle. Clicking any card opens an **in-page fullscreen player** — navigate between videos with the on-screen arrows, the **keyboard arrows**, or a **swipe**, jump around with **chapter markers** built from the beat captions, and download from the same view. Give the user that gallery URL (newest folder first) — or the direct `http:\u002F\u002F\u003Ctailscale-ip>:8099\u002F\u003Cproject>\u002F\u003Cfolder>\u002F\u003Ctimestamp>\u002Ffinal.mp4` (no `\u003Cfolder>` segment for an ungrouped run; direct links still work as before). Confirm range works locally if unsure: `curl -s -D- -o \u002Fdev\u002Fnull -H 'Range: bytes=0-99' \u003Curl>` → expect `206 Partial Content`. Optional HTTPS upgrade: `tailscale serve --bg \u003Cport>`. When you record several videos, give the gallery URL once and list each video's direct link under its folder.\n\n### 9. Learn\nIf the user corrects flow choice, captions, or what to show\u002Favoid, **append a dated bullet to `.walkthrough\u002Fnotes.md`**. Flow selection is the part that improves with use — say so in your handover.\n\n## Evidence mode (`mode: evidence`)\nEvidence mode records lean, per-criterion proof for an automated gate — not a story. It **keeps every honesty rule and every mechanic** and overrides only what is named here; the marketing default (all of **Workflow** above) is unchanged.\n\n- **Storyboard derives from the slice's ACCEPTANCE CRITERIA, not a story arc** — **one beat per acceptance criterion**, plus the minimal navigation needed to reach each. Step 4's \"tell the feature's REAL story, end-to-end\" **does not apply**: there is **no comprehensive-arc mandate**, **no intro\u002Foutro title cards**, and **no \"make MORE videos\" \u002F several-focused-videos guidance** — one criterion, one beat.\n- **Short holds, terse captions.** `hold` defaults to **1200 ms** (dense screens **2000 ms**), not 3200–6000. Each caption is **terse — the criterion id plus a short phrase** (e.g. `AC-3 — record persists after reload`).\n- **Kept UNCHANGED — behavior is still the proof.** No test runners on camera (a passing suite is never the evidence); the **`evidence` panels**; the **functional-truth `assert`s** (and an evidence panel's `highlight.match`); the **visible cursor + click pulse, settle-before-caption, and `waitFor`\u002Fselector-wait** mechanics; and the **per-beat vision verification (step 6)**. Evidence mode weakens none of these.\n- **Skip the holistic claude-video gate (step 7).** Evidence does not need storytelling verification — **per-beat vision (step 6) plus the inline functional asserts ARE the gate.** (Marketing mode KEEPS both gates.)\n- **Retry ceiling: 1 re-record** (not 6). If, after that single re-record, a beat still fails on a **caption\u002Flegibility** ground **while its functional `assert` PASSED**, do NOT keep chasing polish — record the video as **`evidence-degraded`** in `notes.md`\u002Fstatus with the reason. An honest degraded artifact beats six re-records over legibility. (A failed functional `assert` is still a real failure — render it honestly per **Honesty**, never faked green.)\n- **Emit `evidence.json` next to the video** — an array of `{ beat, criterionId, timestamp, assert, result }`, one entry per beat, referenced from the gate-status \u002F evidence-index so a reviewer verifies each criterion **against the JSON without watching the video**.\n- **Long operations carried as-is** — the `continue` \u002F `speed` \u002F `waitBefore` timelapse-or-cut machinery from step 5 applies unchanged, with `speed` defaulting **aggressive (8×)**.\n\n## Honesty\nIf something does not work, show it not working (mark that beat `expectFailure: true` → red \"FAILED\" caption) and let the run be flagged in the gallery. Never edit a failing flow into looking like it passed.\n\n## Reference\n- `references\u002Fstoryboard-schema.md` — full storyboard\u002Fconfig\u002Fnotes schema, segment types, selector language, manifest shape.\n- `references\u002Fdecisions.md` — the tool bake-off and why each choice was made (and its limits).\n","# Walkthrough recorder\n\nProduce ONE stitched, captioned MP4 that demonstrates a finished change, then **prove it is correct by viewing extracted frames before handing over**. You cannot watch video — the self-verification loop is mandatory, not optional.\n\n## No terminals on camera — show rendered EVIDENCE, never typing\nA video of a shell being typed into is worthless as proof and unusable in a public walkthrough. **Never record a terminal, a shell prompt, or commands being typed\u002Frun on camera.** The audience is a human who wants to *see the thing work* and, later, a website visitor watching this as a product walkthrough. When the proof lives in a file, an API response, a log, or a command's output, use an **`evidence` segment**: the command (if any) runs OFF-camera and the video shows only the captured **result** as a clean titled panel, with the **proving line highlighted and annotated**. Opening a file and pointing at the line that proves the change is good; recording yourself typing `cat`, `curl`, or `tail` to get there is not. (There is no `terminal` segment anymore — legacy ones auto-migrate to a panel, with a warning.)\n\n## Proof means behavior — test runs are BANNED from camera\nA passing test suite is not proof that anything was implemented, and the user never wants to watch one. **Never show a test runner or test results** — no `npm test`, `vitest`, `jest`, `pytest`, `playwright test`, `go test`, `cargo test`, coverage output, or CI logs, ever, in any beat. `record.mjs` refuses storyboards whose evidence `command` matches a test runner; do not try to work around it. Proof is the feature **visibly doing the thing in the running app**: drive the real UI, show the real data persisting, show the live endpoint's actual response and the real log line in an evidence panel. If you cannot demonstrate the change as observable behavior, say so and ask — do not substitute a test run.\n\n## Two layers of truth (never collapse them)\n- **Functional truth** — Playwright `assert`s during recording confirm the feature actually did the thing (and highlight the asserted element as the \"verified result\" beat); an evidence panel's `highlight.match` is the same kind of check on captured output (the proof string must really be present, or the beat fails). These are inline checks on the live app\u002Freal output — not a test suite, and nothing test-shaped appears on screen.\n- **Communication truth** — you read extracted frames and confirm the video *shows and labels* the right thing. Vision cannot confirm business correctness, so both layers are required. Communication truth is checked TWICE: per-beat (each frame, step 6) **and** holistically (does the whole video tell the real end-to-end story — step 7, the claude-video gate).\n\n## Mode — `marketing` (default) vs `evidence`, selected by parameter, never inferred\nThis skill runs in one of two modes, chosen ONLY by an explicit **`mode`** parameter — it is **never** inferred from the change, the repo, or the caller.\n- **`mode: marketing` (DEFAULT)** — the full storytelling walkthrough described in every step below: story-arc flow selection, 10–20+ beats, 3200–6000 ms holds, intro\u002Foutro title cards, **both** vision gates (per-beat step 6 **and** the holistic claude-video gate step 7), and up to 6 re-records. **A standalone invocation is always marketing** unless the caller explicitly passes `mode: evidence` — standalone behavior is exactly as it is today.\n- **`mode: evidence`** — a lean per-criterion proof pass for an automated build gate (see **Evidence mode** below). **`autothing-walkthrough` ALWAYS passes `mode: evidence`** (plus the slice's acceptance-criteria list); nothing else selects it.\n\nEverything in the **Workflow** below is the marketing default. Evidence mode keeps the same machinery and every honesty rule but overrides only the beats named in **Evidence mode** — the two never mix, and the default is untouched.\n\n## Workflow\n\n### 1. Preflight (first run on a machine)\nRun `scripts\u002Fpreflight.sh`. It checks node\u002Fffmpeg\u002Fplaywright-cli\u002F**claude-video** and reports the Tailscale IP. Install anything missing before continuing. **claude-video (the `\u002Fwatch` skill) is required** — it powers the holistic review gate (step 7); install once with `\u002Fplugin marketplace add bradautomates\u002Fclaude-video` then `\u002Fplugin install watch@claude-video` (or point `WALKTHROUGH_WATCH_PY` at an existing `watch.py`).\n\n### 2. Read project memory\n- Read `.walkthrough\u002Fconfig.json` and `.walkthrough\u002Fnotes.md` in the target repo. If absent, create them from the templates in `references\u002Fstoryboard-schema.md` (ask the user for `baseURL`\u002F`startCommand` if not obvious from `package.json`).\n- **`notes.md` drives flow selection** — honor it (which flows matter, caption language, what to always show, what to avoid on camera).\n\n### 3. Make the app reachable\n- Start the app with `config.startCommand` if it is not already running (background it; never block the terminal; use the project's configured port). Confirm `baseURL` responds.\n- **Auth**: if the app needs login, use a stored session instead of typing credentials on camera. Establish it ONCE, off-camera:\n  `playwright-cli open \u003CbaseURL\u002Flogin>`, drive the login (and any forced password-change) by hand or with playwright-cli, then `playwright-cli state-save .walkthrough\u002Fauth.json`. Reference it as `authState` on the browser segment. Add `auth.json` to `.gitignore`. Never put tokens or `.env` contents in an evidence `command` or its output.\n\n### 4. Choose flows: tell the feature's REAL story, end-to-end\n**A walkthrough is a story, not a screen tour. Show *why the feature exists and how it is actually used*, from the real starting point to the real payoff — the whole arc a developer needs to believe it works.** The arc is almost always: **starting point → the action that exercises the feature → it actually running → the REAL result\u002Fartifact → (where it applies) a follow-up change and its effect.** A video that stops at \"the page renders\" or skips the payoff has failed this step, no matter how clean each frame is.\n\n- **Worked example — a build on Ekoa.** Don't record \"the build page exists.\" Record the journey: **start a new conversation → submit the build request → show the first few seconds while it's building → skip the minutes it churns → show the COMPLETED artifact → make another change → show the change take effect.** That is the story; anything less doesn't show what the feature is *for*. Apply the same arc to any feature: a form → the created record surviving a reload; a router change → the request visibly routed differently; an importer → the imported data rendered.\n- **Long-running operations are first-class — never fake or omit them.** When the feature kicks off something slow (a build, a generation, a job), do NOT cut to a pre-baked result and do NOT sit through dead minutes on camera. Keep ONE live session and either **timelapse** the wait or **cut** it (see step 5: `continue` + `speed` or `waitBefore`, with a \"≈ N min later\" title card). Show enough of the start that the viewer sees it genuinely running, then the genuine finished artifact from that same run.\n- **First, look for a demo the project already ships and prefer it** — a demo\u002Ftour\u002Fshowcase route or hash-route, a `demo`\u002F`seed`\u002F`story`\u002F`tour` script in `package.json`, seeded demo data, a Storybook, a README \"Demo\" section, or a flow named in `.walkthrough\u002Fnotes.md`. If one exists, record THAT exact path. Do not synthesize a generic flow that ignores an obvious built-in demo — the user wants to see the real thing working, not a stand-in.\n- **Default to comprehensive, end-to-end coverage — not a teaser.** Demonstrate the actual feature the task delivered, all the way through, with **real data that persists** (create a record → see it in the list → reload → it survived). Walk **every meaningful state**: empty → action → in-progress → populated → verified. Click into each tab, switch a selector and show the result change, scroll the whole table, drive a second flow if the feature has one. There is **no beat cap and no duration cap** — a thorough walkthrough is commonly 10–20+ beats and several minutes, and that is the goal, not something to trim. A video that \"only proves a page renders\" is a failure of this step.\n- **Organize by `folder`, and make MORE videos.** Set the storyboard's `folder` to the feature area (e.g. `\"model-router\"`, `\"improver\"`, `\"runtime\u002Fcodex\"`). When a topic is broad, record **several focused videos into the same folder** — one clear flow each — rather than one shallow video that skims everything. The gallery groups by `\u003Cproject> \u002F \u003Cfolder>`.\n- **Hold long enough to read.** `hold` defaults to 3200 ms; for dense screens (policy tables, populated lists, JSON output) set `hold` to 4000–6000 so the viewer can actually absorb it. Long single browser segments are fine (up to 600 s; override with `runTimeoutMs`) and read as one real session.\n- In each video include, where the feature allows: a real click, a route\u002Ftab change, a selector change that visibly remaps something, an **evidence panel** proving the live system state (the actual API response, the persisted record in a file, the real server log — captured off-camera, proving line highlighted), and a full e2e flow ending in an asserted\u002Fhighlighted result. Add an intro title card (`reflectFlag: true`) and an outro.\n- **When the proof IS the network traffic** (server-side pagination, a persist POST, a route re-targeting a backend) and the user wants to \"see the network \u002F network tab\", a viewport recording can't show DevTools — attach a browser-segment **`networkPanel`** instead: a live top-right HUD that re-paints each matching `request`\u002F`response` (page\u002Fsize → status\u002Frows) from the real Playwright events. See `references\u002Fstoryboard-schema.md` → \"Network panel\". This is the supported fallback for network-tab requests.\n- **CRITICAL: no terminals, no test runners on camera.** Never record a shell or typing; show a rendered `evidence` panel (off-camera capture, proving line highlighted) instead. And no `npm test`, `vitest`, `jest`, `pytest`, `cargo test`, test output, or CI logs — ever. If the feature can only be \"proven\" by a passing test, ask the user instead of recording the test. The walkthrough must show the feature **visibly doing the thing in the real running app**, not a test passing.\n- Write `storyboard.json` per `references\u002Fstoryboard-schema.md`. For each beat set the exact `caption` and a concrete `expectedScreen` (\"the automations list with a New automation button\") — these become the vision assertions.\n- Order beats so pages that embed a **cross-origin iframe** (e.g. an embedded terminal pane) land last — the caption HUD can intermittently render as an empty gray strip on those pages, and sequencing them last keeps every earlier caption clean.\n- **Settle every freshly-loaded page BEFORE its first caption beat.** On a page that is still loading, the caption HUD can miss the first beat entirely, and fixed-wait beats tend to capture loading states (spinners, skeletons) instead of the ready page. Make a settle action the storyboard default: start each freshly-loaded page with a `waitFor` on a selector that only exists once the page is ready, and only then run the first captioned beat. Prefer selector waits over fixed waits throughout.\n- **Pages with persistent WebSocket connections** (WS-action pages, live-stream views, chat panels) are unreliable recording targets: the open WS connection defeats the between-beat `networkidle` settle, causing empty-output crashes or >120 s hangs. Workaround: pre-seed any needed state via API\u002FHTTP before the recording (avoid WS-action beats entirely where possible), or accept the committed e2e as the gate for WS-heavy flows and record only the HTTP\u002Fstatic surfaces of the same feature.\n\n### 5. Record\n`node scripts\u002Frecord.mjs \u003Cstoryboard.json>` → prints `{ runDir, final, beats, flagged }` and writes `manifest.json` (measured beat→timestamp map) + `pass-record.json`.\n- **Concurrent runs are isolated automatically.** Each run gets its own private playwright-cli daemon namespace (derived from its run dir), so you can record from several sessions\u002Fprojects at once without them tearing down each other's browser. You do not set anything — no `WALKTHROUGH_PW_SESSION`, no `kill-all`. (Never run `playwright-cli kill-all` during a recording: it is machine-wide and will kill every concurrent run's browser.)\n- The recorder automatically shows a **visible cursor + click pulse** at every click\u002Ffill\u002Fhover and **scrolls each target into view before highlighting it** — so the video reads as a real user session and the \"verified result\" box always lands ON the element, never off-screen. You do not author these; do not add them to the storyboard.\n- **Long operations, kept honest in ONE live session** (full schema in `references\u002Fstoryboard-schema.md`):\n  - `continue: true` on a browser segment **reuses the session the previous segment left open** — same page, same live state — so an operation kicked off earlier is still running. (The first segment can't `continue`.)\n  - **Timelapse** the wait: a `continue` segment with `speed: 8` records the real progress, then compresses it 8× (offsets are scaled, so the manifest stays accurate). Pair with a beat `holdUntil: { selector }` that keeps the \"Building…\" caption rolling until the completion signal appears.\n  - **Cut** the wait: a `continue` segment with `waitBefore: { selector }` waits for completion OFF-camera (unrecorded), then rolls on the finished result. Bridge the jump with a `title` card like `\"≈ 3 minutes later\"`.\n  - Bump `runTimeoutMs` (and the `waitFor`\u002F`holdUntil` `timeout`) above the real operation time for genuinely long builds.\n\n### 6. Extract frames + VISION-VERIFY (the gate — do not skip)\n`node scripts\u002Fextract_frames.mjs \u003CrunDir>` → one frame per beat at its measured midpoint (`frames\u002Findex.json` lists each frame with its `expectCaption`\u002F`expectScreen`).\n\nThen **Read every beat frame** and assert, per beat, concretely:\n- the caption reads exactly `expectCaption` and is legible, AND\n- the screen matches `expectScreen` (name the specific thing you see — \"the automations list with a New automation button\", not \"looks right\").\n- for `expectFailure` beats: confirm the failure is shown distinctly (red \"FAILED\" caption) and the run is flagged. A correctly-shown failure **passes** — do not try to \"repair\" it.\n\nOn any mismatch: identify the failing beat, diagnose the cause (caption text, a missing `waitFor`, a wrong selector, an unsettled animation, timing), fix the storyboard, **re-record**, re-extract, re-verify. Add `--interval` on a re-run if you need frames between beats to localize a problem.\n\n**Retry ceiling**: max 3 attempts on the same beat, max 6 re-records total (shared with step 7). If still failing, STOP — write `STUCK.md` in the runDir with the failing frame path, the expected vs. observed, and what you tried, and ask the user. Never hand over while any expected caption or screen is unverified, and never fake success.\n\nWhen all beats pass, proceed to the holistic gate (step 7) — **do not set `verifiedAt` yet.**\n\n### 7. Holistic video review — the SECOND gate (claude-video; do not skip)\nThe per-beat gate proves each frame is right; it cannot tell whether the **whole video shows the real feature end-to-end** (the step-4 arc). This gate does — by actually watching the finished video.\n\n`node scripts\u002Freview_video.mjs \u003CrunDir>` → locates claude-video, ingests `final.mp4` (silent → `--no-whisper`) into `\u003CrunDir>\u002Fwatch\u002F`, and prints a strict 5-point rubric plus the frames the tool produced.\n\nThen **Read those frames in order and answer the rubric**: does the video show the real starting point, the action, it actually running, the REAL result, and (where it applies) a follow-up change? What essential part of the story is missing or only implied? Any dead\u002Fblank\u002Fbroken stretches or success-faked failures?\n- **PASS** only if a developer who never saw this feature would, from this video alone, understand what it does and see it genuinely working end-to-end.\n- **FAIL** → treat it exactly like a failed beat: name the gap (a missing arc step, a skipped payoff, an unshown follow-up change, a dead stretch), **re-plan the storyboard** (add\u002Fextend the flow — often a `continue` result\u002Fchange segment or a long-op timelapse), **re-record, re-verify both gates.** Same retry ceiling as step 6.\n\nOnly when BOTH gates pass, set `verifiedAt` (ISO timestamp) in `pass-record.json`.\n\n### 8. Publish\nEnsure the gallery server is running: `node scripts\u002Fserve.mjs` (binds to the Tailscale IP, supports range\u002Fscrubbing). It prints `{ url }`. The gallery is a single page: it groups runs by `\u003Cproject> \u002F \u003Cfolder>`, shows real video thumbnails (ffmpeg, cached as `thumb.jpg` per run) with formatted dates, and supports live **search**, **sort**, project\u002Fstatus **filters**, and a group toggle. Clicking any card opens an **in-page fullscreen player** — navigate between videos with the on-screen arrows, the **keyboard arrows**, or a **swipe**, jump around with **chapter markers** built from the beat captions, and download from the same view. Give the user that gallery URL (newest folder first) — or the direct `http:\u002F\u002F\u003Ctailscale-ip>:8099\u002F\u003Cproject>\u002F\u003Cfolder>\u002F\u003Ctimestamp>\u002Ffinal.mp4` (no `\u003Cfolder>` segment for an ungrouped run; direct links still work as before). Confirm range works locally if unsure: `curl -s -D- -o \u002Fdev\u002Fnull -H 'Range: bytes=0-99' \u003Curl>` → expect `206 Partial Content`. Optional HTTPS upgrade: `tailscale serve --bg \u003Cport>`. When you record several videos, give the gallery URL once and list each video's direct link under its folder.\n\n### 9. Learn\nIf the user corrects flow choice, captions, or what to show\u002Favoid, **append a dated bullet to `.walkthrough\u002Fnotes.md`**. Flow selection is the part that improves with use — say so in your handover.\n\n## Evidence mode (`mode: evidence`)\nEvidence mode records lean, per-criterion proof for an automated gate — not a story. It **keeps every honesty rule and every mechanic** and overrides only what is named here; the marketing default (all of **Workflow** above) is unchanged.\n\n- **Storyboard derives from the slice's ACCEPTANCE CRITERIA, not a story arc** — **one beat per acceptance criterion**, plus the minimal navigation needed to reach each. Step 4's \"tell the feature's REAL story, end-to-end\" **does not apply**: there is **no comprehensive-arc mandate**, **no intro\u002Foutro title cards**, and **no \"make MORE videos\" \u002F several-focused-videos guidance** — one criterion, one beat.\n- **Short holds, terse captions.** `hold` defaults to **1200 ms** (dense screens **2000 ms**), not 3200–6000. Each caption is **terse — the criterion id plus a short phrase** (e.g. `AC-3 — record persists after reload`).\n- **Kept UNCHANGED — behavior is still the proof.** No test runners on camera (a passing suite is never the evidence); the **`evidence` panels**; the **functional-truth `assert`s** (and an evidence panel's `highlight.match`); the **visible cursor + click pulse, settle-before-caption, and `waitFor`\u002Fselector-wait** mechanics; and the **per-beat vision verification (step 6)**. Evidence mode weakens none of these.\n- **Skip the holistic claude-video gate (step 7).** Evidence does not need storytelling verification — **per-beat vision (step 6) plus the inline functional asserts ARE the gate.** (Marketing mode KEEPS both gates.)\n- **Retry ceiling: 1 re-record** (not 6). If, after that single re-record, a beat still fails on a **caption\u002Flegibility** ground **while its functional `assert` PASSED**, do NOT keep chasing polish — record the video as **`evidence-degraded`** in `notes.md`\u002Fstatus with the reason. An honest degraded artifact beats six re-records over legibility. (A failed functional `assert` is still a real failure — render it honestly per **Honesty**, never faked green.)\n- **Emit `evidence.json` next to the video** — an array of `{ beat, criterionId, timestamp, assert, result }`, one entry per beat, referenced from the gate-status \u002F evidence-index so a reviewer verifies each criterion **against the JSON without watching the video**.\n- **Long operations carried as-is** — the `continue` \u002F `speed` \u002F `waitBefore` timelapse-or-cut machinery from step 5 applies unchanged, with `speed` defaulting **aggressive (8×)**.\n\n## Honesty\nIf something does not work, show it not working (mark that beat `expectFailure: true` → red \"FAILED\" caption) and let the run be flagged in the gallery. Never edit a failing flow into looking like it passed.\n\n## Reference\n- `references\u002Fstoryboard-schema.md` — full storyboard\u002Fconfig\u002Fnotes schema, segment types, selector language, manifest shape.\n- `references\u002Fdecisions.md` — the tool bake-off and why each choice was made (and its limits).\n",{"name":5,"description":7},"main","31458d7e0e08a7b3494c27bf2b912ed41c87a138","fittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough",0,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison","https:\u002F\u002Fgongiskhan.github.io\u002Fagent-garrison\u002F","https:\u002F\u002Fgithub.com\u002Fgongiskhan","2026-11-07 05:27:23",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add gongiskhan\u002Fagent-garrison --skill walkthrough",{"tool":61,"command":62},"bunx","bunx skills add gongiskhan\u002Fagent-garrison --skill walkthrough",{"tool":64,"command":65},"pnpm","pnpm dlx skills add gongiskhan\u002Fagent-garrison --skill walkthrough","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002FSKILL.md",true,[69,75,81,85,91,95,99,103,107,111,115,119,123,127,131],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"logs\u002Fsecurity\u002F.security-key","OTHER","其他",32,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Flogs\u002Fsecurity\u002F.security-key",{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fdecisions.md","REFERENCE","参考文档",11532,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Freferences\u002Fdecisions.md",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fstoryboard-schema.md",21431,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Freferences\u002Fstoryboard-schema.md",{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"scripts\u002Fextract_frames.mjs","SCRIPT","脚本",2390,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Fextract_frames.mjs",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"scripts\u002Fgallery.html",24094,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Fgallery.html",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"scripts\u002Flib\u002Fbrowser.mjs",26831,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Flib\u002Fbrowser.mjs",{"path":100,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":101,"sourceHtmlUrl":102},"scripts\u002Flib\u002Fevidence.mjs",9545,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Flib\u002Fevidence.mjs",{"path":104,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":105,"sourceHtmlUrl":106},"scripts\u002Flib\u002Fffmpeg.mjs",2701,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Flib\u002Fffmpeg.mjs",{"path":108,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":109,"sourceHtmlUrl":110},"scripts\u002Flib\u002Frender.mjs",8211,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Flib\u002Frender.mjs",{"path":112,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":113,"sourceHtmlUrl":114},"scripts\u002Flib\u002Fstyle.mjs",2012,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Flib\u002Fstyle.mjs",{"path":116,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":117,"sourceHtmlUrl":118},"scripts\u002Flib\u002Futil.mjs",5830,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Flib\u002Futil.mjs",{"path":120,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":121,"sourceHtmlUrl":122},"scripts\u002Fpreflight.sh",3159,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Fpreflight.sh",{"path":124,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":125,"sourceHtmlUrl":126},"scripts\u002Frecord.mjs",13808,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Frecord.mjs",{"path":128,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":129,"sourceHtmlUrl":130},"scripts\u002Freview_video.mjs",6507,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Freview_video.mjs",{"path":132,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":133,"sourceHtmlUrl":134},"scripts\u002Fserve.mjs",9703,"https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Fwalkthrough\u002F.apm\u002Fskills\u002Fwalkthrough\u002Fscripts\u002Fserve.mjs",[136,148,158,169,181,194],{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":142,"publishedAt":42},"01M71RTFA0HD83YBE1TE7DCE6B","pinned-helper","An owned skill the human has pinned so the Improver must not touch it.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fimprover\u002Fskills\u002Fpinned-helper\u002FSKILL.md",[],[143,144,145,146,147],"pinned helper","helper","it","touch","human",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":42},"01M71RTDKBG0WQHPHKFZKFWDHF","legacy-helper","A rarely used helper kept around from an earlier workflow.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fimprover\u002Fskills\u002Flegacy-helper\u002FSKILL.md",[],[155,144,156,157],"legacy helper","Legacy","workflow",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":42},"01M71RTCC6ZVVJ9MHHESXPHWA6","human-notes","A human-authored skill not deployed by APM (loose, not in the lock).","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fimprover\u002Fskills\u002Fhuman-notes\u002FSKILL.md",[],[165,147,166,167,168],"human notes","notes","lock","apm",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":42},"01M71RTB83ZP6VK6XH19Z93FAC","garrison-helper","Helps compose and station Garrison Fittings into Faculty role slots.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fimprover\u002Fskills\u002Fgarrison-helper\u002FSKILL.md",[],[176,177,144,178,179,180],"garrison helper","garrison","role","compose","slots",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":42},"01M71RT54T0SQS42XEP5FVQ28K","Trello","Manage tasks via Trello REST API.","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Ftrello\u002F.apm\u002Fskills\u002Ftrello\u002FSKILL.md",[],[188,189,190,38,191,192,193],"trello","tasks","REST","manage","rest api","via",{"skillNo":195,"name":196,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":42},"01M71RT4APFW8F1ZN3X4BDN1HE","tier-classifier","https:\u002F\u002Fgithub.com\u002Fgongiskhan\u002Fagent-garrison\u002Fblob\u002Fmain\u002Ffittings\u002Fseed\u002Ftier-classifier\u002F.apm\u002Fskills\u002Ftier-classifier\u002FSKILL.md",[],[200,201],"classifier","tier classifier"]