• New team members join the repository and need to quickly understand module boundaries, call chains, and entry files
• Users raise a specific question but do not require immediate solutions / fixes
• Conduct evidence-based exploration before feature-design / issue-analyze / issue-fix
• Technical directions are still under discussion, requiring lightweight spike (exploration only, no final decisions)

Refer to

easysdd/reference/shared-conventions.md

for shared paths and naming conventions. The output of this skill is written to

easysdd/compound/

, with file names formatted as

YYYY-MM-DD-explore-{slug}.md

, and frontmatter tagged with

doc_type: explore

.

reference.md

• Quick answers must appear before evidence—readers should see conclusions first when opening the document, then decide whether to read further for evidence
• Conclusions must be traceable to evidence; pure speculation is not allowed
• If evidence is insufficient, set

  confidence

  to

  medium

  or

  low

• When old explorations become outdated, mark the old document as

  outdated

  and create a new version for the current state

1. "What is the single most important question you want to answer first?"
2. "Which module / directory do you want to focus on?"

easysdd/reference/shared-conventions.md

• If the user mentions "update / review / a previous explore / this module was explored before" or explicitly points to an old explore document → directly follow the update or supersede path. The characteristic of explore is: when code changes render old conclusions invalid, mark the old document as

  status=outdated

  and create a new one (supersede); when only supplementing evidence / tightening conclusions but core conclusions remain unchanged, follow the "update existing entry" path
• Otherwise, use the "Search Tools" below to search by keywords / modules. If a similar old explore document is found, read it first. If it can directly answer the question, inform the user: "There is an available explore document at {path}. Do you want to reuse it or conduct a new exploration?"

updated: YYYY-MM-DD

• Use Glob / Grep / Read to actually read code, do not rely on guesses
• Accumulate evidence while reading; simultaneously think about which conclusion each piece of evidence supports—do not record evidence that does not support any conclusion
• Aim for 3–8 key pieces of evidence, each marked with

  File: Line Number

• When involving multi-module collaboration, or for

  module-overview

  /

  spike

  types, prepare a Mermaid diagram and place it in the quick answer section drafted in Phase 3
• After forming preliminary conclusions, actively check: Can the existing evidence convince a skeptical person? If yes, stop; there is no need to expand the search scope further

• Write the quick answer section first, then fill in key evidence—this order is crucial: having conclusions first forces you to check whether the evidence actually supports them, ensuring the effectiveness of each piece of evidence
• The AI drafts the complete explore document at once, and the user confirms after review
• Revise according to feedback before finalizing if there are changes

• New Path: Write to

  easysdd/compound/

  , name the file

  YYYY-MM-DD-explore-{slug}.md

  , and add

  doc_type: explore

  at the top of the frontmatter (see

  reference.md

  )
• Update Path: Write back to the original file located in Phase 1.5, and add

  updated: YYYY-MM-DD

  to the frontmatter
• Supersede Path: Follow §6, Item 5 in

  shared-conventions.md

  ; mark the old document as

  status=outdated

  and add

  superseded-by

See

easysdd/reference/tools.md

for complete syntax and examples. This section only lists typical queries specific to explore.

undefined

• Exploration questions and scope have been clarified
• Core conclusions have been provided in the quick answer section (conclusions are placed upfront, not buried after evidence)
• 3-8 key pieces of evidence, each marked with File: Line Number and explaining which conclusion it supports
• For multi-module collaboration or module-overview / spike types, there is a Mermaid diagram in the quick answer section
• The document has been archived to

  easysdd/compound/

  , with the file name

  YYYY-MM-DD-explore-{slug}.md

• Next-step suggestions have been provided (routing to which sub-workflow)

Shared guardrails for archiving workflows (add-only, quality over quantity, do not write on behalf of users, discoverability, check for overlaps after archiving) can be found in §6 of

easysdd/reference/shared-conventions.md

. Anti-patterns specific to this skill:

• Providing conclusions without reading code
• Evidence only states "looks like" without marking File: Line Number
• Conclusions are written after evidence—the quick answer section must come before the key evidence section
• The evidence section is several times longer than the quick answer section—first streamline evidence and delete entries that do not support conclusions
• No Mermaid diagram for cross-module processes, only textual descriptions of multi-module collaboration
• Making decisions in advance—explore only records "what is observed" and does not make conclusions on "what should be done in the future"
• Providing solutions without an evidence chain—each conclusion must be traceable to specific File: Line Number
• Continuing to reference outdated historical explore documents without marking

  status

• Reading or writing documents in the

  compound/

  directory where

  doc_type

  is not

  explore

  —this skill only handles explore documents