paulasilvatech What context do you need
Before answering a codebase question, produce a concise evidence request that separates must-see files from helpful files, already-seen context, and remaining uncertainty so the next answer can be grounded.
When to invoke
- "What context do you need before answering?"
- "Which files should I send you?"
- "Tell me what you need to inspect first."
- "What code would help you debug this?"
- "What files are required for an accurate review?"
Context selection criteria
| Question type | Must see | Should see |
|---|---|---|
| Bug or exception | Failing file, stack trace location, caller, tests covering the behavior, and relevant config. | Logs with secrets removed, recent diff, related error handling utilities. |
| Feature implementation | Target module, adjacent similar feature, public interface, tests, and config or route registration. | Product spec, API docs, database schema, fixtures, UI snapshots. |
| Refactor | Current implementation, call sites, tests, type definitions, and build/lint constraints. | Architecture docs, deprecated alternatives, performance notes. |
| Code review | Diff or changed files, tests changed or omitted, risky dependencies, and validation output. | Related modules and issue/PR context. |
| Architecture question | Entry points, module boundaries, dependency wiring, configuration, and data flow. | Diagrams, ADRs, deployment files, observability setup. |
File request rules
- Ask for paths, not pasted blobs, when repository access is available.
- Prefer the smallest set that can disprove a wrong answer.
- Include tests whenever behavior, regressions, or refactors are involved.
- Include configuration when behavior depends on routing, dependency injection, build tools, environment variables, feature flags, or package versions.
- Mark generated, vendored, build output, and dependency directories as unnecessary unless the question is specifically about them.
- Note files already seen in the conversation so the user does not resend them.
- State uncertainty explicitly instead of answering from assumptions.
Output template
## Files I Need
### Must See (required for accurate answer)
- `path/to/file.ts` — <why this file is required>
### Should See (helpful for complete answer)
- `path/to/file.ts` — <why this file would improve confidence>
### Already Have
- `path/to/file.ts` — <from earlier in conversation or current context>
### Uncertainties
- <what remains unknown without the requested code>
After you provide these files, ask the question again with any error text or validation output.
Quality gate
- The response does not answer the underlying technical question prematurely.
- Must-see files are limited to evidence required for an accurate answer.
- Should-see files are useful but not blockers.
- Already-seen files are listed when known.
- Each requested file has a concrete reason.
- Uncertainties describe what cannot be known yet.
- The output follows the
## Files I Needstructure exactly.