gstack 代码智能 Provider 契约用一个可选的 repo-oriented 接口替换 1.7 万行自研索引胶水【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack本文基于 gstack 仓库的设计文档 CODE_INTELLIGENCE_PROVIDER_CONTRACT.md完整解析 gstack 的代码智能 Provider 契约这一核心机制它如何用一个仅含 4 个必需方法 3 个可选能力的小接口把原本由约 17k 行自研胶水代码承担的索引、搜索、知识图谱工作委托给 GBrain、Sourcebot、Graphify 三个外部 Provider并深入 lib/code-intelligence/ 的源码说明契约的类型定义、类型化错误码、逐仓库 egress 同意consent门禁、Picker 选择机制、gstack-code-intelligenceCLI 的完整用法以及该契约如何分四个阶段替换现有的 GBrain 胶水。读完后你可以理解 gstack Provider 关闭时依然完整可用这一硬约束在代码层面是如何保证的也能掌握该契约对外部工具做集成时的设计取舍。背景为什么 gstack 要定义一个 Provider 契约设计文档开宗明义地给出了问题陈述gstack 自身携带了约 17k LOC 的自研代码智能胶水包括transcript 摄取bin/gstack-memory-ingest.ts约 1.9k LOC统一同步动词bin/gstack-gbrain-sync.ts约 1.6k LOC上下文加载bin/gstack-brain-context-load.ts三层规划缓存bin/gstack-brain-cache源对账、引擎状态分类、破坏性操作守卫外加约 15 个bin/gstack-gbrain-*与bin/gstack-brain-*入口点和约 40 个测试这些全部是围绕同一个外部工具GBrain的直接 CLI shell-out手工搭建的管线。gstack 不想继续维护一个自研索引器而是希望定义一个小的、可选的契约由外部 Provider 去实现——索引/搜索/图谱的工作留在 Provider 侧gstack 只保留调用面。文档中有一条不可协商的硬约束也是整个契约的灵魂Provider 关闭时 gstack 必须完整可用。纯文件路径决策存储、Context Recovery、grep保持可靠永远不依赖任何 Provider 的存在。这与现有的决策存储哲学一脉相承lib/gstack-decision.ts零 gbrain 依赖lib/gstack-decision-semantic.ts 在语义召回失败时降级为null。契约是增强enhancement永远不是依赖dependency。这一原则在 lib/code-intelligence/contract.ts 的文件头注释中被再次强调Never a dependency, always an enhancement。设计决策repo-oriented而非 document-store这是文档中已拍板、不再重议的决策Settled (do not relitigate)契约是**以仓库为单元repo-oriented**的四个必需操作为register_source(repo) — 必需 refresh(source) — 必需 search(query) — 必需 status(source) — 必需而add/delete/export是 Provider可以MAY声明的可选能力。GBrain 声明了它们其原生原语是文档按 slug 操作put/delete/get/export而代码搜索与代码图谱工具则拒绝提供。文档明确否决了文档存储型契约把 add / delete-by-id / export 设为必需操作理由是它歪曲了代码搜索/图谱工具的真实形态Sourcebot 索引的是整个仓库并暴露 search它根本没有删除文档 id X的概念。强迫所有 Provider 实现一套文档 CRUD 面要么会排除掉我们最想要的工具全仓库索引器、图谱工具要么迫使它们用谎言去 stub 必需操作。仓库进、查询出repo-in / query-out才是诚实的最大公约数GBrain 的文档轴保留为可选能力而不是契约的形状本身。这一决策在源码中得到忠实落地lib/code-intelligence/contract.ts 将能力分为两组常量——export const REQUIRED_CAPABILITIES: readonly CodeProviderCapability[] [ register_source, refresh, search, status, ] as const; export const OPTIONAL_CAPABILITIES: readonly CodeProviderCapability[] [ add, delete, export, ] as const;并且每个适配器构造时都会调用assertRequiredCapabilities()做 fail-fast 校验见下节。契约的 TypeScript 定义契约位于 lib/code-intelligence/contract.ts共 201 行。文档中给出的接口形状与实现一致核心定义如下contract.ts#L110-L127interface CodeProvider { readonly id: gbrain | sourcebot | graphify; readonly label: string; readonly capabilities: ReadonlySetCodeProviderCapability; readonly local: boolean; // true 无仓库内容离开本机 has(capability: CodeProviderCapability): boolean; registerSource(repo: RepoRef, opts?: OpOptions): PromiseSourceStatus; refresh(source: SourceRef, opts?: OpOptions): PromiseSourceStatus; search(query: string, opts?: SearchOptions): PromiseCodeSearchHit[]; status(source?: SourceRef, opts?: OpOptions): PromiseSourceStatus; add?(doc: { slug: string; body: string }, opts?: OpOptions): PromiseSourceStatus; delete?(slug: string, opts?: OpOptions): PromiseSourceStatus; export?(source: SourceRef, opts?: OpOptions): Promisestring; }配套的核心数据结构同样值得注意RepoRefcontract.ts#L54-L61idProvider 注册该仓库时使用的源 idpath本地工作树路径 可选remoteUrl。SourceStatusstate为闭集registered | indexing | ready | absent | unknownitemCount报告页面/文件/图谱节点数量partial: true表示 Provider 只实现了部分状态探测对应能力矩阵中 Sourcebot/Graphify 的status打 ~。CodeSearchHitrefslug、文件路径或符号 id取决于 Provider、可选score/snippetkind为document | file | symbol | graph-node统一了三种 Provider 的异构结果形状。OpOptionscontract.ts#L85-L101env测试注入假 CLI 用、timeout毫秒、以及最关键的consented——逐仓库的内容出网同意标记。注释明确指出搜索查询文本本身就是仓库衍生的内容repo-derived content因此对非本地 Providerregister_source / refresh / add / search全部需要 consent。契约的三条不变量每个 Provider 必须实现四个必需方法并且必须精确声明它所支撑的能力——assertRequiredCapabilities在构造期强制校验必需四项contract.ts#L164-L172有测试将其钉死。可选方法存在当且仅当对应能力已被声明。调用未声明的可选操作抛出CAPABILITY_UNSUPPORTED——绝不静默 no-op。守卫函数assertCapability()contract.ts#L178-L186实现了这一点。类型化失败模型闭集错误码文档将错误处理类比为runtime/context.js的ContextError纪律一个闭集代码表构造函数对未知代码抛异常。实现位于 contract.ts#L129-L158export const CODE_PROVIDER_FAILURES Object.freeze([ PROVIDER_UNAVAILABLE, PROVIDER_NOT_CONSENTED, CAPABILITY_UNSUPPORTED, SOURCE_NOT_REGISTERED, PROVIDER_TIMEOUT, PROVIDER_ERROR, ] as const); export class CodeProviderError extends Error { constructor(code: CodeProviderFailure, message: string, providerId?: CodeProviderId) { if (!FAILURE_SET.has(code)) throw new TypeError(Unknown code-provider failure code: ${code}); ... } }六个错误码及语义与文档表格一致错误码含义PROVIDER_UNAVAILABLECLI/MCP 传输层缺失——降级到纯文件路径PROVIDER_NOT_CONSENTED该仓库未同意索引且内容将离开本机CAPABILITY_UNSUPPORTEDProvider 拒绝该操作SOURCE_NOT_REGISTERED操作需要一个未注册的 sourcePROVIDER_TIMEOUTProvider 超出操作超时PROVIDER_ERRORProvider 已运行但失败其中PROVIDER_UNAVAILABLE是承重的load-bearing一个调用方捕获它或使用 Picker 的 null 解析后回退到 grep / 纯文件路径它永远不会致命。从源码可以看到这一降级在 GBrain 适配器中如何被具体化gbrain-adapter.ts#L246-L266#assertOk()区分三类失败——CLI 不在 PATHENOENT →PROVIDER_UNAVAILABLE、超时ETIMEDOUT/SIGTERM →PROVIDER_TIMEOUT、以及环境性失败。环境性失败由一个共享正则ENVIRONMENTAL_ERROR_REgbrain-adapter.ts#L59-L60匹配覆盖PGLite/WASM初始化失败、数据库不可达、未配置等形态——这些统统降级为PROVIDER_UNAVAILABLE并只取 stderr 第一行而不是把一段 WASM 堆栈 dump 抛给用户。这个正则同时被#assertOkspawn 失败路径和#wrap异常包装路径复用注释明确说两条路径永不漂移。双轴同意Consent模型契约的第二个核心安全机制是两条正交的同意轴两条都显式、都绝不自动授予1. 网络 / 内容出网同意逐仓库在任何仓库内容离开本机之前索引必须按仓库获得同意。契约在registerSource/refresh/add实际实现中还包括search/export因为查询文本也是仓库衍生内容中强制执行。核心守卫是 assertEgressConsentexport function assertEgressConsent(provider: CodeProvider, opts?: OpOptions): void { if (provider.local) return; // 本地 Provider 豁免——无内容出网 if (opts?.consented true) return; throw new CodeProviderError( PROVIDER_NOT_CONSENTED, ${provider.label} would send repo content off this machine; per-repo indexing consent is required, provider.id, ); }本地 ProviderGraphify跳过这一轴。GBrain 适配器在search()中有一段值得注意的 fail-closed 说明gbrain-adapter.ts#L153-L160因为DATABASE_URL可能在 gbrain CLI 自己的配置内解析、指向远程库适配器无法做廉价的 loopback 检查所以每一次发送都视为需要 consent——抛错发生在任何字节或任何 egress 收据存在之前。2. 安装同意仅 GraphifyGraphify 永远不会被自动安装。options/status展示只有在它的 CLI 存在时才标记为可用gstack 中没有任何代码会运行 Graphify 安装器安装是用户行为pip install graphifyy graphify install。文档指出这匹配 Context.dev 的模型选择selection的持久化不等于授予出网同意出网需要另一步显式动作。这一分离在 lib/code-intelligence/selection.ts 中落实得相当彻底——选择存储是单一 JSON 文件$GSTACK_HOME/code-intelligence.json默认~/.gstack/selection.ts#L33-L36结构为export interface Selection { provider: CodeProviderId | null; /** 绝对仓库路径 → 是否已同意 */ consents: Recordstring, boolean; /** Provider id → 它最近索引的绝对仓库路径让 search 能找回同一份图 */ roots: Recordstring, string; /** 用户明确选择不索引——永不再次询问 */ declined: boolean; }从源码结构看consent 的读取还叠加了一层逐 remote 的信任策略否决vetohasConsent()先查逐仓库 consent再经过repoPolicyVeto()——若策略层级为deny则所有操作被否决为read-only则只否决写类操作register/index/refresh/add/delete读类操作search/export/status放行策略存储不可读或 helper 无法 spawn 时 fail-closed一律否决selection.ts#L94-L120。写类操作分类在 contract.ts#L22-L30 的OpClass注释中定义未分类的调用方默认按write处理——同样 fail-closed。此外GBrain 适配器在每次携带内容的发送之前写一份 egress 收据#receiptgbrain-adapter.ts#L104-L116记录目的地、载荷类别、字节数与 sha256当确切载荷文本已知时如add的文档体、search的查询且 consent 字段记录实际的同意状态——防篡改账本绝不为未检查 consent 的发送声明 consentedtrue。三个 Provider 的能力矩阵文档给出的逐 Provider 能力矩阵是理解三者差异的核心表格操作GBrain首选推荐SourcebotGraphifyregister_source✓sources add --federated✓ 本地git连接写入 config.json✓graphify update dir本地、无 LLMrefresh✓syncsync --strategy code --full✓ 自动配置变更 reindexIntervalMs✓graphify update dirsearch✓gbrain search联邦语料✓POST /api/search匿名访问时无需 keyBearer key 可选✓graphify query q --graph graph.jsonstatus✓sources list page_count~ 部分服务器存活探测~ 部分graph.json 存在 节点数add✓put slug✗ 拒绝✗ 拒绝delete✓delete slug✗ 拒绝✗ 拒绝export✓export✗ 拒绝✓ 读graphify-out/graph.jsonlocal无出网否联邦 DBloopback →是远程主机 → 否是纯本地三个 Provider 的细节与源码佐证GBrain首选推荐gstack 生态工具。完整契约适配通过既有 gbrain CLI 咽喉点驱动——复用 lib/gbrain-exec.tsspawnGbrain注入DATABASE_URL与 lib/gbrain-sources.tsensureSourceRegistered/probeSource声明全部 7 项能力local falsegbrain-adapter.ts#L79-L88。其refresh()实现了一个经验证的两遍流程gbrain-adapter.ts#L136-L149// 第 1 遍默认 syncmarkdown 策略——索引文档 this.#assertOk(spawnGbrain([sync, --source, source.id], { baseEnv: opts.env, timeout })); // 第 2 遍真正的代码索引路径。没有它代码永远不会被索引 this.#assertOk(spawnGbrain([sync, --source, source.id, --strategy, code, --full], { baseEnv: opts.env, timeout }));超时也有讲究默认操作超时 30s但refresh使用 120s 上限REFRESH_TIMEOUT_MS因为上千 tracked 文件仓库的完整代码索引常规性地超过 30s查询/状态保持 30sgbrain-adapter.ts#L43-L49。Sourcebot自托管全仓库正则搜索Docker Compose 部署捆绑 server Postgres Redis无受支持的非 Docker 路径。register_source向 server 的config.json添加本地{ type: git, url: file:///path }连接配置变更触发重索引本地仓库需要remote.origin.url否则被跳过search是POST {baseUrl}/api/searchstatus探测该端点。拒绝add/delete/export。它是本地工具——索引后的代码留在你的机器上API key 可选启用匿名访问FORCE_ENABLE_ANONYMOUS_ACCESStrue的本地实例无需 key 即可服务/api/search适配器仅在设置了 key 时才发送Authorization: Bearer SOURCEBOT_API_KEY。loopbackbaseUrl使localtrue内容不出机器远程baseUrl则需要出网 consent。Graphify本地 tree-sitter 代码图谱graphifyCLI。适配器使用graphify update dir——本地、无 LLM 的构建写出graphify-out/graph.json刻意避开裸graphify dir构建后者会运行需要 API key 网络的 LLM 抽取后端。graphify query q --graph graph.json执行搜索其NODE .../EDGE ...输出通过src/at字段携带文件位置export直接读图谱 JSON。完全本地localtrue。可选仅凭用户显式动作安装pip install graphifyy graphify install需要 Python 3.10绝不被自动安装。文档还刻意排除了两个选项不提供本地索引选项naive 的本地索引会劣化结果质量——宁可路由到真正的 Provider 或纯文件 grep也不做一个半成品自研索引以及三个 Provider全部由 runtime 直接驱动不需要 MCP——GBrain/Graphify 走 CLI shell-outspawnSync与既有 gbrain 胶水相同的 ENOENT→PROVIDER_UNAVAILABLE降级Sourcebot 走 HTTP 配置文件编辑fetch可注入使测试无需真实 server 即可跑 stub。Sourcebot 与 Graphify 虽自带 MCP server 供 in-agent 使用但契约不依赖它们因为其 CLI/HTTP 面足以完成索引与搜索。PickerGBrain 永远排第一选择机制位于 lib/code-intelligence/picker.ts lib/code-intelligence/selection.ts用户通过gstack-code-intelligence select provider选择 Provider持久化到$GSTACK_HOME/code-intelligence.json。resolveSelectedProvider()picker.ts#L54-L57构造所选 Provider未选择任何 Provider 时返回null——这就是 provider-OFF 路径调用方降级到 grep / 纯文件决策存储export function resolveSelectedProvider(opts: PickerOptions {}): CodeProvider | null { const { provider } readSelection(opts.env); return provider ? providerById(provider, opts) : null; }可用性在调用时call time证明所选 Provider 的 CLI/server 若缺失其操作抛PROVIDER_UNAVAILABLE调用方捕获并降级。RECOMMENDED_ORDERpicker.ts#L26是静态的GBrain → Sourcebot → Graphify事实——GBrain 永远被推荐第一Picker 绝不静默偏向非推荐工具。detectAvailable()picker.ts#L79-L110并发探测各 Provider 以驱动options/status展示GBrain 走真实的localEngineStatus()Graphify 检查 CLI/图谱存在Sourcebot 走 HTTP 存活探测。三个探测相互独立、并发执行且各自被 3s 的PROBE_TIMEOUT_MS封顶——源码注释解释了这个数字的由来一个死掉的非 loopbackSOURCEBOT_URL若在 30s 操作默认超时下探测仅打印选项表就要卡 30 秒而 3s 对存活检查已绰绰有余。CLIgstack-code-intelligence实战用法CLI 入口为 bin/gstack-code-intelligence284 行bun 脚本完整命令面bin/gstack-code-intelligence#L9-L16gstack-code-intelligence suggest [repo] [--json] # 一次性索引询问闸门这里该不该问用户 gstack-code-intelligence options # 列出 ProviderGBrain 排第一 可用性 gstack-code-intelligence status # 当前选择 可用性 gstack-code-intelligence consent [repo-path] yes|no # 记录逐仓库索引同意值必填 gstack-code-intelligence select gbrain|sourcebot|graphify|none gstack-code-intelligence index [repo-path] # 用所选 Provider 索引本仓库 gstack-code-intelligence search query... # 经所选 Provider 搜索要点非本地 ProviderGBrain或跑在远程主机上的 Sourcebot在你为该仓库 consent 之前拒绝索引Graphify 与 localhost 上的 Sourcebot 是本地工具无内容出机器不需要 consent。select none走setProvider(null)selection.ts#L62-L68并记录declined: true使会话开始时的询问永不重复反向地选择任何 Provider 会清除既有的 declined 标记。suggest子命令是会话开始时的一次性询问闸门由shouldOfferIndexing()判断是否该问基于 tracked 文件数阈值见 lib/code-intelligence/suggest.ts并以--json输出自包含的选项 理由使代理的提问无需额外上下文。文档验证部分记载了一次端到端 smoke test 路径select→ consent 闸门 → 本地 Graphify 索引5 节点图谱→ search。契约如何替换现有 GBrain 胶水文档给出的映射表是路线图的核心现状自研契约之下bin/gstack-gbrain-sync.tssync/reindex-code/sourcesprovider.registerSource/provider.refreshlib/gstack-decision-semantic.ts的semanticRecallprovider.search作用域内→ 同样的 degrade-to-nullbin/gstack-brain-context-load.tsquery/list_pagesprovider.search/provider.statusbin/gstack-memory-ingest.tsimport, putprovider.add可选能力仅 GBrainlib/gbrain-sources.tsensureSourceRegistered,probeSourceGBrain 适配器内部实现lib/gbrain-local-status.tsGBrain 适配器可用性探测保留、复用bin/gstack-gbrain-detect/-install/-source-wireup/-repo-policyProvider setup picker consent更薄文档特别强调目标不是在一个 commit 里删掉 17k LOC而是让每个消费者调用契约然后在契约背后逐 Provider 退役自研路径。只需求搜索我的代码或降级的消费者从此完全不 import gbrain 细节。分阶段上线Rollout每个阶段独立可回滚。Skill 模板的编辑被刻意推迟到后续阶段正因如此前两个 slice 不会触发gen:gstack2/ parity 重基线循环阶段 1本 slice契约、三个真实适配器、可用 CLI。contract.ts 完全可驱动的 GBrainCLI、GraphifyCLI、SourcebotHTTP config适配器 选择存储 gstack-code-intelligenceCLIoptions/status/select/consent/index/search 测试。用户今天就能选择 Provider 并索引/搜索自己的仓库。尚无 skill 模板或生成文件变更。阶段 2内部消费者路由到契约。把gstack-decision-semantic与gstack-brain-context-load指向resolveSelectedProvider()精确保留 degrade-to-null。对纯文件路径行为中性。阶段 3在 skill 中暴露选择器。在 skill 能受益于索引搜索的时刻提供 picker镜像context命令的即时just-in-timeconsent 提问。重新生成 skillbun run gen:gstack2、重跑bun run test:gstack2、有意重基线 parity。阶段 4退役自研胶水。当所有消费者都在契约之上后逐 Provider 删除 sync/ingest/cache 入口点及其测试。真实环境验证两轮执行与两次纠错文档用一整节诚实记录了验证过程三个适配器都在隔离环境中并行 agent、每个一个 worktree被真实工具驱动且全部实现了真实的索引 搜索一个真实仓库端到端。跑了两轮因为第一轮修复中包含了一个只有真实执行才能抓到的错误GBrain — 真实 PostgrespgvectorDocker、gbrain 0.42.56 — 已证明。默认 pglite/WASM 引擎在 macOS 上损坏上游 garrytan/gbrain#223因此可用配方通过DATABASE_URL让 gbrain 指向真实 Postgres。真实端到端搜索返回了实际代码定义[0.88] src-checksum-ts … export statement computeChecksum。真实执行抓到作者自己引入的一个回归他基于对--help的误读从refresh中移除了--strategy code导致代码静默地从未被索引只有文档被索引。已恢复为经验证的两遍流程sync然后sync --strategy code --full--federated注册对全局搜索是承重的。此前还修过引擎挂掉现在降级为PROVIDER_UNAVAILABLE单行消息而非PROVIDER_ERROR WASM 堆栈 dump。Sourcebot — 线上 v6.5.0Docker— 已证明无需 key。端点、请求体、响应解析对真实服务器全部正确。更正一个早先的错误结论Sourcebot 本地使用不需要 API key——启用匿名访问FORCE_ENABLE_ANONYMOUS_ACCESStrue后/api/search无 key 可用已通过真实命中验证CLI 未设 key 的情况下。key 保持可选本地仓库需要remote.origin.url才能被索引。它是本地工具代码留在机器上除非SOURCEBOT_TELEMETRY_DISABLEDtrue启动时有一个遥测 ping。Graphify — 真实安装、graphify 0.9.23 — 已证明。更正另一个早先的错误断言对代码而言graphify dir与graphify update dir产出相同的 AST 图谱且无 LLM 调用LLM 只重命名社区簇并摄取非代码文档零新增节点/边且解析器丢弃它触碰的字段。因此刻意不提供 LLM 模式localtrue是正确的。适配器使用graphify update真实 index search 返回了正确的file:line引用。另修复search现在读取被索引仓库的图谱持久化 rootoptions将已安装的 Provider 报告为 available。文档把更大的教训留档读一遍--help或单个 agent 的结论不构成证明——跑真实工具才是。 这一条推翻了作者第一轮的两个判断gbrain flag 的移除与 graphify 的 LLM 断言。边界这个契约不改变什么按 GStack 2 规范契约与 CLAUDE.md 边界无云浏览器、无替代 iOS 驱动、无本地图像模型、无 Provider 市场、无工作流引擎、无新状态数据库。Context.dev 仍是 web 上下文的唯一新授权外部服务本契约治理的是代码智能这条独立轴。既有的决策存储与 Context Recovery 保持纯文件、Provider 无关。测试基线契约的测试基线是 test/code-intelligence.test.ts1122 行无 live 工具覆盖文档声明的全部不变量能力矩阵不变量所有 Provider 声明四个必需能力只有 GBrain 声明文档操作local标记含 loopback vs 远程的 Sourcebot结果解析器parseGbrainSearch/parseGraphifyQuery/parseSourcebotSearch针对从真实工具捕获的格式而非臆造形状选择存储 逐仓库 consent provider-OFFnullconsent 闸门GBrain 非本地且无 consent 时抛PROVIDER_NOT_CONSENTED本地 Graphify 豁免GBrain 适配器对 fakegbrainshimGraphify 适配器对 fakegraphifyshim索引建图、搜索返回命中、status 计节点数Sourcebot 适配器对注入的fetch 临时config.jsonregister 写入本地 git 连接、search 把files[]映射为命中每个适配器在工具/server 缺失时都降级为PROVIDER_UNAVAILABLE。gstack-code-intelligenceCLI 则被端到端 smoke testselect → consent 闸门 → 本地 Graphify 索引5 节点图谱→ search。小结gstack 的代码智能 Provider 契约是一个典型的接缝seam式设计4 个必需方法 3 个可选能力的最小 repo-oriented 接口、闭集类型化错误码、逐仓库 egress consent、GBrain 优先的推荐序、以及一条贯穿始终的硬约束——Provider 关闭时一切照常工作。它没有试图统一三个形态迥异的工具联邦记忆 DB、自托管仓库搜索、本地代码图谱而是只取它们的仓库进、查询出最大公约数把 GBrain 的文档轴降格为可选能力。配套的 lib/code-intelligence/ 实现contract 三个适配器 selection picker约 1.1k LOC与 test/code-intelligence.test.ts 共同保证了契约的每一条声明都有可验证的代码依据而四个阶段的 rollout 计划则确保 1.7 万行自研胶水的退役是逐 Provider、逐消费者、每步可回滚的。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考