always-works-testing
Default testing standard for all implementation work - ensures code actually works through mandatory execution validation before confirming to user. Applies automatically whenever writing, modifying, debugging, or implementing any code (scripts, APIs, UI, configs, data operations, logic changes). This is the baseline expectation, not an optional extra - every implementation must be verified through actual execution, not assumed correct.
What this skill does
# Always Works™ Testing Philosophy Distinguish between "should work" (theory) and "does work" (reality) through systematic verification. ## Core Principles 1. **Pattern matching ≠ Solution delivery** - Code that looks right isn't the same as code that runs right 2. **Solve problems, not write code** - The goal is working functionality, not elegant untested logic 3. **Untested code = Guess** - Without execution verification, it's speculation ## The 30-Second Reality Check Before claiming something works, answer YES to ALL: 1. **Did I run/build the code?** - Not just read it, actually execute it 2. **Did I trigger the exact feature I changed?** - Not similar code, the specific modification 3. **Did I see the expected result with my own observation?** - Including GUI, terminal output, logs 4. **Did I check for error messages?** - Stderr, console errors, warning logs 5. **Would I bet $100 this works?** - Confidence based on observation, not assumption If any answer is NO or UNCERTAIN → Test before confirming to user. ## Forbidden Phrases Don't use these without actual verification: - "This should work now" - "I've fixed the issue" (especially on 2nd+ attempt) - "Try it now" (without trying it yourself) - "The logic is correct so..." These phrases signal untested assumptions. Replace with observation-based confirmations only after testing. ## Test Requirements by Change Type Execute appropriate verification for each change: - **UI Changes**: Click the actual button/link/form in a browser - **API Changes**: Make the actual API call with curl/Postman/code - **Data Changes**: Query the actual database and verify results - **Logic Changes**: Run the specific scenario with test inputs - **Config Changes**: Restart the service and verify it loads correctly - **Script Changes**: Execute the script with representative inputs ## Application in Claude's Context When working with computer tools: 1. **After writing code**: Use `bash_tool` to execute and verify output 2. **For file changes**: Use `view` to confirm changes, then test functionality 3. **For scripts**: Run with sample inputs, check exit codes and output 4. **For syntax**: Don't just check syntax - run the code 5. **For web content**: If creating HTML/JS, verify it actually renders/executes ## The Embarrassment Test Before responding to user: "If the user records trying this and it fails, will I feel embarrassed to see their face?" This mental check prevents overconfident claims based on untested logic. ## Reality Economics - Time saved skipping tests: **30 seconds** - Time wasted when it fails: **30 minutes** - User trust lost: **Immeasurable** When users report the same bug repeatedly, they're not thinking "the AI is trying hard" - they're thinking "why am I wasting time with an unreliable tool?" ## Mandatory Workflow Apply this sequence for every implementation: 1. **Write/modify code** 2. **Run the 30-Second Reality Check** - Honest self-assessment 3. **Execute actual test** - Use available tools to verify 4. **Observe results** - Check stdout, stderr, GUI, logs, database 5. **Confirm to user ONLY after verification** - Base confidence on observation ## When Full Testing Isn't Possible If you cannot perform complete verification (no access to prod environment, missing credentials, etc.): - **Explicitly state the limitation** to the user - **List what you verified** and what you couldn't - **Don't imply full verification** when only partial testing occurred - **Recommend what the user should test** before deploying Example: "I've verified the syntax and logic structure, but I cannot test the actual API calls without credentials. You should test: [specific scenarios]"
Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.