shackleton-hiring
Use when hiring for early-stage high-growth companies, when filtering out comfort-seekers, or when building teams tackling unsolved technical challenges
Single-Threaded Leadership Model
An organizational model where a single leader is fully accountable for a specific goal and controls all cross-functional resources needed, minimizing external dependencies. Amazon's alternative to matrixed organizations.
Three Levels of Product Work
Understand that product work happens at three levels (Impact, Execution, Optics) and conflicts arise when people argue from different levels. Use to diagnose team misalignment.
Waterline Model
Diagnose team problems by checking structural issues (goals/roles) at the surface before diving deep into personality conflicts. 80% of team problems are structural, not personal.
Willow Tree Leadership Style
A metaphor for managing change—remain rooted in core purpose while being extremely flexible in tactics, absorbing storms of change without breaking. Use during pivots, restructures, or industry upheavals.
Causal Interview Protocol
A JTBD interviewing technique to reconstruct the customer's timeline and uncover causal mechanisms behind a purchase. Resembles criminal investigation—penetrate surface-level answers to find the struggling moment.
chatter-driven-development
Use when designing futuristic agentic workflows, when wanting AI to proactively act on team communications, or when eliminating the bottleneck of formal specifications
curiosity-loops
Use when facing a significant decision (career pivot, product direction, technical choice) and feeling stuck or indecisive, when seeking contextual advice rather than generic recommendations
Diagnose with Data, Treat with Design
Use data to establish business observability (diagnosing problems) but use creative design thinking to solve them (treatment). Resolves the conflict between data-driven and intuition-driven product development.
lazy-vain-selfish-users
Use when designing onboarding flows, writing marketing copy, or creating the first-mile product experience to capture attention from indifferent users
vibefigma
Convert Figma designs to production-ready React components with Tailwind CSS. Use when user provides a Figma URL, asks to convert Figma designs to React/code, wants to extract components from Figma, or mentions "vibefigma". Requires a Figma access token (via --token flag, FIGMA_TOKEN env var, or .env file).
osgrep
Semantic code search. Use alongside grep - grep for exact strings, osgrep for concepts.
best-minds
模拟器思维：不问"你怎么看"，而是问"世界上谁最懂这个？TA 会怎么说？"。触发词：最强大脑、顶级专家、世界级、best minds、谁最懂这个
go-performance
Use when optimizing Go code, investigating slow performance, or writing performance-critical sections. Also use when a user mentions slow Go code, string concatenation in loops, or asks about benchmarking, even if the user doesn't explicitly mention performance patterns. Does not cover concurrent performance patterns (see go-concurrency).
go-code-review
Use when reviewing Go code or checking code against community style standards. Also use proactively before submitting a Go PR or when reviewing any Go code changes, even if the user doesn't explicitly request a style review. Does not cover language-specific syntax — delegates to specialized skills.
go-concurrency
Use when writing concurrent Go code — goroutines, channels, mutexes, or thread-safety guarantees. Also use when parallelizing work, fixing data races, or protecting shared state, even if the user doesn't explicitly mention concurrency primitives. Does not cover context.Context patterns (see go-context).
go-control-flow
Use when writing conditionals, loops, or switch statements in Go — including if with initialization, early returns, for loop forms, range, switch, type switches, and blank identifier patterns. Also use when writing a simple if/else or for loop, even if the user doesn't mention guard clauses or variable scoping. Does not cover error flow patterns (see go-error-handling).
go-naming
Use when naming any Go identifier — packages, types, functions, methods, variables, constants, or receivers — to ensure idiomatic, clear names. Also use when a user is creating new types, packages, or exported APIs, even if they don't explicitly ask about naming conventions. Does not cover package organization (see go-packages).
go-data-structures
Use when working with Go slices, maps, or arrays — choosing between new and make, using append, declaring empty slices (nil vs literal for JSON), implementing sets with maps, and copying data at boundaries. Also use when building or manipulating collections, even if the user doesn't ask about allocation idioms. Does not cover concurrent data structure safety (see go-concurrency).
go-declarations
Use when declaring or initializing Go variables, constants, structs, or maps — including var vs :=, reducing scope with if-init, formatting composite literals, designing iota enums, and using any instead of interface{}. Also use when writing a new struct or const block, even if the user doesn't ask about declaration style. Does not cover naming conventions (see go-naming).
go-packages
Use when creating Go packages, organizing imports, managing dependencies, or deciding how to structure Go code into packages. Also use when starting a new Go project or splitting a growing codebase into packages, even if the user doesn't explicitly ask about package organization. Does not cover naming individual identifiers (see go-naming).
go-defensive
Use when hardening Go code at API boundaries — copying slices/maps, verifying interface compliance, using defer for cleanup, time.Time/time.Duration, or avoiding mutable globals. Also use when reviewing for robustness concerns like missing cleanup or unsafe crypto usage, even if the user doesn't mention "defensive programming." Does not cover error handling strategy (see go-error-handling).
go-documentation
Use when writing or reviewing documentation for Go packages, types, functions, or methods. Also use proactively when creating new exported types, functions, or packages, even if the user doesn't explicitly ask about documentation. Does not cover code comments for non-exported symbols (see go-style-core).
go-error-handling
Use when writing Go code that returns, wraps, or handles errors — choosing between sentinel errors, custom types, and fmt.Errorf (%w vs %v), structuring error flow, or deciding whether to log or return. Also use when propagating errors across package boundaries or using errors.Is/As, even if the user doesn't ask about error strategy. Does not cover panic/recover patterns (see go-defensive).
go-functional-options
Use when designing a Go constructor or factory function with optional configuration — especially with 3+ optional parameters or extensible APIs. Also use when building a New* function that takes many settings, even if they don't mention "functional options" by name. Does not cover general function design (see go-functions).
go-functions
Use when organizing functions within a Go file, formatting function signatures, designing return values, or following Printf-style naming conventions. Also use when a user is adding or refactoring any Go function, even if they don't mention function design or signature formatting. Does not cover functional options constructors (see go-functional-options).
go-generics
Use when deciding whether to use Go generics, writing generic functions or types, choosing constraints, or picking between type aliases and type definitions. Also use when a user is writing a utility function that could work with multiple types, even if they don't mention generics explicitly. Does not cover interface design without generics (see go-interfaces).
go-interfaces
Use when defining or implementing Go interfaces, designing abstractions, creating mockable boundaries for testing, or composing types through embedding. Also use when deciding whether to accept an interface or return a concrete type, or using type assertions or type switches, even if the user doesn't explicitly mention interfaces. Does not cover generics-based polymorphism (see go-generics).
go-linting
Use when setting up linting for a Go project, configuring golangci-lint, or adding Go checks to a CI/CD pipeline. Also use when starting a new Go project and deciding which linters to enable, even if the user only asks about "code quality" or "static analysis" without mentioning specific linter names. Does not cover code review process (see go-code-review).
go-logging
Use when choosing a logging approach, configuring slog, writing structured log statements, or deciding log levels in Go. Also use when setting up production logging, adding request-scoped context to logs, or migrating from log to slog, even if the user doesn't explicitly mention logging. Does not cover error handling strategy (see go-error-handling).
go-context
Use when working with context.Context in Go — placement in signatures, propagating cancellation and deadlines, and storing values in context vs parameters. Also use when cancelling long-running operations, setting timeouts, or passing request-scoped data, even if they don't mention context.Context directly. Does not cover goroutine lifecycle or sync primitives (see go-concurrency).
go-style-core
Use when working with Go formatting, line length, nesting, naked returns, semicolons, or core style principles. Also use when a style question isn't covered by a more specific skill, even if the user doesn't reference a specific style rule. Does not cover domain-specific patterns like error handling, naming, or testing (see specialized skills). Acts as fallback when no more specific style skill applies.
go-testing
Use when writing, reviewing, or improving Go test code — including table-driven tests, subtests, parallel tests, test helpers, test doubles, and assertions with cmp.Diff. Also use when a user asks to write a test for a Go function, even if they don't mention specific patterns like table-driven tests or subtests. Does not cover benchmark performance testing (see go-performance).
ui-ux-pro-max
UI/UX design intelligence. 50 styles, 21 palettes, 50 font pairings, 20 charts, 8 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient.
fresh-eyes
Re-reads code you just wrote with fresh perspective to catch bugs, errors, and issues. Use after completing a feature, fixing a bug, or any code changes. Triggers on "review my code", "fresh eyes", "check for bugs", "did I miss anything", or "sanity check".
accessibility-review
Reviews UI for accessibility issues against WCAG 2.1/2.2 AA. Triggers on "is this accessible?", "check accessibility", or contrast/a11y review requests.
create-prd
Plan features interactively. Asks clarifying questions, then generates a detailed PRD document.
red-pen
>
humanize
Reviews and edits copy to remove AI-generated patterns and make text sound natural. Use when editing drafts, reviewing copy, "humanize this", "make it less AI", "sounds too AI", "remove AI patterns", "edit my copy", "this sounds robotic", or when text feels machine-generated.
motion-design
Provides motion design guidance for UI components. Triggers on animation requests ("animate this", "add transition", "motion for"), refinement requests ("clean up this animation", "clean up the motion", "this feels too fast/slow", "make this feel more alive/natural"), and questions about easing, timing, or micro-interactions.
og-images
Guides creation of OpenGraph and Twitter share images using next/og ImageResponse. Covers layout patterns, custom fonts, avatars, title case, and Satori rules. Use when building OG images, Twitter cards, or social previews.
ralph-github-create-issues
Converts a PRD markdown file into GitHub Issues (parent + sub-issues) for ralph-github-start-loop to execute. Use when user wants to push PRD stories to GitHub Issues.
ralph-github-start-loop
Runs autonomous loop fetching stories from GitHub Issues. Implements and closes issues as done. Triggers on "loop through my PRDs", "work on my issues", "start the autonomous loop", "implement my PRDs", or requests to work through GitHub issues autonomously.
ralph-json-create-issues
Converts a PRD or plan markdown file into prd.json format for ralph-json-start-loop to execute autonomously. Use when user wants to convert a PRD or plan to JSON stories.
ralph-json-start-loop
Runs the Ralph autonomous loop. Executes stories from prds/*.json using git worktrees.
review-agents-md
Creates minimal, effective AGENTS.md files using progressive disclosure. Triggers on "create agents.md", "refactor agents.md", "review my agents.md", "claude.md", or questions about agent configuration files. Also triggers proactively when a project is missing AGENTS.md.
review-pr
Reviews PR comments from GitHub (Copilot, reviewers), evaluates against actual code, replies with reasoning, and resolves threads. Triggers on "review pr comments", "address pr feedback", "fix pr comments", or "review copilot suggestions".
skill-review
Reviews and validates agent skills against best practices. Triggers on "review this skill", "check my skill", "validate skill", "is this skill well-written", or when creating/editing skills.
technical-writing
Writes technical blog posts about features being built. Triggers when user asks to write about development progress, implementations, or project updates.
x-writing
Transforms notes into X (Twitter) posts. Triggers when user asks to create social content, draft tweets, or turn notes/ideas into posts.
Page 441 of 1657 · 82819 results