hemapriyan-rk
UserClaude Code skills for engineering, research, and patent work where a plausible answer isn't good enough. Built-in checks for trade-offs, failure modes, prior art, and weak claims
Categories
Indexed Skills (28)
agent-system-design
Design an AI agent system's orchestration, memory/state architecture, tool-use boundaries, and cost/runaway-loop guards — the upstream design layer, before any code exists to audit. Use when designing a new single-agent or multi-agent system, or when an existing agent system is unpredictable, expensive, or hard to debug. Distinct from `ml-security-audit`, which audits code for prompt-injection risk after the fact — this designs the boundaries so that risk is scoped in from the start.
api-contract-design
Design the contract between services or between client and server — protocol choice (REST/GraphQL/gRPC), versioning strategy, error-response contract, and backward-compatibility rules. Use whenever designing a new API, reviewing one for a breaking-change risk, or asked to add a field/endpoint to an existing API. Sits between database design and frontend/client design — the boundary contract itself, not either side's internals.
architecture-design
Design or review system architecture for distributed systems, AI/ML infrastructure, edge-cloud pipelines, or AI agent systems — with mandatory trade-off decisions, failure-mode analysis, and a security/adversarial pass, not just a component diagram. Use whenever the user is designing a new system, refactoring an existing one, or asks "how should I architect X" for anything involving scaling, observability, distributed state, or ML components. Do not use for simple single-service app scaffolding with no distributed or ML complexity — that doesn't need this level of rigor.
code-handoff
Package a design/ideation conversation into a self-contained handoff brief for a coding agent (Claude Code or a fresh coding session) so implementation starts from locked decisions instead of re-deriving context or re-exploring already-rejected approaches. Use whenever the user says they're moving from planning/chat into building, asks to "hand this off to Claude Code," or wants a task prompt/context file to paste into a coding session. Do not use this to write the actual implementation — only to produce the handoff artifact.
cross-ai-handoff
Distill a Claude conversation or project into a self-contained, model-agnostic brief for use with a different AI system (ChatGPT, Gemini, Grok, a local LLM, etc.) that has no access to this conversation, Claude's memory, or Claude-specific artifacts. Use whenever the user asks to take this context to another AI, get a second opinion elsewhere, or continue this work in a different tool. Do not use this for handoff to Claude Code — use the `code-handoff` skill for that, since it can assume a shared Claude context this skill cannot.
crypto-storage-audit
Audit code that implements encryption, key management, or secure/policy-gated storage — envelope encryption (DEK/KEK), key derivation, access-policy enforcement, secure deletion. Use for any code handling encryption keys, an encrypted file format, or gated decryption logic. This checks for the specific mistakes that make real-world crypto implementations fail even when the chosen algorithms are correct.
database-design
Design a database schema and storage strategy — normalization vs. denormalization, indexing, SQL vs. NoSQL choice, sharding/replication and consistency model — with every trade-off stated explicitly rather than defaulted by habit or fashion. Use when designing a new schema, choosing a database technology, or reviewing an existing schema for scaling or correctness issues.
dataset-sourcing
Find and evaluate datasets for training or validating a model — checking license, quality, leakage risk, bias, and whether the dataset's actual distribution matches the real deployment domain. Use whenever a project needs training or validation data, and before treating any found dataset as ready to use as-is.
distributed-debugger
Root-cause debugging methodology for concurrency, async, and distributed bugs — race conditions, deadlocks, retry storms, partial failures, message reordering, clock skew. Use when a bug is intermittent, hard to reproduce, only shows up under load, or spans multiple services/processes. Do not use for straightforward deterministic bugs — this is specifically for the class that "goes away when you add a print statement."
embedded-constrained-coding
Write or review code for resource-constrained targets — microcontrollers, on-device mobile/edge inference, or any environment with a hard memory/power/latency budget. Use whenever the target is not a general-purpose server, or the user mentions RAM/flash limits, battery/power budget, quantization, or cross-compilation for an embedded or mobile target. Do not use this for ordinary server/cloud code with no hard resource ceiling.
freedom-to-operate-analysis
Assess whether building and selling a specific product or process risks infringing an active third-party patent — a different question from whether your own invention is novel. Use before committing to productize or commercialize anything patent-adjacent, or whenever the user asks "can we actually ship this without getting sued" or "is this clear to build." This is a technical infringement-risk scoping exercise, not legal advice — a formal opinion requires a patent attorney.
frontend-architecture
Design frontend architecture — rendering strategy (SSR/SSG/ISR/CSR), state management boundaries, component data flow, and performance budgets — as structural/technical decisions, not visual styling. Use when architecting a new frontend app or reviewing an existing one for state-management or rendering-strategy problems. This is not about aesthetics, layout, or typography — use the visual design skill for that; this skill is about where state lives and how data flows.
github-master
Manage a project's git/GitHub workflow end to end — connecting a local repo to a GitHub remote, disciplined local auto-checkpoint commits during active work, commit message quality, and safe local-to-remote sync (fetch-before-push, branch strategy, no blind force-pushes). Use whenever the user asks to set up git/GitHub for a project, wants work checkpointed or committed automatically during a session, needs help pushing/pulling/syncing with a remote, or is deciding on a branching strategy.
idea-finder
Generate genuinely novel technical/product/research ideas within a domain by finding unsolved constraint intersections — not generic brainstorming. Use whenever the user wants new invention/patent/paper/product ideas in a technical space, asks "what's a gap nobody's filled here," or wants direction before committing to a project. Every idea produced must survive a "why hasn't this been done" gut-check before being presented. Do not use for open-ended creative brainstorming unrelated to technical/patent/research output — this is for ideas that need to hold up, not for volume.
ieee-paper-drafter
Draft an IEEE-conference/journal-style research paper — full section structure, IEEE numeric citation style, and a ready IEEEtran LaTeX skeleton — with the same rigor bar a reviewer would apply. Use whenever the user wants to write up a research idea, project, or result as an IEEE-format paper, or asks for an abstract/related-work/methodology section in that style. Do not use this for informal write-ups or blog-style summaries — that's plain markdown, not this skill.
ml-model-selection
Choose the right ML model architecture, size, and family for a task given real constraints — latency ceiling, accuracy floor, compute/memory budget, and deployment target (cloud vs. edge/on-device) — instead of defaulting to the largest or most fashionable model. Use whenever picking a model for a new pipeline, or reconsidering one that's too slow, expensive, or large for its actual deployment target.
ml-security-audit
Audit code for adversarial-ML and model-security risk — evasion, data poisoning, model/IP extraction, prompt injection in LLM-agent code, and sensor spoofing in fusion pipelines. Use for any inference pipeline, training loop, LLM agent with tool access, or sensor-fusion/vision code, especially before treating it as production-ready. This is distinct from general security review — it targets attack classes specific to ML systems.
mobile-platform-architecture
Design mobile-specific architecture — offline-first sync strategy, background execution limits, native/cross-platform bridge boundaries, battery- and network-aware behavior, and process-death state restoration — for iOS, Android, or cross-platform frameworks. Use when architecting a mobile app or reviewing one for reliability/battery problems. Distinct from `frontend-architecture`, which covers web rendering strategy and browser-side state — this is mobile OS-specific constraints.
observability-design
Design a system's observability from first principles — SLI/SLO and error-budget definition, trace architecture across service boundaries, structured logging strategy, and alerting that stays actionable instead of degrading into noise. Use when designing new observability for a system, when an existing system is "hard to debug in production," or when alert fatigue is a stated problem. Distinct from adding a few log lines to existing code — this is the design of the observability layer itself.
patent-drafter
Draft a full patent specification — background, summary, detailed description, and a claim ladder (independent + dependent claims) — for an invention. Use whenever the user asks to draft a patent, write patent claims, or turn an invention into a filing-ready-style document. Requires (or produces, if missing) a novelty check first — drafting polished claims around something already anticipated by prior art wastes effort, so this skill will not silently skip that step. Produces a technical working draft for attorney review, not a filed legal document.
patent-novelty-evaluator
Stress-test an invention for patentability — novelty, inventive step/non-obviousness, subject-matter eligibility, and claim scope — before time or money goes into filing. Use whenever the user describes an invention, a patent claim, or a "is this patentable" question, or asks to re-evaluate an existing patent draft or provisional. Gives a blunt kill/weak/defensible verdict backed by the closest prior art found, not a generic "sounds novel" reassurance. This is technical prior-art and claim analysis, not legal advice — a patent attorney should confirm before filing.
project-scaffolding
Set up a new project's directory structure and boilerplate following the real convention for its language/framework/deliverable type, rather than an invented ad hoc layout. Use whenever starting a new project or repo, adding a module that needs its own structural convention, or restructuring an existing messy layout. Covers single packages, applications, services, and monorepos.
researcher-evaluator
Stress-test a piece of research — a report, literature review, competitive analysis, or "I looked into it and..." summary — for rigor, bias, and hidden gaps before it gets relied on. Use whenever the user shares research (their own, another AI's, or a document) and asks whether it holds up, whether they missed something, or whether a conclusion is safe to act on. Give a blunt verdict, not a polite summary. Do not use this for grading writing style — this is about evidentiary rigor only.
researcher
Conduct deep, adversarial technical research — prior art, state-of-the-art, competitive landscape, standards — for patents, papers, architecture decisions, or any claim that needs to survive scrutiny. Use whenever the user asks to research a technical topic, check if something already exists, find prior art, scope a literature review, or validate a technical/market claim before committing to it. Do not use for quick single-fact lookups — this is for multi-source, defensible research where being wrong is expensive.
safety-compliance-scoping
Scope which safety and regulatory compliance frameworks plausibly apply to a system — functional safety standards, medical device classification pathways, industrial safety directives — based on its actual use case and failure consequence, before deep technical or product investment. Use early, whenever a system's use case touches health, safety, or regulated industrial contexts, to identify what compliance burden is coming rather than discovering it after the architecture is locked in. This produces a scoping map, not a certification — a qualified regulatory/compliance professional and, where relevant, legal counsel must own the actual compliance path.
scale-refactor
Refactor a working prototype toward production shape — surfacing scaling bottlenecks, adding observability, and hardening the trust boundaries it actually crosses — without a wholesale rewrite that loses working behavior. Use when code that started as a proof-of-concept or hackathon-speed build needs to survive real load, real failures, or a real audit, or when the user says something like "this works, now make it not fall over."
secure-code-review
Review code, a diff, or a PR for real security and correctness bugs — not style nitpicks. Use before merging anything that crosses a trust boundary (service-to-service calls, user input, file/network I/O, auth checks), whenever the user asks for a code review or security review, or before a patent PoC / project component gets treated as production-ready. Prioritizes exploitable findings over cosmetic ones.
test-architect
Generate tests focused on edge cases, invalid input, concurrency, and failure injection — not coverage padding. Use whenever the user asks for tests to be written, or when code touches concurrency, external I/O, network calls, or ML inference and needs real confidence rather than a high coverage number. Do not use this to generate ten variations of the same happy-path test.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.