← all publishers

jcdavis131

@jcdavis131 source repo

Report this profile Claim this profile

• 42 skills
• 0 followers
• 16 hours ago last updated

1. ▌
   Prompt Caching · jcdavis131 bundle

   Designs and wires Anthropic prompt caching for Messages API calls — automatic vs explicit breakpoints, prefix ordering, TTL, minimum token thresholds, and cache-invalidation traps. Use when building Claude API integrations, agent loops, multi-turn chats, large tool/system prompts, or when the user mentions prompt caching, cache_control, or cache_read_input_tokens.
   0 installs
2. ▌
   Session Orient · jcdavis131

   Run environmental recon at the start of a coding session before writing any code — disk space, blocker state, target path file count, and queue blockers. Use at session boot, when switching to a new task or target directory, or before any non-trivial change in an unfamiliar area.
   0 installs
3. ▌
   Lane Discipline · jcdavis131

   In a multi-agent fleet, verify a piece of work is in your designated lane before doing it, and state the check out loud. Defer to the owning agent when the work belongs to another lane. Use whenever the repo has documented agent/team role boundaries (AGENTS.md, .cursor/rules/, .claude/TEAM.md, fleet-team rules) and the task touches a shared area.
   0 installs
4. ▌
   Agent Guardrails · jcdavis131

   Give every autonomous agent three guardrails — a per-team allowlist (what it can do), bounded loops (can't run forever), and full transcripts (auditable). Use when building an autonomous agent, a recurring agent loop, or any agent that runs without per-step human approval.
   0 installs
5. ▌
   Follow Procedure · jcdavis131

   When a documented, named procedure exists for the decision at hand (a dataviz palette procedure, a commit-message convention, a deploy checklist, a spec, an ADR), cite it by name and follow it rather than improvising. Use whenever a written procedure, spec, checklist, ADR, or convention applies to the current decision — especially in spec-driven repos.
   0 installs
6. ▌
   Policy As Config · jcdavis131

   Encode policy — consent mechanisms, data flow, allowlists, retention, feature gates — as config/data rather than hardcoded, so it's auditable, grep-able, and changeable without a code edit. Use when adding a consent flow, a data-sharing path, a feature allowlist, a retention rule, or any policy that compliance/product may need to inspect or change.
   0 installs
7. ▌
   Readiness Report · jcdavis131 bundle

   Delivers a structured production-readiness handoff — numbered items needing operator input, each classified pre-existing vs introduced and tagged with repo issue IDs, plus exact verification commands. Use when a multi-task build is ready for operator review, before a deploy gate, or when decisions are the operator's to make.
   0 installs
8. ▌
   Cost Transparency · jcdavis131

   Surface the real cost (wall-clock time and tokens/context) of long-running steps so the user can spot a runaway step and the agent can self-calibrate. Use when a step takes materially longer than a typical edit — a long build, a long test run, a multi-minute wiring task, a heavy generation.
   0 installs
9. ▌
   Event Driven Wait · jcdavis131 bundle

   When waiting on a specific observable event — a file appearing, a log line matching, a git ref advancing, a directory growing, a port opening — arm a watcher that wakes on that event instead of polling on a timer. Use when the wait condition is observable as a filesystem, log, or ref change, especially for long waits where blind polling wastes tokens and can miss the moment.
   0 installs
10. ▌
    Match Conventions · jcdavis131

    Read one or two sibling files in the same area before writing a new file, so the new file matches the codebase's existing imports, component shape, data-fetching style, and folder structure. Use before creating any new file in an existing area of the codebase — a new page, component, route handler, test, service module, or config — especially when a similar file already exists nearby.
    0 installs
11. ▌
    Persist Learnings · jcdavis131

    During wait windows (long installs, builds, tests, deploys), save durable session learnings to memory files so the next session inherits them. Treat memory as a first-class session artifact, not optional notes. Use whenever a wait window opens and you have fresh, reusable learnings in context — a gotcha, a working command, a corrected assumption, a decision rationale.
    0 installs
12. ▌
    Post Deploy Smoke · jcdavis131

    After a deploy, confirm the live URL actually serves the expected content (not just that the API returned 200) by polling it with a bounded retry loop that greps for an expected string per URL. Use after any deploy to verify propagation, after a rebrand/rename to confirm the new content is live, or before telling the user a deploy is "done".
    0 installs
13. ▌
    Respect The Guard · jcdavis131 bundle

    When blocked by a safety guard (push-to-main protection, destructive-command confirm, permission boundary, failed eval gate), uses the legitimate path instead of bypassing — and surfaces exactly how the operator relaxes the guard if desired. Use when a guard stops the fast path, when tempted to use --no-verify or --force, when a deploy script offers only an exec variant, or when input/API limits apply.
    0 installs
14. ▌
    Use Design System · jcdavis131 bundle

    Uses shared UI package primitives instead of hand-rolled markup, greps the source to verify class and component names, and sets page metadata on every page. Use when authoring UI in a repo with a shared UI package (e.g. @synthaembed/ui-fleet), when adding pages or components, or when unsure of a design token or class name.
    0 installs
15. ▌
    Dependency Hygiene · jcdavis131

    Keep heavy, pin-pulling adapters out of a project's universal lockfile by declaring them as opt-in extras installed only where needed. Use when adding a dependency with heavy or conflicting transitive pins (LLM libs, PDF/OCR libs, ML frameworks), when a shared environment must stay coherent for training/inference, or when an adapter is only needed by one workspace.
    0 installs
16. ▌
    Pre Commit Hygiene · jcdavis131

    Before a large or migration commit, exclude junk (build output, local tool dirs, node_modules) and scan for secrets and sensitive files so they don't enter history. Use before any commit that spans many files or a migration, before `git add`, and whenever the user says "never commit secrets" or "let's push this".
    0 installs
17. ▌
    Silent Op Recovery · jcdavis131 bundle

    When a long-running command goes silent, checks interim progress first, then kills by recorded PID and restarts with a visible-output reporter plus a bounded tail. Use when install, build, test, deploy, or fetch stops producing output longer than expected and hang vs slow progress is unclear.
    0 installs
18. ▌
    Conservative Rename · jcdavis131

    When applying a brand or name rename across a codebase, replaces paths and ids only — never blanket word replaces — and cleans up unused imports in the same phase. Use when rebranding sites, agents, or products where the old name could appear in unrelated prose (hub, cursor, control).
    0 installs
19. ▌
    Correct Assumptions · jcdavis131

    When live recon contradicts a prior assumption or a documented blocker, trust the live evidence, state the correction explicitly with the evidence, and update your plan. Use whenever you discover the environment differs from what you (or the docs, or the task notes) assumed — a service that's actually running, a port that's actually open, a blocker that's actually resolved, a dependency that's actually installed.
    0 installs
20. ▌
    Document Non Action · jcdavis131

    When you deliberately choose not to do something that looks like it would be part of the task, state the non-action and its rationale explicitly so it isn't read as an oversight. Use whenever you skip a plausible-looking step on purpose — a file you didn't edit, a feature you didn't wire, an existing issue you didn't rework, a test you didn't add — because of a real constraint or a lane/spec boundary.
    0 installs
21. ▌
    Logical Commit Split · jcdavis131

    Split a large migration or multi-concern change into logical commits grouped by concern, on a branch whose name encodes the commit story, rather than one giant commit. Use when a change spans multiple distinct concerns (infra + data + UI, baseline + feature + commerce), when the change would be unreviewable as one commit, or when one slice might need to be reverted independently.
    0 installs
22. ▌
    Monorepo Review Loop · jcdavis131 bundle

    A recurring review workflow that walks a monorepo through a fixed arc — orient, plan, fan out reviewers, review code, run gates, check guards, align metadata, deploy+smoke, close out — using the 39 codified skills as the steps. Use to continuously update and refine a detailed monorepo so "done" is unambiguous, every claim is auditable, and docs/registry/tests/deploy stay aligned with the code. Run on a cadence (e.g. daily) or on demand after a batch of changes.
    0 installs
23. ▌
    Abstract The Provider · jcdavis131

    When swapping one third-party dependency for another (Shopify→Medusa, Stripe→Paddle, OpenAI→Anthropic), prefer a provider-agnostic abstraction with the new provider as the default, rather than a hard swap. Use when the user asks to replace a vendor, when choosing an open-source alternative to a paid service, or when a feature could plausibly need a second provider later.
    0 installs
24. ▌
    Diagnose Before Retry · jcdavis131

    When an operation fails, form a hypothesis from the logs/evidence before retrying — never retry blindly. Distinguish op-caused failures from self-caused artifacts (your own stops/kills), state the hypothesis with supporting context and appropriate uncertainty, and retry in the foreground with a timeout and observability so the retry is also a test of the hypothesis. Use when a long command (migrate, build, install, deploy, fetch) fails and you're tempted to just re-run it.
    0 installs
25. ▌
    Recap On Long Session · jcdavis131

    After a long stretch of work (~30+ minutes or many turns), emit a compressed recap of what's done, what's in flight, and what's next, so the user and any fresh context can re-enter without re-reading the whole conversation. Use when elapsed wall-clock or turn count makes the conversation hard to re-enter, or when the user re-engages after stepping away.
    0 installs
26. ▌
    Shell Confirm Hygiene · jcdavis131

    Decide when to pause for user confirmation before running a shell command, and how to keep flow afterward. Use before running commands that are destructive, irreversible, cross trust boundaries, contain shell expansion/subexpressions, touch the network, or modify state outside the working tree.
    0 installs
27. ▌
    Idempotent Seed Script · jcdavis131

    Write data-seed scripts (add-product, add-user, migrate-data, bootstrap-tenant) to be idempotent — detect existing records and skip rather than duplicate or fail — and run them with a targeted grep (added/skip/error) so the outcome is visible in one line. Use when seeding data into a database or service (e-commerce products, tenants, users, reference data), especially scripts that may be re-run.
    0 installs
28. ▌
    Verify Subagent Output · jcdavis131

    After parallel subagents (SME reviewers, research agents, task agents) return, spot-check their output against the named contract/standard before synthesizing or marking the task done. Use whenever you dispatched subagents and they've returned artifacts — especially before treating their output as ground truth in a synthesis or a "done" report.
    0 installs
29. ▌
    Disk Pressure Proactive · jcdavis131

    In a disk-constrained environment, proactively prune caches and build output for headroom *before* operations fail, while foreground work continues in parallel. State the safety property of each prune so the user trusts it without a confirm. Use when disk free space is low (~<2-3 GB), when heavy installs/builds are incoming, or in repos with a known disk blocker (BLK-DISK).
    0 installs
30. ▌
    Background Failure Triage · jcdavis131 bundle

    When a backgrounded command fails while the foreground lane is making progress, do not abort the foreground lane — log the failure, queue it for triage, and continue. Triage the failure at the next natural boundary. Use whenever a background shell task, background subagent, or parallel lane fails while you're mid-task on something independent.
    0 installs
31. ▌
    Use Available Integrations · jcdavis131 bundle

    Discovers session platform integrations, inspects existing state, and acts only on the delta — falling back to direct API or CLI when tools lack an operation. Use when deploying, provisioning, or managing Vercel, GitHub, Railway, Neon, or other external platform resources.
    0 installs
32. ▌
    Deterministic Core LLM Judgment · jcdavis131

    Build agents where the deterministic duties are the load-bearing backbone (always execute, reliable, auditable) and the LLM only adds an optional judgment layer on top — ranking, curation, synthesis. The agent must do its core work with the LLM layer off; the LLM only makes the work better. Use when designing or building an autonomous agent, a recurring agent loop, or any system where reliability matters more than cleverness.
    0 installs
33. ▌
    A11Y Gate · jcdavis131

    Statically verify new UI primitives for accessibility — animations gated behind prefers-reduced-motion, keyboard accessible, ARIA present — before declaring the primitive done. Use when authoring or modifying a UI primitive (component, page section, interactive widget), especially interactive/animated ones. Pairs well as a fill-the-wait task while builds run.
    0 installs
34. ▌
    Auto Mode · jcdavis131 bundle

    Behavior for autonomous multi-task execution where the user has delegated the whole plan. Work the task board top-to-bottom, advancing each item to done before the next, and only stop to surface a genuine decision the user must make or a blocker the agent cannot resolve. Integrates addyosmani/agent-skills lifecycle workflows per board item. Use when the user has said "go", "auto", "do the whole thing", "/build auto", or has otherwise delegated the plan rather than a single step.
    0 installs
35. ▌
    Sme Fanout · jcdavis131

    Spawn parallel subject-matter-expert subagents each owning one lane of a complex task, with a fixed output contract, then synthesize. Use when a task spans multiple distinct domains (e.g. security + perf + docs + tests + schema), when a single-agent pass would be shallow across all of them, or when the user asks for a multi-perspective review/report.
    0 installs
36. ▌
    Smoke Import · jcdavis131

    Fast sanity-check that new or edited packages import cleanly, without running a full dependency sync or test suite. Use after creating/editing a Python package's __init__.py, adding a new module to a monorepo, wiring sibling packages, or before wiring a package into a router — any time you want the cheapest possible "did I wire this up" signal.
    0 installs
37. ▌
    Fill The Wait · jcdavis131

    When a long-running operation (install, build, test run, deploy, model download) is in flight, pick up an independent in-lane task to advance in parallel rather than idling. Use whenever a wait of ~30 seconds or more is forced by a backgrounded command and there's an independent in-lane task ready to start.
    0 installs
38. ▌
    Validate Gate · jcdavis131

    Run the cheapest non-trivial correctness gate for the change type — install (offline-preferring) + typecheck for frontend, smoke-import + targeted tests for Python — before declaring a task done. Use after any code edit, before marking a task complete, and before moving to the next board item.
    0 installs
39. ▌
    Affected Tests · jcdavis131

    Affected Tests
    0 installs
40. ▌
    Close The Loop · jcdavis131

    When a multi-step user request is fully complete, deliver an explicit "closes the full request chain" summary that recaps the whole arc against the original ask, cites the commit SHA, separates any deferred "small notes for later" (with time estimates + doc pointers) from the win, and names the next action. Use when a long or multi-part request reaches full completion — not at intermediate milestones.
    0 installs
41. ▌
    Metadata Align · jcdavis131

    After a structural change (new service, new site, renamed package, new fleet entry), update every docs/registry/metadata surface that references the structure, in the same change — not a deferred doc-debt cleanup. Use when adding/moving/removing a service or site, when the architecture changes, or when a new feature should appear in the README/fleet registry/package metadata.
    0 installs
42. ▌
    Progress Board · jcdavis131

    Maintains a visible, counted, one-line task board for ambient progress awareness. Use when running any multi-step task (3+ steps), when switching lanes, when the user asks for status, or when a long background op runs alongside foreground work.
    0 installs