# Onboarding > Get oriented in the pardes marketplace and tune the user's Claude Code setup. Explains what each plugin does and how they compose, then runs an advisory config doctor that reports recommended settings and applies them only on explicit confirmation. Use when a user is new to the marketplace, asks what these plugins do or how to get set up, or wants their config checked. - **Type:** Skill - **Install:** `agentstack add skill-shivaedev-pardes-onboarding` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [ShivaeDev](https://agentstack.voostack.com/s/shivaedev) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [ShivaeDev](https://github.com/ShivaeDev) - **Source:** https://github.com/ShivaeDev/pardes/tree/main/plugins/onboarding/skills/onboarding ## Install ```sh agentstack add skill-shivaedev-pardes-onboarding ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # onboarding You are helping a user get oriented in the **pardes** marketplace and tune their Claude Code setup. This skill has two halves: **orient** (explain what's here and how it fits together) and **doctor** (check their config and, only if they say yes, apply recommended settings). Do the orientation first, then offer the doctor — don't run the doctor unprompted unless the user clearly asked for a config check. ## Half 1 — Orient the user Pardes is a small marketplace of focused Claude Code plugins. Most ship one skill; a few ship other artifacts instead (shared infrastructure, a status line, workflow scripts). Explain the pieces in plain terms and, importantly, **how they compose** — the value is in the combination: - **base** — a foundational scaffold; shared hooks and core skills land here as the marketplace grows. Nothing else depends on it yet, so install it only if you want the scaffold present. - **orchestrate** — plans one large multi-chunk PR through a short interview, then ships it by dispatching focused sub-agents one chunk at a time. Reach for it when a single PR is too big for one context but is sequenceable into discrete commits. - **shift-leader** — the standing autonomous orchestrator *above* a single PR: it runs a multi-PR / multi-agent effort, dispatches file-disjoint work to parallel worktrees, gates dependent work on merges (never merging itself), opens and monitors each PR, and survives compaction via a durable state file. It uses `orchestrate` (if present) to plan+ship each individual large PR. - **shell-helpers** — dependency-free shell helpers that the orchestration skills lean on: freshen a checkout to a clean baseline, prune merged branches, reap stale worktrees. Available both as PATH commands and as sourceable shell functions. - **pr-description** — writes a tight PR description (Why / How / Decisions / Callouts, no filler). Pairs naturally with `orchestrate` and `shift-leader` when a PR is ready to open. - **statusline** — a rich multi-line status line: model, context-pressure bar, cost, git, PR, and rate limits on the main line, plus per-subagent gauges in the agent panel. Most useful precisely when `shift-leader` has several sub-agents running — you can watch each one's context pressure. - **workflows** — a starter library of Workflow-tool scripts — writer→reviewer, read-only investigation, parallel-edit-then-serialized-verify — each callable as `workflows:`. They're the concrete orchestration moves the higher-level skills lean on, ready to run or fork. The composition story to convey: **shift-leader** is the conductor, **orchestrate** plans+ships each big PR under it, **workflows** supplies the reusable orchestration moves they run (writer→reviewer, investigation, parallel-verify), **shell-helpers** keeps the worktrees and branches clean, **pr-description** writes the PRs, and **statusline** lets the user see it all happening. A user new to the marketplace usually wants whichever of those match their workflow. If a user simply wants the whole set, mention **pardes-all** — a meta plugin with no skill of its own that just depends on every other plugin, so a single install pulls in the entire marketplace at once. It's the "give me everything" option for someone who doesn't want to pick à la carte. (The human-facing README has the exact install command; point them there rather than reciting it.) When you mention any sibling skill, treat it as **optional and possibly-installed**: if the skill is available in this session, suggest invoking it directly; if it isn't, describe what it does and point the user at installing that plugin from the marketplace (the human-facing README has the exact install commands — don't paste install commands into your own reasoning here). Tailor the orientation to what the user actually asked. If they just said "what is this / help me get started," give the short tour above and then move to the doctor. If they asked about a specific plugin, lead with that one and how it composes with the rest. ## Half 2 — Run the config doctor The doctor is a dependency-free script that compares the user's `~/.claude/settings.json` against a manifest of **recommended** (never required) settings tuned for this marketplace's orchestration-heavy style. It is **advisory by default** and only writes anything on an explicit `--apply` run, after a backup, and only for keys that are currently missing. ### Step 1 — Advisory report (always safe; read-only) Run the report. It only reads settings; it changes nothing. ```bash bun "${CLAUDE_PLUGIN_ROOT}/scripts/doctor.ts" ``` The report marks each recommended key as **set** (already matches), **missing** (absent — an apply would add it), or **differs** (present but holds a different value — the doctor will never overwrite it). It also lists a couple of intents (workflows-enabled-by-default, agent view) that have no stable settings key, so the doctor describes them but cannot apply them. Read the report back to the user in plain language: what's already good, what's missing, and for anything that differs, note that the doctor leaves their choice alone. ### Step 2 — Offer to apply, and get explicit confirmation If anything is **missing**, offer to apply *only* the missing recommendations. This is a genuine choice — use the question tool / ask the user directly. **Never apply without an explicit yes.** Make clear that: - it adds **only the missing keys** — it never overwrites a value they already set (the "differs" entries stay theirs), - it writes a **timestamped backup** of `settings.json` first, - it touches **no unrelated keys**, and - it prints exactly what it changed. Only after the user explicitly confirms, run: ```bash bun "${CLAUDE_PLUGIN_ROOT}/scripts/doctor.ts" --apply ``` Then report back exactly what the doctor said it changed, and where the backup was written. If the user wants to undo it, the change is reversible by restoring that backup or removing the added keys. If nothing is missing, tell the user their config already matches the recommendations and skip the apply. ### Notes - The settings path can be overridden with `--settings ` or the `DOCTOR_SETTINGS_PATH` env var. That's mainly for testing against a sample file — for a real user, leave it at the default (`~/.claude/settings.json`). - If the doctor reports the settings file is unparseable, do **not** try to apply. Tell the user to fix or remove the file first; never let an apply run against a file the doctor couldn't parse. - Recommended values are intentionally generic. If a user has a deliberately different value (e.g. a different model or effort level), that's fine — respect it; the "differs" status exists exactly so the doctor reports without nagging or overwriting. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [ShivaeDev](https://github.com/ShivaeDev) - **Source:** [ShivaeDev/pardes](https://github.com/ShivaeDev/pardes) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-shivaedev-pardes-onboarding - Seller: https://agentstack.voostack.com/s/shivaedev - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.