The /to-explore Skill
Explores open-ended problem domains, investigates legacy codebases, formulates architectural trade-offs, runs disposable feasibility spikes, and drafts discovery foundations.
"Getting acquainted with the problem. Take time to examine the problem as a whole, its main parts, its details. Do not jump into calculations before you know what you are doing." — George Pólya, How to Solve It (1945)
/to-explore Explore multi-tenant checkout billing architecture, compare PostgreSQL schema vs DynamoDB, and generate discovery draft.What it does
to-explore is the ideation and discovery engine of the Pólya SDLC. It operates when requirements are ambiguous, technical feasibility is unproven, or legacy architecture needs surveying before taking on major refactorings. It grounds itself in Pólya's principle of *Getting Acquainted with the Problem*: surveying existing repository topography, mapping data inputs, and comparing competitive architectural options.
It constructs disposable feasibility spikes to test technical limits, clarifies unknowns, and documents findings in a comprehensive Discovery Draft at docs/discovery/{slug}-discovery.md. It refuses to author formal specifications or modify production source code.
When to reach for it
Where the work currently lives decides whether this is the right skill:
| The work is… | Reach for |
|---|---|
| An open-ended greenfield feature idea or unmapped business domain | /to-explore |
| A technical uncertainty needing a prototype or feasibility spike | /to-explore |
| A legacy codebase needing structural surveying before refactoring | /to-explore |
| Clear user stories needing a Product Requirements Document (PRD) | /to-prd |
| Architectural trade-offs settled, ready for technical specification | /to-spec |
Prerequisites
- Problem Brief or Goal: A high-level description of what feature, system, or refactoring you are investigating.
- Disposable Spikes Only: Any prototype code written during exploration is strictly temporary and must not be treated as production code.
- Discovery Artifact Seams: Writes strictly to
docs/discovery/{slug}-discovery.md.
What one run does
A single discovery run follows five exploratory steps:
- Topography Scan & Codebase Reality: Surveys existing folder structures, package manifests, and architecture maps to establish current system baselines.
- Architectural Critique & Trade-Off Analysis: Formulates 2–3 competing architectural strategies, comparing complexity, maintainability, and scalability trade-offs.
- Feasibility Spikes & Boundary Testing: Runs rapid disposable spikes to test unknown libraries, latency limits, or serialization constraints.
- Discovery Draft Authoring: Compiles findings, problem statements, and risk vectors into
docs/discovery/{slug}-discovery.md. - SDLC Handoff: Directs the user to
/to-prd(if business requirements need formalization) or/to-spec(if technical architecture is ready).
Common questions
When should I use /to-explore vs /to-spec?
Use /to-explore when the problem is still fluid and you need to investigate technical feasibility, compare libraries, or understand legacy code. Use /to-spec once the architectural direction is decided and you need formal immutable DTO schemas and Clean Architecture seams.
Can I use code written during a spike directly in production?
No. Spikes are disposable proof-of-concept experiments designed to validate hypotheses. Production code must be implemented test-first at clean seams during Phase 3 (/to-code).
It's working if
- It compares multiple concrete architectural alternatives with trade-offs.
- It identifies high-risk unknowns before committing to an implementation path.
- It authors a clear discovery draft at
docs/discovery/{slug}-discovery.md. - It writes zero functional production code in
/srcor/lib.
Where it fits
to-explore is Phase 0 in the main idea-to-ship pipeline:
🔭 /to-explore → /to-prd → /to-spec → /to-clarify → /to-plan → 🛑 PAUSE → /to-code → /to-review → /to-docs
It acts as the head of the discovery pipeline. Once findings are documented in docs/discovery/, it hands off to /to-prd for business requirements or directly to /to-spec for technical architecture.