skills/why/SKILL.md
Analyze why Claude made its previous response. Trace reasoning to system prompt, CLAUDE.md, memory, skills, or context
npx skillsauth add abix-/claude-blueprints skills/whyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Analyze your most recent response (before this skill was invoked) and explain WHY you produced it. This is not about right/wrong. It is about tracing the reasoning chain so the user can identify what to change when behavior drifts.
/why was invoked)| Source | What to check |
|--------|--------------|
| System prompt | Built-in instructions from Anthropic (tool usage rules, tone, safety) |
| CLAUDE.md | User's global rules (~/.claude/CLAUDE.md) |
| Workspace CLAUDE.md | Repo-level rules (<repo>/CLAUDE.md) |
| Skill | A skill file that was loaded (~/.claude/skills/<name>/SKILL.md) |
| Memory | A memory file (~/.claude/projects/*/memory/) |
| Context | Something the user said in this conversation |
| Model default | Claude's training. Not from any instruction, just default behavior |
| Inference | You inferred/assumed something not explicitly stated anywhere |
Use this exact format:
CHOICE SOURCE EVIDENCE
------------------------------------------------------------------------------------------
used ASCII table format CLAUDE.md:24 "NEVER use Unicode...ALWAYS use ASCII"
ended with confidence rating CLAUDE.md:26 "ALWAYS end every response with..."
read file before editing system prompt "read it first...before suggesting modifications"
assumed user wanted X inference (no source -- I filled in a gap)
...
For each row:
Print a summary section:
GROUNDED: {n} choices traced to explicit instructions
INFERRED: {n} choices based on assumption or model default
If any choices were inferred, add:
INFERENCES:
- {choice}: {why you inferred this and what would have changed your behavior}
This section is the most valuable. It shows the user exactly where to add a rule or clarification to prevent future drift.
development
YAML standards for config files, Ansible playbooks, k8s manifests, GitHub Actions, docker-compose, and any project config. Built from the YAML 1.2 spec, yamllint defaults, and the practical pitfalls (Norway problem, type coercion, anchor gotchas).
development
--- name: ueforge description: ueforge framework: the base layer every UE4SS Rust mod in the Grounded2Mods workspace builds on. Authoritative on the composition model (Effect/Trigger/Skill), the Def/Registry/Instance/Controller pattern, hot reload, discovery, hardening doctrine, and the five framework modules (rpg, stacks, difficulty, inventory, damage). Use when writing or modifying code under `ueforge/` in [abix-/Grounded2Mods](https://github.com/abix-/Grounded2Mods), or when promoting a patte
tools
TypeScript and JavaScript standards. Sourced from [abix-/chromium-extensions](https://github.com/abix-/chromium-extensions) (Hush + filter-anything-everywhere). Use when writing TS/JS, including browser extension bootstrap shims, MV3 service workers, and small web frontends.
development
--- name: schedule1 description: Modding Schedule 1 (TVGS, IL2CPP Unity + MelonLoader + Harmony). Authoritative on Schedule 1 game specifics: engine type, MelonLoader/Il2CppInterop references, eMployee mod root-cause findings, vanilla CookRoutine + StartMixingStationBehaviour internals, certainty-tracking discipline. Mod code lives in [`abix-/Schedule1Mods`](https://github.com/abix-/Schedule1Mods) (the `EmployeeReset` sidecar is the current shipped mod). Not for playing the game. user-invocable: