sdd-explore

Files (1)

• SKILL.md

SKILL.md (first lines)

> **ORCHESTRATOR GATE**: If you loaded this skill via the `skill()` tool, you are
> the ORCHESTRATOR — STOP. Do NOT execute these instructions inline. Delegate to
> the dedicated `sdd-explore` sub-agent using your platform's delegation primitive
> (e.g., `task(...)`, sub-agent invocation, etc.). This skill is for EXECUTORS
> only.

## Executor Override

If you ARE the `sdd-explore` sub-agent (NOT the orchestrator), the gate above does NOT apply to you. Continue with the phase work below. Do NOT delegate. Do NOT call the Skill tool. You are the executor — execute.


## Language Domain Contract

Generated technical artifacts default to English. Do not inherit the user's conversational language or the active persona's regional voice for SDD artifacts unless the user explicitly requests that artifact language or the project convention requires it.

If Spanish technical artifacts are explicitly requested, use neutral/professional Spanish unless the user explicitly asks for a regional variant.

Public/contextual comments follow the target context language by default. Explicit user language or tone overrides win; Spanish comments default to neutral/professional Spanish unless the user or target context clearly calls for regional tone.

## Purpose

You are a sub-agent responsible for EXPLORATION. You investigate the codebase, think through problems, compare approaches, and return a structured analysis. By default you only research and report back; only create `exploration.md` when this exploration is tied to a named change.

## What You Receive

The orchestrator will give you:
- A topic or feature to explore

## Execution and Persistence Contract

> Follow **Section B** (retrieval) and **Section C** (persistence) from `skills/_shared/sdd-phase-common.md`.

Read and follow `skills/_shared/openspec-convention.md`.

### Retrieving Context

Read `openspec/config.yaml` and `openspec/specs/`.

## What to Do

### Step 1: Load Skills
Follow **Section A** from `skills/_shared/sdd-phase-common.md`.

### Step 2: Understand the Request

Parse what the user wants to explore:
- Is this a new feature? A bug fix? A refactor?
- What domain does it touch?

### Step 3: Investigate the Codebase

Read relevant code to understand:
- Current architecture and patterns
- Files and modules that would be affected
- Existing behavior that relates to the request
- Potential constraints or risks

```
INVESTIGATE:
├── Read entry points and key files
├── Search for related functionality
├── Check existing tests (if any)
├── Look for patterns already in use
└── Identify dependencies and coupling
```

### Step 3b: Determine Project Type (Web Detection)

Decide whether this project is a **web project**, because that drives Playwright
E2E generation later in the flow. Look for signals:

- A web framework or UI layer (e.g. `package.json` with react/vue/svelte/next/angular,
  a `templates/`/`views/` layer, server-rendered routes, a SPA build, etc.).
- A dev server, browser-facing routes, or existing E2E tooling (`playwright`,
  `cypress`, `selenium`, `chromedp`).

Report one of: `web`, `not-web`, or `unknown`.

- If signals clearly indicate a web UI → `web`.
- If the project is clearly a library/CLI/backend-only with no browser surface → `not-web`.
- If the project is **NEW or blank** and the type cannot be determined from code →
  `unknown`. In this case the orchestrator MUST ASK the user (preflight group E,
  alongside the rhythm) whether to enable Playwright web testing. State this
  explicitly in your output so the orchestrator knows to ask.

This determination informs `playwright.enabled` in `.archon/config.yaml`. Never
enable Playwright for a `not-web` project.

### Step 3c: Classify Change Size

Decide how big and well-understood this change is, because that drives whether the
orchestrator suggests the sized `fast` track ([[harness-fast-track]]) at the preflight
deviation question. Look for signals:

- Scope touches a single file/module with a well-understood, mechanical fix or
  small addition, no new capability, no cross-cutting concern.
- Estimated changed lines are small (comparable to a `bugfix`-sized change) and the
  approach is obvious — no open design questions.
- Contrast with a change spanning multiple modules, introducing a new capability,
  or carrying non-trivial risk/ambiguity.

Report one of: `small`, `substantial`, or `unknown`.

- `small` → the change is scoped, mechanical, and low-risk. This MAY lead the
  orchestrator to suggest `track: fast` via the existing preflight deviation-question
  pattern (one scoped question) — never auto-selected silently.
- `substantial` → the change has real scope, risk, or design ambiguity. The track
  stays `full`; no `fast` suggestion is made.
- If the size cannot be determined confidently (e.g. too early, insufficient
  investigation, or genuinely ambiguous scope) → `unknown`. The track defaults to
  `full`; `fast` is never suggested on `unknown`.

Report this classification to the orchestrator in your return envelope (e.g. `Size:
small`) — do NOT run `archon workflow complete` yourself; per
`skills/_shared/sdd-phase-common.md`'s executor boundary, mutating `state.yaml` on
phase completion is the orchestrator's action, run once you report back, not the
executor's. There is exactly ONE completion call per phase — `workflow complete`
now rejects a second call on an already-completed phase, so a separate size-only
or track-only follow-up call is not just redundant, it is a hard error. The

From AlexCas/archon-ai, MIT.

More from AlexCas/archon-ai