Token导航 LogoToken导航

Agent Skill · 前端设计

parallel(parallel 搜索)

parallel 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

parallel 是前端设计类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为执行命令;许可证信息还不明确,第三方扫描已通过,按安装量在前端设计类的 10,216 个 Skill 里排第 8,006。

总安装 321周安装 13GitHub Stars 18下载 101核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:parallel(parallel 搜索)
来源仓库:https://github.com/jay-523/agent-skills
仓库路径:skills/parallel
安装命令:
npx skills add https://github.com/jay-523/agent-skills --skill parallel
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/jay-523/agent-skills --skill parallel

这个 Skill 是做什么的

前端设计类 Skill 关注页面结构、视觉规范和组件写法,输出通常是可运行的界面代码。

parallel 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息。适合在 Codex、Claude、Cursor、Gemini CLI 中围绕仓库状态、代码变更或协作事项进行整理。通过 npx skills add 命令从指定仓库安装 parallel 技能。

安装前需确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。建议结合原始 README 核验具体用法和功能边界。

来源仓库内路径:skills/parallel

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/jay-523/agent-skills --skill parallel;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要执行命令,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

parallel 怎么安装?

在终端执行 npx skills add https://github.com/jay-523/agent-skills --skill parallel。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

parallel 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

parallel 需要什么权限?

权限级别是执行命令。安装流程涉及命令执行,可能通过 npx skills add https://github.com/jay-523/agent-skills --skill parallel 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

parallel 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

parallel 用的人多吗?

公开数据是累计安装 321 次,近一周安装 13 次,下载 101 次,GitHub 18 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

parallel 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 需要执行命令,装到常用环境前要先评估影响面。
  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理前端设计类任务、又不想每次都手写提示词的人。

不太适合

  • 不能接受 Skill 在你机器上执行命令的人。
  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

前端设计类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
frontend-design

前端设计 · Codex、Claude

8,823,360126,072只读MIT通过
vercel-composition-patterns

Vercel 组合模式 · Codex、Claude

3,858,81625,893需要联网MIT通过
vercel-react-native-skills

Vercel React native skills 前端 · Codex、Claude

2,468,66425,878只读MIT通过
adapt

adapt 搜索 · Codex、Claude

2,027,04023,125操作浏览器未明确通过
bolder

bolder 分析 · Codex、Claude

2,004,28823,130只读未明确通过
parallel

parallel 搜索 · 本页

32118执行命令未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

/parallel -- Parallel Agent Orchestration via tmux + git Worktrees

Split a task into independent workstreams and run them as parallel Claude Code agents in separate tmux panes, each in its own git worktree.

Argument

Either a task description to plan and decompose, or the word "plan" to use the current plan from this conversation.

Procedure

Phase 1 -- Plan

If the argument is "plan": use the existing plan from the current conversation context.

Otherwise: create a plan for the given task. Identify what needs to be built, the modules involved, and the dependencies between them.

Phase 2 -- Decompose into Workstreams

Split the plan into 3-4 independent workstreams (hard maximum: 4).

Decomposition rules:

  • Divide by domain/module, NOT by task type. Each agent owns a vertical slice (e.g., "auth module", "payment module"), not a horizontal layer (e.g., "write all tests", "write all implementations"). Horizontal decomposition causes 3-10x token waste because each agent must re-read the same context.
  • Each agent owns its files exclusively. No two agents write to the same file. Shared dependencies are read-only for non-owning agents.
  • If a workstream depends on another's output, mark it and sequence the launch accordingly.

Present the decomposition table and wait for user approval:

| Agent | Domain | Owned Files | Read-Only Files | Depends On |
|-------|--------|-------------|-----------------|------------|
| auth  | Authentication | src/auth/* | src/models/* | none |
| api   | API endpoints  | src/api/*  | src/auth/*   | auth |
| ui    | Frontend       | src/ui/*   | src/api/*    | none |

Do NOT proceed until the user approves this decomposition.

Phase 3 -- Setup Worktrees

For each agent in the approved decomposition:

git worktree add ./worktrees/{agent-name} -b parallel/{agent-name}

Add worktrees/ to .gitignore if not already present.

For each worktree:

# Copy environment files
cp .env ./worktrees/{agent-name}/.env 2>/dev/null || true
cp -r venv ./worktrees/{agent-name}/venv 2>/dev/null || true

# Create coordination directories
mkdir -p ./worktrees/{agent-name}/run
mkdir -p ./shared/progress

Install dependencies if needed:

cd ./worktrees/{agent-name} && source venv/bin/activate && uv pip install -e . 2>/dev/null || true

Phase 4 -- Generate Agent Prompts

For each agent, write ./worktrees/{agent-name}/run/prompt.md containing:

  1. Scope: What this agent is responsible for building
  2. File Ownership: Files this agent may create/modify (exclusive)
  3. Read-Only Files: Files this agent may read but must not modify
  4. Success Criteria: How to know when the work is done
  5. Constraints:

- Follow all CLAUDE.md conventions (copy relevant entries) - Add docstrings to all functions with algorithm in English - Expected schema for loose objects in docstrings - if __name__ == '__main__' blocks with hardcoded examples - No argparse, no emojis - Use uv pip install, source venv/bin/activate

  1. Progress Tracking: Write status to ../shared/progress/{agent-name}.json after each major milestone using this format: {"agent": "{agent-name}", "timestamp": "ISO-8601", "status": "in_progress|blocked|done", "completed": ["list of completed items"], "remaining": ["list of remaining items"], "blocked_by": null, "notes": ""}

Phase 4.5 -- Create Launcher Script

Write ./run-agent.sh in the project root:

#!/bin/bash
# Usage: bash run-agent.sh /path/to/worktree [model]
# Pipes the agent prompt to claude -p with pre-approved tools.
# Writes output to run/output.md and prints a COMPLETE marker when done.
cd "$1"
source venv/bin/activate 2>/dev/null || true
MODEL="${2:-claude-sonnet-4-6}"
echo "=== Starting agent: $(basename $1) with model $MODEL ==="
echo "=== $(date) ==="
echo ""
cat run/prompt.md | claude -p \
  --model "$MODEL" \
  --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
  2>&1 | tee run/output.md
echo ""
echo "=== Agent $(basename $1) COMPLETE at $(date) ==="

Make it executable: chmod +x run-agent.sh

CRITICAL: Pipe the prompt via stdin (cat prompt.md | claude -p). NEVER pass the prompt content through tmux send-keys -- any quotes, backticks, $, backslashes, or newlines in the prompt will be shell-expanded or break the command. The launcher script avoids this entirely by keeping the prompt in a file and piping it.

Phase 5 -- Launch Agents

Create a tmux session and launch agents via the launcher script:

# Create session
tmux new-session -d -s parallel -x 200 -y 50

# First agent gets the first pane
tmux send-keys -t parallel "bash run-agent.sh $(pwd)/worktrees/{agent-1}" Enter

# Additional agents get split panes
tmux split-window -t parallel -h
tmux send-keys -t parallel "bash run-agent.sh $(pwd)/worktrees/{agent-2}" Enter

# Repeat for agents 3-4 if needed
tmux split-window -t parallel -v
tmux send-keys -t parallel "bash run-agent.sh $(pwd)/worktrees/{agent-3}" Enter

After launching, verify processes are running:

ps aux | grep "claude -p" | grep -v grep | wc -l

Print monitoring instructions for the user:

## Parallel Agents Running

Attach to the session:
  tmux attach -t parallel

Monitor progress:
  cat shared/progress/*.json | jq .

Switch between panes:
  Ctrl-b + arrow keys

Kill session when done:
  tmux kill-session -t parallel

Phase 5.5 -- Wait for Completion

Use the wait-for-text.sh helper from the /tmux skill to automatically detect when each agent finishes:

WAIT="$HOME/Developer/personal_projects/agent-skills/skills/tmux/scripts/wait-for-text.sh"
TIMEOUT=600  # 10 minutes per agent; adjust as needed

all_done=true
for pane_id in {list of parallel:0.N targets}; do
  agent_name="{name for this pane}"
  if bash "$WAIT" -t "$pane_id" -p "COMPLETE" -T "$TIMEOUT" -i 5; then
    echo "$agent_name: DONE"
  else
    echo "$agent_name: TIMED OUT or FAILED -- check pane manually"
    all_done=false
  fi
done

if $all_done; then
  echo "All agents complete. Ready to merge."
else
  echo "Some agents did not finish. Check timed-out panes before merging."
fi

The loop watches for the COMPLETE marker that run-agent.sh prints when claude -p exits. Each agent gets the full timeout before moving to the next check.

You can also manually check progress via cat shared/progress/*.json.

Phase 6 -- Merge Strategy

After all agents report "done", provide merge commands:

# Merge each agent branch with --no-ff to preserve history
git merge --no-ff parallel/{agent-1} -m "Merge {agent-1}: {description}"
git merge --no-ff parallel/{agent-2} -m "Merge {agent-2}: {description}"
git merge --no-ff parallel/{agent-3} -m "Merge {agent-3}: {description}"

Conflict resolution guidance:

  • If two agents touched the same file despite ownership rules, the owning agent's version wins
  • For shared config files (package.json, pyproject.toml), merge both sets of changes manually
  • Run the full test suite after each merge

Cleanup commands:

# Remove worktrees
git worktree remove ./worktrees/{agent-1}
git worktree remove ./worktrees/{agent-2}
git worktree remove ./worktrees/{agent-3}

# Delete branches
git branch -d parallel/{agent-1}
git branch -d parallel/{agent-2}
git branch -d parallel/{agent-3}

# Remove shared progress
rm -rf ./shared/progress/

Troubleshooting

Check agent status Run the health-check recipe from /tmux to classify every pane:

DIAG="$HOME/Developer/personal_projects/agent-skills/skills/tmux/scripts/diagnose-agents.sh"
bash "$DIAG" parallel "worktrees/*/run/output.md"

Each pane is classified as DONE, WORKING, FAILED, or UNKNOWN. See the /tmux skill's "Health-Check Running Agents" recipe for details on what each state means and how it's detected.

FAILED state -- what to do Inspect the pane for the root cause:

tmux capture-pane -t parallel:0.{pane} -p -S - | tail -30

Common causes: rate limit hit, permission denial (missing --allowedTools), Python/Node traceback, or OOM. Fix the cause and re-launch the agent (see below).

DONE but no run/output.md This is a tee buffering issue. The agent finished (COMPLETE marker present in the pane) but the file wasn't flushed. Capture the pane scrollback directly:

tmux capture-pane -t parallel:0.{pane} -p -S - > worktrees/{agent}/run/output.md

Re-running a single failed agent Send the launcher command to the same pane:

tmux send-keys -t parallel:0.{pane} "bash run-agent.sh $(pwd)/worktrees/{agent-name}" Enter

The previous output.md will be overwritten by tee.

tmux session died Re-create the session (Phase 5). Run diagnose-agents.sh or check which agents have the COMPLETE marker in their run/output.md. Only re-launch agents that didn't complete. Completed agents already committed their work to their worktree branch.

Worktree in a bad state after agent crash Check the branch for partial commits: cd worktrees/{agent} && git log --oneline -5. If the agent made useful partial progress, you can keep the branch and re-launch to continue. If the state is unrecoverable:

git worktree remove ./worktrees/{agent-name}
git branch -D parallel/{agent-name}

Then re-create the worktree (Phase 3) and re-launch.

Merge conflicts during Phase 6 If agents violated file ownership rules and both modified the same file, the owning agent's version wins. Use git checkout --theirs {file} or git checkout --ours {file} accordingly. Run tests after each merge.

Important

  • Maximum 3-4 parallel agents. More than 4 has diminishing returns and burns credits rapidly.
  • Always decompose by domain/module, never by task type.
  • Always wait for user approval of the decomposition before creating worktrees.
  • Each agent MUST have exclusive file ownership. Overlapping writes guarantee merge conflicts and wasted work.
  • Do not launch agents for tasks that have sequential dependencies. If B depends on A's output, A must finish first.

平台分布

Codex

33.48%
按下载量换算34

Claude

32%
按下载量换算32

Cursor

19.44%
按下载量换算20

Gemini CLI

9.68%
按下载量换算10

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/jay-523/agent-skills --skill parallel 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills