--- name: slide-target description: Load the full working context for ONE DidiDecks slide (deck/variant/slot) so an agent can iterate on it slide-by-slide without re-explaining where things live. The first of the `slide-*` skill family (target → improve → rank → decompose). Use whenever the user wants to work on a specific slide of a DidiDecks/Astro deck — "let's work on slide 2", "fix this card", "/slide-target rural-income v1 02", "go slide by slide", "target the funder-pipeline slide" — or when iterating on a client-site deck under dididecks-ai (reach-edu-hub, chroma-decks, etc.). Assembles the section file, the slides.ts slot, the narrative slot, the rank/audit status, the live URLs, and the design-system tokens for exactly that slide, then scopes all work to it. Composes with deck-iteration-workflow and theme-system. --- # slide-target Load everything needed to work on **one slide** of a DidiDecks deck, then keep the work scoped to that slide. This is the agent-side analogue of augment-it's "context broker → ActiveView" pattern: instead of re-describing which slide and where its files live every time, you name the slide once and the skill assembles the **context slab** for it. First of the `slide-*` family. Later siblings (not yet built): `slide-improve` (apply a design pass), `slide-rank` (set the audit status), `slide-decompose` (scaffold the Play-UI counterpart). Designed to be extractable into a publishable "DidiDecks slide skills" library. ## When to use - The user wants to iterate on a specific slide: *"let's do slide 2"*, *"fix the four cards"*, *"work on the funder-pipeline slide"*, *"/slide-target rural-income v1 02"*. - Any slide-by-slide deck iteration under `dididecks-ai/client-sites/*`. ## Invocation forms - `/slide-target ` — fully explicit, e.g. `/slide-target rural-income v1 02`. - `/slide-target ` — infer ``/`` from the most recently discussed deck in the conversation (confirm if ambiguous). - `/slide-target` (no args) — **Tier-1 bridge**: if `/.dididecks/active-slide.json` exists (written by the deck's dev shell as the user scrolls), read `{deck, variant, slot}` from it. If it doesn't exist, ask for the slide. Slot is the zero-padded slot id (`01`, `02`, `09`, `10`…), matching `data-slot`. ## Resolution algorithm — assemble the context slab Run these against the **client-site root** (the nearest ancestor of the cwd that has `src/data/decks.ts`; if the user is in the monorepo root, ask which client). 1. **Section component (the thing you edit).** Grep for the slide's section: ``` grep -rl 'data-slot=""' /src | xargs grep -l 'data-variant=""' ``` This finds the file whether the deck uses standalone section components (e.g. reach: `src/layouts/sections//T-*.astro`) or inline `
`s in the scroll page (e.g. chroma's `src/pages/scroll/.../index.astro`). Also note the Play-UI counterpart if it exists: `src/components/slides//-.astro`. 2. **Slot registry entry.** In `src/data/slides.ts`, `SLOTS[""]` → the entry with `slot === ""` (its `title`, `slug`). 3. **Deck registry entry.** In `src/data/decks.ts`, the deck `` and the variant `` (title, label, status, lede). 4. **Narrative slot (source of truth for content).** If a narrative exists, find the matching slide in it: - strategies: `context-v/narratives/strategies//README.md` - otherwise look under `context-v/narratives/` for the deck's outline. Read the slot's bullet/section so edits stay faithful to the narrative. 5. **Rank / audit status.** In `data/audits/slides.json`, the key `"//"` → `{scroll, play}` status (urgent-redo / could-be-better / passable / perfect / pending). 6. **Live URLs.** Scroll: `/scroll//` (jump with `#s-` where N is the 1-based section index). Play (if the per-slide file exists): `/play///`. TOC: `/toc//`. 7. **Design system (so edits stay on-brand).** `src/styles/deck-primitives.css` (the token-driven section vocabulary) and `src/styles/theme.css` (the Tier-2 semantic + `--fx-*` tokens). Edits should compose these, not hardcode colors. Read items 1, 4, and 7 in full; surface 2/3/5/6 as a compact header so the user sees what's loaded. ## Then: work scoped to the slide - **Stay on this slide.** Only touch the section file from step 1 (and, for a shared fix, `deck-primitives.css`/`theme.css` — but call that out explicitly, since it affects every slide). - **Honor the design system.** Use the `deck-*` primitives and the brand tokens (`--color-*`, `--fx-*`). No per-element `dark:`/`vibrant:` hardcoding — the tokens make all three modes work. If a bug is mode-specific (e.g. dark-mode contrast), reproduce/verify in that mode. - **Stay faithful to the narrative** (step 4). Flag unverified figures with the `deck-verify` marker rather than inventing numbers. - **After editing**, offer to update the rank in `data/audits/slides.json` (or, once `slide-rank` exists, hand off to it) and tell the user the live URL to re-check. ## Notes - Variant slugs are currently **globally unique per client** (the shell keys `SLOTS` by variant alone). If a slot lookup is ambiguous, that constraint was violated — see the dididecks shell limitation note. - The Tier-1 bridge file (`.dididecks/active-slide.json`) is written by the deck dev shell from the SlideRankPill's IntersectionObserver. If it's not there yet, the explicit-args form is the path. ## See also - `deck-iteration-workflow` — the Scroll-UI-first → variant rhythm this scopes into. - `theme-system` / `maintain-design-md` — the token + design-system discipline. - `dididecks-ai/client-sites/reach-edu-hub/context-v/explorations/Deck-Collections-A-Menu-Layer-Above-Single-Deck-Convergence.md` — the deck/variant/collection model. - augment-it `context-v/specs/Chat-Context-Awareness-Architecture.md` — the context-broker pattern this borrows (ActiveView → context slab).