Shreyas Kapale
296 posts

Shreyas Kapale
@Shreyaskapale
Founding Architect @ Lyzr | Creator of GitAgent | believer of git native AI agent infra | Building the Infra to support AI agents.


从 @garrytan 的 GStack 学习到的其实不止 Skill 的写法,更多的是 Workflow 的构建。一个可控的,步进式的,引导性的工作流,不管是实际产出,还是用户心智,对比 skill 都有极大的改进。我目前学习到的 5 个核心模式: 1. 统一的 AskUserQuestion 格式 每次提问都有 4 个固定板块: Re-ground(重申上下文)、Simplify(简单解释)、Recommend(带理由的推荐)、Options(带工作量估算的选项) 极大的降低了用户的输入门槛,从某种程度上来说,规范了用户的输入。而 AI 的效果,很大程度上是因为用户的输入层次不齐,造成产出不一样。 2. 全流程的 Skill 链路引导 每个 skill 结束时主动推荐下一个 skill,形成链,例如:/office-hours → /plan-ceo-review → /plan-eng-review → /ship 3. 进度条 + 状态追踪面板 QA 报告有评分、分类统计表、before/after 对比、ship readiness 仪表盘。进度和状态的可视化对于工作流是必须的。 4. 完成报告 + 数据统计 /retro输出 commit 统计、热点分析、focus score;/qa 输出修复数量和 before/after 截图。交付即复盘,且给了用户确定性。 5. Telemetry + 复盘数据积累 每次 skill 调用记录到skill-usage.jsonl,/retro 可以分析历史趋势。说实话我在我的写作skill 里面也做了数据追踪和迭代,但是我只追踪了写作规则,也就是功能层面的数据,并没有追踪工作流层面的效率数据。 所以基于 Gstack 的设计,我把我的写作工作流升级了。另外我也会对我的其他 skills 进行整合。 说实话 Garry 带来的是一套系统化的思维,也就是乔布斯之前说的“把点连成线”。而大家做过事的就知道,对比单点功能,流程化的效率和质量提升是指数级的。 从这个角度来说,确实做到了 "Markdown is code",或者说 "Markdown is software"。




































