code-to-pantry
Extract a code pattern from the current codebase into Nathan's pantry repo as a reusable recipe. Use when Nathan says 'add to pantry', 'save this code pattern', or wants to preserve a technique for reuse.
What this skill does
# Code to pantry Nathan's pantry (`github.com/nweii/pantry`) is a personal collection of modular, self-contained code recipes. The goal is to capture the *technique*, stripped of its original context, in a form that can be dropped into any future project without modification. ## What makes a good pantry entry A pantry entry should be: - **Truly abstracted**: no variable names, imports, comments, or usage examples that reference the source project. Someone reading the component cold should have no idea where it came from. - **Self-contained**: all logic lives in one file; external dependencies are minimal and explicit - **Opinionated defaults**: parameterized just enough for useful variation, with sensible defaults that work out of the box without configuration - **Named for the technique**, not the use case (e.g., `grain`, not `background-texture`) ## Step 1: Understand what to extract Read the code the user is pointing at. If they haven't pointed at specific code, ask them to identify it. Then identify: - **The core technique**: what is the conceptual pattern, independent of the surrounding application? - **App-specific shell**: what parts are wired to this specific app's state, routing, styling system, or data model? - **The stack**: what language/framework is this? (React/TSX, plain JS/TS, CSS, Python, etc.) ## Step 2: Design the abstraction — discuss before writing Propose an abstraction plan and get Nathan's approval before writing any files. Cover: 1. **Name**: a short, lowercase, hyphenated identifier for the technique (this becomes the filename) 2. **What gets extracted**: the essential mechanism, described in one sentence 3. **What gets dropped**: app-specific assumptions, hardcoded values that don't generalize, framework boilerplate that isn't part of the technique 4. **Props / API surface**: what parameters make sense to expose? What should be hardcoded defaults? 5. **ABOUTME line**: a single sentence describing what the file does — this becomes the registry description. It must be generic; it cannot reference the source project. 6. **Dependencies**: list any non-trivial imports the extracted code will need If the source code is deeply entangled with app-specific concerns, surface that tension explicitly. Sometimes the right call is to extract a *narrower* slice of the technique rather than trying to abstract everything at once. **Wait for approval before proceeding.** ## Step 3: Write the pantry entry ### Finding the pantry repo Try these in order until one works: 1. Check if a local clone exists by searching common developer paths (`~/Developer`, `~/code`, `~/projects`, etc.) for a directory named `pantry` with a `registry.json` 2. Use `gh repo clone nweii/pantry` to clone it to a temporary location 3. Use any available GitHub MCP/plugin tools to write files directly to the repo Once you have local access, write to `src/<name>.<ext>` where `<ext>` matches the stack. ### File conventions (all stacks) - **First line**: `// ABOUTME: <one-sentence description of what this file does>` (use `#` for Python) - The ABOUTME description must be generic — no references to the source project, app name, or context - No inline comments that reference the source project or why the code was originally written - Usage examples in comments must use placeholder/generic names (`<MyComponent />`, `<div className="relative">`, etc.) ### React/TSX conventions - Named exports only (no default exports) - Props interface above the component - All props optional with sensible defaults - No dependencies beyond `react` (peer dep) - Use `useId()` (React 18+) for any internally-generated IDs ### Non-React conventions Match the idioms of the target language. For plain TypeScript/JavaScript utilities: export named functions. For CSS: export as a standalone file with a usage comment at the top. For other languages/frameworks, use the standard module export pattern for that ecosystem. ### Pantry-specific: the pre-commit hook The pantry uses a pre-commit hook (`scripts/sync.js`) that auto-generates `registry.json` and `src/index.ts`. Do not edit those files manually — just commit and the hook handles them. ## Step 4: Commit and push From the pantry repo directory: ```bash git add src/<name>.<ext> git commit -m "add <name>" git push ``` The pre-commit hook will stage `registry.json` and `src/index.ts` automatically as part of the commit. Confirm to Nathan that the component is live and available via: ```bash bunx github:nweii/pantry add <name> ``` ## Common pitfalls - **Over-abstracting**: don't try to make something configurable that will always be the same. The right amount of parameterization is what the technique actually needs. - **Under-abstracting**: don't leave in hardcoded values that only make sense in the source app's context. - **Naming for the use case**: if you find yourself naming it after what the source app does with it, step back and name it for what the technique *is*. - **Leaking source context**: scan all comments, JSDoc, and example code for any reference to the source project before writing.
Related in General
modeling-omnistudio-epc-catalog
IncludedSalesforce Industries CME EPC product-modeling skill for Product2-based catalog creation. Use when creating EPC products, configuring product attributes, building offer bundles with Product Child Items, or reviewing EPC DataPack JSON metadata for product catalog changes. TRIGGER when: user creates or updates Product2 EPC records, AttributeAssignment payloads, AttributeMetadata/AttributeDefaultValues, Offer bundles, or ProductChildItem relationships. DO NOT TRIGGER when: designing OmniScripts/FlexCards/Integration Procedures (use building-omnistudio-omniscript, building-omnistudio-flexcard, or building-omnistudio-integration-procedure), implementing Apex business logic (use generating-apex), or troubleshooting deployment pipelines (use deploying-metadata).
relationship-science-coach
IncludedUse this skill for direct, practical adult relationship coaching: couples conflict, repair, trust, marriage, dating, flirting, attachment patterns, emotional connection, sex, desire differences, eroticism, kink negotiation, affection, love languages, breakups, and long-term passion. Draw on Gottman, EFT and Hold Me Tight, attachment science, modern sex research, Perel, Nagoski, Kerner, Schnarch, Love and Stosny, and flexible love-language tools. Be concrete and low-hedge. Redirect only for imminent danger, abuse, coercive control, minors, non-consent, self-harm, stalking, or medical/legal/psychiatric decisions.
building-sf-integrations
IncludedSalesforce integration architecture and runtime plumbing with 120-point scoring. Use this skill to set up Named Credentials, External Credentials, External Services, REST/SOAP callout patterns, Platform Events, and Change Data Capture. TRIGGER when: user sets up Named Credentials, External Services, REST/SOAP callouts, Platform Events, CDC, or touches .namedCredential-meta.xml files. DO NOT TRIGGER when: Connected App/OAuth config (use configuring-connected-apps), Apex-only logic (use generating-apex), or data import/export (use handling-sf-data).
venue-templates
IncludedAccess comprehensive LaTeX templates, formatting requirements, and submission guidelines for major scientific publication venues (Nature, Science, PLOS, IEEE, ACM), academic conferences (NeurIPS, ICML, CVPR, CHI), research posters, and grant proposals (NSF, NIH, DOE, DARPA). This skill should be used when preparing manuscripts for journal submission, conference papers, research posters, or grant proposals and need venue-specific formatting requirements and templates.
let-fate-decide
IncludedDraws the 12 Houses of the Zodiac Tarot spread to inject entropy into planning when prompts are vague, ambiguous, or casually delegated. Interprets the spread to guide next steps. Use when the user says 'let fate decide', 'YOLO', 'whatever', 'idk', or other nonchalant phrases, makes Yu-Gi-Oh references, or when you are about to arbitrarily pick between multiple reasonable approaches. Prefer over ask-questions-if-underspecified when the user's tone is casual or playful rather than precision-seeking.
net-ops
IncludedCross-platform network troubleshooting (Windows, macOS, Linux) via local or remote shell. Use for: DNS broken, can't resolve hostnames, nslookup/dig works but apps fail, NRPT, WFP, scutil, /etc/resolver, systemd-resolved, /etc/resolv.conf, NetworkManager, VPN DNS leak residue (ProtonVPN/Mullvad/WireGuard/AnyConnect), AV/firewall blocking DNS or DoH, Tailscale DNS interaction, intermittent connectivity, remote diagnostics over SSH.