Skip to content
Back to skills

Explore

ASecurity

Research and pressure-test an idea before deciding whether to write intent.

  • 3 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added October 19, 2026
developmentbashrailsgitsecurity

Works with

  • terminal
  • cli

Security analysis

A100/100

Scanned October 19, 2026

npx -y skills add marin-ai-tech/sdlc --skill explore --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Explore?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Explore
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/marin-ai-tech-explore/badge)](https://www.skillsdirectory.com/skills/marin-ai-tech-explore)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: explore
description: Research and pressure-test an idea before deciding whether to write intent.
when_to_use: The user wants to explore an idea, compare alternatives, or decide whether to proceed.
argument-hint: "<idea or slug>"
license: "PolyForm-Noncommercial-1.0.0 with sdlc Additional Permissions, or sdlc Commercial License (https://github.com/marin-ai-tech/sdlc)"
compatibility: Requires the sdlc CLI (sdlc) from the sdlc package.
allowed-tools: Bash(sdlc *)
metadata:
  author: marin-ai technologies
  version: "1"
  generatedBy: "sdlc 0.23.7"
---

Explore an idea without starting a change. An exploration can end here and never become an intent.

**Harness contract** (applies to every SDLC workflow)
- `sdlc` is the source of truth for lifecycle state. Read it (`sdlc status --change <id> --json`) instead of inferring the stage from the conversation, and re-read artifacts from disk before using them.
- Gates are human decisions. Never run `sdlc approve`, `sdlc reject`, `sdlc waive` or `sdlc tests unlock`, and never edit `.sdlc.yaml`. When a gate needs a person, stop, name the people from the hint (`next.people` in `sdlc next --json`) rather than the role, and give them the exact command to run in their own terminal.
- An answer in chat is never an approval: gate approvals, `track set`, `backlog move`/`drop` and other human decisions happen only as a command the person runs in their own terminal. Offer the choice, explain the consequences, and give the exact command.
- OpenSpec is the specification subsystem: `sdlc openspec <args>` runs the bundled OpenSpec CLI (`list --specs`, `show`, `validate`, `instructions`). Change folders live in `openspec/changes/<id>/`.
- **Change selection**: use the change named in the input. Otherwise run `sdlc status --json`; with exactly one active change use it, with several ask which one. Announce "Using change: <id>".
- **Language**: talk to the person, and write notes and artifacts, in the person's language; when `locale:` is set in `openspec/sdlc.yaml`, use that language. Keep command names, file names, ids and the template headings as they are (sdlc and OpenSpec parse those headings).
- End every workflow with the next step from `sdlc next --json` (the exact command when a person must act).

**Input**: the user's request (a change id, or a description of the work)

If the input is empty, stop and ask the user in plain text which idea to explore: what it is, why now, and any constraints. Do not invent a topic and do not create a note until they answer.

**Steps**

1. Derive a short kebab-case slug from the idea. Create the note with `sdlc explore <slug>` at `openspec/explorations/<slug>.md`. If it already exists, read and continue it; never overwrite it.
2. Restate the problem in the originator's words under **Problem**. Keep uncertainty explicit.
3. Read the relevant code, run `sdlc openspec list --specs`, and inspect archived changes. Summarize the current behavior and prior decisions under **What exists**.
4. Delegate external and codebase research to the `sdlc-researcher` subagent. Record findings and their sources under **Research**, distinguishing evidence from inference.
5. Write two or three comparable **Alternatives**, including “do nothing”. Compare expected benefit, effort, and what each leaves unresolved.
6. **Pressure test** each option through four named lenses. For each, state the assumption and how it could fail: **user** (who actually needs this, and how do we know?), **technical** (what could make it infeasible?), **cost** (build and run), and **risk** (security, privacy, compliance, reversibility).
7. Recommend **proceed**, **reshape**, or **stop**, with reasons and open questions. Use the AskUserQuestion tool to offer those three choices, mark the recommendation, and explain each consequence. A weak idea may stop here.
8. If proceeding, add the idea with `sdlc backlog add <title> --outcome <outcome> --accept <measure> --source-type exploration --source-ref openspec/explorations/<slug>.md`. The backlog priority determines when it starts. Once started, continue with `/sdlc:intent`.

**Pausing and resuming**
- Before you stop to wait for the person's answer or for research, write your questions under **Open questions** in the note and mark every unfinished section with `_pending: <what is missing>_`. The note, not the chat, must show where the exploration stopped.
- When the note already exists, read it and continue from the first pending section; do not restart.
- If the person cannot answer, continue with explicit assumptions, record them under **Open questions**, and say how the recommendation would change if an assumption is wrong.

**Guardrails**
- Research only: do not edit project code.
- Keep the note concise and cite sources for claims that determine the recommendation.

<!--
Generated by sdlc 0.23.7 (https://github.com/marin-ai-tech/sdlc).
Required Notice: Copyright (c) 2026 marin-ai technologies (https://github.com/marin-ai-tech/sdlc)
License: PolyForm Noncommercial 1.0.0 (https://polyformproject.org/licenses/noncommercial/1.0.0) with the sdlc Additional Permissions, or a commercial license; see https://github.com/marin-ai-tech/sdlc
-->

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.