القائمة
Explain how something works in this codebase by exploring code and producing a clear architectural explanation. Optionally critique the architecture for issues.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Locate and inspect local data for the Copilot personal finance macOS app. Use when the user wants to find Copilot app data, inspect budgets, transactions, balances, or explain why the budget view differs from cash leaving a bank account.
Check how much has been spent on Pi sessions for a given day, broken down by model and project. Use when the user asks about Pi costs, spending, or token usage.
Create a visual explanation of the current session diff as a single HTML page and show it in a native Glimpse window. Use when the user wants a visual walkthrough of local code changes instead of a plain text diff.
Search, create, and manage pages in the Saffron Health Notion workspace. Use when the user asks about Notion tasks, notes, projects, or wants to interact with Notion databases.
استنادا إلى تصنيف SOC المهني
| name | how |
| description | Explain how something works in this codebase by exploring code and producing a clear architectural explanation. Optionally critique the architecture for issues. |
Explore the codebase to answer "how does X work?" questions. Produce clear 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.
Two modes:
This skill uses Pi's tools as follows:
bash with find, ls, or rg (ripgrep)bash with rgfinder for complex multi-step code searchesreadtask — Pi does not support per-subagent model selection, so all tasks run on the session's model. For critique mode, this means you lose model diversity (the original design uses different models for independent perspectives). Compensate by giving each critic a distinct analytical lens in their prompt.All subagent task prompts must include an explicit instruction: "Do NOT modify any files. This is a read-only exploration task."
Parse what the user is asking about. They might say:
Identify the scope. If it's ambiguous, make your best guess and state your interpretation before exploring. Don't ask — explore and let the user redirect if you're off.
Assess complexity to decide the approach:
When in doubt, lean toward the simple path — you can always spawn explorers if the explainer hits a wall.
Decompose the question into 2-4 parallel exploration angles. Each angle should cover a distinct slice of the subsystem so the explorers aren't duplicating work. For example, if the question is "how does message virtualization work?", you might split into:
The right decomposition depends on the question — use your judgment. For narrow questions, 2 explorers is fine. For broad subsystems, use up to 4.
Spawn all explorers as parallel task calls in a single message. Each explorer gets the same base prompt from references/explorer-prompt.md, plus a specific exploration angle telling it which slice to focus on. Each explorer should:
bash with find/rg for relevant directories, search for key types/interfaces/class namesEach explorer returns structured findings: the components it found, the flow it traced, the files it read, and anything non-obvious. Overlap between explorers is fine — the explainer will reconcile.
Then proceed to Step 3.
Spawn a single task subagent that explores and explains in one pass. This agent does its own exploration (using bash with find/rg, read, and finder) and writes the explanation directly. Read references/explainer-prompt.md for the communication style and output format — the agent follows the same structure, it just doesn't have explorer findings as input.
Proceed to Step 4.
Once all explorers have returned, spawn a single task subagent to synthesize their findings into one coherent explanation. The explainer gets all explorers' findings and writes the human-facing explanation (see output format below). Read references/explainer-prompt.md for the full prompt template. The explainer reconciles overlapping findings, resolves contradictions, and weaves the separate slices into a unified picture.
Take the explainer's output and present it to the user. You may lightly edit for clarity or add context from the conversation, but don't substantially rewrite — the explainer agent's communication is the product.
The explanation should follow this structure, but adapt it to what makes sense for the question. Not every section is needed for every question.
Overview — 1-2 paragraphs. What is this thing, what does it do, why does it exist. Someone should be able to read this and decide whether they need to keep reading.
Key Concepts — The important types, services, or abstractions. Brief definition of each, not exhaustive — just the ones needed to understand the rest.
How It Works — The core of the explanation. Walk through the flow: what triggers it, what happens step by step, where does data go, what are the decision points. Use prose, not pseudocode. Reference specific files and functions so the reader can go look, but don't dump code blocks unless a specific snippet is genuinely necessary to understand the point.
Where Things Live — A brief map of the relevant files/directories. Not every file — just the ones someone would need to find to start working in this area.
Gotchas — Things that are non-obvious, surprising, or that would trip someone up. Historical context that explains why something looks weird. Known sharp edges.
Triggered when the user asks for architectural issues, problems, or improvements — not just understanding.
Run the full explain flow above (Steps 1-4). You need to understand the architecture before you can critique it.
After the explanation is complete, spawn 3 architectural critics as parallel task calls in a single message.
Since Pi doesn't support per-subagent model selection (the original skill uses different LLM models for diversity of perspective), compensate by giving each critic a distinct analytical focus:
| Critic | Focus |
|---|---|
| Critic A | Abstraction Fit + Boundary Discipline (from rubric) |
| Critic B | Data Model + Complexity vs. Value (from rubric) |
| Critic C | Evolution Readiness + Consistency (from rubric) |
Each critic is allowed to comment on anything, but their assigned lenses are where they should go deepest.
Read references/critic-prompt.md for the prompt template. Each critic gets:
references/critique-rubric.mdYou're a pragmatic lead, not an aggregator.
Categorize findings:
Present the explanation first (from Step 1), then the critique verdict below it. The explanation should stand on its own — someone who just wants to understand the system shouldn't have to wade through critique.