From skills-alena
Use when the user wants a learning-first walkthrough, tutorial-style implementation guidance, or /lmf behavior before or alongside execution.
npx claudepluginhub radenadri/skills-alenaThis skill uses the workspace's default tool permissions.
This skill turns a request into a tutorial-first response that teaches the user what is happening before pushing them straight into implementation. It wraps `brainstorming`, `writing-plans`, and `writing-documentation` into one repeatable flow so `/lmf` can stay educational without becoming vague.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Performs token-optimized structural code search using tree-sitter AST parsing to discover symbols, outline files, and unfold code without reading full files.
This skill turns a request into a tutorial-first response that teaches the user what is happening before pushing them straight into implementation. It wraps brainstorming, writing-plans, and writing-documentation into one repeatable flow so /lmf can stay educational without becoming vague.
/lmf is also the manual-coding alternative to /execute: it should explain the work, show the shape of the implementation, and include copyable code blocks when code would help the user type the solution themselves instead of having the agent apply it automatically.
Core principle: Teach the mental model first, then the implementation path, then the concrete next action.
WHEN /LMF IS ACTIVE, EXPLAIN THE MENTAL MODEL BEFORE PRESCRIBING THE STEPS.
/lmfexecuting-plans)systematic-debugging)writing-documentation)YOU CANNOT:
- Lead with code dumps before explaining the problem shape and recommended path
- Skip the mental model and jump straight to a checklist
- Repeat the underlying skills verbatim without synthesizing them for the user's task
- Hide uncertainty behind confident tutorial language -- call out assumptions explicitly
- Produce a generic lesson disconnected from the current codebase or request
- Turn /lmf into a helper-script instruction -- it must work through direct agent output
- Overwhelm the user with exhaustive theory when a shorter explanation would teach faster
- Claim the user is "ready to implement" without giving concrete next actions
- Omit copyable code when the user clearly needs to type the implementation by hand
- Use placeholder snippets, ellipses, or pseudo-code where real code is needed to teach the implementation
| Rationalization | Reality |
|---|---|
| "They asked for help, so I'll just give them the final code" | /lmf exists to teach before it ships code, not to avoid code entirely. |
| "The concepts are obvious" | If they invoked /lmf, the concepts are not obvious enough yet. |
| "I'll explain after the steps" | Once the user is buried in steps, the teaching value is lost. |
| "A long theory dump is more educational" | Good teaching is selective, not bloated. |
| "The wrapper skill can just point to other skills" | A wrapper that does not synthesize is not doing its job. |
| "This request is too practical for tutorial mode" | Practical requests are exactly where explanation-first guidance matters. |
| "If I include code, it stops being /lmf" | /lmf should include code when the code helps the user learn and implement manually. |
1. What is the one-sentence problem framing for this request? (state it plainly)
2. What mental model does the user need before touching implementation? (name it)
3. Which assumptions am I making because the request or codebase does not prove them yet? (list them)
4. Which existing codebase facts support the guidance I am about to give? (cite files or note when none exist)
5. What is the recommended path, and why is it the best trade-off for this specific request? (explain the trade-off)
6. What are the first concrete actions the user can take after reading this? (list them)
7. Did I teach the "why" before the "do this" instructions? (show the section order)
8. Did I keep the explanation specific to the request instead of generic tutorial filler? (prove it)
9. If I included code, does each snippet clarify a concept and give the user something real to type? (justify it)
10. Can the user act on this output immediately without needing another translation step? (state how)
1. IDENTIFY the user's actual job to be done, not just the literal wording.
2. READ the relevant local files or plan documents so the tutorial reflects real context.
3. STATE the problem in one sentence and call out any material uncertainty.
1. APPLY brainstorming logic to clarify the goal, trade-offs, and scope boundaries.
2. APPLY writing-plans logic to produce an implementation path with ordered actions.
3. APPLY writing-documentation logic to make the response readable to someone with zero context.
4. SYNTHESIZE the result into one response -- do not hand the user three disconnected mini-docs.
1. EXPLAIN the mental model first -- what this is, why it matters, and how to think about it.
2. GIVE the recommended approach second -- what path to take and why this path wins.
3. BREAK the work into concrete steps third -- ordered, actionable, and scoped.
4. INCLUDE code when it reduces ambiguity, teaches a non-obvious concept faster, or lets the user implement the change manually.
5. WHEN code is needed, prefer complete, copyable code blocks over pseudo-code or placeholder fragments.
1. END with the exact next move the user can take.
2. IF implementation is requested, bridge cleanly into execution instead of repeating the lesson.
3. IF documentation is requested, leave the user with wording or structure they can directly adopt.
4. IF the user wants to code manually, give them the exact files and code blocks they can type in themselves.
Use this structure unless the user asks for a different shape:
# /lmf
## What This Actually Is
[Plain-English framing]
## Mental Model
[How to think about the problem]
## Recommended Path
[Approach and trade-off]
## Step-by-Step
1. [Concrete action]
2. [Concrete action]
3. [Concrete action]
## Copyable Code
[Only include when code is needed to implement or clarify the request.
Prefer complete fenced blocks per file, with file names and no placeholder ellipses.]
## Next Move
[Immediate follow-up action]
When the request is implementation-oriented, /lmf should usually include a Copyable Code section after the explanation. The section should:
..., TODO, or "fill this in"/lmf as a synonym for /plan or /doc without the learning-first layerbrainstorming provides the reasoning backbone for the teaching flow.writing-plans turns the explanation into an actionable path.writing-documentation keeps the output readable and reusable.executing-plans takes over when the user wants to move from tutorial mode into implementation.