Agent skill

Create Worktree

by ClickHouse in ClickHouse/ClickHouse

Create a ClickHouse git worktree with submodules hardlinked from the main repo.

Apache-2.0Auto-check passedDatabases

Install Create Worktree

skills CLI
$ npx skills add ClickHouse/ClickHouse --skill create-worktree -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ClickHouse/ClickHouse create-worktree --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ClickHouse/ClickHouse.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/create-worktree .claude/skills/create-worktree && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
create-worktree
GitHub stars
50k
Token cost
~3.5k tokens
SKILL.md length
922 words
Files
1
Skills in repo
24
Repo updated
First seen
Licence
Apache-2.0

At a glance

Create a ClickHouse git worktree with submodules hardlinked from the main repo.

  • Works in 7 steps: Determine the source repo → Validate inputs → Determine worktree path and branch state → …
  • The user wants to create a new worktree for ClickHouse development
  • SKILL.md covers Arguments, Process, Examples and Notes
  • Calls git, aws and openssl

What it does

Create Worktree is an agent skill from ClickHouse/ClickHouse. Create a ClickHouse git worktree with submodules hardlinked from the main repo. Use when the user wants to create a new worktree for ClickHouse development.

Its SKILL.md is about 3.5k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Databases, covering Git worktrees and Data warehousing. It works with ClickHouse and Git. The repository describes itself as: ClickHouse® is a real-time analytics database management system. The licence is Apache-2.0.

When your agent uses it

  • The user wants to create a new worktree for ClickHouse development
  • Tasks that involve Git worktrees
  • Tasks that involve Data warehousing

Example prompts

  • “/create-worktree”

Requirements

  • Pre-approved tools (allowed-tools): Bash(git:*), Bash(cp:*), Bash(ln:*), Bash(ls:*), Bash(rm:*), Bash(mkdir:*), Bash(find:*), Bash(pwd:*), Bash(sed:*), Bash(awk:*), Bash(xargs:*), Bash(sh:*), Bash(nproc:*), AskUserQuestion

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Determine the source repo
  2. Validate inputs
  3. Determine worktree path and branch state
  4. Create the worktree
  5. Decide whether to set up submodules
  6. Set up submodules via hardlinks
  7. Report results

What it can do on your machine

Read from SKILL.md and the folder at commit cd023af. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Bash(git:*)
    • Bash(cp:*)
    • Bash(ln:*)
    • Bash(ls:*)
    • Bash(rm:*)
    • Bash(mkdir:*)
    • Bash(find:*)
    • Bash(pwd:*)
    • Bash(sed:*)
    • Bash(awk:*)

    …and 4 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • aws
    • openssl
    • curl

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, aws and curl, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Create Worktree loads about 3.5k tokens when it runs. Until then it costs about 43 tokens; SKILL.md has 922 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~43
When it runs · the whole SKILL.md, loaded when a task matches
~3.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from ClickHouse/ClickHouse at commit cd023af, republished under its Apache-2.0 licence (© ClickHouse). 922 words, ~3,518 tokens.

Download SKILL.mdSave it as .claude/skills/create-worktree/SKILL.md (or your agent's skills folder).
name
create-worktree
description
Create a ClickHouse git worktree with submodules hardlinked from the main repo. Use when the user wants to create a new worktree for ClickHouse development.
allowed-tools
Bash(git:*), Bash(cp:*), Bash(ln:*), Bash(ls:*), Bash(rm:*), Bash(mkdir:*), Bash(find:*), Bash(pwd:*), Bash(sed:*), Bash(awk:*), Bash(xargs:*), Bash(sh:*), Bash(nproc:*), AskUserQuestion
argument-hint
<branch-name>
disable-model-invocation
false

Create ClickHouse Worktree Skill

Create a new git worktree for ClickHouse development. When the worktree will be built or tested, submodules are hardlinked from the main repo (independent copies, no network, no extra disk for git objects). For text-only tasks (docs, comments, typo fixes), submodule setup is skipped — it's the slow part of the workflow and is pure overhead when nothing will be compiled.

Arguments

  • $0 (required): Branch name. If the branch already exists, the worktree will check it out. If it doesn't exist, a new branch will be created from the current HEAD of the main repo.

Process

1. Determine the source repo
  • Detect the source repo (MAIN_REPO) by running git rev-parse --show-toplevel from the current working directory.
  • Verify it is a git repository. If not, report an error and stop.
2. Validate inputs
  • Ensure $0 (branch name) is provided. If not, use AskUserQuestion to ask the user for a branch name.
  • Compute SAFE_BRANCH by replacing all / characters in the branch name with -. For example, branch release/25.12 → SAFE_BRANCH=release-25.12. This avoids creating nested directories from slashes in branch names.
  • Use AskUserQuestion to ask the user for the worktree destination path. Suggest <MAIN_REPO>/../<MAIN_REPO_NAME>-<SAFE_BRANCH> as the default — this places the worktree as a sibling of the main repo directory, named after both the repo and the branch (e.g. ../ClickHouse-my-feature or ../ClickHouse-release-25.12). The user may enter a different path if preferred.

Let WORKTREE_PATH be the chosen path (resolved to an absolute path).

3. Determine worktree path and branch state
  • Worktree path: <WORKTREE_PATH> (from step 2)
  • Check if the worktree directory already exists. If it does, report to the user and stop.
  • Check if the branch already exists:
    bash
    git -C <MAIN_REPO> branch --list <branch-name>
    git -C <MAIN_REPO> branch --list -r "origin/<branch-name>"
4. Create the worktree

If branch exists locally:

bash
# Text-only:
git -C <MAIN_REPO> worktree add <WORKTREE_PATH> <branch-name>

# Build/test:
git -C <MAIN_REPO> worktree add --no-checkout <WORKTREE_PATH> <branch-name>

If branch exists on remote only:

bash
# Text-only:
git -C <MAIN_REPO> worktree add <WORKTREE_PATH> -b <branch-name> origin/<branch-name>

# Build/test:
git -C <MAIN_REPO> worktree add --no-checkout <WORKTREE_PATH> -b <branch-name> origin/<branch-name>

If branch does not exist (create new):

bash
# Text-only:
git -C <MAIN_REPO> worktree add -b <branch-name> <WORKTREE_PATH>

# Build/test:
git -C <MAIN_REPO> worktree add --no-checkout -b <branch-name> <WORKTREE_PATH>
5. Decide whether to set up submodules

The submodule hardlink step below is the slow part of this skill — it walks every contrib module, runs cp -al over all of them, rewrites configs, and checks out every submodule's working tree. The checkout repair treats nproc as a total worker budget: a small number of outer submodule jobs, each using parallel checkout workers internally.

Skip step 6 entirely (jump to step 7) when the planned work is text-only and won't be built or tested locally:

  • docs, comments, changelog entries, .md files
  • typo fixes in source files where no compile is needed to verify

Run step 6 when the task will involve ninja or running tests against this worktree.

If genuinely unsure, use AskUserQuestion: "Will you build or run tests in this worktree? (No → skip submodule setup, much faster)"

Show full SKILL.md (512 more words)Show less

Only do this step if step 5 selected the build/test path. Instead of cloning each submodule from the network, hardlink the git modules directory from the main repo. This gives each worktree an independent copy of the submodule git data (safe to modify independently) without using extra disk space for the object files, and without any network access.

Determine GIT_DIR — the .git directory of the main repo. For a regular repo this is <MAIN_REPO>/.git. For a worktree it may differ; use git -C <MAIN_REPO> rev-parse --git-common-dir to get the correct path.

Determine WORKTREE_ENTRY — the name git uses for this worktree's entry in $GIT_DIR/worktrees/. This is $(basename <WORKTREE_PATH>).

bash
GIT_COMMON_DIR=$(git -C <MAIN_REPO> rev-parse --git-common-dir)
case "$GIT_COMMON_DIR" in
    /*) GIT_DIR=$GIT_COMMON_DIR ;;
    *) GIT_DIR=<MAIN_REPO>/$GIT_COMMON_DIR ;;
esac
WORKTREE_ENTRY=$(basename <WORKTREE_PATH>)

# Hardlink-copy the modules directory from the main repo while checking out the
# parent worktree files. These write disjoint paths, and the module copy only
# needs the worktree metadata created by `git worktree add --no-checkout`.
( cp -al $GIT_DIR/modules \
         $GIT_DIR/worktrees/$WORKTREE_ENTRY/modules ) &
cp_pid=$!

parent_checkout_status=0
git -C <WORKTREE_PATH> \
    -c checkout.workers=0 \
    -c core.fsync=none \
    -c gc.auto=0 \
    checkout -q -f HEAD -- . || parent_checkout_status=$?

modules_copy_status=0
wait "$cp_pid" || modules_copy_status=$?

if [ "$parent_checkout_status" -ne 0 ]
then
    printf "FAILED: parent checkout\n" >&2
    exit "$parent_checkout_status"
fi

if [ "$modules_copy_status" -ne 0 ]
then
    printf "FAILED: cp -al modules\n" >&2
    exit "$modules_copy_status"
fi

# Register submodules in the worktree config while rewriting module configs.
# These operations touch disjoint files: `submodule init` writes the worktree
# config, while the sed pass fixes copied submodule `config` and
# `config.worktree` files under the hardlinked modules dir.
git -C <WORKTREE_PATH> submodule init &
init_pid=$!

# Fix the worktree pointer inside each submodule's config and config.worktree
# files in one tree walk. Most modules use `config`; a few use the
# worktreeConfig extension and store the actual core.worktree in
# `config.worktree` instead.
find $GIT_DIR/worktrees/$WORKTREE_ENTRY/modules \
    \( -name config -o -name config.worktree \) -exec \
    sed -i "s|worktree = .*/contrib/|worktree = <WORKTREE_PATH>/contrib/|" {} +

if ! wait "$init_pid"
then
    printf "FAILED: submodule init\n" >&2
    exit 1
fi

CPU_COUNT=$(nproc)
DEFAULT_SUBMODULE_CHECKOUT_WORKERS=8
if [ "$DEFAULT_SUBMODULE_CHECKOUT_WORKERS" -gt "$CPU_COUNT" ]
then
    DEFAULT_SUBMODULE_CHECKOUT_WORKERS=$CPU_COUNT
fi

SUBMODULE_CHECKOUT_WORKERS=${SUBMODULE_CHECKOUT_WORKERS:-$DEFAULT_SUBMODULE_CHECKOUT_WORKERS}
if [ "$SUBMODULE_CHECKOUT_WORKERS" -lt 1 ]
then
    printf "FAILED: SUBMODULE_CHECKOUT_WORKERS must be positive\n" >&2
    exit 1
fi

SUBMODULE_JOBS=${SUBMODULE_JOBS:-$(( CPU_COUNT / SUBMODULE_CHECKOUT_WORKERS ))}
if [ "$SUBMODULE_JOBS" -lt 1 ]
then
    SUBMODULE_JOBS=1
fi

# This direct materialization path intentionally bypasses `git submodule update`.
# Refuse custom update commands because skipping those would change semantics.
( git -C <WORKTREE_PATH> config --file .gitmodules --get-regexp "^submodule\\..*\\.update$" 2>/dev/null || true ) |
    while IFS=" " read -r config_key update_command
    do
        case "$update_command" in
            "!"*)
                printf "FAILED: custom submodule update command is unsupported on local hardlink path: %s\n" "$config_key" >&2
                exit 1
                ;;
        esac
    done || exit 1

# Materialize submodule working trees in one parallel pass. Capture the gitlink
# commits once, sanity-check the count, then reuse the same list to feed each
# worker. If a commit is missing from the hardlinked module data, `git checkout`
# fails locally without fetching.
GITLINKS=$(git -C <WORKTREE_PATH> ls-files -s |
    sed -n "s/^160000 \([0-9a-f][0-9a-f]*\) 0[[:space:]]\(.*\)$/\1 \2/p")
GITLINK_COUNT=$(printf "%s\n" "$GITLINKS" | sed -n '$=')
SUBMODULE_COUNT=$(git -C <WORKTREE_PATH> config --file .gitmodules --get-regexp "^submodule\\..*\\.path$" |
    sed -n '$=')
if [ "${GITLINK_COUNT:-0}" != "${SUBMODULE_COUNT:-0}" ]
then
    printf "FAILED: gitlink count %s does not match .gitmodules count %s\n" "${GITLINK_COUNT:-0}" "${SUBMODULE_COUNT:-0}" >&2
    exit 1
fi

# Start known heavy submodules first, then emit the full gitlink list and keep
# the first occurrence of each path. This preserves largest-first scheduling
# without the per-submodule pack-size probing overhead.
{
    for submodule_path in \
        contrib/llvm-project \
        contrib/google-cloud-cpp \
        contrib/aws \
        contrib/openssl \
        contrib/icu \
        contrib/boost \
        contrib/rust_vendor \
        contrib/sysroot \
        contrib/grpc \
        contrib/arrow \
        contrib/curl \
        contrib/rocksdb \
        contrib/postgres \
        contrib/wasmtime
    do
        printf "%s\n" "$GITLINKS" |
            awk -v p="$submodule_path" '$2 == p { print; exit }'
    done

    printf "%s\n" "$GITLINKS"
} |
    awk "!seen[\$2]++ { print }" |
    while IFS=" " read -r expected_commit submodule_path
    do
        printf "%s\0%s\0" "$expected_commit" "$submodule_path"
    done |
    xargs -0 -r -n2 -P "$SUBMODULE_JOBS" sh -c '
        worktree_path=$1
        git_dir=$2
        worktree_entry=$3
        checkout_workers=$4
        expected_commit=$5
        submodule_path=$6

        if [ -z "$expected_commit" ] || [ -z "$submodule_path" ]
        then
            printf "FAILED: empty submodule checkout tuple\n" >&2
            exit 1
        fi

        module_git_dir="$git_dir/worktrees/$worktree_entry/modules/$submodule_path"
        module_worktree="$worktree_path/$submodule_path"

        mkdir -p "$module_worktree" || exit 1
        printf "gitdir: %s\n" "$module_git_dir" > "$module_worktree/.git" || exit 1

        if ! git --git-dir="$module_git_dir" --work-tree="$module_worktree" \
            -c advice.detachedHead=false \
            -c checkout.workers="$checkout_workers" \
            -c checkout.thresholdForParallelism=100 \
            -c index.threads=true \
            -c core.fsync=none \
            -c gc.auto=0 \
            checkout -q -f --detach "$expected_commit"
        then
            printf "FAILED: %s: commit %s is missing from the local mirror\n" "$submodule_path" "$expected_commit" >&2
            exit 1
        fi
    ' sh "<WORKTREE_PATH>" "$GIT_DIR" "$WORKTREE_ENTRY" "$SUBMODULE_CHECKOUT_WORKERS"

submodule_checkout_status=$?
if [ "$submodule_checkout_status" -ne 0 ]
then
    printf "ERROR: a submodule could not be checked out at the commit the superproject records (see the FAILED line above).\n" >&2
    printf "The local mirror is missing that commit, which happens when this worktree's branch pins a submodule\n" >&2
    printf "to a commit the main repo has never fetched. Fetch it in the main repo, then re-run step 6:\n" >&2
    printf "    git -C <MAIN_REPO> submodule update --init\n" >&2
    exit "$submodule_checkout_status"
fi

Important: git submodule init plus direct local checkout is used instead of git submodule update --init so the skill stays local-only. The submodule SHA is read from the superproject gitlink (git ls-files -s), so a worktree whose branch pins a submodule to a different commit than the source checkout still gets the correct dependency. If the hardlinked module data is incomplete, the command should fail; do not let git fetch or clone from the network on this path. If any submodule repair fails, the skill fails instead of silently skipping it, and prints the one command that fixes it (git -C <MAIN_REPO> submodule update --init, which fetches the missing commit into the shared mirror so a re-run succeeds offline). The default worker counts use nproc as a total budget: SUBMODULE_CHECKOUT_WORKERS defaults to min(8, nproc), and SUBMODULE_JOBS defaults to nproc / SUBMODULE_CHECKOUT_WORKERS, clamped to at least 1.

7. Report results

Report to the user:

  • Source repo: <MAIN_REPO>
  • Worktree path: <WORKTREE_PATH>
  • Branch: <branch-name> (newly created or existing)
  • Submodules: either "hardlinked from main repo (independent copies, no network cloning)" or "skipped (text-only task)" depending on the choice in step 5
  • Suggest: cd <WORKTREE_PATH>

Examples

  • /create-worktree my-feature — Create a new worktree with a new branch my-feature
  • /create-worktree fix/issue-12345 — Create a new worktree, branch name can contain slashes (slashes are replaced with dashes in the default directory name)

Notes

  • For text-only tasks (docs, comments, typo fixes, changelog entries), step 6 is skipped — git worktree add alone is enough, and the worktree is ready immediately. If you later need to build there, run step 6's commands by hand.
  • Submodules use hardlinks (cp -al) — git object files are hardlinked (no extra disk space) but each worktree has its own independent directory structure and config. Modifying submodules in one worktree does not affect others. Note this applies to the git object database only: the submodule working-tree files are checked out fresh (not hardlinked), so editing a contrib source in one worktree never touches another.
  • The main repo must have submodules already cloned (git submodule update --init must have been run in the main repo at least once).
  • To remove a worktree later (preferred):
    bash
    git -C <MAIN_REPO> worktree remove --force <WORKTREE_PATH>
    git -C <MAIN_REPO> worktree prune
  • Or, if the directory is already gone:
    bash
    rm -rf <WORKTREE_PATH>
    git -C <MAIN_REPO> worktree prune
  • Build directories are NOT shared — you'll need to set up CMake/build separately in the new worktree.

© ClickHouse, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/create-worktree of ClickHouse/ClickHouse.

Open the folder on GitHubat commit cd023af

Compare with similar skills

Create Worktree next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Create Worktree compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Create Worktree this skillClickHouse/ClickHouse50k—~3.5kAutomated safety check: PassApache-2.0
Version Upgrade Advisorchmonitor/chmonitor299—~1.6kAutomated safety check: PassGPL-3.0
Clickhouse Logs Queriessupabase/supabase111k—~2.4kAutomated safety check: PassApache-2.0
Chdb SQLvemetric/vemetric3941 repos~1.2kAutomated safety check: PassApache-2.0
Write Doc ExamplesClickHouse/clickhouse-java1.6k—~3.1kAutomated safety check: PassApache-2.0
Clickhouse Architecture Advisorvemetric/vemetric3942 repos~791Automated safety check: PassApache-2.0

Similar skills

  • Version Upgrade Advisor

    chmonitor/chmonitor

    Advises whether and how to upgrade ClickHouse — versioning scheme, upgrade path, what you gain, pre/post-upgrade checklist.

    299 GitHub stars~1.6k tokensUpdated 2 days ago
    DatabasesAuto-check passed
  • Clickhouse Logs Queries

    supabase/supabase

    Official

    Write, review, and migrate Supabase logs queries against the ClickHouse-backed logs table (the logs.all.otel analytics endpoint).

    111k GitHub stars~2.4k tokensUpdated today
    DatabasesAuto-check passed
  • Chdb SQL

    vemetric/vemetric

    A skill your agent uses when the user wants to run SQL — especially analytical SQL — on local files (parquet/csv/json), URLs, S3 paths, or remote databases (Postgres, MySQL, MongoDB, ClickHouse…

    394 GitHub starsUsed in 1 repo~1.2k tokens
    DatabasesAuto-check passed
  • Write Doc Examples

    ClickHouse/clickhouse-java

    Write, rewrite, and format documentation code snippets into reusable, production-ready methods with necessary library imports and clean linting.

    1.6k GitHub stars~3.1k tokensUpdated today
    DevelopmentAuto-check passed
  • MUST USE when designing ClickHouse architectures, selecting between ingestion or modeling patterns, or translating best practices into workload-specific system designs.

    394 GitHub starsUsed in 2 repos~791 tokens
    DatabasesAuto-check passed
  • Observal Admin

    Observal/Observal

    Administers Observal users, settings, diagnostics, review queues, security events, audit logs, SAML, SCIM, the local Observal server, its upgrades and rollback, and its own PostgreSQL and ClickHouse…

    4.2k GitHub stars~774 tokensUpdated yesterday
    DatabasesAuto-check passed

More from ClickHouse/ClickHouse

All 24 skills in this repo
  • Keeper Stress Analysis

    ClickHouse/ClickHouse

    Analyze ClickHouse Keeper stress-test results from play.clickhouse.com / keeperstresstests data warehouse.

    50k GitHub stars~4.7k tokensUpdated today
    Auto-check passed
  • Perf Comparison

    ClickHouse/ClickHouse

    Evaluate ClickHouse performance test results from existing CI/dashboard data or local perf.py runs.

    50k GitHub stars~3.9k tokensUpdated today
    Auto-check: notes
  • Patch Release Check

    ClickHouse/ClickHouse

    Check whether ClickHouse's supported versions (last 3 majors + latest LTS) have recent stable patch releases, diagnose why the scheduled AutoReleases pipeline failed, and identify which releases…

    50k GitHub stars~4k tokensUpdated today
    Auto-check: notes
  • Alloc Profile

    ClickHouse/ClickHouse

    Analyze a jemalloc (or other) allocation profile in collapsed stack format.

    50k GitHub stars~4.3k tokensUpdated today
    Auto-check passed
  • Bisect

    ClickHouse/ClickHouse

    Bisect a ClickHouse regression using pre-built master binaries from CI.

    50k GitHub stars~1.4k tokensUpdated today
    Auto-check passed
  • Clickhouse PR Description

    ClickHouse/ClickHouse

    Generate PR descriptions for ClickHouse/ClickHouse that match maintainer expectations.

    50k GitHub stars~1.9k tokensUpdated today
    Auto-check passed

Works with

Questions about Create Worktree

What does Create Worktree do?

Create a ClickHouse git worktree with submodules hardlinked from the main repo. Create Worktree is an agent skill from ClickHouse/ClickHouse. Create a ClickHouse git worktree with submodules hardlinked from the main repo.

When should I use Create Worktree?

Create Worktree fits situations like: the user wants to create a new worktree for ClickHouse development; tasks that involve Git worktrees; tasks that involve Data warehousing.

How do I install Create Worktree in Claude Code?

Run `npx skills add ClickHouse/ClickHouse --skill create-worktree -a claude-code`. Or copy the skill folder (.claude/skills/create-worktree in ClickHouse/ClickHouse) into .claude/skills/create-worktree in your project. Claude Code loads it when a task matches its description.

How do I install Create Worktree in Codex?

Run `npx skills add ClickHouse/ClickHouse --skill create-worktree -a codex`. Or copy the skill folder (.claude/skills/create-worktree in ClickHouse/ClickHouse) into .agents/skills/create-worktree in your project. Codex loads it when a task matches its description.

Can I use Create Worktree in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ClickHouse/ClickHouse --skill create-worktree -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/create-worktree, .gemini/skills/create-worktree, .github/skills/create-worktree and .opencode/skills/create-worktree in your project.

What does Create Worktree need to run?

Going by SKILL.md and its folder, Create Worktree needs the command-line tools its instructions call (git, aws, openssl and curl). Its frontmatter pre-approves these tools: Bash(git:*), Bash(cp:*), Bash(ln:*), Bash(ls:*), Bash(rm:*), Bash(mkdir:*), Bash(find:*), Bash(pwd:*), Bash(sed:*), Bash(awk:*), Bash(xargs:*), Bash(sh:*), Bash(nproc:*), AskUserQuestion.

Does Create Worktree access the network?

SKILL.md contains no URLs. Its commands use git and curl, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Create Worktree safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Create Worktree use?

Create Worktree is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Create Worktree use?

About 3.5k tokens (SKILL.md is roughly 14k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Create Worktree?

Skills that share tags, products or a category with Create Worktree: Version Upgrade Advisor (chmonitor/chmonitor, 299 stars), Clickhouse Logs Queries (supabase/supabase, 111k stars), Chdb SQL (vemetric/vemetric, 394 stars) and Write Doc Examples (ClickHouse/clickhouse-java, 1.6k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Create Worktree?

ClickHouse (a GitHub organization) maintains it in ClickHouse/ClickHouse, which has 50,288 GitHub stars. The repository holds 24 skills in this directory. The repository was last updated on October 8, 2026.

Source: ClickHouse/ClickHouse on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.