Slide target

Skill lossless-group/lossless-agent-skills/slide-target

Pi & Agent-Skills-standard skills used by The Lossless Group. Starting with context-vigilance.

Install

npx -y skills add lossless-group/lossless-agent-skills --skill slide-target

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

6.0 KB, as published. Nobody here has run it

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).

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.
Slot registry entry. In src/data/slides.ts, SLOTS["<variant>"] → the entry with slot === "<NN>" (its title, slug).
Deck registry entry. In src/data/decks.ts, the deck <deck> and the variant <variant> (title, label, status, lede).
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.
Rank / audit status. In data/audits/slides.json, the key "<deck>/<variant>/<NN>" → {scroll, play} status (urgent-redo / could-be-better / passable / perfect / pending).
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>.
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.