how
Explore the codebase and explain how a subsystem, a feature or a flow works, as the architecture and runtime flow a senior engineer needs before working in it, with the files and functions to look at. Use for 'how does X work', a code walkthrough before changing code you do not know, and placement, ownership and layering questions ('where should this live', 'which package owns this', 'is this the right layer'). For why the code is the way it is, use discover:why. Not for a question that reading one function answers.
- License 许可
- Apache-2.0
- 所属仓库
- lyngon/devkit
- 最近更新
- 2026-11-14
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- how
- description
- Explore the codebase and explain how a subsystem, a feature or a flow works, as the architecture and runtime flow a senior engineer needs before working in it, with the files and functions to look at. Use for 'how does X work', a code walkthrough before changing code you do not know, and placement, ownership and layering questions ('where should this live', 'which package owns this', 'is this the right layer'). For why the code is the way it is, use discover:why. Not for a question that reading one function answers.
- argument-hint
- <the question, naming the code, subsystem or flow it is about>
02 资源文件 2
- 参考文档references/explainer-prompt.md3.0 KB
- 参考文档references/explorer-prompt.md2.7 KB
03 SKILL.md 正文
How
Explore the codebase to answer "how does X work?" questions. Produce architectural explanations at the level of a senior engineer onboarding onto a subsystem, enough to build a working mental model, not so much that it reads like annotated source code.
Explorers and the explainer are subagents that inherit the session's model. They read and search, and they change nothing.
Assess complexity
If the scope is ambiguous, state your interpretation and explore. The operator can redirect.
- Simple (a single module, a small utility, a narrow question such as "how does function X work"): no explorers. One explainer explores and explains in a single pass. Go to "Explain directly".
- Complex (a subsystem spanning multiple files or services, a cross-cutting feature, a full architectural overview): spawn parallel explorers first, then hand off to the explainer. Go to "Explore".
When in doubt, take the simple path.
Explore, for a complex question
Decompose the question into 2 to 4 exploration angles, each a distinct slice of the subsystem. Spawn all explorers in a single message, so that they run concurrently, and go on only once every finding is back.
Each explorer gets the prompt in references/explorer-prompt.md with its angle filled in.
Then go to "Synthesize".
Explain directly, for a simple question
Spawn one subagent that explores and explains in one pass.
Build its prompt from references/explainer-prompt.md without the explorer-findings section.
Go to "Present".
Synthesize, for a complex question
Once all explorers have returned, spawn one subagent to synthesize their findings into one explanation.
Build its prompt from references/explainer-prompt.md with every explorer's findings filled in.
Present
Once the explainer's output is back, present it to the operator. Light edits for clarity or context from the conversation are fine. Do not substantially rewrite it.
Output format
The explanation uses the sections defined in references/explainer-prompt.md, dropping any that do not apply: Overview, Key concepts, How it works, Where things live, Gotchas.
04 同仓库更多 Skills
unslop
Remove AI writing patterns from prose and give it a voice. Use whenever writing or editing non-code text (docs, READMEs, decision records, posts, commit messages, PR descriptions), before handing it over, and on request: "unslop", "humanize", "make this sound human", "clean up this writing", "edit for voice", "de-AI this text".
technical
Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use before writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages, every time, however small the document.
simpler
Restate the last message in plain human language, with no jargon. Use when the reader did not follow the last message and says so: "bro", "say that simpler", "in plain words", "no jargon".
init
Set up a fresh repository, or adopt an existing one, to Lyngon conventions. Interviews the owner relentlessly about purpose, failure modes, audiences, stack and constraints, then writes INTENT.md, .claude/CLAUDE.md, README.md, CONCEPTS.md, decision records, devenv, git hooks, CI and every package in the kind-first Lyngon layout. User-invoked only.
add-package
Create a package in a Lyngon repository in the directory its kind decides (apps/, libs/, contracts/, tools/, infra/), with README.md, devenv.nix and the layer lint, and register it in its workspace and devenv. Use whenever a new app, service, CLI, library, adapter, contract, schema, tool, infra module or environment is needed, including when one feature needs several packages. Never create a package by hand.
index
The index of Lyngon's principles, one line per principle saying when it applies and what it demands, each with a file under references/. Invoke before work that takes judgment, such as a design choice, a refactor, a bug fix, a test, a measurement, a script, a document or a question to the owner; then read the file of each principle that applies.