Run any Skill in Manus with one click

inspect-module

Stars2

Forks0

UpdatedMay 30, 2026 at 14:54

Use this skill whenever the user mentions "explore", "inspect", "understand", "what does X do", "where is Y", or before adding a new feature in an unfamiliar area. Produces a structured map of one module — files, exports, dependencies, layer assignment, and recent commits — without reading the entire codebase. Always invoke this skill before editing an unfamiliar module so the agent has accurate context, not guesses.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

tuanle96

tuanle96/zca-rust

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

4 files

SKILL.md

readonly

name	inspect-module
description	Use this skill whenever the user mentions "explore", "inspect", "understand", "what does X do", "where is Y", or before adding a new feature in an unfamiliar area. Produces a structured map of one module — files, exports, dependencies, layer assignment, and recent commits — without reading the entire codebase. Always invoke this skill before editing an unfamiliar module so the agent has accurate context, not guesses.
allowed-tools	Read, Glob, Grep, Bash(git log:), Bash(git ls-tree:), Bash(tree:), Bash(node .claude/skills/inspect-module/scripts/module-summary.mjs:)
suggested-turns	6

When to use

The user asked any of: "how does X work", "what's in src/foo", "before I add feature Y, what's in the area?", "explore ", "show me the shape of ".

Steps

Resolve the target. If the user gave a feature name (not a path), grep .harness/feature_list.json for it. If multiple paths match, ask the user which.
One-shot summary (deterministic). Run the side-car script — bundles target kind + layer + recent commits, and for module targets also exports + inbound + outbound deps, into one JSON blob, replacing three LLM turns of grep:
```
node .claude/skills/inspect-module/scripts/module-summary.mjs <target>
```
Read the JSON. If targetKind is workspace, render a workspace overview from workspace.domains and do not warn about layer: null. If targetKind is unlayered, the path is outside any configured layer root — flag that and ask whether the user wants to add it. If targetKind is module, use the reported layer normally.
Forward-only check. For targetKind: "module", walk outbound[] and verify each crosses layers forward only (never backward). The structural test enforces this mechanically too, but flagging here short-circuits a wasted write step.
Risks. Flag any of: dynamic imports, eval, shell-out with interpolation, missing tests for an exported function. (LLM judgment — the side-car reports facts, not risks.)

Output contract

Produce a Markdown report with these sections, in this order:

For targetKind: "workspace":

### Module: workspace overview
### Layer: workspace overview
### Domains: <domain roots and layers>
### Recent changes: <top 3 commit messages>
### Risks: <bulleted list, "none" if clean>

For module or unlayered targets:

### Module: <path>
### Layer: <layer-name or unlayered>
### Public surface: <list>
### Inbound deps: <list of paths>
### Outbound deps: <list of paths or external packages>
### Recent changes: <top 3 commit messages>
### Risks: <bulleted list, "none" if clean>

End with: "I am ready to make changes to <module>. The architecture-reviewer subagent will be invoked on completion."

Anti-patterns

Don't read every file in the module — sample exports, then drill in only where the user's task points.
Don't propose changes in this skill. This is read-only context-gathering.

More from this repository

same repository

add-adr

tuanle96/zca-rust

Use this skill whenever a decision is made about architecture, dependencies, frameworks, naming conventions, or layer order. Creates a numbered ADR (Architecture Decision Record) in `.harness/docs/adr/` in the canonical Nygard format. Always invoke this before changing layer order, adding a layer, swapping a major dependency, or introducing a new external service.

2026-05-302

add-feature

tuanle96/zca-rust

Use this skill whenever the user asks to add, implement, or build a new feature, capability, endpoint, page, command, or anything user-visible. Enforces the Anthropic two-fold harness pattern — read .harness/feature_list.json, pick exactly one feature, implement incrementally, run the structural test on every save, and never declare "done" without updating the JSON. Always invoke this skill instead of writing new feature code freehand.

2026-05-302

debug-flow

tuanle96/zca-rust

Use this skill whenever the user reports a bug, unexpected output, or "this doesn't work". Runs the dev server, drives the failing flow via Playwright MCP if installed (else captures stdout/stderr), and produces a minimal repro before any fix. Mirrors the OpenAI Chrome-DevTools-Protocol-into-runtime pattern at solo scale — verify the failure before you propose a fix.

2026-05-302

deliver-html

tuanle96/zca-rust

Use this skill whenever the user asks to analyze, audit, review, summarize, produce a report, write a plan, make a proposal, draft a decision doc, list "next actions", or any other task that produces a DOCUMENT a HUMAN reads-and-acts-on. Outputs a self-contained <slug>.html at repo root using the shared dark-theme CSS. Why HTML and not Markdown: golden principle #9 — Markdown is great for files an agent reads-and-edits (CLAUDE.md, SKILL.md, ADRs), but a HUMAN reading a 700-line MD deliverable will scroll, miss the conclusion, and ask the agent to clarify — burning turns and tokens. HTML deliverable is read once, decided once. Do NOT use this skill for files the agent itself reads (those stay MD), for stdout output from /review-this-pr or /garbage-collection (pass-through MD), or for short summaries under ~30 lines (overhead not worth it).

2026-05-302

doc-drift-scan

tuanle96/zca-rust

Use this skill weekly, before releases, or when the user mentions "stale docs", "doc drift", "docs are wrong", or "the README is out of date". Cross-checks every code path, file path, and command referenced in `.harness/docs/` and `CLAUDE.md` against the current repo state and produces a list of stale references — the doc-gardening agent pattern.

2026-05-302

eval-runner

tuanle96/zca-rust

Use this skill whenever a skill, subagent, or hook is changed, before merging to main, or when the user mentions "eval", "regression test for the harness", or "is the harness still working". This skill is a thin wrapper — it runs a single shell command (`npm run harness:eval` or `python -m harness.eval_runner`) and summarizes the JSONL output. Do not implement the eval logic yourself; the runner is already deterministic.

2026-05-302

name	inspect-module
description	Use this skill whenever the user mentions "explore", "inspect", "understand", "what does X do", "where is Y", or before adding a new feature in an unfamiliar area. Produces a structured map of one module — files, exports, dependencies, layer assignment, and recent commits — without reading the entire codebase. Always invoke this skill before editing an unfamiliar module so the agent has accurate context, not guesses.
allowed-tools	Read, Glob, Grep, Bash(git log:), Bash(git ls-tree:), Bash(tree:), Bash(node .claude/skills/inspect-module/scripts/module-summary.mjs:)
suggested-turns	6

When to use

The user asked any of: "how does X work", "what's in src/foo", "before I add feature Y, what's in the area?", "explore ", "show me the shape of ".

Steps

Resolve the target. If the user gave a feature name (not a path), grep .harness/feature_list.json for it. If multiple paths match, ask the user which.
One-shot summary (deterministic). Run the side-car script — bundles target kind + layer + recent commits, and for module targets also exports + inbound + outbound deps, into one JSON blob, replacing three LLM turns of grep:
```
node .claude/skills/inspect-module/scripts/module-summary.mjs <target>
```
Read the JSON. If targetKind is workspace, render a workspace overview from workspace.domains and do not warn about layer: null. If targetKind is unlayered, the path is outside any configured layer root — flag that and ask whether the user wants to add it. If targetKind is module, use the reported layer normally.
Forward-only check. For targetKind: "module", walk outbound[] and verify each crosses layers forward only (never backward). The structural test enforces this mechanically too, but flagging here short-circuits a wasted write step.
Risks. Flag any of: dynamic imports, eval, shell-out with interpolation, missing tests for an exported function. (LLM judgment — the side-car reports facts, not risks.)

Output contract

Produce a Markdown report with these sections, in this order:

For targetKind: "workspace":

### Module: workspace overview
### Layer: workspace overview
### Domains: <domain roots and layers>
### Recent changes: <top 3 commit messages>
### Risks: <bulleted list, "none" if clean>

For module or unlayered targets:

### Module: <path>
### Layer: <layer-name or unlayered>
### Public surface: <list>
### Inbound deps: <list of paths>
### Outbound deps: <list of paths or external packages>
### Recent changes: <top 3 commit messages>
### Risks: <bulleted list, "none" if clean>

End with: "I am ready to make changes to <module>. The architecture-reviewer subagent will be invoked on completion."

Anti-patterns

Don't read every file in the module — sample exports, then drill in only where the user's task points.
Don't propose changes in this skill. This is read-only context-gathering.