investigating-applisted

## 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 `investigating` skill, or a dispatched agent rooted in the app), then let the actual research run. This skill doesn't reimplement investigation 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 research 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 research need the app's own harness, or is your own global `investigating` skill, run right here, enough? - **Solo:** invoke your `investigating` skill directly in this session (once per resolved app if `work-on` named more than one), giving it the resolved app's directory as known context. - **Dispatch:** send it through