From rendr-forge-skills
One-time per-repo setup for the deslop pipeline, normally invoked by /deslop as step 0 (skipped if STACK.md already exists). Interviews the user about their stack (auth, payments, backend style, database, secrets, ops); detecting what it can from the repo first; and generates a STACK.md house overlay that the audit skills read. Triggered automatically by /deslop on first use in a repo; invoke directly when the user's stack has changed (switched auth provider, payment processor, framework, database) and STACK.md needs regenerating.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rendr-forge-skills:setup-deslopThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate this project's `STACK.md`: the house overlay that tells the stack-agnostic audit what each category means *here*. Run once per repo (or once per org, if you share a stack). After this, `/map-the-surface`, `/plug-the-holes`, and `/launch-gate` know how to read your codebase.
Generate this project's STACK.md: the house overlay that tells the stack-agnostic audit what each category means here. Run once per repo (or once per org, if you share a stack). After this, /map-the-surface, /plug-the-holes, and /launch-gate know how to read your codebase.
The audit categories are universal; only their instantiation is yours. This skill captures that instantiation once so the audit never has to guess. The thinking behind it (the five questions every mapping answers) is in references/MAPPING-PATTERN.md. The blank it fills is references/STACK-TEMPLATE.md.
Before interviewing, read what the repo already tells you: package.json/lockfile, framework config, schema/migration files, env-var names (names only, never values). Form a hypothesis of the stack and present it: "Looks like an RPC-style backend with a managed auth provider, a single document store, an LLM API for AI features, secrets in env vars. Sound right?" Confirming a good guess is faster and kinder than a blank interrogation.
Work through the five mapping questions (see MAPPING-PATTERN). Ask in plain language, grouped, confirming detections rather than re-asking them. Cover:
Keep it to a handful of grouped exchanges, not 20 separate questions. If the user is unsure on one, mark it Unknown in STACK.md. An honest unknown is a finding the audit will resolve, not a blocker here.
If the interview reveals no single place tenant scoping is enforced (per-handler copy-paste, or worse, missing), propose the seam appropriate to the stack: a requireTenant-style wrapper, a scoped data-access layer, or database row-level security. This is the highest-leverage line in the whole overlay; it's where closing Holes and removing slop become the same edit.
Fill references/STACK-TEMPLATE.md from the answers and write it to the repo root (or .deslop/STACK.md). The template is table-driven, not prose: one row per stack layer, one row per audit category. Each "Audit target" cell is a concrete enumeration the auditor can carry out (e.g. "grep dist/ for non-VITE_ secret names", "enumerate handlers that don't call withOrg(ctx, ...)"). Note any Unknowns explicitly in the Unknowns section — they become things /plug-the-holes resolves rather than guesses.
Show the user the generated STACK.md, let them correct it, then point them at /map-the-surface to begin.
Org shortcut: if a team always ships the same stack, they keep one canonical STACK.md and copy it into each repo instead of re-interviewing. /setup-deslop then becomes "confirm this still matches."
Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub rendr-web/rendr-forge-skills --plugin rendr-forge-skills