1. Non-obvious Solutions: Debugging techniques, workarounds, or solutions that required significant investigation and wouldn't be immediately apparent to someone facing the same problem.
2. Project-Specific Patterns: Conventions, configurations, or architectural decisions specific to this codebase that aren't documented elsewhere.
3. Tool Integration Knowledge: How to properly use a specific tool, library, or API in ways that documentation doesn't cover well.
4. Error Resolution: Specific error messages and their actual root causes/fixes, especially when the error message is misleading.
5. Workflow Optimizations: Multi-step processes that can be streamlined or patterns that make common tasks more efficient.

• Reusable: Will this help with future tasks? (Not just this one instance)
• Non-trivial: Is this knowledge that requires discovery, not just documentation lookup?
• Specific: Can you describe the exact trigger conditions and solution?
• Verified: Has this solution actually worked, not just theoretically?

Add other tool paths as needed

• What was the problem or task?
• What was non-obvious about the solution?
• What would someone need to know to solve this faster next time?
• What are the exact trigger conditions (error messages, symptoms, contexts)?

• Technology-specific best practices (frameworks, libraries, tools)
• Current documentation or API changes
• Common patterns or solutions for similar problems
• Known gotchas or pitfalls in the problem domain
• Alternative approaches or solutions

• The topic involves specific technologies, frameworks, or tools
• You're uncertain about current best practices
• The solution might have changed after January 2025 (knowledge cutoff)
• There might be official documentation or community standards
• You want to verify your understanding is current

• Project-specific internal patterns unique to this codebase
• Solutions that are clearly context-specific and wouldn't be documented
• Generic programming concepts that are stable and well-understood
• Time-sensitive situations where the skill needs to be created immediately

1. Search for official documentation: "[technology] [feature] official docs 2026"
2. Search for best practices: "[technology] [problem] best practices 2026"
3. Search for common issues: "[technology] [error message] solution 2026"
4. Review top results and incorporate relevant information
5. Always cite sources in a "References" section of the skill

• "Next.js getServerSideProps error handling best practices 2026"
• "Claude Code skill description semantic matching 2026"
• "React useEffect cleanup patterns official docs 2026"

• Add a "References" section at the end of the skill with source URLs
• Incorporate best practices into the "Solution" section
• Include warnings about deprecated patterns in the "Notes" section
• Mention official recommendations where applicable

• Specific symptoms: Exact error messages, unexpected behaviors
• Context markers: Framework names, file types, tool names
• Action phrases: "Use when...", "Helps with...", "Solves..."

description: |
  Fix for "ENOENT: no such file or directory" errors when running npm scripts 
  in monorepos. Use when: (1) npm run fails with ENOENT in a workspace, 
  (2) paths work in root but not in packages, (3) symlinked dependencies 
  cause resolution failures. Covers node_modules resolution in Lerna, 
  Turborepo, and npm workspaces.

• Project-specific skills:

  .claude/skills/[skill-name]/SKILL.md

• User-wide skills:

  ~/.claude/skills/[skill-name]/SKILL.md

scripts/

/claudeception

1. Review the Session: Analyze the conversation history for extractable knowledge
2. Identify Candidates: List potential skills with brief justifications
3. Prioritize: Focus on the highest-value, most reusable knowledge
4. Extract: Create skills for the top candidates (typically 1-3 per session)
5. Summarize: Report what skills were created and why

• "What did I just learn that wasn't obvious before starting?"
• "If I faced this exact problem again, what would I wish I knew?"
• "What error message or symptom led me here, and what was the actual cause?"
• "Is this pattern specific to this project, or would it help in similar projects?"
• "What would I tell a colleague who hits this same issue?"

1. Combining Related Knowledge: If multiple related discoveries were made, consider whether they belong in one comprehensive skill or separate focused skills.
2. Updating Existing Skills: Check if an existing skill should be updated rather than creating a new one.
3. Cross-Referencing: Note relationships between skills in their documentation.

• Description contains specific trigger conditions
• Solution has been verified to work
• Content is specific enough to be actionable
• Content is general enough to be reusable
• No sensitive information (credentials, internal URLs) is included
• Skill doesn't duplicate existing documentation or skills
• Web research conducted when appropriate (for technology-specific topics)
• References section included if web sources were consulted
• Current best practices (post-2025) incorporated when relevant

• Over-extraction: Not every task deserves a skill. Mundane solutions don't need preservation.
• Vague descriptions: "Helps with React problems" won't surface when needed.
• Unverified solutions: Only extract what actually worked.
• Documentation duplication: Don't recreate official docs; link to them and add what's missing.
• Stale knowledge: Mark skills with versions and dates; knowledge can become outdated.

1. Creation: Initial extraction with documented verification
2. Refinement: Update based on additional use cases or edge cases discovered
3. Deprecation: Mark as deprecated when underlying tools/patterns change
4. Archival: Remove or archive skills that are no longer relevant

getServerSideProps

• Problem: Server-side errors don't appear in browser console
• Non-obvious aspect: Expected behavior for server-side code in Next.js
• Trigger: Generic error page with empty browser console

• Found official docs on error handling
• Discovered recommended patterns for try-catch in data fetching
• Learned about error boundaries for server components

---
name: nextjs-server-side-error-debugging
description: |
  Debug getServerSideProps and getStaticProps errors in Next.js. Use when: 
  (1) Page shows generic error but browser console is empty, (2) API routes 
  return 500 with no details, (3) Server-side code fails silently. Check 
  terminal/server logs instead of browser for actual error messages.
author: Claude Code
version: 1.0.0
date: 2024-01-15
---

• Page displays "Internal Server Error" or custom error page
• Browser console shows no errors
• Using getServerSideProps, getStaticProps, or API routes
• Error only occurs on navigation/refresh, not on client-side transitions

1. Check the terminal where

   npm run dev

   is running—errors appear there
2. For production, check server logs (Vercel dashboard, CloudWatch, etc.)
3. Add try-catch with console.error in server-side functions for clarity
4. Use Next.js error handling: return

   { notFound: true }

   or

   { redirect: {...} }

   instead of throwing

• This applies to all server-side code in Next.js, not just data fetching
• In development, Next.js sometimes shows a modal with partial error info
• The

  next.config.js

  option

  reactStrictMode

  can cause double-execution that makes debugging confusing

• Next.js Data Fetching: getServerSideProps
• Next.js Error Handling

undefined

1. Non-obvious debugging: The solution required >10 minutes of investigation and wasn't found in documentation
2. Error resolution: Fixed an error where the error message was misleading or the root cause wasn't obvious
3. Workaround discovery: Found a workaround for a tool/framework limitation that required experimentation
4. Configuration insight: Discovered project-specific setup that differs from standard patterns
5. Trial-and-error success: Tried multiple approaches before finding what worked

• User runs

  /claudeception

  to review the session
• User says "save this as a skill" or similar
• User asks "what did we learn?"

• "Did I just spend meaningful time investigating something?"
• "Would future-me benefit from having this documented?"
• "Was the solution non-obvious from documentation alone?"