GPT-5.6 / Fable 5 讓 gstack 的 Prompt 型 Skills 價值大減，但 Browser、QA、Review、Security、Deploy 等程序化 Skills 反而更值得保留。本文用研究數據與實務判斷，幫你決定哪些該刪、哪些該留。
在 GPT-5.6 / Fable 5 這類 Frontier Model 登場後，gstack 這套 Skills 是否還有存在於本機的必要？答案不是簡單的「有」或「沒有」，而是要看它裡面裝的是哪一種 Skills。
兩種 Skills，兩種命運
gstack 目前定位為 23 個 specialist skills + 8 個 power tools，涵蓋 CEO、Engineering Manager、Designer、QA、Security、Release Engineer、Browser 等角色。但其中其實混雜了兩種本質上完全不同的東西：
第一種：替模型「思考」的 Prompt Skills
例如 /office-hours、/spec、/plan-ceo-review、/plan-eng-review、/plan-design-review、/autoplan。
這些 Skills 本質上是在告訴模型：「現在你是 CEO，換個角度想」「現在你是 Engineering Manager，重新檢查 architecture」「現在先列 assumption，再 challenge assumption」。
在 2025 年的 Claude / GPT 上，這類 Skills 非常有價值。但到了 Fable 5 / GPT-5.6，Frontier Model 已經內建 requirement decomposition、architecture reasoning、implementation planning、codebase exploration、self-critique、test generation、edge-case reasoning、visual reasoning、long-horizon planning 等能力。
再疊上這些 Prompt Skills，很多時候不是提高品質，而是在增加 token、latency、context pollution、重複 reasoning、over-planning，甚至造成 model steering conflict。
第二種：把工程流程「程序化」的 Skills
例如 /review、/investigate、/qa、/browse、/setup-browser-cookies、/design-review、/cso、/ship、/land-and-deploy、/canary、/benchmark。
這些 Skills 不是增加模型的 IQ，而是增加 procedure compliance。例如 /review 已經不是一句「你現在是 Staff Engineer」而已，它包含 base branch detection、diff、scope drift、SQL safety、LLM trust boundary 等明確程序。
這種 Skills 不會因為模型變聰明而失去價值，因為它是在補模型的紀律、工具與 SOP。
研究數據支持這個判斷
2026 年 3 月的 SWE-Skills-Bench 專門測試 Agent Skills 對現代 coding agent 的幫助，結果非常值得注意：
- 49 個 SWE Skills 中，有 39 個完全沒有提高 pass rate
- 整體平均改善只有 +1.2%
- 有 3 個 Skills 讓模型表現下降最多 10%
- 真正有明顯效果的只有 7 個 specialized skills，最佳能提高約 +30%
其中一個重要問題是：Skill 裡面的規則如果和目前 project / model / library 狀態不一致，反而會干擾模型。
這與 Frontier Model 的使用體感完全一致：Generic intelligence Skills 價值快速下降，Domain-specific procedural Skills 仍然很有價值。
2026 年的 gstack 判決
如果你問的是「我是不是可以直接把 gstack 整個 uninstall？」，答案是：可以，但我不會直接整包丟掉。
更合理的做法是把 gstack 從「AI Engineering Framework」降級成「Engineering Skill Library」，只保留大約 8–12 個 procedural skills：
review
investigate
qa
qa-only
browse
setup-browser-cookies
design-review
cso
ship
land-and-deploy
benchmark
canary
而把以下 Skills 從 default workflow 拿掉：
office-hours
spec
plan-ceo-review
plan-eng-review
plan-design-review
autoplan
document-generate
為什麼 /autoplan 現在反而有點反效果
gstack 官方 /autoplan 的概念是把 CEO、Design、Engineering、DX review、Plan 等多個 review pipeline 自動跑過一遍。
在中階模型時代這很好。但在 GPT-5.6 / Fable 5：
Frontier Model reasoning
+
CEO reasoning prompt
+
Design reasoning prompt
+
Engineering reasoning prompt
+
Autoplan orchestration
很容易變成 reasoning amplification，而不是 information amplification——花了更多 token，模型想了四次差不多的事情。
對於真正困難的 coding task，更乾淨的流程反而是：
User requirement
↓
Frontier Model
↓
inspect repo
↓
make plan
↓
implement
↓
specialized verification skills
↓
review / QA / browser / security
↓
ship
Frontier Model 仍然需要 Skill 的證據
即使 Frontier Model 很強，明確的 checklist / requirement 仍然能顯著改善可靠性：
- 2026 年 8 月的 SOC 2 coding 評估中，在沒有特別提示安全要求時，Frontier Models 的 compliance 只有約 47–88%；只加入一句明確 SOC 2 requirement 後，就提升到 86–100%。
- 2026 年 7 月研究發現，在長 context 裡，generic self-check 只有 5/10，而 detailed external checklist 達到 10/10，差異有統計顯著性。
所以：模型更聰明 ≠ 不需要 SOP。反而是模型越能自主執行，越值得把重要 SOP deterministic 化。
更進一步：不建議 Global Loading
如果現在是 ~/.claude/skills/gstack/ 整包掛著，讓 Claude Code 每個 project 都看到全部 Skills，我會開始傾向改掉。
Skill 數量越來越多後，「全部讓模型看到」本身開始成為成本。理想結構反而是：
Agent
│
├── Native Frontier Intelligence
│ ├── planning
│ ├── architecture
│ ├── coding
│ └── reasoning
│
├── Project Instructions
│ └── AGENTS.md / CLAUDE.md
│
└── Specialized Skills
├── browser
├── QA
├── review
├── security
├── benchmark
└── deploy
而不是：
Frontier Model
+
30 個人格 Prompt
+
100 個 workflow rules
+
大量 global Skills
結論
截至 2026 年 8 月，gstack 的定位不是「已經過時」，而是「它原本大約一半以上的 Prompt-Orchestration 價值，已經被 Fable 5 / GPT-5.6 吃掉；剩下真正有價值的是 procedural tooling」。
如果只討論是否還值得「整包存在於 Global Skills」：我會選擇否。
如果討論其中專門處理 Browser、QA、Review、Security、Deploy 的 Skills 是否仍值得存在：值得，而且這部分 Frontier Model 越強，價值反而越高。