hello
Show a nice greeting message with a timestamp. Use this when the user wants to greet or say hello, optionally to a certain subject <subject> and in a certain…
Five-Whys Root-Cause Analysis.
$ npx -y skills add rse/ase --skill ase-meta-why --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/ase-meta-whyContext preview
The summary Claude sees to decide when to auto-load this skill.
Five-Whys Root-Cause Analysis.
name: ase-meta-why
argument-hint: "[--help|-h] [--depth|-d <N>] [--width|-w <M>] <fact>"
description: >
Five-Whys Root-Cause Analysis.
user-invocable: true
disable-model-invocation: false
effort: high@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
<purpose name="ase-meta-why"> Five-Whys Root-Cause Analysis </purpose>
<expand name="getopt" arg1="ase-meta-why" arg2="--depth|-d=5 --width|-w=1"> $ARGUMENTS </expand>
<objective> Apply the *Five-Whys* *root-cause analysis* technique to investigate the following problem:
<problem>Why <getopt-arguments/>?</problem>
For this, iteratively ask "why" to drill down from symptoms to the root-cause. This helps to identify the fundamental reason behind a problem rather than just addressing surface-level symptoms. </objective>
<flow>
1. <step id="STEP 1: Restate Problem">
<if condition="<getopt-arguments/> is empty"> Only output the following <template/> and then immediately *STOP* processing the entire current skill:
<template> ⧉ **ASE**: ✪ skill: **ase-meta-why**, ▶ ERROR: expected a `<fact>` argument </template> </if>
State the problem statement.
<template> <ase-tpl-bullet-signal/> **PROBLEM**: <problem/> </template>
</step>
2. <step id="STEP 2: Root-Cause Analysis">
Find the root-cause of <problem/> by following this iteration cycle. Start with a <question/> set equal to the <problem/>.
Determine the *maximum chain length* from <getopt-option-depth/>: set <depth/> to <getopt-option-depth/>; if <getopt-option-depth/> is *non-numeric* or *less than or equal to 0*, use the default *5* instead.
Determine the *maximum chain width* from <getopt-option-width/>: set <width/> to <getopt-option-width/>; if <getopt-option-width/> is *non-numeric* or *less than or equal to 0*, use the default *1* instead.
Walk a *single* causality chain (the classic Five-Whys):
Start with <n>1</n> (set iteration counter to one).
<while condition="<n/> is less than or equal to <depth/>">
Ask <question/> and document the answer in <answer/> with the following template. Don't stop at symptoms; keep digging for systemic issues. Consider technical, domain-specific, process-related, or organizational causes.
<template> <ase-tpl-bullet-secondary/> **WHY <n/>**: <answer/> </template>
Then, for the next iteration, set <question/> now to be the last <answer/>. The magic is NOT in exactly <depth/> "Whys" -- you can <break/> the iteration when you have already reached the root-cause. Finally, set <n/> to <n/> + 1 (increment iteration counter).
</while>
</if>
Walk a *widened* causality chain: at each "why" level, surface up to <width/> *candidate* sub-causes, then commit to the single most significant one and descend into it (the chain stays single-rooted -- the extra candidates are *not* each drilled to their own root-cause). Their purpose is to guard against *premature commitment* to the wrong sub-cause: by enumerating the plausible alternatives at each level, the chosen descent is a *justified* selection rather than the first plausible answer, and the unchosen candidates remain on record as *fallbacks* to backtrack into (see STEP 3) should the chosen path fail validation.
Remember the *unchosen* candidates of every level (keep them in <fallbacks/>, tagged by their level <n/>), so STEP 3 can backtrack into them.
Start with <n>1</n> (set iteration counter to one).
<while condition="<n/> is less than or equal to <depth/>">
Ask <question/> and surface up to <width/> *distinct*, *non-overlapping* candidate sub-causes, each documented in <answer-k/>. Let <count/> be the number of candidates you actually surfaced (at least one, at most <width/>). Don't stop at symptoms; keep digging for systemic issues. Explore *different* candidates -- technical, domain-specific, process-related, or organizational causes -- and avoid restating the same cause in different words.
Start with <k>1</k> (set candidate counter to one). <while condition="<k/> is less than or equal to <count/>"> <template> <ase-tpl-bullet-secondary/> **WHY <n/>.<k/>**: <answer-k/> </template> Set <k/> to <k/> + 1 (increment candidate counter). </while>
Then choose, among the <answer-k/>, the *most causally-significant* candidate -- the one most likely to lead to the true root-cause -- set <chosen-k/> to its candidate index (the <k/> of the chosen <answer-k/>), and *justify* the choice in one line (state explicitly *why* it beats the other candidates, e.g. it alone also explains the timing, scope, or magnitude of the level's fact). A bare "most significant" is *not* sufficient; if no candidate clearly dominates, say so.
<template> <ase-tpl-bullet-secondary/> **WHY <n/> → chosen <n/>.<chosen-k/>**: <justification/> </template>
Record the remaining candidates as <fallbacks/> for level <n/>. Then, for the next iteration, set <question/> to the chosen candidate. You can <break/> the iteration when the chosen candidate has already reached its root-cause. Finally, set <n/> to <n/> + 1 (increment iteration counter).
</while>
</if>
Repo: rse/ase
Show a nice greeting message with a timestamp. Use this when the user wants to greet or say hello, optionally to a certain subject <subject> and in a certain…
Review software architecture, including package cohesion and inter-package coupling
Discover additional, third-party components (libraries/frameworks) for the technology stack to provide needed functionality.
Analyze the source code for problems in either the logic and semantics and its related control flow, performance and efficiency, or security.
Craft Source Code: Use when user wants to "create", "add", or "craft" a new feature from scratch.
Dissect the current Git change set, treated as an epic, domain-wise and logically into cohesive parts and materialize each part in its own dedicated Git…