Token导航 LogoToken导航

Agent Skill · 研究检索

swain-do(斯温多)

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

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

总安装 2,827周安装 119GitHub Stars 2下载 990核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

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

skills.shnpx skills
npx skills add https://github.com/cristoslc/swain --skill swain-do

这个 Skill 是做什么的

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

swain-do 用于查找、检索和筛选相关信息。适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词快速定位候选结果。通过 npx skills add 命令从指定仓库安装,需结合原始 README 核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

当前已有较完整的功能说明,可直接用于相关搜索场景。

来源仓库内路径:skills/swain-do

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

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

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

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

常见问题

6 条

swain-do 怎么安装?

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

swain-do 支持哪些 AI 工具?

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

swain-do 需要什么权限?

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

swain-do 是免费的吗?

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

swain-do 用的人多吗?

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

swain-do 安全吗?

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

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

值得选的地方

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

先想清楚的地方

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

适不适合你

更适合

  • 已经在用 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调用外部服务未明确有提醒
swain-do

斯温多 · 本页

2,8272执行命令未明确通过

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

SKILL.md 原文

Execution Tracking

Before proceeding with any state-changing operation, check for an active session:

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
bash "$REPO_ROOT/.agents/bin/swain-session-check.sh" 2>/dev/null

If the JSON output has "status" other than "active", inform the operator: "No active session — start one with /swain-init?" Proceed if they dismiss.

Abstraction layer for agent execution tracking. Other skills (e.g., swain-design) express intent using abstract terms; this skill translates that intent into concrete CLI commands.

Before first use: Read references/tk-cheatsheet.md for complete command syntax, flags, ID formats, and anti-patterns.

Artifact handoff protocol

This skill receives handoffs from swain-design based on a four-tier tracking model:

TierArtifactsThis skill's role
ImplementationSPECCreate a tracked implementation plan and task breakdown before any code is written
CoordinationEPIC, VISION, JOURNEYDo not track directly — swain-design decomposes these into children first, then hands off the children
ResearchSPIKECreate a tracked plan when the research is complex enough to benefit from task breakdown
ReferenceADR, PERSONA, RUNBOOKNo tracking expected

If invoked directly on a coordination-tier artifact (EPIC, VISION, JOURNEY) without prior decomposition, defer to swain-design to create child SPECs first, then create plans for those children.

Term mapping

Other skills use these abstract terms. This skill maps them to the current backend (tk):

Abstract termMeaningtk command
implementation planTop-level container grouping all tasks for a spec artifacttk create "Title" -t epic --external-ref <SPEC-ID>
taskAn individual unit of work within a plantk create "Title" -t task --parent <epic-id>
origin refImmutable link from a plan to the spec that seeded it--external-ref <ID> flag on epic creation
spec tagMutable tag linking a task to every spec it affects--tags spec:<ID> on create
dependencyOrdering constraint between taskstk dep <child> <parent> (child depends on parent)
ready workUnblocked tasks available for pickuptk ready
claimAtomically take ownership of a tasktk claim <id>
completeMark a task as donetk add-note <id> "reason" then tk close <id>
abandonClose a task that will not be completedtk add-note <id> "Abandoned: <why>" then tk close <id>
escalateAbandon + invoke swain-design to update upstream artifactsAbandon, then invoke swain-design skill

Configuration and bootstrap

Config stored in .agents/execution-tracking.vars.json (created on first run). Read references/configuration.md for first-run setup questions, config keys, and the 6-step bootstrap workflow.

Statuses

tk accepts exactly three status values: open, in_progress, closed. Use the status command to set arbitrary statuses, but the dependency graph (ready, blocked) only evaluates these three.

To express abandonment, use tk add-note <id> "Abandoned:..." then tk close <id> — see Escalation.

Ticket lifecycle (ADR-015)

Tickets are ephemeral execution scaffolding — they exist to help agents track and resume work during SPEC implementation. Once the parent SPEC transitions to a terminal state (Complete, Abandoned), its tickets may be discarded. Tickets are not committed to trunk, not used as retro evidence, and should not block worktree cleanup. The session log (.agents/session.json JSONL) is the archival record of what happened; tickets are the live dashboard of what's in progress.

Operating rules

  1. Always include --description (or -d) when creating issues — a title alone loses the "why" behind a task. Future agents (or your future self) picking up this work need enough context to act without re-researching.
  2. Create/update tasks at the start of work, after each major milestone, and before final response — this keeps the tracker useful as a live dashboard rather than a post-hoc record.
  3. Keep task titles short and action-oriented — they appear in tk ready output, tree views, and notifications where space is limited.
  4. Store handoff notes using tk add-note <id> "context" rather than ephemeral chat context — chat history is lost between sessions, but task notes persist and are visible to any agent or observer.
  5. Include references to related artifact IDs in tags (e.g., spec:SPEC-003) — this enables querying all work touching a given spec.
  6. Prefix abandonment reasons with Abandoned: when closing incomplete tasks — this convention makes abandoned work findable so nothing silently disappears.
  7. Use ticket-query for structured output — when you need JSON for programmatic use, pipe through ticket-query (available in the vendored bin/ directory) instead of parsing human-readable output. Example: ticket-query '.status == "open"'

TDD enforcement

Strict RED-GREEN-REFACTOR with anti-rationalization safeguards and completion verification. Read references/tdd-enforcement.md for the anti-rationalization table, task ordering rules, and evidence requirements.

Spec lineage tagging

Use --external-ref SPEC-NNN on plan epics (immutable origin) and --tags spec:SPEC-NNN on child tasks (mutable). Query: ticket-query '.tags and (.tags | contains("spec:SPEC-003"))'. Cross-plan links: tk link <task-a> <task-b>.

Escalation

When work cannot proceed as designed, abandon tasks and escalate to swain-design. Read references/escalation.md for the triage table, abandonment commands, escalation workflow, and cross-spec handling.

"What's next?" flow

Run tk ready for unblocked tasks and ticket-query '.status == "in_progress"' for in-flight work. If .tickets/ is empty or missing, defer to bash "$(git rev-parse --show-toplevel 2>/dev/null || pwd)/.agents/bin/chart.sh" ready for artifact-level guidance.

Context on claim

When claiming a task tagged with spec:<ID>, show the Vision ancestry breadcrumb to provide strategic context. Run bash "$(git rev-parse --show-toplevel 2>/dev/null || pwd)/.agents/bin/chart.sh" scope <SPEC-ID> 2>/dev/null | head -5 to display the parent chain. This tells the agent/operator how the current task connects to project strategy.

Artifact/tk reconciliation

When specwatch detects mismatches (TK_SYNC, TK_ORPHAN in .agents/specwatch.log), read references/reconciliation.md for the mismatch types, resolution commands, and reconciliation workflow.

Session bookmark

After state-changing operations, update the bookmark: bash "$(git rev-parse --show-toplevel 2>/dev/null || pwd)/.agents/bin/swain-bookmark.sh" "<action> <task-description>"

Superpowers skill chaining

When superpowers is installed, swain-do invokes these skills at specific points. Skipping them or inlining the work undermines the guarantees they provide — TDD catches regressions before they compound, and verification prevents false completion claims that waste downstream effort:

  1. Before writing code for any task: Invoke the test-driven-development skill. Write a failing test first (RED), then make it pass (GREEN), then refactor. This applies to every task, not just the first one.
  2. When dispatching parallel work: Invoke subagent-driven-development (if subagents are available and tasks are independent) or executing-plans (if serial). Read references/execution-strategy.md for the decision tree.
  3. Before claiming any task or plan is complete: Invoke verification-before-completion. Run the verification commands, read the output, and only then assert success. No completion claims without fresh evidence.

Detection: ls.agents/skills/test-driven-development/SKILL.md.claude/skills/test-driven-development/SKILL.md 2>/dev/null — if at least one path exists, superpowers is available. Cache the result for the session.

When superpowers is NOT installed, swain-do uses its built-in TDD enforcement (see references/tdd-enforcement.md) and serial execution.

Plan ingestion (superpowers integration)

When a superpowers plan file exists, use the ingestion script (scripts/ingest-plan.py) instead of manual task decomposition. Read references/plan-ingestion.md for usage, format requirements, and when NOT to use it.

Execution strategy

Selects serial vs. subagent-driven execution based on superpowers availability and task complexity. Read references/execution-strategy.md for the decision tree, detection commands, and worktree-artifact mapping.

Pre-plan implementation detection

Before creating a plan for a SPEC, scan for evidence that it's already implemented. This avoids re-implementing work that exists on unmerged branches or was done in a prior session. Run these checks in parallel — they're independent signals that feed a single decision.

Signal scan

SignalCheckWhy it matters
Unmerged branches`git for-each-ref --format='%(refname:short) %(upstream:trackshort)' refs/heads/ \grep -i "<SPEC-ID>" then verify not merged: git merge-base --is-ancestor <branch> HEAD`Worktree branches from prior sessions are the strongest signal — they contain commits that never reached trunk. Discovering this mid-plan-creation is disruptive; catching it here is cheap.
Git history`git log --oneline --all \grep -i "<SPEC-ID>"`Commits referencing the spec ID indicate implementation happened somewhere in the repo's history.
Deliverable filesRead the spec to identify described outputs (scripts, modules, configs). Check whether they exist on HEAD via ls or Glob.Files on disk without matching commits may indicate partial or uncommitted work.
Tests passRe-run the spec's tests now and read the output. Prior results are not evidence — only fresh execution counts.This is the critical gate. Agents are prone to rationalizing that "tests passed before" without re-running. The reason this matters: code changes between sessions can silently break previously-passing tests.

Decision

  • 2+ signals → take the retroactive-close path (below)
  • 1 signal → proceed with normal plan creation; note the signal in the first task's description
  • 0 signals → proceed normally

Retroactive-close path

When evidence confirms prior implementation, skip full task decomposition:

  1. Create a single tracking task: tk create "Retroactive verification: <SPEC-ID>" -t task --external-ref <SPEC-ID> -d "Verify prior implementation before closing SPEC."
  2. Claim it: tk claim <id>
  3. Run verification-before-completion (if superpowers installed) or re-run the spec's tests manually.
  4. If verification passes: add a note with the evidence, close the task, then invoke swain-design to transition the spec to Complete.
  5. If verification fails: fall back to normal plan creation — the prior implementation was incomplete.

Worktree isolation preamble

All mutating work tracked by swain-do happens in a worktree — regardless of whether it touches source code, artifacts, skill files, or data. This prevents half-finished changes from polluting trunk and avoids collisions between parallel agents. Before any operation that will produce file changes (plan creation, task claim, code writing, artifact editing, skill file changes, spec transitions, execution handoff), run this detection:

# SPEC-250: Check env var first (set by bin/swain), then git plumbing
if [ -n "${SWAIN_WORKTREE_PATH:-}" ]; then
  IN_WORKTREE=yes
else
  GIT_COMMON=$(git rev-parse --git-common-dir 2>/dev/null)
  GIT_DIR=$(git rev-parse --git-dir 2>/dev/null)
  [ "$GIT_COMMON" != "$GIT_DIR" ] && IN_WORKTREE=yes || IN_WORKTREE=no
fi

Read-only operations skip this check entirely — proceed in the current context. The explicit read-only allowlist:

  • tk ready, tk show, tk status, tk list
  • ticket-query (structured queries)
  • Plan inspection (reading plan files without modifying them)
  • Status checks and task queries

If IN_WORKTREE=yes: already isolated. Proceed normally.

If IN_WORKTREE=no (main worktree) and the operation will produce file changes:

  1. Commit any dirty files before the branch is cut. A worktree checks out from HEAD — both untracked files and uncommitted modifications to tracked files are invisible inside it. This matters for artifacts created or edited moments earlier in the same session. REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)" UNTRACKED=$(git -C "$REPO_ROOT" ls-files --others --exclude-standard 2>/dev/null) MODIFIED=$(git -C "$REPO_ROOT" diff --name-only 2>/dev/null) if [-n "$UNTRACKED"] || [-n "$MODIFIED"]; then [-n "$UNTRACKED"] && echo "$UNTRACKED" | xargs -d '\n' git -C "$REPO_ROOT" add -- [-n "$MODIFIED"] && echo "$MODIFIED" | xargs -d '\n' git -C "$REPO_ROOT" add -- git -C "$REPO_ROOT" commit -m "chore: stage dirty tree before worktree creation" || {echo "ERROR: pre-commit step failed — aborting worktree creation" exit 1} fi If the commit fails (e.g., pre-commit hook rejection), surface the error and stop.
  2. Check for existing worktrees matching the target spec/work: REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)" bash "$REPO_ROOT/.agents/bin/swain-worktree-overlap.sh" "<SPEC-ID>" If the JSON output has "found": true, offer to reuse: "Worktree for <SPEC-ID> already exists at <path>. Reuse it?" If yes, inform the operator to restart the session with swain --resume <name>. If no, inform the operator to start a new session with the purpose text.
  3. Worktree creation is handled by bin/swain pre-launch (SPEC-245, EPIC-056). Most runtimes (Gemini CLI, Codex, Copilot, Crush) cannot change their working directory mid-session — only Claude Code can via EnterWorktree, and that is a runtime-specific crutch, not a universal pattern. The correct universal approach is pre-launch isolation via bin/swain. If SWAIN_WORKTREE_PATH is set, the agent is already in a managed worktree. If IN_WORKTREE=yes via git plumbing, the agent is in a worktree (possibly entered manually). In both cases, proceed with work. If IN_WORKTREE=no and the operation requires isolation, inform the operator: "Not in a worktree. Start a new session with swain \"<purpose>\" to get worktree isolation."
  4. After entering (if worktree was just created by bin/swain), re-run tab naming to reflect the new branch: bash "$REPO_ROOT/.agents/bin/swain-tab-name.sh" --path "$(pwd)" --auto
  5. Record the worktree bookmark (SPEC-235). After entering a worktree, call swain-bookmark.sh to register it in session.json. WT_PATH="$(pwd)" WT_BRANCH="$(git branch --show-current 2>/dev/null || echo 'unknown')" bash "$REPO_ROOT/.agents/bin/swain-bookmark.sh" worktree add "$WT_PATH" "$WT_BRANCH"

Operator override: If the operator explicitly says "work on trunk" or "don't isolate," respect the override and proceed on trunk. Log a warning: "Proceeding on trunk at operator request — changes will land directly on the development branch."

Note (SPEC-195): swain-init does not create worktrees at startup — worktree creation is deferred to this preamble, which runs when swain-do dispatches actual work. This ensures worktree names reflect the work context and allows overlap detection.

When all tasks in the plan complete, or when the operator requests, run the plan completion handoff (see below) before exiting the worktree.

Plan completion and handoff

When all tasks under a plan epic are closed (or the operator declares the work done), execute this chain before exiting the worktree. This ensures retros, SPEC transitions, and EPIC cascades fire consistently.

Step 1 — Detect plan completion

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
export PATH="$REPO_ROOT/.agents/bin:$PATH"
# Check if any tasks under the plan epic are still open
OPEN_COUNT=$(ticket-query ".parent == \"<epic-id>\" and .status != \"closed\"" 2>/dev/null | wc -l | tr -d ' ')

If OPEN_COUNT > 0, the plan is not complete — continue working or ask the operator. If OPEN_COUNT == 0, proceed.

Step 2 — Run completion pipeline (SPEC-257)

After detecting plan completion, run the quality gate pipeline before transitioning the SPEC. This ensures BDD tests, smoke tests, and retro all fire automatically.

2a — Create completion state file

Identify the SPEC ID from the plan epic's --external-ref:

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
SPEC_ID=$(tk show <epic-id> 2>/dev/null | grep -i 'external_ref' | awk '{print $NF}')
if [ -z "$SPEC_ID" ]; then
  echo "WARNING: No SPEC linked to plan epic — skipping completion pipeline."
fi

If SPEC_ID is empty, skip Step 2 entirely and proceed to Step 3. Log the warning.

Create the state file per DESIGN-018:

mkdir -p "$REPO_ROOT/.agents"
jq -n --arg spec "$SPEC_ID" --arg branch "$(git branch --show-current)" \
  '{spec_id: $spec, branch: $branch, pipeline_started: (now | todate), steps: {bdd_tests: {status: "pending", timestamp: null, detail: null}, smoke_test: {status: "pending", timestamp: null, detail: null}, retro: {status: "pending", timestamp: null, detail: null}}}' \
  > "$REPO_ROOT/.agents/completion-state.json.tmp" \
  && mv "$REPO_ROOT/.agents/completion-state.json.tmp" "$REPO_ROOT/.agents/completion-state.json"
2b — Run BDD tests

Check if swain-test.sh is available:

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
SWAIN_TEST="$REPO_ROOT/.agents/bin/swain-test.sh"

If swain-test.sh exists: Run it once, capture output and exit code:

BDD_OUTPUT=$(bash "$SWAIN_TEST" --artifacts "$SPEC_ID" 2>&1)
BDD_EXIT=$?
  • If exit code is 0 → update state to passed: BDD_DETAIL=$(echo "$BDD_OUTPUT" | head -5 | tr '\n' ' ') jq --arg status "passed" --arg detail "$BDD_DETAIL" \ '.steps.bdd_tests.status = $status |.steps.bdd_tests.timestamp = (now | todate) |.steps.bdd_tests.detail = $detail' \ "$REPO_ROOT/.agents/completion-state.json" > "$REPO_ROOT/.agents/completion-state.json.tmp" \ && mv "$REPO_ROOT/.agents/completion-state.json.tmp" "$REPO_ROOT/.agents/completion-state.json"
  • If exit code is non-zero → update state to failed: BDD_DETAIL=$(echo "$BDD_OUTPUT" | tail -10 | tr '\n' ' ') jq --arg status "failed" --arg detail "$BDD_DETAIL" \ '.steps.bdd_tests.status = $status |.steps.bdd_tests.timestamp = (now | todate) |.steps.bdd_tests.detail = $detail' \ "$REPO_ROOT/.agents/completion-state.json" > "$REPO_ROOT/.agents/completion-state.json.tmp" \ && mv "$REPO_ROOT/.agents/completion-state.json.tmp" "$REPO_ROOT/.agents/completion-state.json" Stop the pipeline. Report the failure to the operator: "BDD tests failed. Details: {detail}. Say retry to re-run, or skip BDD to continue without."

If swain-test.sh does not exist: Warn and mark skipped:

jq --arg status "skipped" --arg detail "swain-test.sh not available" \
  '.steps.bdd_tests.status = $status | .steps.bdd_tests.timestamp = (now | todate) | .steps.bdd_tests.detail = $detail' \
  "$REPO_ROOT/.agents/completion-state.json" > "$REPO_ROOT/.agents/completion-state.json.tmp" \
  && mv "$REPO_ROOT/.agents/completion-state.json.tmp" "$REPO_ROOT/.agents/completion-state.json"

Display: "swain-test not available — skipping BDD gate."

2c — Run smoke tests

Only proceed if bdd_tests is passed or skipped. If bdd_tests is failed, the pipeline is paused — do not run smoke.

BDD_STATUS=$(jq -r '.steps.bdd_tests.status' "$REPO_ROOT/.agents/completion-state.json")

If BDD_STATUS is passed or skipped:

If swain-test.sh exists: The smoke test output from swain-test.sh includes a ## SMOKE section with manual verification steps. Extract and present these to the operator:

SMOKE_SECTION=$(bash "$SWAIN_TEST" --artifacts "$SPEC_ID" 2>&1 | sed -n '/^## SMOKE/,/^## /p' | head -20)

Present the smoke instructions and ask for confirmation:

Smoke test instructions: {smoke section content} Did the smoke test pass? (yes / no / skip)
  • yes → update smoke_test to passed with detail "operator confirmed"
  • no → update smoke_test to failed with detail from operator. Stop pipeline: "Smoke test failed. Say retry to re-check, or skip smoke to continue."
  • skip → update smoke_test to skipped with detail "operator chose to skip"

Use the same jq update pattern from 2b to write state.

If swain-test.sh does not exist: Mark skipped with detail "swain-test.sh not available", same as BDD fallback.

2d — Run retrospective

Only proceed if both bdd_tests and smoke_test are passed or skipped. Retro cannot be skipped — if the operator says "skip retro", refuse: "Retro always runs. It captures learning even from imperfect work."

Invoke the swain-retro skill using the agent's Skill tool (this is a tool invocation, not a bash command):

Use the Skill tool: invoke swain-retro with args: "SPEC completion — run retro for <SPEC-ID> before phase transition."

After swain-retro completes, update the state:

jq --arg status "passed" --arg detail "retro captured" \
  '.steps.retro.status = $status | .steps.retro.timestamp = (now | todate) | .steps.retro.detail = $detail' \
  "$REPO_ROOT/.agents/completion-state.json" > "$REPO_ROOT/.agents/completion-state.json.tmp" \
  && mv "$REPO_ROOT/.agents/completion-state.json.tmp" "$REPO_ROOT/.agents/completion-state.json"

If swain-retro fails (skill invocation error), update state to failed and report. The operator can say retry to re-run.

2e — Skip and resume handling

Skip handling: At any point during the pipeline, the operator can say:

  • "skip BDD" → set bdd_tests to skipped with detail "operator requested skip", continue to 2c
  • "skip smoke" → set smoke_test to skipped with detail "operator requested skip", continue to 2d
  • "skip retro" → refuse. Retro always runs. Say: "Retro captures learning even from imperfect work — it cannot be skipped."

Resume handling: If a step failed and the operator says "retry" or "continue":

  1. Read .agents/completion-state.json
  2. Find the first step with status pending or failed
  3. Resume the pipeline from that step — do not re-run steps that already passed or were skipped

Pipeline gate: After all three steps, verify completion:

PENDING=$(jq -r '.steps | to_entries[] | select(.value.status == "pending" or .value.status == "failed") | .key' "$REPO_ROOT/.agents/completion-state.json")

If PENDING is empty (all steps passed or skipped), proceed to Step 3 (SPEC transition). If not, the pipeline is blocked — report which steps remain.

Step 3 — Invoke swain-design for SPEC transition

Pipeline gate (SPEC-257): Only proceed to SPEC transition if the completion pipeline passed. Check: jq -r '.steps | to_entries[] | select(.value.status == "pending" or.value.status == "failed") |.key' "$REPO_ROOT/.agents/completion-state.json". If any steps are pending or failed, do not transition — return to Step 2 to resolve.

Identify the SPEC linked to the plan epic (via --external-ref):

tk show <epic-id> 2>/dev/null  # external_ref field contains the SPEC ID

Invoke swain-design to transition the SPEC forward. The target phase depends on the spec's current state and whether verification is complete:

  • If all acceptance criteria have evidence → transition to Complete
  • If acceptance criteria need manual verification → transition to Needs Manual Test
  • If implementation is done but untested → transition to In Progress (if not already)

swain-design handles the downstream chain automatically:

  • Checks whether the parent EPIC should also transition (all child SPECs complete → EPIC Complete)
  • If the EPIC reaches a terminal state → invokes swain-retro for the EPIC-level retrospective (the SPEC-level retro already ran in Step 2d)

Step 4 — Offer merge and cleanup

After the SPEC transition completes, offer to merge and clean up:

All tasks closed. SPEC-NNN transitioned to {phase}. Merge this branch into {base-branch} and clean up the worktree?

If the operator accepts:

  1. Ensure all changes are committed
  2. Run /swain-sync to merge and push (marks lockfile ready_for_cleanup)
  3. Worktree cleanup is handled by bin/swain after the runtime exits (SPEC-245)

If the operator declines, the branch is preserved. bin/swain will show it in the menu next launch.

Note (ADR-015): .tickets/ files in the worktree are ephemeral scaffolding and should not block cleanup. Tickets have no archival value after SPEC completion.

Skipping the chain

The operator can say "just exit" or "skip the handoff" to bypass Steps 2–4 and go directly to ExitWorktree. Log a note on the plan epic: tk add-note <epic-id> "Exited without completion handoff". The worktree remains for the next session.

Note: Skipping the chain means the completion pipeline did not run. If .agents/completion-state.json was already created (Step 2a ran), any pending steps remain pending. swain-teardown will detect this and invoke the missing steps before sync.

Bookmark management (ADR-023)

Bookmarks track what the operator is working on. They persist across sessions so the next session can pick up where this one left off.

Set bookmark

When the operator says "bookmark this", "remember where I am", or after state-changing operations:

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
bash "$REPO_ROOT/.agents/bin/swain-bookmark.sh" "<context note>"

Infer the note from conversation context or the operator's explicit text. Do not prompt for a note if the context is clear.

Worktree bookmarks

When entering a worktree (already handled in the worktree isolation preamble, Step 5), the worktree is registered:

bash "$REPO_ROOT/.agents/bin/swain-bookmark.sh" worktree add "$WT_PATH" "$WT_BRANCH"

Clear bookmark

When the operator says "clear bookmark" or "fresh start":

bash "$REPO_ROOT/.agents/bin/swain-bookmark.sh" --clear

Decision recording (ADR-023)

When the operator or agent makes a significant decision (approves a spec, chooses an approach, sets direction), record it:

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
bash "$REPO_ROOT/.agents/bin/swain-session-state.sh" record-decision --note "Approved SPEC-119 implementation approach"

Decisions are tracked against the session's decision budget. When the budget is reached, inform the operator and suggest running /swain-teardown.

Progress log (ADR-023)

After completing tasks or reaching milestones, update the progress log:

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
bash "$REPO_ROOT/.agents/bin/swain-progress-log.sh" --digest "$REPO_ROOT/.agents/session-log.jsonl"

This updates each touched EPIC/Initiative's progress.md and ## Progress section.

Fallback

If tk cannot be found or is unavailable:

  1. Log the failure reason.
  2. Fall back to a neutral text task ledger (JSONL or Markdown checklist) in the working directory.
  3. Use the same status model (open, in_progress, blocked, closed) and keep updates externally visible.

平台分布

Codex

33.56%
按下载量换算332

Claude

28.39%
按下载量换算281

Cursor

20.7%
按下载量换算205

Gemini CLI

9.77%
按下载量换算97

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

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

安装前确认

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

继续浏览同类 Skills