Menu
Discuss and get approval before edits for ambiguous, architectural, or multi-file changes.
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
Create ordinary task-branch commits; use git-mainline-squash for final archive squashes.
Create and integrate Rezics worktrees using the main/archive workflow.
Apply a code-first plan — route each durable item to its home in code (types/tests/comments), then make the source document disposable. No validation CLI, no state machine. Use when implementing a plan/proposal.
Thinking partner for exploring ideas, investigating the rezics codebase, and clarifying requirements before a plan exists. Use when the user wants to think something through. Never implements.
Propose a code-first plan — a single markdown file with context, durable constraints/decisions, and a task checklist. No spec files. Use when the user wants to turn an idea into actionable, implementable work.
| name | discuss-first |
| description | Discuss and get approval before edits for ambiguous, architectural, or multi-file changes. |
Do not modify, create, or delete any file until the user explicitly approves the proposal.
## Proposal
**Goal**
<One or two sentences: what problem this solves or what the user asked for.>
**Approach**
<Step-by-step plan. Be specific — name functions, files, patterns.>
1. ...
2. ...
3. ...
**Files Affected**
| File | Change |
| --------------- | ----------------------------------- |
| path/to/file.ts | modify — describe what changes |
| path/to/new.ts | create — describe what it contains |
| path/to/old.ts | delete — reason |
**Trade-offs / Risks**
<Anything the user should decide: alternative approaches, potential breakage,
assumptions you're making, out-of-scope items you noticed.>
---
Does this look right? Say **yes** to proceed, or let me know what to adjust.
| User response | Action |
|---|---|
| "yes", "go", "proceed", "lgtm", "looks good" | Enter Phase 3 |
| Requests changes | Update the proposal, re-present, wait again |
| "no", "cancel", "stop" | Halt. Make no changes. |
| Ambiguous | Ask for clarification before doing anything |
"I found [X] which wasn't in the original plan. Should I [proposed adjustment], or would you like to revise the proposal first?"
## Done
**Changes made:**
- `path/to/file.ts` — <what was changed>
- `path/to/new.ts` — <what was created>
**Anything to follow up:**
- <tests to run, migrations to apply, env vars to set, etc.>
Phase 1 → Read → Propose → Ask for approval
Phase 2 → Wait (no edits)
Phase 3 → Execute exactly what was approved → Summarize
Scope creep rule: When in doubt, surface it — never silently expand the plan.