agentleFS
yunsiiyunsii/wezdeck/skills/cross-repo-delegate/SKILL.md

cross-repo-delegate

Skill4 starsChanged 48 days agoMITView on GitHub

Cross-repo work tickets (platform skill). Use when the user wants to file a ticket from one project to another (提单 / 跨仓委托 / 开给别的仓库的单), or in the receiving project to list inbox, claim, challenge assumptions, reply, or close (有没有我的单 / 认领 / 关单). Agent loads this skill and runs the co-located runner; humans only state intent. Target repos come from the local allowlist config, not from this description.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 4 are distinctive, and 8 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 8

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If a ticket is already session-claimed (owner=human), run / reply --continue / watch will not steal the lease unless the user explicitly …

    line 63
  2. Very specific:

    If ~/.agent/tickets/config.yml lacks the target, add it (path + aliases) before create.

    line 101
  3. Distinctive:

    Write observed + assumed from the user’s finding (required).

    line 109
  4. Very specific:

    Do not add --run unless the user asked for Mode 3 (委托开发).

    line 124
  5. Distinctive:

    Read the full ticket, then edit code in the current worktree/TUI.

    line 140
  6. Distinctive:

    If claim returns lease held → stop.

    line 141
  7. Very specific:

    Do not: call "$D" run after a successful session claim.

    line 142
  8. Distinctive:

    Only when the user explicitly wants a background worker:

    line 146
  9. Very specific:

    Update/create the topic solution doc in the target repo yourself.

    line 198
  10. Very specific:

    Use "$D" next --id <id> when unsure whose turn it is.

    line 209
  11. Very specific:

    Don’t: after claim (session) call run / spawn delegate-* worktree / headless worker

    line 220
  12. Very specific:

    Don’t: use --run / run unless the user asked to 委托 / 后台 / 派工人 (Mode 3)

    line 221

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Cross-repo delegate (work tickets)

Who runs: the coding agent (Host TUI / OpenClaw), not the human.
Never tell the user to copy-paste run.sh as the primary path.

Single source: this directory (SKILL.md + run.sh + test.sh). Other paths are symlinks from scripts/dev/link-platform-skills.sh.

Skill id: cross-repo-delegate. Short CLI on PATH (optional): delegate.

Three modes (hard rule)

ModeUser intentYou doMust NOT
1. 主会话创建工单提单 / 跨仓委托 / 只交票create(无 --run)自动 run / worktree / worker
2. 主会话认领并开发有没有我的单;认领;认领后改inbox → claim → show → 在当前 TUI/cwd 开发run / create --run / 建 delegate-* worktree
3. 主会话建单并委托开发明确说后台跑 / 派工人 / 委托开发create … --run 或已有单上 run --phase auto把 Mode 2 的认领误当成 Mode 3

claim 默认 session(owner=human)。Headless worker 才用 claim --as-worker(由 run 内部调用)。
认领 ≠ 派工人。 用户在 TUI 认领后,由当前主会话读票、调研、改代码、challenge / close。

Concrete repo names live only in ~/.agent/tickets/config.yml (and the user’s words), not in this skill’s trigger text.

Routing: ticket vs multi-dir mount

Default for 跨仓委托 / 认领 / 挑战 / 关单: this skill (Modes 1–3).
Product multi-dir mounts (Claude --add-dir, Codex multi-folder, Cursor multi-root, parent-folder workspaces) are a tactical way to keep one semantic edit coherent across checkouts. They do not replace the ticket protocol (ownership, observed/assumed, challenge/reply, allowlist, audit).

User signalYou do
提单 / 跨仓委托 / 有没有我的单 / 认领 / 挑战假设 / 关单 / 派工人Modes 1–3 below
Same intent must land in 2+ repos in one sitting (shared type rename, co-edited contract)Allow a short product multi-dir session; do not invent a second ticket store; prefer tickets when ownership or challenge is needed
Source-repo agent wants to “keep context” by writing the allowlisted target as standing practiceRefuse that framing — file/claim on the target (Mode 1/2) or Mode 3 worker on a target worktree

More visible files are not better cross-repo context for delegation: the target session must load that repo’s AGENTS.md / CLAUDE.md, keep the single-writer lease, and leave a reviewable contract. Policy detail: docs/agent-scheduling.md#ticket-vs-multi-dir-mount (from repo root: docs/agent-scheduling.md#ticket-vs-multi-dir-mount).

Skip / redirect: long exploratory design → interactive TUI / OpenClaw C2 handoff, not a ticket loop.

Mode 3 only — explicit headless dispatch

"$D" create … --run [--backend claude|codex|grok]
# = research; if verdict=accept → implement immediately
# if challenge/need_input → stops for initiator

"$D" run --id <id> --phase auto|research|implement
"$D" reply --id <id> --decision "…" --continue   # after challenge (worker-owned only)
"$D" watch --id <id> [--once] [--interval 20]    # blocked initiator loop (worker-owned)

Policy for Mode 3: no objection after research → start implement; objection → human reply then continue. Filing with --run means the initiator is blocked — prefer watch so work resumes when the ball returns. Use --mock offline.

If a ticket is already session-claimed (owner=human), run / reply --continue / watch will not steal the lease unless the user explicitly asks to force headless (run --steal). Prefer developing in the claiming TUI.

Prompt injection (token trim): workers embed a phase view, not the full ticket. Omit only high-noise / phase-irrelevant sections — never the hop’s contract. Both phases keep Summary + Assumptions; implement also gets Verification + Decision (+ Implement if present). Thread / events.jsonl stay on disk under _data/<id>/ (and .delegate/ticket.md) for on-demand Read only.

Headless workers call shared scripts/dev/host-agent-invoke/ (write mode), set AGENT_ATTENTION_SKIP=1 / DELEGATE_HEADLESS, and (Claude) disableAllHooks so they must not appear in the human attention badge / Alt+/ list. Scheduling map: docs/agent-scheduling.md.

Resolve TOOL_HOME (first hit wins)

1. $CROSS_REPO_DELEGATE_HOME or $DELEGATE_HOME
2. directory of this SKILL.md if run.sh is co-located
3. $HOME/.agents/skills/cross-repo-delegate   # usual after link
4. $WEZDECK_ROOT/skills/cross-repo-delegate
5. $HOME/github/wezterm-config/skills/cross-repo-delegate
TOOL_HOME=…   # dir that contains run.sh
D="$TOOL_HOME/run.sh"
# If `delegate` is on PATH (install-cli), you may use it; otherwise always $D.

Never assume the skill lives only under the TARGET repo (TOOL ≠ TARGET).

One-time (only if missing)

"$D" init
# optional PATH: "$D" install-cli   # installs short name `delegate`

If ~/.agent/tickets/config.yml lacks the target, add it (path + aliases) before create.

Agent procedure

A) Mode 1 — File a ticket (initiator project cwd)

  1. Resolve TOOL_HOME; confirm "$D" is executable.
  2. Infer --to <allowlist_key> from the user; use --from . when cwd is the source project (or an explicit source key).
  3. Write observed + assumed from the user’s finding (required).
  4. Run:
"$D" create \
  --to <target_key> \
  --from . \
  --title "<short>" \
  --observed "<what you saw>" \
  --assumed "<what target should guarantee>" \
  [--snippet-ref "path:line"] \
  [--summary "…"] [--source-pr "#…"]
  1. Report the printed id to the user. Do not commit the ticket into any git tree.
    Do not add --run unless the user asked for Mode 3 (委托开发).

B) Mode 2 — Inbox / claim / develop in this session (receiving project cwd)

"$D" inbox --to .
"$D" next --to .
"$D" claim --id <id>    # owner=human, mode=session
"$D" show --id <id>

--to . / --from . resolve the allowlist key from cwd via the primary git worktree root (git rev-parse --git-common-dir), so a linked worktree (…/.worktrees/<repo>/dev-…) counts as the same repo as the primary checkout — never as the worktree slug basename.

Read the full ticket, then edit code in the current worktree/TUI.
If claim returns lease held → stop; do not dual-write.
Do not call "$D" run after a successful session claim.

C) Mode 3 — Create and delegate development

Only when the user explicitly wants a background worker:

"$D" create … --run [--backend claude|codex|grok]
# or later:
"$D" run --id <id> --phase auto
"$D" watch --id <id>   # initiator blocked on worker

D) Challenge (target) → reply (initiator)

"$D" challenge --id <id> \
  --measured "…" --impact "…" --recommended "…" [--needs "…"]
# initiator side:
"$D" reply --id <id> --decision "…" --status waiting_target
# Mode 3 worker-owned only:
"$D" reply --id <id> --decision "…" --continue

Session-claimed tickets: after reply, the claiming TUI continues implement — no --continue.

E) Close

"$D" close --id <id> --doc <topic-doc-in-target-repo>
# or explicit skip:
"$D" close --id <id> --no-doc "<reason>"
# keep Mode 3 worktree (rare):
"$D" close --id <id> --no-doc "<reason>" --keep-worktree

close also reclaims the Mode 3 delegate-<id> worktree when meta.worktree is set (strips .delegate/**, keeps the local branch). Failure to reclaim does not undo close.

F) Inspect Mode 3 worktrees (decision table)

"$D" worktrees                 # JSON + stderr skim (suggest/dirty/ahead/age)
"$D" worktrees --alive         # only trees still on disk
"$D" worktrees --to .          # filter by target allowlist key

G) GC leftover Mode 3 worktrees

"$D" gc --dry-run
"$D" gc --execute --status closed,rejected,failed
"$D" gc --execute --include-shipped --min-age 7d
"$D" gc --execute --force --id <id>   # discard non-.delegate dirt

Update/create the topic solution doc in the target repo yourself; never commit ~/.agent/tickets/** into the project.

Status (authoritative)

submitted · in_progress · waiting_initiator · waiting_target · shipped · closed · rejected · failed

owner: worker | initiator | human

  • human = Mode 2 session claim (main TUI develops)
  • worker = Mode 3 headless path

Use "$D" next --id <id> when unsure whose turn it is.

Don't

  • Don’t ask the human to run CLI as the main path
  • Don’t commit tickets into project git / docs/decisions/
  • Don’t invent a second OpenClaw-only ticket store — same skill
  • Don’t skip --observed / --assumed on create
  • Don’t close without --doc or --no-doc
  • Don’t start a second claim while a lease is active
  • Don’t treat Ticket-headless as C3 ACP (or the reverse); OpenClaw Main picks 执行通道 — see openclaw/docs/agent-interaction.md §6
  • Don’t after claim (session) call run / spawn delegate-* worktree / headless worker
  • Don’t use --run / run unless the user asked to 委托 / 后台 / 派工人 (Mode 3)
  • Don’t replace Modes 1–3 with a standing multi-dir mount from the source repo into the target (“context is better if I edit both”) — tickets own delegation; mounts are tactical same-intent co-edits only

Tests (operators / CI — not the user path)

"$TOOL_HOME/test.sh"    # isolated MOCK fs; no LLM; no ~/.agent pollution

Related

  • Runner: run.sh · lib: lib/ (lifecycle.sh = claim/run/reply) · offline: test.sh
  • Link: scripts/dev/link-platform-skills.sh
  • Sibling: adversarial-review, brainstorm
  • Scheduling: docs/agent-scheduling.md (ticket vs multi-dir: #ticket-vs-multi-dir-mount)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.