Claude Code: Software Development Skills

Look up a spec field on, or diff a failing request against, one named endpoint in a Salesforce API reference published on developer.salesforce.com ("DSC"). Invoke whenever the user's ask is about what one specific endpoint's spec says or why one specific call doesn't match it – OAuth scopes, query params, request body, response schema, auth scheme, HTTP method/path, or a cURL/HTTP request paired with an error body (invalidclient, insufficientscope, 400 missingparameter, 401 AuthenticationFailedException, 415 content-type, etc.). Covers spec-field lookups ("what scopes does shopper-products getProducts need?", "which query params does searchOrders take?", "what auth scheme guards createOrder?"), code-generation asks against a named endpoint ("write me a node script that calls getProduct" – quote the spec; don't write the code), how-to asks that are really spec-field questions ("how do I paginate searchOrders", "what limit does X accept"), and failing-request diagnosis ("why is this 403ing", "diff this against the spec", "what scope is missing"). This is the unified successor to dsc-endpoint-lookup and dsc-triage; prefer it whenever either of those would have fired – the runtime branches internally on whether a failing request is attached. Every claim cited to a public developer.salesforce.com URL. Works against any DSC reference dsc-scrape can deliver. Hands off honestly for errors the spec can't explain (5xx, 404 path-or-resource-missing, 409 conflicts). Decline when no endpoint field is in scope at all: concept or comparison questions without a named endpoint ("what's the difference between OCAPI and SCAPI", "what is SLAS"), parsing a user-supplied local file rather than a DSC reference ("parse my ~/work/foo.json"), scraping whole references wholesale (that's dsc-scrape), multi-call ordering / scenario-building (that's dsc-scenario), and guides / concept pages / atlas-format books / release notes. Also decline questions about what a separate runtime consumer of the response requires – Customer Service Center field dependencies, SFRA hook semantics, "which response fields can my custom hook null out without breaking X" – even when an endpoint is named; the spec describes the endpoint's own input/output, not what other runtimes downstream of the response do with it, so any spec-framed answer would be fabrication.

Look up and quote one spec field on one endpoint in a Salesforce API reference published on developer.salesforce.com ("DSC") – OAuth scopes, query params, request body, response schema, auth scheme, HTTP method/path – by reading JSON that dsc-scrape produced (or producing it on demand). Works against any DSC reference the scraper can deliver. Invoke whenever answering the user's ask requires knowing what one specific endpoint's spec says about one of those fields, even if the user's surface ask is broader: direct spec-field lookups ("what scopes does shopper-products getProducts need?", "which query params does searchOrders take?", "what auth scheme guards createOrder?"), code-generation asks that reference a named endpoint ("write me a node script that calls getProduct" – quote the spec for the user to write the code against; don't write the code yourself), and how-to asks that are really spec-field questions in disguise ("how do I paginate search results", "what limit does X accept" – quote the relevant param; ask which search endpoint if ambiguous). The reference name can be implicit if the endpoint name is unambiguous. Decline when no endpoint field is in scope at all: concept or comparison questions without a named endpoint ("what's the difference between OCAPI and SCAPI", "what is SLAS"), parsing a user-supplied local file rather than a DSC reference ("parse my ~/work/foo.json"), scraping whole references wholesale (that's dsc-scrape), and guides / concept pages / release notes.

Build a multi-call repro plan against a Salesforce API reference published on developer.salesforce.com ("DSC"). Invoke when the user wants to reproduce a customer flow on a sandbox and needs to know which supporting API calls to make, in what order, with which scopes, and how IDs thread through the chain – examples: "repro a registered shopper adding a promo coupon and checking out", "what do I need to call before createOrder", "prerequisites for createOrder" (treat "prerequisites" or "prereqs" of a target op as a multi-call request even if the user says just that word), "build me a scenario around this cURL", "chain of calls to get from X to Y". Accepts an operationId, a natural-language goal, or a sample cURL/HTTP request as the target. Runs a type-graph walk (structural dependencies) and composes a linear plan + runnable cURL block. Every step cited to a public developer.salesforce.com URL. Works against any DSC reference dsc-scrape can deliver. Not for scraping a reference wholesale (that's dsc-scrape), not for answering one-off "what does this endpoint require" lookups like "what scopes does X need" (that's dsc-endpoint-lookup – single-endpoint, no ordering), not for diagnosing why an existing request is failing (that's dsc-triage), and not for authoring a runnable demo/repro script the user will paste into a terminal – even if the subject is a Salesforce API on DSC (that's stepped-demo-script; this skill produces the plan of calls, not the paste-and-run bash).

Scrape developer.salesforce.com (DSC) API reference pages and write structured JSON. Invoke whenever the user asks to scrape, extract, fetch, mirror, capture, discover, or get the contents of any DSC reference URL (anything under /docs/.../references/ or the top-level /docs/apis catalog) -- including "get me the Shopper Products endpoints", "pull the SCAPI reference", "pull an OCAPI reference", "what APIs exist on DSC", "list Commerce Cloud references", "what's under Agentforce", or "scrape this whole API family." Handles the top-level product catalog, product-area reference listings, individual references (OAS 3 YAML, RAML/AMF JSON, Swagger 2 / OCAPI, ReDoc), and single operations in one fetch-based architecture. Not for guides, concept pages, atlas-format books, or release notes -- decline.

Diagnose a failing Salesforce API request against its public spec on developer.salesforce.com ("DSC"). Invoke whenever the user pastes a cURL command, raw HTTP request, or error body (invalidclient, insufficientscope, 400 missingparameter, etc.) from a customer ticket and asks "why is this failing" / "what scope is missing" / "what's wrong with this request." Diffs required vs. provided scopes (decoded from the access token or from a registered client list the user supplies) and required vs. actual request shape (method, params, headers, body schema). Every claim cited to a public developer.salesforce.com URL. Works against any DSC reference dsc-scrape can deliver. Hands off honestly for errors the spec can't explain (5xx, 404 path-or-resource-missing, 409 conflicts). Not for scraping a reference wholesale (that's dsc-scrape), not for answering one-off "what does this endpoint require" questions (that's dsc-endpoint-lookup).

Walk a contributor through forking a GitHub repo they don't own, branching, committing, and opening a PR back to upstream – using gh and git. Invoke when the user wants to contribute to a repo where they lack write access: "I want to make a PR to ", "contribute a fix to ", "fork this and PR up", "open a PR against ", or when they've already cloned an upstream-not-fork and a git push would fail. Handles the four states a contributor can be in (no clone yet / cloned upstream directly / fork already exists locally / fork exists on GitHub but not cloned), forks via gh repo fork --clone --remote so origin and upstream are wired correctly, helps name a branch, then PAUSES for the user to make their commits before pushing and opening the PR with gh pr create. Not for: pushing to a repo the user already owns (no fork needed – just git push + gh pr create); diagnosing 403s from missing SAML SSO grants on gh tokens (one-time per org, not part of the per-PR flow – tell the user to grant SSO at github.com/settings/tokens and retry); resolving merge conflicts; multi-PR / stacked-diff workflows.

Author a self-contained bash script that walks a human through a multi-step demo – pausing between steps so they can read output before proceeding, and asserting expected vs. actual so pass/fail is visible at a glance. Use whenever the user wants a runnable repro, walkthrough, or demonstration with discrete steps: reproducing a bug on a sandbox, showing off correct behavior of an API, narrating a CLI flow, making a script an engineer or a stakeholder can paste into a terminal and run top-to-bottom. Phrases that should trigger: "repro script", "demo script", "case script", "walkthrough", "step-through", "show me the steps", "script I can run to demonstrate", "paste-and-run", "script I can share", "script they can run themselves", "reproduction for the team", "whip one up". This skill owns the authoring step even when the subject is a specific product/API (SCAPI, cQuotient/Einstein, GitHub, kubectl, git) – if the output is "a script" and the verb is "write/make/draft/build/generate", this is the right skill. For Salesforce-specific scenario planning without writing a script (e.g. "what do I need to call before createOrder", "prereqs for addItemToBasket"), use dsc-scenario instead. Not for: non-interactive pipelines (CI, one-shot batch jobs) – those shouldn't pause for human input. Not for: generating the domain-specific payloads themselves (API bodies, SQL, etc.) – that's the user's content; this skill authors the scaffolding around it.