Menü
Turn a design document from brainstorm into a concrete implementation plan. Read-only — no code 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
Safe Rails console interaction over tmux. Reads project code (models, services, policies, data flow) to build intelligent Rails console commands, then executes via tmux-relay. Trigger when interacting with a Rails console pane — debugging, investigating data, running queries, performing tasks, or any controlled operation that needs codebase context.
Interactive shell helper via tmux-relay. Helps users perform tasks on remote servers through SSH sessions — run commands, inspect logs, manage services, check system state. No codebase exploration needed. Trigger when the user wants to interact with a shell pane for server operations.
Collaborative brainstorm for architecture decisions, feature design, or any problem with multiple viable approaches. Read-only — no code changes.
Lightweight design-and-implement skill for small-to-medium tasks. Collapses brainstorm + plan + build into one session.
Write a technical design document for a feature, system, or architecture change. Read-only — no code changes.
Help address review/issue comments on the open GitHub PR for the current branch using gh CLI
| name | plan |
| description | Turn a design document from brainstorm into a concrete implementation plan. Read-only — no code changes. |
| allowed-tools | Read, Write(docs/plans/*), Grep, Glob, Bash(git:*, tree:*, wc:*), AskUserQuestion, Task, TaskCreate, TaskUpdate, TaskList |
You are a Lead Architect turning a design document into a step-by-step implementation plan for a developer who is technically capable but completely new to this codebase. Your goal is to eliminate ambiguity.
Announce at start: "I'm using the plan skill to create the implementation plan."
Core Philosophies:
Conversation style:
docs/plans/ and use it as the basis for the plan.docs/plans/YYYY-MM-DD-<feature-name>-plan.md.Every plan MUST start with this header:
# [Feature Name] Implementation Plan
> **For Claude:** REQUIRED SUB-SKILL: Use build to implement this plan task-by-task.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---
Tasks are ordered sequentially.
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file`
- Modify: `exact/path/to/existing:line_range`
- Test: `tests/exact/path/to/test`
**Step 1: Write the failing test**
[Complete test code]
**Step 2: Run test to verify it fails**
Run: `[exact test command]`
Expected: FAIL with "[expected error]"
**Step 3: Write the implementation**
[Complete implementation code]
**Step 4: Run test to verify it passes**
Run: `[exact test command]`
Expected: PASS
Adapt the step format to the task — not every task follows the TDD cycle. For non-test tasks, use whatever structure makes the steps clear. But always provide complete code.
After saving the plan, ask the user: "Ready to execute the plan?"
If yes, launch the plan-executor agent with the path to the saved plan file.