• New team members joining the repository 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 first (only exploration, no final decisions)

Refer to

codestable/reference/shared-conventions.md

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

codestable/compound/

, with the file name format

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

, and the frontmatter includes

doc_type: explore

.

reference.md

• Quick answers must come before evidence — Readers should see the conclusion first when opening the document, then decide whether to read the evidence
• Conclusions must be traceable to evidence; pure speculation is not allowed
• When 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 top question you want to answer first?"
2. "Which module / directory do you want to focus on?"

codestable/reference/shared-conventions.md

• If the user mentions "update / review / a previous explore / this module was explored before" or clearly 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); if only supplementing evidence / tightening conclusions without changing core conclusions, 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 speculation
• 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? Stop once sufficient, do not expand the search scope unnecessarily

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

• New Path: Write to

  codestable/compound/

  , name the file

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

  , and include

  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, add

  updated: YYYY-MM-DD

  to the frontmatter
• Supersede Path: Follow Item 5 of Section 6 in

  shared-conventions.md

  ; mark the old document as

  status=outdated

  and add

  superseded-by

See

codestable/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 first, 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, the quick answer section includes a Mermaid diagram
• The document has been archived to

  codestable/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 for users, discoverability, check for overlaps after archiving) are in Section 6 of

codestable/reference/shared-conventions.md

. Anti-patterns specific to this skill:

• Providing conclusions without reading code
• Evidence only says "looks like" without marking File: Line Number
• Conclusions are placed 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 was observed", not conclusions on "what should be done in the future"
• Providing solutions without an evidence chain — every 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