Whatelse

What Else

Perform an evidence-backed, read-only exploration of the current project. The goal is not to produce a generic code review, but to expose the gap between the project's documented map and its actual territory.

Operating boundary

• Use the current working directory as the target unless the user names another path.
• Remain read-only unless the user explicitly asks to fix findings.
• Read applicable AGENTS.md, CLAUDE.md, README files, and local instructions before analysis.
• Inspect real evidence before drawing conclusions: source, tests, configuration, migrations, CI, deployment files, logs, git state, and recent history when available.
• Do not invent absent requirements or claim that something is missing before searching broadly enough to support that conclusion.
• Separate verified facts, inferences, and unresolved questions.

Exploration workflow

1. Establish the project map

Identify:

• purpose and user-visible outcomes;
• major modules, entry points, data flows, and external dependencies;
• build, test, deployment, migration, and runtime paths;
• declared architecture, constraints, ownership, and acceptance criteria;
• current git branch, working-tree state, recent commits, TODOs, and known issues.

Do not dump the whole repository. Collect only enough evidence to construct a reliable project map and cite concrete paths, symbols, commands, or runtime observations.

2. Compare the map with the territory

Trace a small number of critical paths from entry point to observable outcome. Look for contradictions between documentation, configuration, tests, implementation, and runtime assumptions.

Pay special attention to:

• behavior that exists but is undocumented;
• documented behavior that is not implemented or tested;
• duplicated rules that may drift;
• configuration defaults that differ across environments;
• error, rollback, migration, concurrency, security, observability, and recovery paths;
• modules with unclear ownership or no caller;
• tests that encode hidden requirements;
• user workflows with no faithful end-to-end verification;
• completion claims not supported by runtime evidence.

3. Classify findings into the four quadrants

Known Knowns

Facts the project explicitly states and evidence confirms. Record these briefly because they define the trusted map.

Known Unknowns

Open questions already visible in TODOs, issues, placeholders, undecided specifications, failing tests, or acknowledged risks. State what decision or evidence is still needed.

Unknown Knowns

Implicit knowledge that the project relies on but has not expressed clearly. Examples include conventions encoded only in tests, invariants repeated in code, deployment knowledge held in scripts, or quality criteria that become obvious only by viewing the real UI or runtime.

Unknown Unknowns

Blind spots the project does not currently acknowledge. Infer these only from evidence such as missing verification at a critical boundary, contradictory implementations, unobserved failure paths, silent data loss risks, stale assumptions, or gaps between local and production behavior.

For every Unknown Unknown, include confidence and the cheapest next probe that could confirm or reject it.

4. Prioritize by information value

Rank findings by:

1. potential impact if the assumption is wrong;
2. likelihood suggested by current evidence;
3. cost of obtaining decisive evidence;
4. whether the answer would change architecture, data models, public interfaces, user behavior, security, or release readiness.

Prefer a cheap discriminating probe over a large speculative fix.

Required output

Return the following structure in Chinese unless the user requests another language.

Project map

A concise description of the system, critical paths, and evidence inspected.

Unknowns map

Use a table with these columns:

ID	Quadrant	Finding	Evidence	Why it matters	Confidence	Next probe

Keep Known Knowns short. Spend most attention on Unknown Knowns and Unknown Unknowns.

Top blind spots

List the three to seven highest-priority blind spots in priority order. For each, explain what could be wrong, the evidence, and the smallest verification action.

What the repository cannot tell us

Explicitly list facts that require production runtime, user research, credentials, business decisions, external systems, or human confirmation.

Recommended exploration sequence

Provide an ordered set of read-only probes or experiments. Do not turn these into implementation tasks unless the user asks to proceed.

Quality bar

A successful run must:

• cite concrete evidence rather than generic best practices;
• distinguish absence of evidence from evidence of absence;
• include all four quadrants;
• identify at least one implicit invariant or hidden quality criterion when evidence supports it;
• identify blind spots without overstating certainty;
• recommend the cheapest next probe for each important uncertainty;
• avoid modifying the project.

If the repository is too small or evidence is insufficient, say so and return the most useful uncertainty map possible instead of manufacturing findings.

Method source

This workflow operationalizes the four-quadrant unknowns map described by Thariq in A Field Guide to Fable: Finding Your Unknowns. It applies the method to repository exploration and is not tied to a specific model or coding tool.