メニュー
Behavioral guidelines to reduce common LLM investigation mistakes. Use when debugging, triaging incidents, tracing root cause, analyzing unexpected behavior, or answering "why is this happening" before changing code.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Generate an optimized AGENTS.md file after analyzing the directory/codebase for context.
Extract a system-first feature spec from code and documentation using Zachman dimensions (WHAT, HOW, WHERE, WHO, WHEN, WHY). Use when users request structured, implementation-grounded specs, architecture extraction, or system design context from an existing codebase and linked sources.
Transform a user's 'basic prompt' into an 'optimized prompt' by applying context engineering -> the right context beats the right prompt.
Verifies and sets up local Ollama — checks install, starts daemon, pulls model, verifies CORS and OpenAI-compatible endpoint. Client-agnostic; use before any skill that needs a working Ollama (e.g. enable-ollama-in-cursor). Use when the user wants Ollama running locally, needs to troubleshoot Ollama, or before configuring any client to use Ollama.
Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
Refactoring with KISS principles. Rethinks implementations to reach the same outcome with less complexity—prefers straightforward, readable code over clever abstractions. Use when refactoring, reviewing code, the user asks for a simpler approach, or when a solution feels over-engineered relative to the problem.
| name | investigation-guidelines |
| description | Behavioral guidelines to reduce common LLM investigation mistakes. Use when debugging, triaging incidents, tracing root cause, analyzing unexpected behavior, or answering "why is this happening" before changing code. |
| license | MIT |
Behavioral guidelines to reduce common LLM mistakes when investigating issues, derived from the same principles as coding-guidelines (simplicity, explicit assumptions, narrow scope, verifiable conclusions) and Andrej Karpathy's observations on LLM pitfalls applied to diagnosis instead of implementation.
Tradeoff: These guidelines bias toward evidence over speed. For obvious one-line fixes, use judgment.
Don't assume. Don't hide confusion. Separate facts from guesses.
Before chasing leads:
Minimum investigation that answers the question. Nothing theatrical.
Ask yourself: "Would a senior engineer say this investigation is unfocused?" If yes, narrow it.
Touch only what the investigation requires. Do not "fix" while diagnosing unless asked.
When exploring:
When your investigation produces noise:
The test: Every step should trace to a stated hypothesis or a missing piece of evidence.
Define what "answered" means. Close the loop with evidence.
Turn vague asks into verifiable outcomes:
For multi-step investigations, state a brief plan:
1. [Step] → verify: [what evidence confirms or rules out]
2. [Step] → verify: [what evidence confirms or rules out]
3. [Step] → verify: [conclusion supported by: ...]
Strong exit criteria let you stop without hand-waving. Weak criteria ("probably X") invite wrong fixes and rework.