Use cases and examples

Recon is most useful after it has seen both an artifact and the reasoning around it. Use real work rather than a toy question.

Return to an implementation decision

Question: Why did we use a signed-in CLI subprocess instead of an agents SDK?

The useful answer is not only the selected implementation. It should explain the authentication constraint, which SDK path was rejected, the cost or trade-off of the subprocess, and which change would make the decision worth revisiting.

Avoid repeating a failed approach

Question: What did we already try before fixing the first-message loading state?

Recon can return the failed path and why it did not solve the user-visible problem, so a new session does not recommend the same attempt again.

Understand a production guard

Question: Why does Recon block ingestion from a linked git worktree?

The answer can connect the guard in code to the earlier duplication or database problem, the ticket that introduced it, and the work session that verified the fix.

Revisit a choice when its condition changes

Question: Which local-only decisions should we revisit now that a team needs shared memory?

Revisit conditions stay attached to their decisions. Recon can surface them when you ask. Recon Local does not currently run a proactive reminder inbox that checks every revisit condition for you.

Preserve non-code reasoning

If a selected document contains product research, customer notes, operating procedures, or a client decision, Recon can organize and recall it. Automatic in-session capture currently depends on supported Claude Code or Codex guidance, so do not assume every external meeting or app is recorded automatically.

What makes a good first question

• Ask about a decision you personally remember making.
• Include the feature, incident, customer, or work area in the wording.
• Prefer “why,” “what changed,” “what did we reject,” or “when should we revisit” over a generic keyword search.
• Open at least one receipt before trusting the answer.