fn-why

Explains a function's purpose, caller contract, and lifecycle phases.

1|Updated Sep 3, 2017
One-click install
npx skills add https://github.com/mmgeorge/config --skill fn-why-mmgeorge
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: fn-why
Source: https://github.com/mmgeorge/config/tree/main/rulesync-global/.rulesync/skills/fn-why
Command: npx skills add https://github.com/mmgeorge/config --skill fn-why-mmgeorge

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code explanations often devolve into line-by-line narration that misses why a function exists. This Skill grounds explanations in the controlling problem, caller contract, and failure boundaries so developers understand design intent rather than mechanics. ## Core Features & Use Cases - Problem-First Summaries: Opens every explanation with the hazard or contract the function controls, naming the function as the active subject. - Caller Contract Inspection: Uses semantic tools (sem_entities, sem_context, sem_impact) to inspect what callers rely on before drafting. - Structured Lifecycle Walkthrough: Groups execution into 2-3 architectural phases with a single closing sentence on atomicity and failure isolation. - Use Case: When onboarding to an unfamiliar codebase, ask why a core method like SessionStore::reconcile exists and receive a contract-focused explanation instead of a line-by-line recap. ## Quick Start Ask the AI to explain why a specific function exists using /fn-why followed by the function name.

Frequently Asked Questions about fn-why

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I explain what a function does without narrating every line?▼

Lead with the problem or contract the function controls, then group execution into 2-3 architectural phases. This Skill enforces that structure: a problem-first summary, a phased lifecycle flow, and one sentence on failure isolation.

How to understand a function's caller contract in a new codebase?▼

Inspect the entity with semantic tools, then pass its exact file path to an impact analysis tool to see what callers rely on, such as handle stability or error boundaries. The explanation is drafted only after that contract is identified.

What makes a good code explanation for design reviews?▼

A good explanation names the function as the active subject, states the invariant protecting system state, and describes the preserved consumer contract. It avoids parameter recitals, intermediate variable narration, and dummy subjects like "This function".

When should I not use a lifecycle walkthrough format?▼

Avoid it for trivial getters or single-line helpers where no invariant or caller contract exists. The format is designed for functions with meaningful pre-validation, state mutation, or failure boundaries worth isolating.