← ClaudeAtlas

inspecting-applisted

Use when the user wants to check or audit something against existing rules or conventions, scoped to one of the project's managed apps, e.g. "audit this module", "check if X follows the rules" — not for open-ended research into how something currently behaves with no rule in question (investigating-app), diagnosing a reported failure (troubleshooting-app), or implementing a fix (`boss-say`).
wayne930242/straw-boss · ★ 4 · Testing & QA · score 77
Install: claude install-skill wayne930242/straw-boss
## Overview See `docs/roles.md` for the cast of characters and the authority framework this skill operates under — not redefined here. Resolve the app, decide the execution tier (`boss-say`'s Task 1 — a plain subagent running your own `inspecting` skill, or a dispatched agent rooted in the app), then let the actual audit run. This skill doesn't reimplement audit methodology either way. ## Task 1: Resolve the app Invoke `work-on` now. Do not proceed without the target app. - If `work-on` asked a clarifying question (an ambiguous name matching more than one app's `match` phrases) or found the request out of the project's managed-app scope, stop here and surface that to the user — don't guess an app to keep moving. - If `work-on` named more than one app, treat Task 2 as running once per app rather than picking one arbitrarily; each app's audit is independent. **Verification:** the target app(s) are established before Task 2, or you've surfaced `work-on`'s clarifying question / out-of-scope result instead of proceeding. ## Task 2: Decide the tier, then hand off Apply `boss-say`'s execution-tier judgment (its Task 1), per app: does this audit need the app's own harness (its real `.claude/rules/`/`CLAUDE.md`, and possibly its own local audit skill), or is your own global `inspecting` skill, run right here, enough? - **Solo:** invoke your `inspecting` skill directly in this session (once per resolved app if `work-on` named more than one), giving it the resolved app's direct