Claude Skills by Amey-Thakur

Run a production readiness review that checks SLOs, runbooks, capacity, and dependencies before an on-call team agrees to own a service. Use when a service is about to be onboarded to a support rotation or handed from its builders to operators.

Assemble a promotion packet that proves sustained impact at the next level, with calibrated scope claims and evidence a committee can verify. Use when you or someone you manage is going up for promotion and you need a case, not a list of tasks.

Run quarterly planning with honest capacity, negotiated cross-team dependencies, and an explicit cut line that names what will not get done. Use when a team commits to a quarter of work and needs the plan to survive contact with reality.

Run a Request for Comments process so a proposal reaches the right audience, collects objections inside a bounded window, and records a decision people can point to later. Use when a change affects teams beyond the author's and needs durable buy-in.

Apply Microsoft's Security Development Lifecycle so threat modeling, tooling, and sign-off are built into each phase instead of bolted on before ship. Use when building or shipping software that takes untrusted input or handles sensitive data and you need a repeatable security process, not a one-time audit.

Write an Amazon six-pager, a narrative memo read in silence at the start of a meeting so a decision rests on reasoning rather than a presenter's charisma. Use when running an operating, strategy, or investment review that must reach a real decision.

Maintain a tech radar that sorts technologies into adopt, trial, assess, and hold against a real evidence bar, and pairs each adoption with a sunset. Use when an organization needs a shared, current view of which tools and techniques to reach for and which to retire.

Evaluate vendors against weighted criteria, a proof of concept that tests your real workload, and a clear-eyed accounting of exit costs before you sign. Use when choosing a paid tool or service you will depend on and a wrong pick is expensive to undo.

Run a war room for a live incident with defined roles, a steady cadence, a decision log, and explicit stand-down criteria. Use when a high-severity outage or crisis needs coordinated response across teams and the improvised version is descending into chaos.

Operate as an accessibility specialist who audits against WCAG, trains teams to stop shipping the same defects, and owns the compliance sign-off. Use when a product needs to be usable with a keyboard, a screen reader, or magnification and someone must certify it before launch.

Operate as a backend engineer who designs stable API contracts, guards data integrity, and ships services that are operable on day one. Use when building or reviewing a service, API, or data path and you want production-grade engineering discipline.

Operate as a cloud architect who lays the landing zone, governs cost, and sequences migration for an organization. Use when asked to stand up a cloud foundation, put guardrails and cost controls in place, or plan how workloads move to the cloud.

Operate as a CTO-level advisor who turns business goals into build-or-buy calls, org design, technology bets, and a named risk posture. Use when a leader needs a technology strategy that a board and a finance team will both accept.

Operate as a data engineer who ships pipelines to a freshness SLA, enforces schema contracts at the source, and owns data quality end to end. Use when building or reviewing a pipeline, warehouse table, or ingestion path that other teams will trust.

Operate as a product data scientist who frames falsifiable hypotheses, analyzes experiments, and reports results without flattering the launch. Use when asked to design an A/B test, read out an experiment, or turn a metric question into a decision.

Operate as a developer relations (DevRel) engineer who closes the loop between external developers and the product team. Use when asked to run developer advocacy: gather feedback, produce technical content, grow a community, and feed evidence back to product and engineering.

Operate as a DevOps engineer who owns the delivery pipeline, keeps environments identical, and makes every deploy reversible. Use when building or reviewing how code reaches production and you want release plumbing that fails safe instead of at 3 a.m.

Operate as an engineering manager who grows people, protects delivery health, hires deliberately, and shields the team from noise. Use when you are accountable for a team's output and careers, not for writing the code yourself.

Operate as a frontend engineer who defends UX quality, enforces performance budgets, and partners with design instead of just closing tickets. Use when building or reviewing a user-facing web feature and you want an engineer's operating discipline, not raw code.

Operate as a growth engineer who moves a funnel metric through instrumented, fast experiments and refuses to win with dark patterns. Use when your job is to raise activation, retention, or conversion with measured changes, not guesses.

Operate as an incident commander who owns the response to a live outage: severity, coordination, and communication, not the fix itself. Use when a production incident is active and someone must run the room instead of everyone debugging in parallel.

Operate as an ML engineer who takes a research model to reliable production behind eval gates and keeps it healthy across its lifecycle. Use when asked to productionize a model, build a training or serving pipeline, or set promotion criteria.

Operate as a mobile engineer who plans around release trains, a real device matrix, and app-store rules that a web engineer never faces. Use when building or reviewing an iOS or Android feature and you need mobile-specific release and compatibility discipline.

Operate as a company-employed open source maintainer who runs governance, licensing hygiene, and community health for a project the business depends on. Use when you steward a public repo that must serve both an external community and an internal roadmap.

Operate as a performance engineer who sets budgets, gates regressions in CI, and runs profiling as a service other teams rely on. Use when latency, throughput, memory, or GPU utilization matters and you want measured wins, not folklore optimizations.

Operate as a platform engineer who builds golden paths for internal developers and earns adoption on merit. Use when asked to design an internal developer platform, pave a common workflow, or prove a platform is being adopted.

Operate as a principal architect who owns the boundaries between systems, curates the technology set, and spends veto power sparingly. Use when you must set architecture direction across teams and keep a platform coherent as it grows.

Operate as a product designer who designs the whole flow, specs every state, defends the work in critique, and hands off at build fidelity. Use when designing a feature, running or joining a critique, or preparing a handoff to engineering.

Operate as a product manager who picks the right problem, writes the spec, makes the tradeoff calls, and owns the launch outcome. Use when you must decide what to build and why, and stand behind the result.

Operate as a QA engineer who owns test strategy, automation coverage, and the release quality signal. Use when asked to build a test approach, decide what to automate, or give a defensible go or no-go on a release.

Operate as a release manager who runs release trains, enforces cut criteria, and holds rollback authority. Use when asked to coordinate a release, decide what makes the cut, or own the go-live and its reversal.

Operate as a security engineer who reduces real risk through threat models, targeted reviews, scalable tooling, and incident duty. Use when a system's security posture is your responsibility and you must prevent and respond, not just audit.

Operate as a site reliability engineer who runs production to an error budget and holds toil below a hard cap. Use when you own the reliability of a live service and must balance feature velocity against uptime with data, not vibes.

Operate as a solutions architect who turns a customer's constraints into a defensible reference design and a path to production. Use when asked to scope a technical solution for a specific account, produce an architecture that fits real limits, and de-risk the build.

Operate as a staff engineer who sets technical direction across teams and multiplies output through people rather than personal commits. Use when you are the senior technical anchor for an initiative spanning several teams or quarters.

Operate as a support engineer who triages by impact, reproduces before escalating, and turns recurring tickets into product fixes. Use when you own customer-reported issues and must resolve them while feeding the product back what keeps breaking.

Operate as a technical program manager who drives a multi-team program to a date by tracking dependencies, burning down risk, and reporting the truth upward. Use when a launch spans several teams and someone must own the schedule and the risk, not the code.

Operate as a technical writer who owns the information architecture, runs docs through a two-gate review, and ships documentation with the feature it describes. Use when planning a docset, writing or reviewing developer docs, or deciding how content is organized.

Operate as a UX researcher who ties every study to a pending decision, synthesizes evidence into ranked insights, and delivers findings that move the roadmap. Use when planning a study, choosing a method, or turning interviews and usability sessions into a decision.

Decide how the business creates, delivers, and captures value, and check the pieces are consistent with each other. Use when starting something, or when growth is not converting into a viable business.

Decide where to spend limited money and attention across competing opportunities, with a consistent basis for comparison. Use when planning a budget or choosing between investments.

Manage the timing of money in and out so the business can pay what it owes when it is due. Use when growing fast, when payment terms are long, or whenever runway is under a year.

Decide where to compete and how to sustain an advantage, rather than assuming a better product wins. Use when entering a market, responding to a competitor, or explaining why you will win.

Understand which costs are fixed, variable, and step, so you know how profit responds to volume and where cuts actually help. Use when planning capacity, cutting costs, or explaining why margin is not improving with growth.

Read a profit and loss, balance sheet, and cash flow statement well enough to see what a business is actually doing. Use when reviewing your own numbers, a partner's, or an acquisition target's.

Estimate how large an opportunity actually is, from the bottom up, and state the assumptions that drive the number. Use when evaluating a market, writing a plan, or challenging a large number in a deck.

Prepare and conduct a negotiation around interests and alternatives rather than positions, so agreements are better and hold. Use before any commercial conversation with something at stake.

Run repeatable delivery reliably by finding the constraint, reducing variability, and measuring flow rather than utilisation. Use when delivery is inconsistent or slower than the work itself requires.

Structure teams, ownership, and decision rights so work flows rather than queueing at handoffs. Use when coordination cost is rising faster than headcount.

Identify who is affected by a decision, what each needs, and how to keep them informed enough to stay aligned. Use when a project crosses teams or when decisions keep getting reopened.