slide-target

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 <deck> <variant> <slot> — fully explicit, e.g. /slide-target rural-income v1 02.
• /slide-target <slot> — infer <deck>/<variant> from the most recently discussed deck in the conversation (confirm if ambiguous).
• /slide-target (no args) — Tier-1 bridge: if <client-root>/.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="<NN>"' <root>/src | xargs grep -l 'data-variant="<variant>"'
   

   This finds the file whether the deck uses standalone section components (e.g. reach: src/layouts/sections/<deck>/T<NN>-*.astro) or inline <section>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/<variant>/<slot>-<slug>.astro.
2. Slot registry entry. In src/data/slides.ts, SLOTS["<variant>"] → the entry with slot === "<NN>" (its title, slug).
3. Deck registry entry. In src/data/decks.ts, the deck <deck> and the variant <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/<deck>/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 "<deck>/<variant>/<NN>" → {scroll, play} status (urgent-redo / could-be-better / passable / perfect / pending).
6. Live URLs. Scroll: /scroll/<deck>/<variant> (jump with #s-<N> where N is the 1-based section index). Play (if the per-slide file exists): /play/<deck>/<variant>/<slot>. TOC: /toc/<deck>/<variant>.
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.