Menü
Discuss and get approval before edits for ambiguous, architectural, or multi-file changes.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
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.