Slash Command

/start

Executes implementation plan from absolute file path (optional seed commitish): creates randomized git branch, implements via agent with reviews, commits changes, creates GitHub PR.

Git

Github

Bash

git-workflow

automation

npx claudepluginhub pbdeuchler/llm-plugins --plugin one-shot

Prompt Preview

# Execute Implementation Plan

**Implementation plan file:** `$1`
**Seed Commitish:** `$2` (Optional)

This execution workflow uses:

- Per-task code review

## Before Starting

The first argument MUST be an absolute path. Verify it exists:

1. Verify we are in a git repo:

   

2. If $2 (seed commitish) was provided, verify the commitish exists and check out to it. If not, take note of the current branch you are on:

   

3. Verify the plan file exists:

   

4. Checkout a new branch from the current HEAD (which should be the seed committish if provided). This branch should have a randomiz...

Command Content

Other plugins with /start

/prp-implement

2.2k

Executes a Markdown implementation plan, applying file changes with validation loops after each step to catch and fix issues early.

prp-core

/implement_plan

Implements approved technical plans from ./thoughts/shared/plans directory via phases with automated verification, manual pauses, and progress tracking.

rpi

/prp-implement

179.4k

Executes a Markdown plan file step-by-step: detects package manager, prepares git branch, implements tasks with pattern mirroring, validates after every change.

ecc

/implement

Implements changes from a provided plan file or reference, executing phases sequentially with file reads, verification, progress tracking via checkboxes, and mismatch handling.

ai-research-workflows

/execute

Executes implementation plan with automatic sequential/parallel orchestration using git-spice and git worktrees.

spectacular

/start

20.8k

Implements Manus-style file-based planning for complex tasks by creating task_plan.md, findings.md, and progress.md. Supports automatic session recovery after /clear.

planning-with-files

Stats

Parent Repo Stars11

Parent Repo Forks0

Last CommitApr 1, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Execute Implementation Plan

Implementation plan file: $1 Seed Commitish: $2 (Optional)

This execution workflow uses:

Per-task code review

Before Starting

The first argument MUST be an absolute path. Verify it exists:

Verify we are in a git repo:
```
git rev-parse --git-dir
```
If $2 (seed commitish) was provided, verify the commitish exists and check out to it. If not, take note of the current branch you are on:
```
git checkout $2
```
Verify the plan file exists:
```
test -f "$1"
```
Checkout a new branch from the current HEAD (which should be the seed committish if provided). This branch should have a randomized, human readable name:
```
git checkout -b lazy-koala-fence
```

If any of these steps fail, stop and report the error to the user.

Execute

Engage the skill: Use your Skill tool to invoke one-shot:execute-one-shot
If the skill asks for a plan path: The user has already provided it: $1. Do not ask again.

The skill should execute everything in that file, no more and no less. Follow it exactly as written.

Once the skill has completed

Holistic Review: Use your Skill tool to invoke one-shot:holistic-review within a subagent. The implementation plan path is $1 and the base branch is the branch you checked out from (or the seed commitish branch if provided).
Commit the changes from the holistic code review with a detailed commit message describing what was done.
Create a PR using the gh CLI:
- Base branch: If a seed commitish was provided and it is a branch, use that as the base. Otherwise, use the original branch you were on at initialization.
- Compare branch: The new implementation branch.
- Description must include:
  1. Summary of what the implementation plan asked for
  2. What you did to complete the task and why
  3. Any tradeoffs, design decisions, or complications that arose
  4. A summary of test changes and what a reviewer should pay attention to
  5. Anything else reviewers should pay special attention to
IF YOU ENCOUNTER THIS ERROR: pull request create failed: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between {base} and {compare}, Base ref must be a branch (createPullRequest) then ensure {base} exists and is up to date on origin

The success of this entire implementation relies upon it having a good PR description. It is imperative that the description is concise without being terse or lacking information. It should never be long, wordy, or overly descriptive. An engineer of any skill level should be able to use the description and immediately understand what was done, why it was done, and what they should pay attention to most in the review.