get-shit-doneGSD系统架构解析多 Agent 元提示编排、文件式状态机与多运行时抽象【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done本文基于 docs/ja-JP/ARCHITECTURE.md面向贡献者与进阶用户的系统架构文档展开成文并结合当前仓库的目录实测与源码对关键论断进行佐证。get-shit-done以下简称GSD是 TÂCHES 出品的、面向 Claude Code 等 AI 编码 Agent 的轻量级元提示meta-prompting系统。通读本文后你将理解 GSD 的分层架构、五大设计原则、命令/工作流/Agent/引用/模板五类组件的协作方式、.planning 文件系统状态机的组织、安装器多运行时适配逻辑以及钩子hook系统的安全防护思路——足以把 GSD 当作一套“可读懂的编排框架”来使用与扩展。GSD 定位于用户与 AI 编码 Agent 之间的元提示层它本身几乎不写代码而是把「该让 AI 知道什么、按什么顺序让哪些 AI 干活、如何保证干活结果可验证」这件工程化。它支持 Claude Code、Gemini CLI、OpenCode、Kilo、Codex、Copilot、Antigravity、Trae、Cline、Augment Code 等十余种运行时通过四层架构命令层 → 工作流层 → Agent 层 → 文件系统层实现完整的“需求→调研→规划→执行→验证”流水线。系统总览四层流水线的宏观视图GSD 用一句话概括是meta-prompting framework元提示框架它对外提供四种核心能力上下文工程Context engineering——为每个任务生成结构化产物让 AI 拿到完成该任务所需的全部信息多 Agent 编排Multi-agent orchestration——由“轻量编排器”为每个任务派生专用 Agent并给每个 Agent全新干净的上下文窗口规格驱动开发Spec-driven development——需求 → 调研 → 规划 → 执行 → 验证的管道式推进状态管理State management——跨会话、跨上下文重置/clear的持久化项目记忆。文档用下面的分层图描述完整调用链用户 → 命令 → 工作流 → Agent → CLI 工具 →.planning/文件系统┌──────────────────────────────────────────────────────┐ │ USER │ │ /gsd-command [args] │ └─────────────────────┬────────────────────────────────┘ │ ┌─────────────────────▼────────────────────────────────┐ │ COMMAND LAYER │ │ commands/gsd/*.md — Prompt-based command files │ │ (Claude Code custom commands / Codex skills) │ └─────────────────────┬────────────────────────────────┘ │ ┌─────────────────────▼────────────────────────────────┐ │ WORKFLOW LAYER │ │ get-shit-done/workflows/*.md — Orchestration logic │ │ (Reads references, spawns agents, manages state) │ └──────┬──────────────┬─────────────────┬──────────────┘ │ │ │ ┌──────▼──────┐ ┌─────▼─────┐ ┌────────▼───────┐ │ AGENT │ │ AGENT │ │ AGENT │ │ (fresh │ │ (fresh │ │ (fresh │ │ context) │ │ context)│ │ context) │ └──────┬──────┘ └─────┬─────┘ └────────┬───────┘ │ │ │ ┌──────▼──────────────▼─────────────────▼──────────────┐ │ CLI TOOLS LAYER │ │ get-shit-done/bin/gsd-tools.cjs │ │ (State, config, phase, roadmap, verify, templates) │ └──────────────────────┬───────────────────────────────┘ │ ┌──────────────────────▼───────────────────────────────┐ │ FILE SYSTEM (.planning/) │ │ PROJECT.md | REQUIREMENTS.md | ROADMAP.md │ │ STATE.md | config.json | phases/ | research/ │ └──────────────────────────────────────────────────────┘值得强调的一点是“薄编排器”思想工作流文件只负责协调绝不亲自执行重活。代码层面每一行实际逻辑仍由 Agent 或 CLI 工具完成。设计原则让这套系统能一直转下去架构文档总结了五条贯穿全局的设计原则它们是理解后续所有机制的钥匙。1. 每个 Agent 拥有全新的上下文Fresh Context Per Agent编排器orchestrator派生出的每个 Agent 都会获得一个干净的上下文窗口最高 200K token。这直接消除了context rot上下文劣化——即 AI 的上下文窗口被不断累积的对话历史填满后产生的质量衰减。规划、执行、验证等关键步骤交给“记忆空白”的专用 Agent 去完成相当于每次决策都从一张白纸开始。2. 轻量编排器Thin Orchestrators工作流文件get-shit-done/workflows/*.md承担且仅承担四件事通过gsd-tools.cjs init workflow加载上下文返回项目信息、配置、状态、阶段详情等 JSON以聚焦的提示词派生专业 Agent收集结果并路由到下一步在步骤之间更新状态。以实际文件 get-shit-done/workflows/execute-phase.md 为例其core_principle明确写着“Orchestrator coordinates, not executes”编排器负责协调而非执行并通过required_reading先加载agent-contracts.md、context-budget.md、gates.md等引用再通过available_agent_types列出可派生的 Agent 类型gsd-executor、gsd-verifier、gsd-planner、gsd-phase-researcher……每个步骤只做“读上下文、派 Agent、收结果、更新状态”。3. 基于文件的状态管理File-Based State所有状态都以人类可读的 Markdown 与 JSON保存在.planning/目录下。无数据库、无服务端、无外部依赖。这意味着/clear清空上下文后状态依然存在人类与 Agent 都能随时检视状态状态可以提交进 git供团队共享可见性。4. 未配置 启用Absent Enabled工作流的功能开关遵循absent enabled模式若config.json中缺少某个键默认按true处理。换言之用户只需要显式禁用某项能力永远不需要“去开启默认值”。这极大降低了上手成本也让配置文件的体积保持在较小范围。5. 纵深防御Defense in DepthGSD 在多个层次上防御常见失败模式执行前由 plan-checker Agent 验证计划执行时为每个任务产生原子提交atomic commit执行后由验证器对照阶段目标检查一致性UAT用户验收测试作为最终闸门提供人工验证。这套“层层设防”同样体现在钩子系统与 package legitimacy gate 中下文详述。组件架构五类文档资产 两类运行时资产GSD 的仓库内容按“内容类型”组织成清晰的资产族。以下是各类资产的定位与实测数量。命令commands/gsd/*.md命令是面向用户的一等入口。每个文件包含 YAML frontmattername、description、allowed-tools、requires等与一段引导工作流的提示词正文。以 commands/gsd/new-project.md 的实际 frontmatter 为例--- name: gsd:new-project description: Initialize a new project with deep context gathering and PROJECT.md argument-hint: [--auto] allowed-tools: - Read - Bash - Write - Agent - AskUserQuestion requires: [config, phase, plan-phase] ---注意这里的name使用了gsd:冒号命名空间形式Gemini CLI 风格安装器会在部署阶段针对不同运行时改写为各自的调用形式。命令按运行时安装形态也不同Claude Code自定义斜杠命令/gsd-command-nameOpenCode / Kilo / Copilot斜杠命令Codex技能skill$gsd-command-nameAntigravity技能。当前仓库命令数量67 个目录commands/gsd/实测权威清单见 docs/INVENTORY.md。工作流get-shit-done/workflows/*.md命令所引用的编排逻辑。每个工作流文件是一份逐步执行的流程说明包含gsd-tools.cjs init上下文加载、带模型解析的 Agent 派生指令、闸门/检查点定义、状态更新范式、错误处理与恢复策略。当前仓库工作流数量88 个顶层工作流权威口径见 docs/INVENTORY.md。工作流会被逐字加载进 Claude 的上下文因此仓库用tests/workflow-size-budget.test.cjs维护“每文件行数预算”XL 级顶层编排器如 execute-phase/plan-phase/new-project1700 行、LARGE 级 1500 行、DEFAULT 级 1000 行超出预算时要求把分模式正文抽取到workflows/name/modes/、模板抽到templates/、共享知识抽到references/父文件退化为“薄分发器”。这是“轻量编排器”原则在文件体积上的延伸约束。Agentagents/*.md专用 Agent 定义frontmatter 指定name标识符、description角色与目的、tools允许的工具访问Read、Write、Edit、Bash、Grep、Glob、WebSearch 等、color终端输出的视觉区分色。以 agents/gsd-planner.md 为例--- name: gsd-planner description: Creates executable phase plans with task breakdown, dependency analysis, and goal-backward verification. Spawned by /gsd:plan-phase orchestrator. tools: Read, Write, Bash, Glob, Grep, WebFetch, mcp__context7__* color: green ---当前仓库 Agent 数量33 个覆盖研究者、规划者、执行者、验证者、映射器、调试器、审计者等角色完整名单见 docs/INVENTORY.md全量角色卡见 docs/AGENTS.md。引用get-shit-done/references/*.md工作流与 Agent 通过-reference语法引用的共享知识文档避免同一份规则在多处重复粘贴。经实测确认的引用族包括checkpoints.md— 检查点类型定义与交互模式见 get-shit-done/references/checkpoints.mdgates.md— 四类规范闸门Confirm / Quality / Safety / Transition接入 plan-checker 与 verifier见 get-shit-done/references/gates.mdgit-integration.md、git-planning-commit.md— git 提交、分支、历史与规划目录提交约定见 get-shit-done/references/git-integration.md按用途可分为Core referencesmodel-profiles.md、verification-patterns.md、planning-config.md、questioning.md、tdd.md、ui-brand.md、common-bug-patterns.md、Workflow referencesagent-contracts.md、context-budget.md、gate-prompts.md、revision-loop.md、workstream-flag.md等以及 thinking-class 模型的thinking-models-*.md系列。当前仓库引用数量61 个目录get-shit-done/references/实测。模板get-shit-done/templates/所有规划产物的 Markdown 模板由gsd-tools.cjs template fill/scaffold等命令做变量替换后生成预结构化文件。实测模板族包括核心项目文件project.md、requirements.md、roadmap.md、state.md阶段执行phase-prompt.md以及按粒度分档的summary.md、summary-minimal.md、summary-standard.md、summary-complex.md专项验证UI-SPEC.md、UAT.md、VALIDATION.md、DEBUG.md、discussion-log.md子目录codebase/棕地映射stack/architecture/conventions/concerns/structure/testing/integrations、research-project/调研产物SUMMARY/STACK/FEATURES/ARCHITECTURE/PITFALLS。当前仓库模板共 46 个文件含config.json默认配置模板。钩子hooks/与宿主 AI Agent 集成、在运行时介入事件的生命周期钩子。架构文档的基础清单为五个 JS 钩子但仓库实测的shipped 钩子共 13 个清单见 docs/INVENTORY.md下表完整列出钩子事件用途gsd-statusline.jsstatusLine展示模型、任务、目录与上下文用量条gsd-context-monitor.jsPostToolUse/AfterTool剩余上下文 35%/25% 时向 Agent 注入告警gsd-check-update.jsSessionStart后台检查 GSD 新版本gsd-check-update-worker.js后台辅助进程check-update 派生的后台工作进程gsd-update-banner.jsSessionStart可选的更新横幅不使用 statusline 时启用gsd-prompt-guard.jsPreToolUse对.planning/写入扫描提示注入仅建议gsd-workflow-guard.jsPreToolUse检测 GSD 工作流上下文之外的文件编辑可选hooks.workflow_guardgsd-read-guard.jsPreToolUse阻止对会话内未读文件执行 Edit/Write建议性gsd-read-injection-scanner.jsPostToolUse扫描 Read 结果中的注入指令gsd-session-state.shPostToolUse面向 shell 运行时的会话状态跟踪gsd-validate-commit.shPostToolUse强制 conventional commit 的提交校验gsd-phase-boundary.shPostToolUse工作流转换的阶段边界检测gsd-graphify-update.shPostToolUseHEAD 推进后自动重建知识图谱默认关闭CLI 工具get-shit-done/bin/GSD 的 Node.js CLI 工具 gsd-tools.cjs 负责所有“确定性”工作状态读写、配置、阶段、路线图、模板、验证是工作流提示词中为数不多真正执行代码的接缝。其领域模块拆在get-shit-done/bin/lib/下核心模块的职责映射如下完整 74 个 CLI 模块见 docs/INVENTORY.mdCLI 使用说明见 docs/CLI-TOOLS.md模块职责core.cjs错误处理、输出格式化、共享工具state.cjsSTATE.md 解析、更新、进度与指标phase.cjs阶段目录操作、小数编号、计划索引roadmap.cjsROADMAP.md 解析、阶段抽取、计划进度config.cjsconfig.json 读写、分区初始化verify.cjs计划结构、阶段完成度、引用、提交验证template.cjs模板选择与变量替换填充frontmatter.cjsYAML frontmatter 的 CRUDinit.cjs按工作流类型做复合上下文加载milestone.cjs里程碑归档、需求标注commands.cjs杂项命令slug、时间戳、todos、脚手架、统计model-profiles.cjs模型画像解析表security.cjs路径穿越防护、提示注入检测、安全 JSON 解析、shell 参数校验uat.cjsUAT 文件解析、验证债务跟踪、audit-uat 支持这些模块与上层工作流的关系是工作流是“怎么想”CLI 模块是“怎么算”。例如writeStateMd()的文件锁逻辑、模板填充、路线图进度计算等确定性操作全部沉淀在 CLI 层避免在提示词里做不可靠的算术。Agent 模型编排器如何派生并组织 Agent编排器 → Agent 模式每个工作流对 Agent 的使用都遵循统一的编排循环Orchestrator (workflow .md) │ ├── Load context: gsd-tools.cjs init workflow phase │ Returns JSON with: project info, config, state, phase details │ ├── Resolve model: gsd-tools.cjs resolve-model agent-name │ Returns: opus | sonnet | haiku | inherit │ ├── Spawn Agent (Task/SubAgent call) │ ├── Agent prompt (agents/*.md) │ ├── Context payload (init JSON) │ ├── Model assignment │ └── Tool permissions │ ├── Collect result │ └── Update state: gsd-tools.cjs state update/patch/advance-plan其中resolve-model返回opus | sonnet | haiku | inherit——inherit让 GSD 把模型选择权交还给运行时这也是跨运行时抽象的关键机制之一见运行时抽象一节。Agent 派生类别与并行度架构文档对 Agent 派生模式进行了分类每种类别有明确的并行/串行纪律数量为当前仓库实测任务分工描述引自架构文档类别Agent 示例并行度研究者Researchersgsd-project-researcher、gsd-phase-researcher、gsd-ui-researcher、gsd-advisor-researcher4 路并行stack、features、architecture、pitfallsadvisor 在 discuss-phase 中派生综合者Synthesizersgsd-research-synthesizer串行研究者完成后规划者Plannersgsd-planner、gsd-roadmapper串行检查者Checkersgsd-plan-checker、gsd-integration-checker、gsd-ui-checker、gsd-nyquist-auditor串行验证循环最多迭代 3 次执行者Executorsgsd-executor波内并行、波间串行验证者Verifiersgsd-verifier串行全部执行者完成后映射者Mappersgsd-codebase-mapper4 路并行tech、arch、quality、concerns调试者Debuggersgsd-debugger串行交互式审计者Auditorsgsd-ui-auditor、gsd-security-auditor串行波次执行模型Wave Execution Modelexecute-phase把计划按依赖关系分组为波wave无依赖的先进、有依赖的排队Wave Analysis: Plan 01 (no deps) ─┐ Plan 02 (no deps) ─┤── Wave 1 (parallel) Plan 03 (depends: 01) ─┤── Wave 2 (waits for Wave 1) Plan 04 (depends: 02) ─┘ Plan 05 (depends: 03,04) ── Wave 3 (waits for Wave 2)每个执行者获得全新的 200K 上下文窗口要执行的特定 PLAN.md项目上下文PROJECT.md、STATE.md阶段上下文CONTEXT.md若有则含 RESEARCH.md。并行提交安全同一波内多个执行者并发写代码时用两套机制防止冲突--no-verify提交——并行 Agent 跳过 pre-commit 钩子pre-commit 钩子可能引起构建锁竞争例如 Rust 项目里 cargo lock 文件的互相打架编排器在每波完成后统一执行一次git hook run pre-commit把校验收口到串行点。STATE.md 文件锁——所有writeStateMd()调用都基于锁文件互斥STATE.md.lock通过O_EXCL原子创建。这消除了“两个 Agent 同时读 STATE.md、各改各的字段、后写者覆盖先写者改动”的 read-modify-write 竞态。实现里还包含过期锁检测10 秒超时与带抖动的自旋等待。数据流产物如何沿着管道接力新项目流程从一段 idea 描述到项目状态初始化完整链路如下User input (idea description) │ ▼ Questions (questioning.md philosophy) │ ▼ 4x Project Researchers (parallel) ├── Stack → STACK.md ├── Features → FEATURES.md ├── Architecture → ARCHITECTURE.md └── Pitfalls → PITFALLS.md │ ▼ Research Synthesizer → SUMMARY.md │ ▼ Requirements extraction → REQUIREMENTS.md │ ▼ Roadmapper → ROADMAP.md │ ▼ User approval → STATE.md initialized注意研究者并行写出的 STACK/FEATURES/ARCHITECTURE/PITFALLS 四份文件经过综合者合并成 SUMMARY.md 后再进入需求抽取——并行调研保证覆盖面串行综合保证一致性。阶段执行流程一个阶段从讨论到验收的完整推进discuss-phase → CONTEXT.md (user preferences) │ ▼ ui-phase → UI-SPEC.md (design contract, optional) │ ▼ plan-phase ├── Phase Researcher → RESEARCH.md ├── Planner → PLAN.md files └── Plan Checker → Verify loop (max 3x) │ ▼ execute-phase ├── Wave analysis (dependency grouping) ├── Executor per plan → code atomic commits ├── SUMMARY.md per plan └── Verifier → VERIFICATION.md │ ▼ verify-work → UAT.md (user acceptance testing) │ ▼ ui-review → UI-REVIEW.md (visual audit, optional)上下文传播各阶段的产物是后续阶段的输入形成清晰的“产物依赖图”PROJECT.md ────────────────────────────────────────────► All agents REQUIREMENTS.md ───────────────────────────────────────► Planner, Verifier, Auditor ROADMAP.md ────────────────────────────────────────────► Orchestrators STATE.md ──────────────────────────────────────────────► All agents (decisions, blockers) CONTEXT.md (per phase) ────────────────────────────────► Researcher, Planner, Executor RESEARCH.md (per phase) ───────────────────────────────► Planner, Plan Checker PLAN.md (per plan) ────────────────────────────────────► Executor, Plan Checker SUMMARY.md (per plan) ─────────────────────────────────► Verifier, State tracking UI-SPEC.md (per phase) ────────────────────────────────► Executor, UI Auditor文件系统布局安装资产与 .planning 工作区安装文件布局Claude Code 全局安装示例~/.claude/ # Claude Code (global install) ├── commands/gsd/*.md # slash commands ├── get-shit-done/ │ ├── bin/gsd-tools.cjs # CLI utility │ ├── bin/lib/*.cjs # domain modules │ ├── workflows/*.md # workflow definitions │ ├── references/*.md # shared reference docs │ └── templates/ # Planning artifact templates ├── agents/*.md # agent definitions ├── hooks/ # JS sh hooksstatusline、guards、monitors… ├── settings.json # Hook registrations └── VERSION # Installed version number其他运行时的等价路径各不相同OpenCode 在~/.config/opencode/、Kilo 在~/.config/kilo/、Gemini CLI 在~/.gemini/、Codex 在~/.codex/用 skills 而非 commands、Copilot 在~/.github/、Antigravity 在~/.gemini/antigravity/全局或./.agent/本地。此外各运行时普遍支持本地安装形态如./.claude/、./.opencode/、./.codex/、./.cursor/、./.windsurf/、./.qwen/、./.trae/、./.cline/等。项目工作区.planning/所有规划状态都落在项目根的.planning/中以下是实测目录结构对应的完整说明.planning/ ├── PROJECT.md # 项目愿景、约束、决策、演进规则 ├── REQUIREMENTS.md # 带范围的需求v1/v2/范围外 ├── ROADMAP.md # 带状态跟踪的阶段分解 ├── STATE.md # 活记忆当前位置、决策、阻塞项、指标 ├── config.json # 工作流配置 ├── MILESTONES.md # 已完结里程碑归档 ├── research/ # 来自 /gsd-new-project 的领域调研 │ ├── SUMMARY.md │ ├── STACK.md │ ├── FEATURES.md │ ├── ARCHITECTURE.md │ └── PITFALLS.md ├── codebase/ # 棕地映射来自 /gsd-map-codebase │ ├── STACK.md │ ├── ARCHITECTURE.md │ ├── CONVENTIONS.md │ ├── CONCERNS.md │ ├── STRUCTURE.md │ ├── TESTING.md │ └── INTEGRATIONS.md ├── phases/ │ └── XX-phase-name/ │ ├── XX-CONTEXT.md # 用户偏好来自 discuss-phase │ ├── XX-RESEARCH.md # 生态调研来自 plan-phase │ ├── XX-YY-PLAN.md # 执行计划 │ ├── XX-YY-SUMMARY.md # 执行结果 │ ├── XX-VERIFICATION.md # 执行后验证 │ ├── XX-VALIDATION.md # Nyquist 测试覆盖映射 │ ├── XX-UI-SPEC.md # UI 设计契约来自 ui-phase │ ├── XX-UI-REVIEW.md # 视觉审计分数来自 ui-review │ └── XX-UAT.md # 用户验收测试结果 ├── quick/ # 快捷任务跟踪 │ └── YYMMDD-xxx-slug/ │ ├── PLAN.md │ └── SUMMARY.md ├── todos/ │ ├── pending/ # 捕获的灵感 │ └── done/ # 已完成 todo ├── threads/ # 持久上下文线程来自 /gsd-thread ├── seeds/ # 面向未来的点子来自 /gsd-capture --seed ├── debug/ # 活跃调试会话 │ ├── *.md # 活跃会话 │ ├── resolved/ # 已归档会话 │ └── knowledge-base.md # 持久调试知识库 ├── ui-reviews/ # /gsd-ui-review 的截图gitignore └── continue-here.md # 上下文交接来自 pause-work这套布局之所以有效是因为文件即协议文件名前缀XX-阶段号、YY-计划号构成排序与依赖信息工作流之间通过“产出某文件 / 消费某文件”解耦而不是通过进程内对象引用——这天然兼容上下文重置与多 Agent 并行。安装器架构一份源码适配全部运行时安装器仓库中的 bin/install.js承担“统一源码 → 各运行时方言”的翻译职责主要处理九件事运行时检测——交互式提示或 CLI 标志--claude、--opencode、--gemini、--kilo、--codex、--copilot、--antigravity以及--all安装位置选择——全局--global或本地--local文件部署——复制 commands、workflows、references、templates、agents、hooks运行时适配——按运行时逐文件转换内容Claude Code原样使用OpenCode把 commands/agents 转换为 OpenCode 兼容的扁平 command subagent 格式Kilo复用 OpenCode 转换管线 Kilo 的配置路径Codex从 commands 生成 TOML 配置与 skillsCopilot映射工具名Read→read、Bash→execute 等Gemini调整钩子事件名用AfterTool替代PostToolUseAntigravityskills-first Google 模型等价物路径规范化——把~/.claude/路径替换为各运行时特有路径配置集成——在运行时的settings.json中注册钩子补丁备份——v1.17 起把本地修改过的文件备份到gsd-local-patches/供/gsd-update --reapply使用清单跟踪——写入gsd-file-manifest.json保证可干净卸载卸载模式——--uninstall删除全部 GSD 文件、钩子与配置。平台适配Windows子进程使用windowsHide对受保护目录做 EPERM/EACCES 防护并做路径分隔符规范化WSL检测 Windows 版 Node.js 跑在 WSL 上的情况对路径不一致发出警告Docker/CI通过CLAUDE_CONFIG_DIR环境变量支持自定义配置目录位置。钩子系统运行时事件上的守护进程架构钩子本质上是挂在宿主运行时事件上的独立脚本通过 stdin/stdout JSON 通信。以三个核心 JS 钩子为例Runtime Engine (Claude Code / Gemini CLI) │ ├── statusLine event ──► gsd-statusline.js │ Reads: stdin (session JSON) │ Writes: stdout (formatted status), /tmp/claude-ctx-{session}.json (bridge) │ ├── PostToolUse/AfterTool event ──► gsd-context-monitor.js │ Reads: stdin (tool event JSON), /tmp/claude-ctx-{session}.json (bridge) │ Writes: stdout (hookSpecificOutput with additionalContext warning) │ └── SessionStart event ──► gsd-check-update.js Reads: VERSION file Writes: ~/.claude/cache/gsd-update-check.json (spawns background process)有意思的实现细节是“bridge 文件”机制statusLine事件把上下文指标写到/tmp/claude-ctx-{session}.jsonPostToolUse事件再读取它——从而把只展示给用户的状态信息statusline转译为Agent 可见的告警注入additionalContext。实测 hooks/gsd-context-monitor.js 的注释与常量完全印证了这一设计。上下文监控阈值剩余上下文级别Agent 行为 35%Normal不注入警告≤ 35%WARNING“请避免开始新的复杂工作”≤ 25%CRITICAL“上下文即将耗尽请通知用户”防抖策略重复警告之间至少间隔 5 次工具使用但严重度升级WARNING→CRITICAL会绕过防抖立即触发。安全性特征所有钩子都用 try/catch 包裹出错时静默退出stdin 超时守卫3 秒实测代码中为 10 秒兜底防止管道问题导致的挂死超过 60 秒的陈旧指标被忽略bridge 文件缺失被优雅处理子 Agent、新会话场景上下文监控器仅做建议——绝不发出覆盖用户偏好的命令式指令。安全钩子Prompt Guardhooks/gsd-prompt-guard.jsv1.27 引入触发条件对.planning/文件的 Write/Edit扫描内容中的提示注入模式角色覆盖、指令绕过、system 标签注入仅建议——记录检测但不阻断模式内联在钩子文件中security.cjs的子集以保证钩子独立运行。Workflow Guardhooks/gsd-workflow-guard.js触发条件对非.planning/文件的 Write/Edit检测工作流上下文之外的编辑无活跃/gsd-命令或 Task 子 Agent建议使用/gsd-quick或/gsd-fast让改动被状态跟踪通过hooks.workflow_guard: true选择启用默认false。运行时抽象一份写作处处部署GSD 通过“统一命令/工作流架构 安装时一次性翻译”支持多运行时抽象点落在五个维度工具名映射——各运行时工具名不同Claude 的Bash→ Copilot 的execute钩子事件名——Claude Code 用PostToolUseGemini 用AfterToolAgent frontmatter——各运行时 Agent 定义格式不同路径约定——各运行时把配置存在不同目录模型引用——inherit画像让 GSD 把模型选择权委托给运行时。运行时命令形态Agent 系统配置位置Claude Code/gsd-commandTask 启动~/.claude/OpenCode/gsd-command子 Agent 模式~/.config/opencode/Kilo/gsd-command子 Agent 模式~/.config/kilo/Gemini CLI/gsd-commandTask 启动~/.gemini/Codex$gsd-command技能~/.codex/Copilot/gsd-commandAgent 委派~/.github/Antigravity技能技能~/.gemini/antigravity/安装器在安装时完成全部翻译工作流与 Agent 一律以 Claude Code 原生格式写作部署时再转换为目标运行时格式。这也是为什么上游内容资产能做到“一套写作”却能同时以斜杠命令、技能、子 Agent 等多种形态活在各个 AI 编码环境中。小结从宏观到微观GSD 的架构可以浓缩为三条主线内容即代码命令、工作流、Agent、引用、模板全部是可读的 Markdown 资产靠 frontmatter、-reference与文件命名约定组合成一套可运行的“提示词程序”文件即状态.planning/目录是唯一的真相源STATE.md 加文件锁解决并发写入产物文件按阶段/计划编号接力传播上下文接口即翻译CLI 工具gsd-tools.cjs承接所有确定性计算安装器bin/install.js把 Claude 原生格式翻译到十余种运行时钩子在宿主事件上提供仅建议式的安全守护。如果想要进一步对照完整组件清单各资产族的权威计数与全部名单请直接查阅 docs/INVENTORY.md功能导向的介绍见 docs/FEATURES.md面向普通用户的操作指南见 docs/USER-GUIDE.mdCLI 模块说明见 docs/CLI-TOOLS.md。仓库通过tests/inventory-counts.test.cjs、tests/agents-doc-parity.test.cjs、tests/commands-doc-parity.test.cjs、tests/cli-modules-doc-parity.test.cjs、tests/hooks-doc-parity.test.cjs、tests/workflow-size-budget.test.cjs等漂移防护测试持续锁定“文档叙事 ↔ 文件系统”两者的一致——这也正是“规格驱动开发”理念在 GSD 自身维护流程上的自我应用。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考