Token导航 LogoToken导航

Agent Skill · 研究检索

agent-deck(特工甲板)

agent-deck 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

agent-deck 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为执行命令;许可证信息还不明确,第三方扫描有未通过项,按安装量在研究检索类的 73,675 个 Skill 里排第 39,123。

总安装 1,458周安装 62GitHub Stars 2,214下载 511核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/asheshgoplani/agent-deck --skill agent-deck

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词或任务场景快速定位候选结果时使用。适用于终端会话管理和 AI 代理协作流程,提供交互式节点图可视化。通过 npx skills add 命令从 GitHub 安装,需确认脚本路径解析和权限范围。

建议在安装前检查维护状态和文件读写边界,避免误执行命令。agent-deck 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/agent-deck

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

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

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

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

常见问题

6 条

agent-deck 怎么安装?

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

agent-deck 支持哪些 AI 工具?

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

agent-deck 需要什么权限?

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

agent-deck 是免费的吗?

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

agent-deck 用的人多吗?

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

agent-deck 安全吗?

第三方扫描有未通过项,风险较高。除非你确认过源码,否则不建议直接安装到常用环境。

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

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 来源仓库有 2,214 星,维护活跃度相对可查。

先想清楚的地方

  • 需要执行命令,装到常用环境前要先评估影响面。
  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

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

不太适合

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

研究检索类 Skill 对比

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

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
agent-deck

特工甲板 · 本页

1,4582,214执行命令未明确未通过

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

SKILL.md 原文

Agent Deck

Terminal session manager for AI coding agents. Built with Go + Bubble Tea.

Version: 0.8.98 | Repo: github.com/asheshgoplani/agent-deck | Discord: discord.gg/e4xSs6NBN8

Script Path Resolution (IMPORTANT)

This skill includes helper scripts in its scripts/ subdirectory. When Claude Code loads this skill, it shows a line like:

Base directory for this skill: /path/to/.../skills/agent-deck

You MUST use that base directory path to resolve all script references. Store it as SKILL_DIR:

# Set SKILL_DIR to the base directory shown when this skill was loaded
SKILL_DIR="/path/shown/in/base-directory-line"

# Then run scripts as:
$SKILL_DIR/scripts/launch-subagent.sh "Title" "Prompt" --wait

Common mistake: Do NOT use <project-root>/scripts/launch-subagent.sh. The scripts live inside the skill's own directory (plugin cache or project skills folder), NOT in the user's project root.

For plugin users, the path looks like: ~/.claude/plugins/cache/agent-deck/agent-deck/<hash>/skills/agent-deck/scripts/ For local development, the path looks like: <repo>/skills/agent-deck/scripts/

Quick Start

# Launch TUI
agent-deck

# Create and start a session
agent-deck add -t "Project" -c claude /path/to/project
agent-deck session start "Project"

# Send message and get output
agent-deck session send "Project" "Analyze this codebase"
agent-deck session output "Project"

Essential Commands

CommandPurpose
agent-deckLaunch interactive TUI
agent-deck add -t "Name" -c claude /pathCreate session
agent-deck session start/stop/restart <name>Control session
agent-deck session send <name> "message"Send message
agent-deck session output <name>Get last response
`agent-deck session current [-q\--json]`Auto-detect current session
agent-deck session fork <name>Fork Claude conversation
agent-deck mcp listList available MCPs
agent-deck mcp attach <name> <mcp>Attach MCP (then restart)
agent-deck statusQuick status summary
agent-deck add --worktree <branch>Create session in git worktree
agent-deck worktree listList worktrees with sessions
agent-deck worktree cleanupFind orphaned worktrees/sessions
agent-deck feedbackSubmit feedback (opens rating prompt + optional comment)

Status: ● running | ◐ waiting | ○ idle | ✕ error

Sub-Agent Launch

Use when: User says "launch sub-agent", "create sub-agent", "spawn agent"

$SKILL_DIR/scripts/launch-subagent.sh "Title" "Prompt" [--mcp name] [--wait]

The script auto-detects current session/profile and creates a child session.

Retrieval Modes

ModeCommandUse When
Fire & forget(no --wait)Default. Tell user: "Ask me to check when ready"
On-demandagent-deck session output "Title"User asks to check
Blocking--wait flagNeed immediate result

Recommended MCPs

Task TypeMCPs
Web researchexa, firecrawl
Code documentationcontext7
Complex reasoningsequential-thinking

Consult Another Agent (Codex, Gemini)

Use when: User says "consult with codex", "ask gemini", "get codex's opinion", "what does codex think", "consult another agent", "brainstorm with codex/gemini", "get a second opinion"

IMPORTANT: You MUST use the --tool flag to specify which agent. Without it, the script defaults to Claude.

Quick Reference

# Consult Codex (MUST include --tool codex)
$SKILL_DIR/scripts/launch-subagent.sh "Consult Codex" "Your question here" --tool codex --wait --timeout 120

# Consult Gemini (MUST include --tool gemini)
$SKILL_DIR/scripts/launch-subagent.sh "Consult Gemini" "Your question here" --tool gemini --wait --timeout 120

DO NOT try to create Codex/Gemini sessions manually with agent-deck add. Always use the script above. It handles tool-specific initialization, readiness detection, and output retrieval automatically.

Full Options

$SKILL_DIR/scripts/launch-subagent.sh "Title" "Prompt" \
  --tool codex|gemini \     # REQUIRED for non-Claude agents
  --path /project/dir \     # Working directory (auto-inherits parent path if omitted)
  --wait \                  # Block until response is ready
  --timeout 180 \           # Seconds to wait (default: 300)
  --mcp exa                 # Attach MCP servers (can repeat)

Supported Tools

ToolFlagNotes
Claude--tool claudeDefault, no flag needed
Codex--tool codexRequires codex CLI installed
Gemini--tool geminiRequires gemini CLI installed

How It Works

  1. Script auto-detects current session and profile
  2. Creates a child session with the specified tool in the parent's project directory
  3. Waits for the tool to initialize (handles Codex approval prompts automatically)
  4. Sends the question/prompt
  5. With --wait: polls until the agent responds, then returns the full output
  6. Without --wait: returns immediately, check output later with agent-deck session output "Title"

Examples

# Code review from Codex
$SKILL_DIR/scripts/launch-subagent.sh "Codex Review" "Read cmd/main.go and suggest improvements" --tool codex --wait --timeout 180

# Architecture feedback from Gemini
$SKILL_DIR/scripts/launch-subagent.sh "Gemini Arch" "Review the project structure and suggest better patterns" --tool gemini --wait --timeout 180

# Both in parallel (consult both, compare answers)
$SKILL_DIR/scripts/launch-subagent.sh "Ask Codex" "Best way to handle errors in Go?" --tool codex --wait --timeout 120 &
$SKILL_DIR/scripts/launch-subagent.sh "Ask Gemini" "Best way to handle errors in Go?" --tool gemini --wait --timeout 120 &
wait

Cleanup

After getting the response, remove the consultation session:

agent-deck remove "Consult Codex"
# Or remove multiple at once:
agent-deck remove "Codex Review" && agent-deck remove "Gemini Arch"

Peer (Root) Sessions vs Sub-Agents

The default — sub-agent linkage: agent-deck launch and agent-deck add, when invoked from *inside* an existing agent-deck session, automatically link the new session as a child of the calling session (sets parent_session_id, inherits the parent's group when -g is omitted, and grants --add-dir to the parent's project path). This is usually what you want for short-lived work sessions (plan / verify / release / consult).

When the default is wrong — root-level peer sessions: if you are creating a session that should stand independently at the root — a peer conductor, a standalone project session, a session that should outlive the current one, or anything that semantically is NOT a child of the calling session — pass the -no-parent flag.

Use caseParent linkageFlag
Plan / impl / verify worker for the current task✅ child(default)
Consultation (codex / gemini / research)✅ child(default)
Another conductor (root-level peer)❌ child-no-parent
Project session unrelated to current work❌ child-no-parent
Session intended to outlive the caller❌ child-no-parent
# Root-level peer conductor, no parent linkage:
agent-deck launch ~/projects/foo -t "conductor-foo" -g "conductor" -c claude -no-parent -m "..."

# Verify after spawn:
agent-deck list --json | jq '.[] | select(.title=="conductor-foo") | .parent_session_id'
# Must print: null

Symptoms you created a sub-agent when you wanted a peer:

  • parent_session_id is non-null in list --json output
  • The new session's baked pane_start_command contains --add-dir <caller's path> even though you gave it a different project path
  • Transition events for the new session's children flow to the caller instead of the new peer
  • Event routing and heartbeat parent-linkage puts it under the caller's tree in the TUI

Fix for an already-created sub-agent: stop + remove the session, re-launch with -no-parent. There is no in-place un-parent flag.

Note on the launch-subagent.sh script: that script is specifically designed to create sub-agents (the name says so). It does NOT support -no-parent. For peer sessions, skip the script and invoke agent-deck launch -no-parent directly.

Conductors

A conductor is a persistent agent-deck session that orchestrates other sessions. It watches the rest of your sessions, auto-responds when confident, escalates to you when ambiguous, and optionally pairs with a remote channel (Telegram or Slack) so you can talk to it from your phone.

Use this section when the user says "conductor", "set up a conductor", "monitor sessions", "telegram bot for agent-deck", "slack bot for agent-deck", or "remote control my sessions".

# Create a conductor in the default profile
agent-deck conductor setup ops --description "Ops monitor"

# Create on a specific profile (work/personal/etc.)
agent-deck -p work conductor setup infra --description "Infra watcher"

# Use a non-Claude agent for the conductor itself
agent-deck conductor setup review --agent codex --description "Codex reviewer"

# Provide custom env (e.g., third-party Anthropic-compatible endpoint)
agent-deck conductor setup glm-bot \
  -env ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic \
  -env ANTHROPIC_AUTH_TOKEN=<token>

# Status across all conductors
agent-deck conductor status

# List configured conductors
agent-deck conductor list

Each conductor lives at ~/.agent-deck/conductor/<name>/ with its own CLAUDE.md (or AGENTS.md for Codex), meta.json, state.json, and task-log.md. Multiple conductors per profile are supported and each can pair with its own bot.

Channels (Telegram / Slack)

Channels are how a conductor talks to you remotely. Each conductor pairs one-to-one with its own bot — bots are not shared. agent-deck conductor setup interactively walks you through Telegram or Slack pairing during creation.

Key constraints:

  • The Telegram plugin must be installed under the conductor's Claude profile, but never globally enabled in settings.json. Per-session activation happens via the channels field on the conductor's session record.
  • Bot tokens live at <channel-state-dir>/.env (chmod 600). Never committed to git.
  • Exactly one bot, one conductor, one chat — the routing is deterministic.
  • Watch for the "many competing telegram pollers" gotcha (see Known Gotchas section below) — child sessions inherit TELEGRAM_STATE_DIR and can leak duplicate pollers on the same bot token, causing 409 conflicts.

See: documentation/CONDUCTOR.md for the full ten-minute quickstart, telegram bot creation flow, multi-conductor setups, and lifecycle commands.

TUI Keyboard Shortcuts

Navigation

KeyAction
j/k or ↑/↓Move up/down
h/l or ←/→Collapse/expand groups
EnterAttach to session

Session Actions

KeyAction
nNew session
r/RRestart (reloads MCPs)
mMCP Manager
sSkills Manager
f/FFork Claude session
dDelete
MMove to group

Search & Filter

KeyAction
/Local search
GGlobal search (all Claude conversations)
!@#$Filter by status (running/waiting/idle/error)

Global

KeyAction
?Help overlay
Ctrl+QDetach (keep tmux running)
Ctrl+EOpen feedback dialog
qQuit

MCP Management

Default: Do NOT attach MCPs unless user explicitly requests.

# List available
agent-deck mcp list

# Attach and restart
agent-deck mcp attach <session> <mcp-name>
agent-deck session restart <session>

# Or attach on create
agent-deck add -t "Task" -c claude --mcp exa /path

Scopes:

  • LOCAL (default) - .mcp.json in project, affects only that session
  • GLOBAL (--global) - Claude config, affects all projects

Worktree Workflows

Create Session in Git Worktree

When working on a feature that needs isolation from main branch:

# Create session with new worktree and branch
agent-deck add /path/to/repo -t "Feature Work" -c claude --worktree feature/my-feature --new-branch

# Create session in existing branch's worktree
agent-deck add . --worktree develop -c claude

List and Manage Worktrees

# List all worktrees and their associated sessions
agent-deck worktree list

# Show detailed info for a session's worktree
agent-deck worktree info "My Session"

# Find orphaned worktrees/sessions (dry-run)
agent-deck worktree cleanup

# Actually clean up orphans
agent-deck worktree cleanup --force

When to Use Worktrees

Use CaseBenefit
Parallel agent workMultiple agents on same repo, different branches
Feature isolationKeep main branch clean while agent experiments
Code reviewAgent reviews PR in worktree while main work continues
Hotfix workQuick branch off main without disrupting feature work

Watchers

Watchers listen for inbound events (webhooks, push notifications, GitHub events, Slack messages) and route them into conductor sessions. Use them when the user says "set up a watcher", "listen for webhooks", "route GitHub events to my conductor", "forward ntfy notifications", or similar.

Four adapter types are supported:

TypeRequired flagTypical use
webhook--portGeneric HTTP listener
github--secretGitHub repo webhooks with HMAC verification
ntfy--topicntfy.sh push notifications
slack--topicSlack (via Cloudflare Worker bridge)
agent-deck watcher create <type> --name <name> <adapter-flags...>
agent-deck watcher start <name>
agent-deck watcher list                # health + events/hour
agent-deck watcher test <name>         # synthetic event (verify routing)

Full conversational setup flow is available as a separate skill:

agent-deck watcher install-skill watcher-creator

After running the install command, read ~/.agent-deck/skills/pool/watcher-creator/SKILL.md to walk the user through adapter selection, required settings, and configuring ~/.agent-deck/watcher/<name>/clients.json routing.

See agent-deck watcher --help for the full command surface and per-adapter examples.

Configuration

File: ~/.agent-deck/config.toml

[claude]
config_dir = "~/.claude-work"    # Custom Claude profile
dangerous_mode = true            # --dangerously-skip-permissions

[logs]
max_size_mb = 10                 # Max before truncation
max_lines = 10000                # Lines to keep

[mcps.exa]
command = "npx"
args = ["-y", "exa-mcp-server"]
env = { EXA_API_KEY = "key" }
description = "Web search"

See config-reference.md for all options.

Troubleshooting

IssueSolution
Session shows erroragent-deck session start <name>
MCPs not loadingagent-deck session restart <name>
Flag not workingPut flags BEFORE arguments: -m "msg" name not name -m "msg"

Get Help

  • Discord: discord.gg/e4xSs6NBN8 for quick questions and community support
  • GitHub Issues: For bug reports and feature requests

Report a Bug

If something isn't working, create a GitHub issue with context:

# Gather debug info
agent-deck version
agent-deck status --json
cat ~/.agent-deck/config.toml | grep -v "KEY\|TOKEN\|SECRET"  # Sanitized config

# Create issue at:
# https://github.com/asheshgoplani/agent-deck/issues/new

Include:

  1. What you tried (command/action)
  2. What happened vs expected
  3. Output of commands above
  4. Relevant log: tail -100 ~/.agent-deck/logs/agentdeck_<session>_*.log

See troubleshooting.md for detailed diagnostics.

Session Sharing

Share Claude sessions between developers for collaboration or handoff.

Use when: User says "share session", "export session", "send to colleague", "import session"

# Export current session to file (session-share is a sibling skill)
$SKILL_DIR/../session-share/scripts/export.sh
# Output: ~/session-shares/session-<date>-<title>.json

# Import received session
$SKILL_DIR/../session-share/scripts/import.sh ~/Downloads/session-file.json

See: session-share skill for full documentation.

Critical Rules

  1. Flags before arguments: session start -m "Hello" name (not name -m "Hello")
  2. Restart after MCP attach: Always run session restart after mcp attach
  3. Never poll from other agents - can interfere with target session

Known Gotchas (v1.7.0+)

Friction points discovered during real usage. Work around them per the patterns below.

session send --no-wait can leave prompts typed-but-not-submitted

On a freshly-launched Claude session, agent-deck session send --no-wait <id> "..." may paste the message into the input buffer before Claude is fully ready, leaving it TYPED but not SUBMITTED. Classic race.

Workaround (always safe):

agent-deck -p <profile> session send <id> "..." --no-wait -q
sleep 3
# Get the tmux session name and send Enter to submit
TMUX=$(agent-deck -p <profile> session show --json <id> | jq -r .tmux_session)
tmux send-keys -t "$TMUX" Enter

The Enter is idempotent — if already submitted, it's just a no-op newline. Use this pattern every time you session send --no-wait to a freshly-launched session.

Alternative: omit --no-wait so the built-in 60s readiness wait kicks in before submitting.

Replacing the binary while agent-deck is running (text file busy)

If /usr/local/bin/agent-deck is a symlink to a build artifact and the binary is currently running (any tmux session, any daemon), a direct cp over it fails with Text file busy.

Workaround — move-then-copy (keeps running processes on the old inode):

INSTALL=$(which agent-deck)
TARGET=$(readlink -f "$INSTALL")
go build -ldflags "-X main.Version=X.Y.Z" -o /tmp/agent-deck-new ./cmd/agent-deck
mv "$TARGET" "$TARGET.old"
cp /tmp/agent-deck-new "$TARGET" && chmod +x "$TARGET"
agent-deck --version    # verify
rm "$TARGET.old"

Kernel tracks inodes, not names. Running processes keep a reference to the renamed inode; new invocations resolve through the original name to the new inode.

Cross-machine config drift (macOS ↔ Linux)

If ~/.agent-deck/skills/sources.toml (or other config files) were copied verbatim from a macOS machine, paths like /Users/<name>/ won't exist on Linux (should be /home/<user>/). The symptom: agent-deck skill list returns "No skills found" while the pool directory is clearly populated.

Check & fix:

grep -n "/Users/" ~/.agent-deck/skills/sources.toml
# If any matches, substitute the Linux home path:
sed -i "s|/Users/<mac-user>|$HOME|g" ~/.agent-deck/skills/sources.toml

Channel subscription for conductor/bot sessions (v1.7.0+)

For a session to receive Telegram/Discord/Slack messages as conversation turns (not just as MCP tool calls), it MUST be started with --channels <plugin-id>. Use the first-class field:

# At creation (preferred):
agent-deck -p personal add --channel plugin:telegram@claude-plugins-official -c claude -t my-bot /path

# Or after creation, then restart:
agent-deck -p personal session set my-bot channels plugin:telegram@claude-plugins-official
agent-deck -p personal session restart my-bot

The channels field persists and every session start / session restart rebuilds the claude invocation with --channels. Do NOT rely on .mcp.json telegram entries — those load the plugin as a regular MCP (tools only), not a channel (inbound delivery).

Note — v1.7.0 display bug: agent-deck session show --json <id> currently omits the channels field (fix pending). agent-deck list --json | jq '.[] | select(.id==<id>)' shows it correctly. Data is persisted fine regardless.

Many competing telegram pollers after multiple session starts

Telegram's Bot API getUpdates is single-consumer per bot token. If N Claude sessions all load the telegram plugin, N bun pollers race for messages — deliveries land in whichever wins, not where you want them.

Correct topology: exactly ONE session loads the telegram channel plugin (normally the conductor, via --channels at start-time). All other sessions should NOT have telegram in their enabled plugins.

Disable globally: in ~/.claude/settings.json:

"enabledPlugins": {
  "telegram@claude-plugins-official": false
}

Enable per-session: via --channel on the specific session that should receive messages. See "Channel subscription" above.

Debug: pgrep -af "bun.*telegram" | wc -l should return 1. Anything higher means a race. Kill extras: pkill -f "bun.*telegram" then restart only the intended session.

Telegram conductor topology (v1.7.22+)

Supported topology — enforce this on every conductor host:

  • Telegram is activated per-session via --channels plugin:telegram@claude-plugins-official. This is the only supported activation path for a conductor bot.
  • TELEGRAM_STATE_DIR is injected exclusively via [conductors.<name>.claude].env_file in ~/.agent-deck/config.toml. The env file sources deterministically on both fresh-start and --resume spawns.
  • One bot token = one channel-owning session. Never share tokens between sessions.
  • enabledPlugins."telegram@claude-plugins-official" in the profile settings.json must be absent or false. Global enablement makes every claude subprocess (including child agents) load the plugin.

Codified anti-patterns — agent-deck v1.7.22 emits warnings for these:

Anti-patternCodeWhy it breaks
enabledPlugins."telegram@claude-plugins-official" = true in profile settingsGLOBAL_ANTIPATTERNEvery claude process loads the plugin, including every child agent the conductor spawns. Each one starts a bun telegram poller.
Global enablement AND --channels plugin:telegram@... on the same sessionDOUBLE_LOADThe plugin loads twice in one claude process. Two bun pollers race on one bot token and Telegram rejects with 409 Conflict.
session set wrapper "TELEGRAM_STATE_DIR=... {command}"WRAPPER_DEPRECATEDWorks on the resume path; silently fails on fresh-start due to bash -c argv splitting. The env var never reaches claude, so the plugin falls back to the default state dir and two conductors collide. Use env_file instead.
Relying on .mcp.json telegram entries for inbound delivery—.mcp.json loads the plugin as an MCP server (tool-use only). Inbound message → conversation-turn delivery requires --channels.
Using the same bot token for multiple concurrent sessions—getUpdates is single-consumer per token.
Assuming an empty TELEGRAM_STATE_DIR is fine—The plugin falls back to ~/.claude/channels/telegram/; any DM approval there leaks across unrelated conductors.

Verifying steady state (conductor host):

pgrep -af 'bun.*telegram' | grep -v grep | wc -l   # expect: exactly one per conductor bot
for PID in $(pgrep -f 'bun.*telegram.*start'); do
  echo "PID=$PID TSD=$(tr '\0' '\n' < /proc/$PID/environ | grep ^TELEGRAM_STATE_DIR= | cut -d= -f2-)"
done
# Each PID must show a distinct TELEGRAM_STATE_DIR; collisions indicate env_file is not being sourced.

When agent-deck emits a ⚠ GLOBAL_ANTIPATTERN / DOUBLE_LOAD / WRAPPER_DEPRECATED warning, the problem is in your topology, not in agent-deck. Fix the profile settings or the conductor env_file; the warning is a leading indicator of the 409-Conflict symptom that follows minutes-to-hours later.

References

User guides (full how-to, in the repo):

Reference (shipped with this skill):

平台分布

Codex

37.33%
按下载量换算191

Claude

31.41%
按下载量换算161

Cursor

17.56%
按下载量换算90

Gemini CLI

9.34%
按下载量换算48

安全审计

Gen Agent Trust Hub

通过

Socket

可疑

Snyk

未通过

权限和风险

执行命令

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

安装前确认

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

继续浏览同类 Skills