with one click
write-phased
Write a phased specification document
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
Write a phased specification document
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
User-invoked shorthand that inverts delegation — produce a filesystem bundle (checklist, drop-bin directory, notes template) of human-only actions and artifacts blocking project progress, and launch the user's editor on it.
Explicit-request macro. Activate only when the user directly requests this macro; never infer activation from task characteristics. Skill — Shorthand that tells the agent to ask clarifying questions instead of making decisions on its own
Explicit-request macro. Activate only when the user directly requests this macro; never infer activation from task characteristics. Skill — Sequence a task as ordered parts that add up to the whole. Each iteration may read prior iterations' outputs.
Explicit-request macro. Activate only when the user directly requests this macro; never infer activation from task characteristics. Skill — Run N blind agents on the same job in parallel, then merge findings into consensus/unique/conflicts. Agents report only — no edits for concurrent safety.
Explicit-request macro. Activate only when the user directly requests this macro; never infer activation from task characteristics. Skill — Use subagents to save context space and/or parallelize subtasks where possible
Explicit-request macro. Activate only when the user directly requests this macro; never infer activation from task characteristics. Skill — Spawns an independent subagent to critique recent work with web research. Use when the user wants a second opinion, says "doubt this", or wants to verify code against docs.
| name | write-phased |
| description | Write a phased specification document |
Do not re-invoke this skill recursively or reread instructions in a loop. Treat failed tool calls, patch-context mismatches, test failures, and command mistakes as recoverable unless they reveal a genuine blocker. Inspect the current state, correct the cause, and continue. Retrying or adapting a failed operation within this workflow is allowed; do not restart from the beginning. If a patch no longer matches, reread the affected file and regenerate a smaller patch against its current contents. Stop only when progress requires missing configuration or authority, unavailable external state, destructive or irreversible action, a material product choice not resolved by the request or repository, or no defensible safe path remains after diagnosis.
Investigate the request, write and commit a phased specification, then stop. Do not implement it in the same task.
Resolve workspace_dir in this order:
.agents/skill-configs/spex/config.local.yaml.agents/skill-configs/spex/config.yaml.agent-workspace/spex/config.local.yaml, .agent-workspace/spex/config.yaml, .claude/skill-configs/spex/config.local.yaml, then .claude/skill-configs/spex/config.yamlIf config exists only at a legacy path, use it and offer to move it. If none exists, stop and ask the user to choose a workspace directory or .agent-workspace/specs; then create the selected .agents/skill-configs/spex/ config. See config.example.yaml beside this file.
Set ${SPECS_DIR} to the resolved value.
${SPECS_DIR}/{YYMMDD-HHMMSS}-{kebab-case-description}/ using the current local time.README.md plus one PN-{name}.md per phase.# [Feature Name]
**Date:** YYYY-MM-DD HH:MM:SS
**Issue:** [One-line problem]
**Priority:** [High/Medium/Low]
**Status:** Requires Implementation
## Problem Statement
[Current state, target state, impact, and verified root cause]
## Design Principles
1. **[Principle]** — [Explanation]
2. **Incremental delivery** — Every phase leaves the system working.
3. **Verified phases** — Every phase has runnable completion checks.
## Key Design Decisions
| Decision | Choice | Rationale |
|----------|--------|-----------|
| [Decision] | [Choice] | [Rationale] |
## Deferred Features
- [Explicitly out-of-scope item and reason]
## Phase Summary
| Phase | Name | Tests Required | Backward Compatible |
|-------|------|----------------|---------------------|
| 1 | [Title] | [Tests] | Yes |
## Phase Documents
1. [P1-{name}.md](./P1-{name}.md) — [Description]
## Progress Tracking
| Phase | Commit | Status |
|-------|--------|--------|
| 1 | — | Pending |
## Phase N: [Descriptive Title]
**Goal:** [Concrete outcome]
**Entry state:** [Required starting state]
**Exit state:** [Specific, verifiable ending state]
### Implementation Checklist
- [ ] [Task with repository-relative file path]
- [ ] Add or update tests described below
- [ ] Run `[verification command]`
- [ ] Commit: `[message following repository conventions]`
### Code
[Complete implementation guidance, with repository-relative paths and enough context for a fresh agent.]
### Required Tests
**File:** `tests/path/to/test_file.py` (NEW or UPDATE)
[Complete tests or exact test requirements.]
### Example Workflow
[Runnable commands and expected results.]
Each phase must be independently implementable, leave the system working, define explicit entry and exit states, and state cross-phase contracts as facts in every affected phase.
Before committing, verify once:
git ls-files and git check-ignore -v.If normative material is untracked or ignored, either commit it to a tracked location and update the references or inline it in the spec. Do not commit a broken reference.
Add and commit only the spec directory using the repository's commit conventions. The commit message should identify the phased spec and its status. Stop immediately after the commit; implementation belongs to a separate task.