Implement for Openclaw

An implementation workflow that isolates code changes, validates them, commits and pushes the result, and opens a draft GitHub pull request.

mertbuilds
v0.1.0
Aug 10, 2026
0
44
0

Install & Download

1. ClawHub CLI

The fastest way to install a skill directly from the registry.

npx clawhub@latest install implement

2. Manual Installation

Copy the skill folder to one of these locations

Global
~/.openclaw/skills/
Workspace
<project>/skills/

Priority: Workspace > Local > Bundled

3. Prompt Installation

Copy this prompt to OpenClaw to install it automatically.

Help me install implement using Clawhub. If Clawhub is not installed, install it first (npm i -g clawhub).

Prefer to download?

Get the raw skill files in a ZIP archive.

What is Implement?

Implement is an Openclaw Skills workflow for turning an already-discussed coding task into a focused, reviewable change. It creates an isolated Worktrunk worktree, follows repository conventions, implements the feature or fix, runs an appropriate validation command, and preserves the worktree for continued iteration.

The skill completes the delivery path by creating a conventional commit, pushing the branch, and opening a draft pull request. It avoids unrelated cleanup, unsafe Git shortcuts, premature merging, and unnecessary architecture discussions, making it a practical Openclaw Skills option for everyday feature development.

Implement Use Cases

  • Implementing a new feature in an existing Git repository
  • Fixing a bug or adding a focused code change
  • Building a small-to-medium feature after requirements have already been discussed
  • Creating an isolated branch and worktree for parallel development
  • Running a repository-approved typecheck, lint, or validation command before commit
  • Pushing completed work and opening a draft GitHub pull request for review
  • Starting a local development server for a web project and sharing its preview URL
  • Continuing implementation and review feedback in the same worktree

How Implement Works

  1. Check scope: Summarize the intended change, ask one clarifying question only when genuinely ambiguous, and recommend the heavier worktree-dev flow when architecture or scope is too complex.
  2. Create isolation: Choose a descriptive branch using repository conventions such as fix/, feat/, or refactor/, then run wt switch --create <branch-name> --yes.
  3. Implement the change: Read affected files first, follow CLAUDE.md and repository conventions, keep the diff focused, and avoid unrelated refactoring.
  4. Validate: Run a fast, known project check such as typechecking, linting, or compilation when the repository provides one. Do not invent commands.
  5. Review and commit: Scan the diff for API keys, tokens, JWTs, or other obvious secrets, then create a new commit matching recent repository message style.
  6. Push the branch: Run git push -u origin <branch-name> and determine the repository default branch with GitHub CLI.
  7. Open a draft PR: Create a draft pull request whose title and body summarize all commits on the branch, include a test plan, and add an issue-closing reference when the branch contains an issue number.
  8. Start a preview when applicable: Detect the package manager and launch the project development server in the background, polling output for its ready URL and port.
  9. Report results: Provide the branch, PR URL, preview URL, changed files, commit hash, validation result, limitations, and the reminder to run wt remove after the PR merges.
  10. Clean up at session end: Stop background development servers and other tasks when iteration is complete, while keeping them alive during active follow-up work.

Implement Setup

Prerequisites

  • A Git repository with a configured remote
  • Worktrunk (wt) installed and available on PATH
  • GitHub CLI (gh) authenticated for the target repository
  • A repository with clear contribution rules, including CLAUDE.md when applicable

Create the implementation worktree

wt switch --create <branch-name> --yes

Worktrunk may copy ignored environment and dependency files through the user-level post-create hook at ~/.config/worktrunk/config.toml. If required environment variables are missing, retry the copy manually:

wt step copy-ignored --from <source-branch>

Commit, push, and create the draft PR

git commit -m "<short message matching repository style>"
git push -u origin <branch-name>
gh repo view --json defaultBranchRef -q '.defaultBranchRef.name'
gh pr create --draft --title "<short title>" --body "<summary and test plan>"

The workflow remains in the new worktree after the PR is created. Do not use wt merge, force-push, --no-verify, or git commit --amend. Remove the worktree manually after the PR merges:

wt remove

Implement Data Schema & Taxonomy

Implementation records

Data Organization or source
Branch Descriptive Worktrunk branch using prefixes such as fix/, feat/, add/, chore/, refactor/, or perf/
Working directory Isolated Worktrunk worktree associated with the branch
Code changes Focused diff containing only the requested implementation and necessary supporting edits
Commit New commit matching the recent git log --oneline -10 style; no amend or generated signature
Remote state Pushed branch tracked by origin
Pull request Draft GitHub PR with a title under 70 characters, summary, test plan, and optional Closes #<number> reference
Validation Typecheck, lint, test, compilation, or another existing repository check, with its result reported
Preview Background development server URL and detected port when a supported dev script exists

Environment and metadata

  • Worktree-local ignored files may include .env.local, .env.*, node_modules, and other files copied by wt step copy-ignored.
  • The package manager is inferred from lockfiles: bun.lockb, pnpm-lock.yaml, yarn.lock, or otherwise npm.
  • PR content is based on all commits from the feature branch relative to the default branch, not only the latest commit.
  • Background task identifiers are tracked so development servers can be stopped when the session ends.

Implement Advanced Features

  • Isolated Worktrunk worktrees allow multiple features to run side by side without changing the original checkout.
  • Automatic branch naming follows repository prefix conventions and recent Git history.
  • Secret scanning before staging helps catch API keys, tokens, and JWTs before they enter a commit.
  • Pre-commit failures are handled by fixing the underlying issue and creating a new commit rather than bypassing hooks.
  • Draft PR generation includes branch-wide commit context, a structured summary, test-plan checkboxes, and issue-closing metadata.
  • Environment and dependency files can be restored through Worktrunk post-create hooks or the manual copy-ignored fallback.
  • Development server startup detects Bun, pnpm, Yarn, or npm and extracts the ready localhost port from background output.
  • Preview servers remain available during active iteration and are cleaned up proactively at the end of the flow.
  • Explicit boundaries prevent automatic merging, ready-for-review promotion, force-pushing, amending, or switching back to the original worktree.
  • Complex multi-subsystem work is routed toward the more comprehensive worktree-dev workflow instead of forcing a lean implementation path.

SKILL.md


Loading

Related Openclaw Skills

METADATA

Github Stars: 0
forks: 0

Featured*