dig
Clarify ambiguities in plans with structured questions and auto-decide rules
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Clarify ambiguities in plans with structured questions and auto-decide rules
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Process issues sequentially: /dev per issue in isolated sub-agent → CI wait → merge → next
E2E development: investigate → dig → decompose → implement → test → review → PR
Break a task into ordered subtasks with dependencies
Investigate codebase for an issue in a forked context (context isolation)
Audit codebase for tech debt, code quality, and architecture issues — then create GitHub Issues
Create a pull request for the current branch using the project's PR template
| name | dig |
| description | Clarify ambiguities in plans with structured questions and auto-decide rules |
| user-invocable | true |
| allowed-tools | ["ToolSearch"] |
Resolve ambiguities before implementation by generating structured questions with options. Auto-decides choices that follow established project patterns.
From the investigation results, identify every decision point:
| # | Ambiguity | Category | Auto-decidable? |
|---|---|---|---|
| 1 | ... | architecture / api-design / data-flow / concurrency / error-handling / naming / testing | yes/no |
For auto-decidable ambiguities, check the project's CLAUDE.md, rules/*.md, and existing codebase patterns to determine the answer.
How to auto-decide:
Common decision categories:
For non-auto-decidable ambiguities:
For non-auto-decidable ambiguities in the architecture, api-design, or concurrency categories, consult Codex for alternative approaches before asking the user.
Skip this step for: naming, testing, error-handling, data-flow categories (these are resolved by codebase patterns or user preference).
ToolSearch("select:mcp__codex__codex")
mcp__codex__codex(
prompt: "Given these unresolved design decisions, explore alternatives:
## Ambiguities
{list of non-auto-decidable architecture/api-design/concurrency ambiguities with their options}
## Codebase Context
{relevant patterns from Step 2, existing conventions}
For each ambiguity:
1. Evaluate the proposed options
2. Suggest any additional alternatives not yet considered
3. Recommend the best option with reasoning
4. Flag any risks or trade-offs"
)
Incorporate Codex recommendations into the options presented to the user in Step 4.
If ToolSearch fails to find Codex or the call errors:
Present remaining unknowns with AskUserQuestion:
## Dig Results: {requirement}
### Auto-Decided
| # | Decision | Rule | Result |
|---|----------|------|--------|
| 1 | Where to place X | CLAUDE.md: "feature code in src/features/" | src/features/x/ |
### Investigated
| # | Decision | Finding | Result |
|---|----------|---------|--------|
| 2 | Error handling approach | Existing pattern in src/api/client.kt uses Result<T> | Result<T> |
### User-Decided
| # | Decision | Choice | Reason |
|---|----------|--------|--------|
| 3 | Public API surface | Option A: minimal | user preference |
### Assumptions (if any)
| # | Assumption | Risk |
|---|-----------|------|