工作流方法论 · 四套系统（GSD / gstack / mattpocock / Karpathy）

2026/6/27大约 19 分钟

工作流方法论 · 四套系统（GSD / gstack / mattpocock / Karpathy）

章节类型：工作流方法论（与 07 Superpowers 同维度，本章是另外四套对比）。
各节独立阅读；选型 + 安装 + 五方案编程串联见 03 选型与组合方案（方案 B/C/D/E 工作流锚点在同章导航表）。

本章四个系统代表不同的 Skill 工作流哲学——不是「前端 Skill」那种领域包。

GSD — 上下文工程与 Spec 驱动开发

项目概述

GSD（Get Shit Done）是 Claude Code 生态中安装量最大的上下文工程系统之一。它与 Superpowers 的方法论强制执行路线不同——GSD 走的是"上下文工程"路线：不是告诉 Claude 怎么思考，而是给它恰到好处的上下文，让它能正确理解你要什么。

原仓库：gsd-build/get-shit-done（已归档，64K+ stars）
活跃仓库：open-gsd/gsd-core（2026 起 GSD 持续开发的主线）
作者：TÂCHES（@trek-e）
协议：MIT
支持平台：Claude Code / OpenCode / Gemini CLI / Kilo / Codex / Copilot / Cursor / Windsurf 等 14 个平台
安装：npx get-shit-done-cc@latest

GSD 的作者是一个独立开发者——他自己不写代码，Claude Code 替他写。其他 spec-driven 开发工具也有（BMAD、Speckit 等），但他觉得这些都在"把事情搞复杂"——sprint ceremonies、story points、stakeholder syncs、retrospectives、Jira workflows。他说："我不是 50 人的软件公司。我不想玩企业过家家。"所以他造了 GSD。

"The complexity is in the system, not in your workflow."
—— TÂCHES, GSD README

安装

多路径规则 → 05 · 多路径安装

推荐（--minimal）：6 个核心 Skill，冷启动约 700 tokens；03 方案 B 默认用这个。
备选（全量）：86 Skill + 33 subagent；Sonnet/Opus + 大 context 时用；不要与 --minimal 各装一遍。

# 推荐 — 个人全局
npx get-shit-done-cc --claude --global --minimal

# 推荐 — 团队（Skill 进 .claude/skills/ 后 commit）
npx get-shit-done-cc --claude --minimal

# 备选 — 全量（交互选 Runtime / Location）
npx get-shit-done-cc@latest

收尾

/skills
/gsd:help
/doctor

两条 GSD 产品线（勿混装）

	`get-shit-done-cc`（本书 03 方案 B/E 默认）	`@opengsd/gsd-core`（2026 活跃主线）
安装	`npx get-shit-done-cc --claude --global --minimal`	`npx @opengsd/gsd-core@latest`
Claude Code 命令	`/gsd:new-project` 等冒号前缀	`/gsd-new-project` 等连字符前缀
跨会话	读 `.planning/STATE.md`	`/gsd-resume-work`、`/gsd-progress`
组合 playbook	03 方案 B 工作流	步骤相同，命令用右列

依据：gsd-core COMMANDS.md — Claude Code 用 hyphen；Gemini 等用 colon。不要两个安装器装在同一 Runtime。

GSD 解决的核心问题

GSD 解决一个叫"上下文腐烂"（Context Rot）的问题：Claude Code 会话越长，上下文窗口越满，产出质量越断崖式下降。GSD 的做法不是告诉 Claude "怎么做"，而是控制它"看到什么"——通过结构化的上下文工程，确保每次会话中 Claude 看到的都是精确相关的内容，而不是一大坨越来越膨胀的对话历史。

GSD 架构设计

规模与 2026 架构演进

GSD 全量安装包含大量 Skill 和 Subagent：

指标	全量安装	`--minimal` 安装
Skills	86 个 flat skills（或 59 commands + 6 namespace routers）	6 个
Subagents	33 个 `gsd-*` Agent	0
冷启动描述开销	~12K tokens（旧）/ ~120 tokens（namespace 路由层）	~700 tokens

2026 年 GSD 引入 namespace 路由 Skill（gsd:workflow、gsd:project、gsd:review 等 6 个），将冷启动从 ~2150 tokens 降到 ~120 tokens——比单纯提高 budget 更根本。

全量 86 Skill 描述仍约 12K tokens。对本地 LLM（32K-128K）或按 Token 计费 API，建议使用 --minimal。

`--minimal` 模式

GSD 提供了 --minimal（别名 --core-only）安装模式来解决上述问题：

npx get-shit-done-cc --claude --global --minimal

对比：

维度	默认安装	`--minimal` 安装
Skills 数量	86	6
Subagents 数量	33	0
冷启动系统提示词开销	~12K tokens	~700 tokens（94% 缩减）

6 个核心 Skill：new-project、discuss-phase、plan-phase、execute-phase、help、update。

--minimal 模式下无 subagent，/gsd:execute-phase 会降级为 in-context 执行。Frontier 模型（Sonnet/Opus）建议全量安装。

三层架构

GSD 有三层架构：

XML prompt formatting — 用结构化 XML 标签包装所有上下文，让 Claude 精确理解每个信息的角色
Subagent orchestration — 33 个子 Agent 各司其职（代码生成、审查、部署、调试等）
State management — 通过 .planning/ 目录持久化项目状态，跨会话保持上下文

三大质量门

GSD 内置了三个质量检查机制：

Schema drift detection — 检测 ORM 变更是否缺少数据库迁移
Security enforcement — 将安全验证锚定到威胁模型
Scope reduction detection — 防止 plan 阶段悄悄删减需求

GSD 核心工作流

GSD 的核心工作流是三个 Phase，所有命令以 gsd: 为前缀（源码中实际命令格式）：

/gsd:new-project    → 初始化：提问→研究→REQUIREMENTS.md→ROADMAP.md
/gsd:discuss-phase  → 讨论：自适应提问→代码库侦察→灰色区域分析→CONTEXT.md
/gsd:plan-phase     → 计划：研究→生成 PLAN.md→gsd-plan-checker 验证→迭代
/gsd:execute-phase  → 执行：按 wave 分组并行→派发 subagents→收集结果→验证

初始化

npx get-shit-done-cc@latest

安装器提示选择 Runtime 和 Location（Global/Local）。

/gsd:new-project 创建以下文件：

.planning/PROJECT.md — 项目上下文
.planning/config.json — 工作流偏好
.planning/REQUIREMENTS.md — 需求范围
.planning/ROADMAP.md — Phase 结构
.planning/STATE.md — 项目持久记忆

支持 --auto 标志跳过交互。/gsd:map-codebase 扫描代码库为初始化提供上下文。

讨论阶段

/gsd:discuss-phase 详细流程：

加载前置上下文（PROJECT.md、REQUIREMENTS.md、STATE.md、之前的 CONTEXT.md）
侦察代码库中的可复用资产和模式
分析——跳过已在之前阶段确定的灰色区域
呈现剩余灰色区域——用户选择要讨论哪些
逐个深入讨论直到满意
创建 {phase_num}-CONTEXT.md——清晰到下游 Agent 无需再问用户的决策文档

计划阶段

/gsd:plan-phase 完整流程：研究（可选）→ 生成 PLAN.md → gsd-plan-checker 验证 → 迭代直到通过或达到最大次数。

关键标志：

标志	作用
`--research`	强制刷新研究
`--view`	仅查看已有 RESEARCH.md
`--skip-research`	跳过研究阶段
`--auto`	自动模式
`--tdd`	TDD 模式
`--reviews`	触发审查
`--research-phase N`	仅为指定 phase 研究（不生成计划）

执行阶段

/gsd:execute-phase 的核心机制是 wave-based 并行执行。Orchestrator：发现 plans→分析依赖→分组为 waves→派发 subagents→收集结果。每个 subagent 加载完整上下文处理自己的 plan。

关键标志：

标志	作用
`--wave N`	仅执行 Wave N
`--gaps-only`	仅填补遗漏
`--interactive`	交互模式
`--tdd`	TDD 模式

其他常用命令

命令	实际功能
`/gsd:code-review`	审查 phase 变更文件。3 级深度：quick（模式匹配 ~2min）/ standard（逐文件 ~5-15min）/ deep（跨文件调用链 ~15-30min）。`--fix` 自动修复，`--fix --auto` 启动 fix+re-review 迭代最多 3 轮
`/gsd:autonomous`	完全自主执行所有剩余 phases：discuss→plan→execute 逐 phase。仅在需要用户决策时暂停。`--from N` `--to N` 控制范围
`/gsd:debug`	科学方法论调试，subagent 隔离。`--diagnose` 仅诊断不修复。子命令：list / status `{slug}` / continue `{slug}`
`/gsd:ship`	push branch→创建 PR（自动生成 body）→可选触发 review→跟踪合并。闭合 plan→execute→verify→ship 循环

GSD 与 Superpowers 的定位差异

维度	Superpowers	GSD
核心方法	方法论强制执行（硬性约束）	上下文工程（精确信息投喂）
控制方式	Agent 被强制遵循固定流程	Agent 得到精确上下文自主决策
哲学	"连差劲的工程师都能照着做"	"复杂度在系统里，不在你的工作流里"
适合场景	严格质量控制需求	快速迭代 + 跨会话上下文保持
安装体积	15 Skills，轻量	86 Skills，重量（有 minimal 模式）
可组合性	Skills 之间强耦合（流水线）	Skills 相对独立，按需使用

两者可以组合使用——不是非此即彼。Superpowers 提供方法论纪律，GSD 提供上下文工程基础设施。部分开发者选择 Superpowers 的核心 Skills（TDD、brainstorming）配上 GSD 的上下文管理。

gstack — 虚拟工程团队

项目概述

仓库：garrytan/gstack
作者：Garry Tan（Y Combinator CEO）
Stars：111K+（2026-06）
协议：MIT
定位：23 个 opinionated slash-command skills，模拟 CEO、设计师、工程经理、QA、发布经理等角色
特色：TypeScript + Bun、Playwright 浏览器守护进程、GBrain 跨会话知识系统

gstack README 列出 23 个核心 Skill（如 /office-hours、/plan-ceo-review、/review、/qa、/ship 等）。仓库内还有大量 bin/ 脚本和 GBrain 基础设施，不应与 Skill 数量混淆。

gstack 的设计理念：AI 不应只有一个通用模式。好的工程团队有不同角色——gstack 为 Claude Code 提供同样的角色分化。

核心 Skill 速查（按 Sprint 顺序）

阶段	Skill	职能
规划	`/office-hours`	六问 forcing questions，产出设计文档
规划	`/plan-ceo-review`	创始人视角审视产品方向
规划	`/plan-eng-review`	锁架构、数据流、边界情况
规划	`/plan-design-review`	设计审查
实现	`/autoplan`	自动计划生成
质量	`/review`	Staff Engineer 级审查
质量	`/codex`	OpenAI Codex CLI 第二意见（与 `/review` 交叉对比）
安全	`/cso`	安全审计（OWASP / STRIDE，非 Codex 第二意见）
测试	`/browse`	Playwright 浏览器自动化
测试	`/qa`	find-fix-verify 闭环 QA
发布	`/ship`	一键发布：测试→审查→PR
发布	`/land-and-deploy`	部署到生产
安全	`/careful`	拦截危险命令
知识	`/setup-gbrain` / `/sync-gbrain`	GBrain 持久知识初始化与同步

完整列表见 gstack docs/skills.md。

GBrain 持久化知识

GBrain 是 gstack 的跨会话记忆基础设施（非 Skill 本身）：

决策日志语义搜索（gstack-decision-*）
经验教训持久化（gstack-learnings-*）
时间线记录回放（gstack-timeline-*）
可选 Supabase 后端

安装

多路径规则 → 05 · 多路径安装。无 npx / CC Switch 路径，必须 git clone + ./setup。

推荐（个人全局）：clone 到 ~/.claude/skills/gstack 后 ./setup。
备选（团队）：同一目录 ./setup --team，.claude/ 片段进 git。
备选（Codex / Cursor 等）：同一 clone 目录 `./setup --host <agent>`（将 <agent> 换成 cursor / codex 等）。

# 推荐 — 个人全局
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack && ./setup
/skills
/office-hours

# 备选 — 团队
(cd ~/.claude/skills/gstack && ./setup --team)

# 备选 — 其它 Agent（在已 clone 目录执行）
cd ~/.claude/skills/gstack && ./setup --host cursor   # 或 codex / opencode

Skill 不出现：cd ~/.claude/skills/gstack && ./setup 再跑一遍（Windows 非 symlink 环境每次 git pull 后也需重跑 setup）。

产出讨论

Garry Tan 公开数据强调 logical code change（非 raw LOC）：2026 run rate 约 810× 2013 年 pace。社区对"10K LOC/周"等早期说法有争议——gstack 的价值在于把"搞清楚→写→审查→发货"流程压缩为分步骤流水线，而非单纯追求行数。

mattpocock/skills — 反 Vibe Coding 工程工作流

项目概述

2026 年 4 月，TypeScript 教育者 Matt Pocock 把自己的 .claude 目录推送到 GitHub。24 小时内 22,000 stars，GitHub Trending 全球 #1。

仓库：mattpocock/skills
Stars：59K+（2026-06）
协议：MIT
Skill 总数：21 个活跃 Skill（Engineering 12 + Productivity 5 + Misc 4；另有 deprecated/ 和 in-progress/ 不计入）

"My agent skills that I use every day to do real engineering — not vibe coding."
—— Matt Pocock

Engineering Skills（12 个）

Matt 将 Skills 按"谁可以调用"分为两类：User-invoked（仅用户手动 /command 调用，负责编排）和 Model-invoked（用户和 Agent 都可以调用，持有可复用的规范）。User-invoked Skill 可以调用 Model-invoked Skill，但不能反过来。

User-invoked（8 个——管流程编排）

Skill	实际功能
`ask-matt`	这不是简单路由，是整个 Skill 体系的导航地图。定义了三条路径：(1) 主流程 idea → ship：`grill-with-docs`→必要时 `prototype` 分叉→`to-prd`→`to-issues`→每个 Issue 新会话 `implement`；(2) 入站流 bugs/requests：`triage`→`implement`；(3) 代码库健康：`improve-codebase-architecture`→产出 idea→进入主流程。还有跨会话的 `handoff`/`compact` 策略
`grill-with-docs`	调用 `grilling`+`domain-modeling`，在 grilling 的同时建立项目共享语言（更新 CONTEXT.md 和 ADR）
`triage`	完整状态机——2 个分类角色（bug/enhancement）+ 5 个状态角色（needs-triage/needs-info/ready-for-agent/ready-for-human/wontfix）。流程：收集上下文→推荐→验证声明（对 Bug 复现、对 PR 确认 diff）→按需 grill→发布结果。每个 Issue 评论以 "This was generated by AI during triage" 开头。支持 PR 的 triage
`improve-codebase-architecture`	用 `Explore` Agent 扫描代码库寻找深化机会（shallow modules、耦合泄露、测试困难点）。应用删除测试（deletion test）。产出自包含 HTML 报告（Tailwind+Mermaid CDN），生成 before/after 可视化卡片。用户选择一项后，进入 grilling 深入
`setup-matt-pocock-skills`	一次性配置：选 Issue Tracker（GitHub/Linear/本地文件）、triage 标签映射、文档布局。是其他工程 Skill 的前置条件
`to-issues`	把计划/PRD 拆为垂直切片（tracer bullet），每片贯穿所有集成层（schema→API→UI→tests）。每片独立可验证。先做 prefactoring（"make the change easy, then make the easy change"）
`to-prd`	不访谈——直接合成已有对话为 PRD。先探索代码库确定接缝（seams，接口测试边界）。输出含 Problem Statement、Solution、详细 User Stories、Implementation Decisions、Testing Decisions、Out of Scope。标记为 ready-for-agent
`prototype`	丢弃式原型，回答一个具体问题。两个分支：(1) LOGIC.md — 构建交互式终端应用测试状态机/业务逻辑；(2) UI.md — 同一路由生成多种差异化 UI 变体，通过 URL search param 切换
`implement`	基于 PRD 或 Issue 执行的编排 Skill。调 `/tdd`→跑 typecheck→跑测试→调 `/review`→提交。是 `ask-matt` 主流程的最后一步

Model-invoked（4 个——持有可复用的规范）

Skill	实际功能
`diagnosing-bugs`	核心方法论：构建反馈循环。 "This is the skill. Everything else is mechanical." 9 种构建 pass/fail 信号的方法（按推荐顺序：failing test→curl script→CLI invocation→Playwright→captured trace→throwaway harness→property/fuzz loop→bisection harness→HITL bash script）。然后收紧循环（更快、信号更清晰、更确定性）。不轻易跳过阶段
`tdd`	RED-GREEN-REFACTOR 循环，一次一个垂直切片。带 `mocking.md`、`refactoring.md`、`tests.md` 三个参考文件
`domain-modeling`	主动构建领域模型——用术语表挑战术语，用边界场景压力测试，更新 CONTEXT.md 和 ADR
`codebase-design`	深度模块设计的共享词汇。外带 `DEEPENING.md`（深化指南）和 `DESIGN-IT-TWICE.md`（两次设计法）

Productivity Skills（5 个——通用工作流，不限于编程）

User-invoked（4 个）

Skill	实际功能
`grill-me`	Matt 说这是他最受欢迎的 Skill。使用 `/grilling` 可复用循环。与 `grill-with-docs` 的区别：无代码库时用（无状态，不保存任何本地文件）
`handoff`	将当前对话压缩为交接文档，写入 OS 临时目录而非工作区。包含"suggested skills"部分建议下一个 Agent 该用什么 Skill。不重复已在 PRD/ADR/Issue 中的内容。自动脱敏 API Key 等
`teach`	完整的多会话教学系统。在当前目录创建教学空间：`MISSION.md`（学习动机）、`reference/.html`（速查表）、`RESOURCES.md`、`learning-records/.md`（类似 ADR 的学习记录）、`lessons/.html`（自包含 HTML 课程）、`assets/`（可复用组件）。遵循最近发展区理论
`writing-great-skills`	编写和编辑高质量 Skill 的参考指南：词汇表和原则

Model-invoked（1 个）

Skill	实际功能
`grilling`	`grill-me` 和 `grill-with-docs` 背后的可复用循环。一次一个问题直到决策树的每个分支都被解决，每次给出推荐答案。代码库能回答的问题优先探索代码库而不是问用户

Misc Skills（4 个——偶尔用）

Skill	说明
`git-guardrails-claude-code`	设置 Claude Code Hooks 拦截危险 git 命令（push、reset --hard、clean 等）
`migrate-to-shoehorn`	把测试文件从 `as` 类型断言迁移到 @total-typescript/shoehorn
`scaffold-exercises`	创建练习目录结构（sections、problems、solutions、explainers）
`setup-pre-commit`	创建 Husky pre-commit hooks（lint-staged、Prettier、类型检查、测试）

设计哲学与四大失败模式

Matt 在 README 中用引述经典著作的方式解释了他创建这些 Skill 的原因——四种 AI 编程的失败模式：

失败模式 #1：Agent 没做对我想做的事

"No-one knows exactly what they want" ——《程序员修炼之道》

人和 Agent 之间存在沟通鸿沟。解决方法是 grilling session——让 Agent 在动手前详细追问你想做什么。对应 Skill：grill-me、grill-with-docs。

失败模式 #2：Agent 太啰嗦

"有了统一语言，开发者之间的对话和代码的表达都源自同一个领域模型" —— Eric Evans，《领域驱动设计》

Agent 用 20 个词描述一个概念，浪费大量 Token。解决方法是建立共享语言（Shared Language）——一份文档帮助 Agent 解码项目中的术语。Matt 有一个真实的例子：他的 course-video-manager 项目中，把"当一个课程中某个小节内的一个课程被设为'real'（即在文件系统中分配了一个位置）时出现的问题"缩写为"materialization cascade"。这份简洁在每轮会话中都在省钱。

这是 grill-with-docs 的核心能力——不仅做 grilling，还帮你建立与 AI 的共享语言。

失败模式 #3：代码不工作

"始终采取小的、有意识的步骤。反馈速率就是你的速度极限。" ——《程序员修炼之道》

没有反馈循环时，Agent 就是在"盲飞"。解决方案：RED-GREEN-REFACTOR 循环（tdd）+ 规范化的调试流程（diagnosing-bugs）。

失败模式 #4：代码库变成了泥球（Ball of Mud）

"每天都投资系统的设计" —— Kent Beck，《极限编程解析》
"最好的模块是深的。它们通过简单的接口提供大量功能" —— John Ousterhout，《软件设计的哲学》

Agent 可以极速写代码，也同时极速加速软件熵增。解决方案是关心代码的设计——to-prd 在写代码前追问你要碰哪些模块；improve-codebase-architecture 帮你拯救已经变成泥球的代码库，Matt 建议每几天跑一次。

"Software engineering fundamentals matter more than ever."
—— Matt Pocock, README

这四大失败模式和 Karpathy 的四种"慢性病"有惊人的重叠——两位顶级工程师独立发现了相同的问题。区别在于：Karpathy 给出的是原则，Matt 给出的是可执行的 Skill。

安装

多路径规则 → 05 · 多路径安装

入门 — 只装 grill-me（03 方案 D）

推荐（CC Switch 用户）：install + sync。
备选（终端 / 无 CC Switch）：npx skills add；不要混装。

# 推荐（CC Switch）
cc-switch skills install mattpocock/skills:grill-me && cc-switch skills sync

# 备选（npx）
npx skills add mattpocock/skills --skill grill-me -g -a claude-code -y

/skills
/grill-me
/doctor

完整工程流（按需逐个装）

推荐：先 --list，再按需 --skill 追加（tdd、triage、to-prd…）。
不要 npx skills add mattpocock/skills --all（21 Skill 会打爆描述预算）。

npx skills add mattpocock/skills --list
npx skills add mattpocock/skills --skill tdd -g -a claude-code -y
# triage / to-prd / implement 等按需追加

用 triage、to-issues、implement 等编排 Skill 前，在 Claude Code 里先跑一次：

/setup-matt-pocock-skills

Karpathy 四原则 — 一页纸治愈 LLM 编程四大慢性病

背景

2026 年 1 月 26-27 日，Andrej Karpathy 在 X 上发文记录 LLM 编程的四大失败模式。次日，开发者 Forrest Chang（GitHub: forrestchang）将其整理为 CLAUDE.md 文件并开源。

重要说明：仓库名为 andrej-karpathy-skills，内容源自 Karpathy 的观察，但 Karpathy 本人未公开背书此仓库。作者为 Forrest Chang。

原仓库：forrestchang/andrej-karpathy-skills（~91K stars）
社区 fork：multica-ai/andrej-karpathy-skills（更活跃维护）
协议：MIT

四大"慢性病"

病一：偷偷替你假设

模型会默默替你做假设，然后一路执行到底，不验证、不管理困惑、不主动澄清、不指出不一致、不提出权衡、不在该拒绝的时候拒绝。

你说"帮我加个登录"，它不会问用什么认证方式、要不要记住设备、Session 怎么管理——直接按它以为合理的方案开始写。等你审完发现不对，它已经写了 500 行。

病二：过度工程化

特别喜欢把代码和 API 搞复杂、膨胀抽象层、不清理死代码。能用 100 行解决的问题，非要搞出 1,000 行低效、臃肿、脆弱的架构。你得像哄孩子似的说"你为什么不直接这样？"它才恍然大悟"当然！"然后立刻精简到 100 行。

病三：改了不该改的

有时候会修改或删除一些跟当前任务完全无关的注释和代码——因为"不喜欢"或者"没完全理解"。

你让它修一个 Bug，它顺带删了旁边的 TODO 注释，理由是"看起来不需要了"。

病四：即使用了 CLAUDE.md 也还是老样子

Karpathy 写了一句很关键的话：即使用了 CLAUDE.md 做了简单的尝试性修复，上述问题依然存在。 Karpathy 这样的顶级 AI 研究者，也写不好一个让 Claude 完全听话的 CLAUDE.md。

四条对策

andrej-karpathy-skills 把四种病对应为四条原则：

原则	对应病症	核心动作
Think Before Coding	偷偷假设	明确陈述假设；有不确定性时问而不是猜；给出多种解读；该拒绝时拒绝；困惑时停下来把困惑说清楚
Simplicity First	过度工程	只写需要的最少代码；不写没有要求的功能；不为一次性使用建抽象；不写不可能发生的错误处理
Surgical Changes	改不该改的	不改相邻代码、注释、格式；不重构没坏的东西；匹配现有风格即使你会写得不一样；你发现无关的死代码 → 提出来但不要删
Goal-Driven Execution	无法验证	把指令性任务变成可验证目标："加验证" → "写无效输入的测试，让它们通过"；"修 Bug" → "写一个复现的测试，让它通过"

安装

多路径怎么选 → 05 · 多路径安装

推荐 A（Plugin 全局）：所有 Claude Code 项目都要四条原则时用；User scope 装一次。
备选 B（单项目 CLAUDE.md）：只在本 git 仓库生效；CC Switch 用 Prompts / git 同步，不是 skills install。
A / B 只选一条，不要双装。

# A. Plugin 全局（推荐）
/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills
/reload-plugins
/skills

# B. 单项目 CLAUDE.md（备选）
curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md
# 已有 CLAUDE.md 时改为 append，见上游 README

Cursor：复制 .cursor/rules/karpathy-guidelines.mdc（见上游 README）。

与其他工具的关系

Karpathy 四原则内容上是单文件 guidelines（四条约束，无 hooks/MCP）。安装方式可以是 Plugin（跨项目）或按项目 curl 写入 CLAUDE.md（见上方安装）。

本章资料来源：gsd-build/get-shit-done、open-gsd/gsd-core、garrytan/gstack、mattpocock/skills、forrestchang/andrej-karpathy-skills