gstack /plan-tune 深度解析问题敏感度自调优与开发者心理画像的双轨档案机制【免费下载链接】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/gstackgstack 的 40 个 skill 在执行过程中会频繁触发 AskUserQuestionAUQ提问而高级用户往往反复用同样的方式回答同样的问题却没有办法告诉 gstack「别再问这个了」。/plan-tune是 gstack 为此设计的「问题敏感度自调优 开发者心理画像」skill它以自然语言对话为界面让你审查每个问题的提问记录、按问题设置偏好never-ask / always-ask / ask-only-for-one-way、查看「你声称的自己」与「你的行为暗示的自己」之间的差距并控制整个调优开关。读完本文你能掌握它的完整工作机制typed question registry 如何作为安全与自动决策的基础设施、developer-profile.json双轨档案declared inferred的数据模型、~/.gstack/下的本地存储布局以及防止「画像投毒」的 user-origin gate 安全设计。本文以 plan-tune/SKILL.md 为主体规范设计依据来自 docs/designs/PLAN_TUNING_V0.md 与 docs/designs/PLAN_TUNING_V1.md源码佐证来自scripts/、bin/与test/下的实际实现。适用前提gstack 已通过./setup安装到~/.claude/skills/gstack/skill 中所有命令均假设该安装路径且当前版本为VERSION文件中的 1.71.0.0。定位v1 是「观察型」不是「自适应」/plan-tune的自我定位非常克制。SKILL.md 开头明确写道You are adeveloper coach inspecting a profile— not a CLI. The user invokes this skill in plain English and you interpret. Never require subcommand syntax.**v1 范围observational**包含typed question registry、按问题的显式偏好、问题日志、双轨档案declared inferred、纯英文检查界面。v1 不做的事同样明确没有任何 skill 会根据档案改变自身行为——「No skills adapt behavior based on the profile yet」。这个边界不是随意的。docs/designs/PLAN_TUNING_V0.md 记录了功能的演进最初方案是一个「完整自适应底基」psychographic 驱动自动决策、盲区教练、LANDED 庆祝页等经过 office-hours、CEO EXPANSION、DX POLISH、eng review 四轮评审后被外部模型 Codex 的 20 点批评推翻——核心指控是「Substrate was false」如果 AskUserQuestion 只是 prompt 约定而非中间件agent 可以静默跳过指令在不可强制执行的约定之上构建自动决策「是营销话术」。因此 v1 回滚为「registry-first observational」先建立真正可执行的 typed question registry 作为地基psychographic 驱动的行为适配被推迟到 v2并写明了晋升条件registry 在生产环境稳定 90 天、inferred 维度在 3 个 skill 上表现出稳定性、用户 dogfood 验证。触发方式用户说「tune questions」「stop asking me that」「too many questions」「show my profile」「show my vibe」「developer profile」「turn off question tuning」等都会路由到该 skill当用户说同一个 gstack 问题「以前就问过」或第 N 次推翻推荐项时skill 应主动建议。Step 0意图路由与三道隐式门skill 的第一步不是执行功能而是「检测用户想要什么」。SKILL.md 的 Step 0 规定按自然语言意图路由而非关键词匹配并且隐式门implicit gates优先于用户意图路由执行Consent gate同意门question_tuning为false且~/.gstack/.question-tuning-prompted标记文件缺失时触发「Consent opt-in」流程。无论用户如何回答都会写入标记文件保证不被重复提问。Setup gate配置门question_tuning为true但~/.gstack/developer-profile.json的declared对象为空、且~/.gstack/.declared-setup-prompted缺失时触发 5 问设置向导。这个门专门捕获「绕过向导、直接用 gstack-config 把question_tuning设为 true」的用户。Dream-cycle gate蒸馏门~/.gstack/projects/slug/distillation-proposals.json存在且有未applied_at的提案时触发 Dream cycle review。每个提案自带applied_at作为标记天然跳过已处理项。没有隐式门触发时按意图路由到 12 个分支用户意图示例原话执行动作show my profile / what do you know about me / show my vibeInspect profilereview questions / what have I been askedReview question logstop asking me about X / tune: ...Set a preferenceupdate my profile / Ive changed my mindEdit declared profile写入前必须确认show the gapShow gapdream cycle / distillDream cycle distill触发gstack-distill-free-textturn it offgstack-config set question_tuning falseturn it ongstack-config set question_tuning true touch ~/.gstack/.question-tuning-prompted意图不明直接问(a) 看档案 (b) 看问题记录 (c) 设偏好 (d) 改 declared (e) 跑蒸馏 (f) 关闭幂用户可用单词快捷调用profile、vibe、gap、stats、review、enable、disable、setup、distill、dream、audit——但都不强制。Consent opt-in默认关闭无自动翻转隐私姿态是 v1 的硬约束gstack 对所有用户默认question_tuning: false没有任何群体cohort会自动翻转开关。同意 prompt 是启用路径的唯一入口贡献者gstack_contributor: true也不会被自动加入——设计上贡献者的数据对 v2 帮助最大但决定权仍然完全在用户。同意 prompt 的核心话术General framingQuestion tuning is off. gstack can learn which of its prompts you find valuable vs noisy — so over time, gstack stops asking questions youve already answered the same way. It takes about 2 minutes to set up your initial profile. v1 is observational: gstack tracks your preferences and shows you a profile, but doesnt silently change skill behavior yet. Logs stay local (~/.gstack/projects/slug/question-log.jsonl).RECOMMENDATION: Enable and set up your profile. Completeness: A9/10.A) Enable set up (recommended, ~2 min) B) Enable but skip setup (Ill fill it in later) C) Cancel — Im not ready流程要点检测贡献者状态仅用于 prompt 措辞不触发任何自动动作gstack-config get question_tuning与gstack-config get gstack_contributor。发出 AskUserQuestion贡献者版本额外说明「v2 中 skill 会适应你的引导风格你的数据最有帮助」。无论选哪个都 touch~/.gstack/.question-tuning-prompted。选 A 或 Bgstack-config set question_tuning true。选 C什么都不做并告知「Re-enable any time with/plan-tune enableorgstack-config set question_tuning true」。5-Q setup五维心理画像的自声明设置向导用五个独立 AskUserQuestion 调用一次一问每个维度对应一个 0–1 的浮点值选项 A/B/C 分别映射约 0.25 / 平衡 / 0.85Q1 scope_appetite「规划功能时你倾向快速发布最小可用版本还是构建覆盖边界情况的完整版本」A) Ship small, iterate≈0.25/ B) Balanced / C) Boil the ocean≈0.85Q2 risk_tolerance「你宁可快速行动事后修 bug还是行动前仔细检查」A) Check carefully≈0.25/ B) Balanced / C) Move fast≈0.85Q3 detail_preference「你要『直接做』的简洁回答还是带权衡与推理的详尽解释」A) Terse≈0.25/ B) Balanced / C) Verbose with reasoning≈0.85Q4 autonomy「每个重要决定都要咨询你还是委派给 agent」A) Consult me≈0.25/ B) Balanced / C) Delegate≈0.85Q5 architecture_care「『现在发』与『把设计做对』之间你通常倒向哪边」A) Ship now≈0.25/ B) Balanced / C) Get the design right≈0.85五维语义在 scripts/psychographic-signals.ts 中有精确定义scope_appetite: 0 small-scope, ship fast ↔ 1 boil the ocean risk_tolerance: 0 conservative, ask first ↔ 1 move fast, auto-decide detail_preference: 0 terse, just do it ↔ 1 verbose, explain everything autonomy: 0 hands-on, consult me ↔ 1 delegate, trust the agent architecture_care: 0 pragmatic, ship it ↔ 1 principled, get it right声明值通过原子写写.tmp再fs.renameSync落入~/.gstack/developer-profile.json的declared.{dimension}并更新declared_at时间戳。SKILL.md 给出的写入片段用gstack-paths导出GSTACK_STATE_ROOTeval $(~/.claude/skills/gstack/bin/gstack-paths) _PROFILE$GSTACK_STATE_ROOT/developer-profile.json bun -e const fs require(fs); const p JSON.parse(fs.readFileSync($_PROFILE,utf-8)); p.declared p.declared || {}; p.declared.scope_appetite Q1_VALUE; p.declared.risk_tolerance Q2_VALUE; p.declared.detail_preference Q3_VALUE; p.declared.autonomy Q4_VALUE; p.declared.architecture_care Q5_VALUE; p.declared_at new Date().toISOString(); const tmp $_PROFILE.tmp; fs.writeFileSync(tmp, JSON.stringify(p, null, 2)); fs.renameSync(tmp, $_PROFILE); 向导结束后必须 touch~/.gstack/.declared-setup-prompted——即使用户中途放弃「they were asked; they chose not to complete」Setup gate 也尊重这个选择用户随时可以用/plan-tune setup重跑。最后 skill 展示档案作为确认见下一节。Inspect profile纯英文呈现与显示门槛档案检查的入口命令~/.claude/skills/gstack/bin/gstack-developer-profile --profilebin/gstack-developer-profile 是取代旧gstack-builder-profile的统一档案访问器旧 binary 保留为委托到--read的 legacy shim子命令包括--read兼容 /office-hours 的 KEY: VALUE 格式、--derive从事件重算 inferred、--profile完整 JSON、--gapdeclared 与 inferred 的差、--trace dim展示贡献到某维度的每个事件、--vibearchetype 标签、--migrate迁移 builder-profile.jsonl。呈现规则刻意避开原始浮点数用「band 人话」翻译declared[dim]按 0.0–0.3 → low、0.3–0.7 → balanced、0.7–1.0 → high 三档翻译格式如「scope_appetite:0.8 (boil the ocean — you prefer the complete version with edge cases covered)」。只有inferred.diversity通过显示门槛才允许把 inferred 列出来sample_size 20 AND skills_covered 3 AND question_ids_covered 8 AND days_span 7。展示格式「scope_appetite:declared 0.8 (boil the ocean) ↔ observed 0.72 (close)」差距用词分档0.0–0.1 close、0.1–0.3 drift、0.3 mismatch。未达门槛时明确告诉用户还差多少「Not enough observed data yet — need N more events across M more skills before we can show your observed profile.」vibearchetype来自gstack-developer-profile --vibe仅在校准门槛达成或 declared 已填写有东西可比时展示。这里有一个值得注意的设计细节SKILL.md 特别强调显示门槛刻意低于 v2 的 E1 晋升门槛90 天、跨 3 skill 稳定见 PLAN_TUNING_V0。展示 inferred 值是 UI 便利而基于档案修改行为默认值是「 consequential 」的事需要高得多的证明标准——「Do NOT use the display gate as a green light for v2 E1 work」。archetype 模型实现在 scripts/archetypes.ts每个 archetype 是五维空间中的一个中心点matchArchetype()计算带 tightness 缩放的 L2 距离取最近者若没有 archetype 在阈值内返回FALLBACK_ARCHETYPEPolymath——一个校准过的「不符合常见模式」标签。文件头注释说明 v1 只 ship 定义、不接入用户可见输出为 v2 的/plan-tune vibe/narrative做稳定化铺垫。数据流与存储布局registry → check → log → tunev1 的数据流源自 docs/designs/PLAN_TUNING_V0.md由 SKILL.md 的 Question Tuning 小节落到具体命令preamble: 读 question_tuning 配置off 则整段跳过 每个 AskUserQuestion 之前: gstack-question-preference --check registry-id --summary-stdin → AUTO_DECIDE选推荐项并可见地标注 Auto-decided [summary] → [option] (your preference). Change with /plan-tune. → ASK_NORMALLY正常提问 每个 AskUserQuestion 之后: gstack-question-log 追加记录到 ~/.gstack/projects/{SLUG}/question-log.jsonl registry 校验拒绝未知 id 主动提议: Tune this question? Reply tune: [feedback] to adjust. 用户下一轮消息含 tune: 前缀且确实源自用户消息: gstack-question-preference --writesource: inline-userbinary 校验来源 inferred 维度按需由 gstack-developer-profile --derive 重算--check的判定逻辑在 bin/gstack-question-preference 中实现从源码结构看其优先级是one-way 状态永远先查安全优先于偏好然后才看存下的 preferenceone-way 问题 → 一律ASK_NORMALLY如果用户存了 never-ask还会打印NOTE: one-way door overrides your never-ask preference for safety.*-split-*的拆分链逐选项提问 → 一律ASK_NORMALLYregistry 直接拒绝在 split id 上写 never-asktwo-way never-ask→AUTO_DECIDEtwo-way ask-only-for-one-way→AUTO_DECIDE既然不是 one-wayalways-ask或未设置 →ASK_NORMALLY写入偏好时还有反向保护对 one-way id 设置never-ask或ask-only-for-one-way会被拒绝exit 2带door_type: one-way的 stderr 说明always-ask对 one-way id 则合法与安全覆盖语义一致。--stats输出ALWAYS_ASK / NEVER_ASK / ASK_ONLY_ONE_WAY计数并把打在 one-way id 上的抑制性偏好单列为inert。存储布局与 V0 设计文档一致~/.gstack/ developer-profile.json # 统一档案: declared inferred sessions ~/.gstack/projects/{SLUG}/ question-log.jsonl # 每次 AskUserQuestion, 只追加, registry 校验 question-preferences.json # 显式按问题偏好 {question_id: preference} question-events.jsonl # tune: 反馈事件, user-origin gate distillation-proposals.json # dream cycle 蒸馏出的待审提案统一档案的完整 schemaV0 文档{ identity: {email: ...}, declared: { scope_appetite: 0.9, risk_tolerance: 0.7, detail_preference: 0.4, autonomy: 0.5, architecture_care: 0.7 }, inferred: { values: {scope_appetite: 0.72, ...: ...}, sample_size: 47, diversity: {skills_covered: 5, question_ids_covered: 14, days_span: 23} }, gap: {scope_appetite: 0.18}, sessions: [{date: ..., mode: builder, project_slug: ..., signals: []}], signals_accumulated: {named_users: 1, taste: 4, agency: 3} }选择「事件溯源 双轨」的原因在 V0 文档中有完整论证信号映射表signal map会随版本变化从事件重算即可、永不迁移数据declared代表用户主权用户说自己是谁系统在用户驱动的事情上服从inferred代表系统观察展示但不行动gap本身才是有意思的信号——大 gap 暗示自我描述与行为不符是自我洞察但 v1 绝不自动纠正。typed question registry安全与自动决策的地基整个机制的地基是 scripts/question-registry.ts。文件头注释说明了它承担的四个角色日志事件打上注册的 id偏好以注册 id 为键one-way door 安全性在这里声明而非从 prose 摘要推断心理信号映射表以 id 查维度增量。核心类型QuestionCategoryapproval/clarification/routing/cherry-pick/feedback-loopDoorTypeone-way | two-wayQuestionDef要求idkebab-case{skill}-{what-it-asks-about}、skill、category、door_type、可选signal_key与稳定options键door_type的判定标准写得很明确破坏性操作、架构/数据模型分叉、超过 1 天 CC 工作量的 scope 增加、安全/合规选择 →one-way无论用户偏好如何永远提问其余是two-way可被显式偏好自动决策。这是 V0 决策 C 的产物Codex 批评「运行时 prose 解析」让安全依赖措辞一个措辞温和的破坏性操作可能被误分类所以改为一等声明 scripts/one-way-doors.ts 的关键词模式作 belt-and-suspenders 二级兜底。registry 也不是「所有 AUQ 必须注册」的死板要求skill 常在运行时动态构造问题agent 会为这类问题生成{skill}-{slug}形式的 ad-hoc id/plan-tune会把高频出现的 ad-hoc id 表面化为 registry 晋升候选v1 覆盖目标是 ship、review、office-hours、plan-*-review、qa、investigate、land-and-deploy 等 skill 中最常见的 30–50 个类别one-way door 100% 覆盖。CI 层面有 lint 测试断言每个 SKILL.md.tmpl 中的 AUQ 模式都有对应 registry 条目见下节测试。配套的 scripts/psychographic-signals.ts 是手工维护的{signal_key, user_choice} → dimension delta映射设计原则有四手工编写而非 agent 推断小而保守的增量典型 ±0.03 到 ±0.06「单次回答应当 nudge 画像而不是重塑它」绑定 registry 的signal_key让多个问题共享语义模式并非每个问题都贡献每个维度没有signal_key的问题只记录、不移动画像。检查问题日志与设置偏好Review question logskill 直接读取~/.gstack/projects/$SLUG/question-log.jsonl用 bun 内联脚本按question_id聚合出 top 20 的count / skill / followed / overridden统计纯英文呈现并高亮用户频繁推翻推荐的问题——这些就是never-ask偏好的候选。若日志不存在告知「No questions logged yet」。Set a preference的完整流程从用户话语中识别question_id有歧义就列出日志 top 5 让用户选。归一化到三选一never-askstop asking / unnecessary / auto-decide this、always-askask every time / I want to decide、ask-only-for-one-wayonly on destructive stuff / only on one-way doors。措辞清晰则直接写歧义则确认「I read users words aspreferenceonquestion-id. Apply? [Y/n]」——只有明确 Y 才继续。写入命令~/.claude/skills/gstack/bin/gstack-question-preference --write {question_id:id,preference:never-ask|always-ask|ask-only-for-one-way,source:plan-tune,free_text:original phrase}确认话术「Setid→preference. Active immediately. One-way doors still override never-ask for safety — Ill note it when that happens.」注意source字段/plan-tune直接调用时是plan-tune若是其他 skill 内的 inlinetune:反馈则由发起 skill 用inline-user——但必须先验证前缀确实来自用户的聊天消息见安全模型。Recent auto-decisions子视图筛出日志中source auto-decided的最近 10 条让用户抽查强制执行的命中如果某条误判提议将其翻转为always-ask。Audit unmarked questions则统计question_id以hook-开头的 hash-only 条目 top 10这些是 PreToolUse hook 捕获到、但因 skill 模板里缺少gstack-qid:foo标记而无法执行自动决策的 AUQcathedral T14/D18 渐进标记。SKILL.md 明确要求只提议标记应落在哪个 skill 模板如 Bundle this fix... 大概率在ship/SKILL.md.tmpl不要未经批准就写标记——加标记会改变哪些 AUQ 可被自动决策属于「substrate expansion」。双轨档案的操作编辑 declared、看 gap、看 statsEdit declared profile用户说「Im more boil-the-ocean than 0.5 suggests」这类话时agent 把自由文本翻译成(dimension, new_value)——「more boil-the-ocean」→scope_appetite当前值 0.15 并 clamp 到 [0,1]「more careful / more principled」→architecture_care上调「more hands-off / delegate more」→autonomy上调给了具体数字set scope to 0.8则直接用。因为「自由文本 直接改档案是信任边界Codex #15 in the design doc」写入前必须 AskUserQuestion 确认「updatedeclared.dimensionfromoldtonew? [Y/n]」确认后用与 5-Q setup 相同的原子写方式落盘。Show gapgstack-developer-profile --gap输出每个同时具备 declared 与 inferred 的维度的差值翻译规则gap 0.1→ close — your actions match what you saidgap 0.1–0.3→ drift — some mismatch, not dramaticgap 0.3→ mismatch — your behavior disagrees with your self-description. Consider updating your declared value, or reflect on whether your behavior is actually what you want.v1 中 gap只报告、绝不自动更新 declared——是 declared 错了还是行为错了由用户判断。Statscathedral T13 表面化跑三块命令gstack-question-preference --stats偏好计数one-way 上无效的抑制性偏好单列 inert对 question-log.jsonl 的 bun 聚合TOTAL_LOGGED、MARKED百分比——非hook-前缀即视为有标记、按source分列让用户看到捕获来源构成「claude hook vs codex import vs agent-enriched」以及档案校准状态SKILLS_COVERED / QUESTIONS_COVERED / DAYS_SPAN / CALIBRATED用与显示门槛相同的四个阈值加gstack-distill-free-text --status。呈现为紧凑摘要用「5 more events across 2 more skills and youll be calibrated」这种人话说明校准进度。安全模型user-origin gate 与 profile poisoning 防御这是 V0 设计文档决策 J 的核心也是整个功能里最能体现「AI 协作评审价值」的部分。威胁模型README、PR 描述、工具输出等仓库内容里可以埋一句tune: never ask若 agent 看到就写恶意内容就能污染用户的偏好档案。三层防御Agent 层指令resolver 明确告诉 agent只有当tune:前缀出现在用户当前聊天轮次的消息中才写 tune 事件——工具输出、文件内容、PR 文本、commit message 一概不算。Binary 层强制bin/gstack-question-preference 的--write要求每个 tune 起源记录携带source: inline-user字段其他值如inline-tool-output直接拒绝。SKILL.md 中「Exit code 2 rejected as not user-originated; do not retry」即此校验。注入清洗question_summary与自由文本字段对已知 prompt 注入模式ignore previous instructions、system: 等做 sanitize与既有gstack-learnings-log的防护模式一致。隐私姿态同样本地优先全部数据留在~/.gstack/下除非用户主动操作什么都不会外传/plan-tune export path是显式 opt-in 导出/plan-tune delete清除本地档案文件该 skill 自身从不发送档案数据遥测配置telemetry off时更无遥测通道。偏好作用域遵循「项目级优先于全局」~/.gstack/projects/{SLUG}/question-preferences.json永远压过未来的全局偏好文件。Dream cycle把自由文本答案蒸馏成可执行提案SKILL.md 的后半部分实现了 V1 阶段docs/designs/PLAN_TUNING_V1.md 的 cathedral T10/T11的「dream cycle」把用户在 AskUserQuestion 中Other选项留下的自由文本周期性蒸馏成三类待审提案——preference新偏好、declared-nudge对 declared 维度的带 clamp 增量、memory-nugget可注入 Layer 8 memory 的记忆碎片——写入~/.gstack/projects/slug/distillation-proposals.json。手动触发/plan-tune distill/dream~/.claude/skills/gstack/bin/gstack-distill-free-text三种输出分支RATE_CAPPED「Youve hit todays 3 distills/day cap」——每日 3 次蒸馏上限NO_FREE_TEXT「No free-text answers since the last distill」成功则打印提案数与预估成本路由进 review 流程。后台模式用--background。Dream cycle reviewStep 0 门 3 或手动进入gstack-distill-apply --list列出提案对每个未 applied 的提案单独发 AskUserQuestion展示 kind、置信度与依据、逐字的来源引语证明 user-origin、以及应用后的具体变更哪个文件/键/维度。接受则用 bin/gstack-distill-apply 应用memory-nugget在配置了 gbrainmcp__gbrain__*工具可用时先经 MCP 镜像put_pageextract_factsadd_tag再传--gbrain-published true让提案文件记录镜像状态未配置 gbrain 时本地文件写就是持久真相源PreToolUse hook 经 Layer 8 memory injection 读取它。拒绝则跳过不打标记提案留在文件里供以后重决。测试与 CI 防线该功能的实现事实由一组测试锁定均为仓库内可运行的真实文件test/plan-tune.test.tsregistry 完整性、重复 id 检查、偏好优先级never-ask 非 one-way → AUTO_DECIDEnever-ask one-way → ASK_NORMALLY、user-origin gate拒绝非inline-user来源、derivation 重算、统一档案 schema、带 7 会话 fixture 的迁移回归。test/skill-e2e-plan-tune.test.ts 与 test/skill-e2e-plan-tune-cathedral.test.tsskill 级 e2e 与 cathedral 阶段标记、统计、distill行为。test/gstack-developer-profile.test.ts、test/gstack-question-preference.test.ts、test/gstack-question-log.test.ts、test/distill-apply.test.ts、test/distill-free-text.test.ts对三个 binary 与 distill 流程的单元/集成覆盖。test/plan-tune-gates.test.tsStep 0 隐式门consent / setup / dream-cycle的触发条件。test/one-way-doors.test.tsone-way 分类的 registry 声明 关键词兜底。test/skill-coverage-matrix.ts 及其配套测试维护 skill 覆盖矩阵防止新功能漏接。运行方式仓库使用 bun 工具链见 package.json 与 bunfig.tomlbun test全量跑单独验证该功能可bun test test/plan-tune.test.ts。v2 的门槛与明确的「不做」V0 设计文档把被推迟项连同验收标准写成表这是该仓库工程文化的典型样本每一项都有「为什么推迟」与「何时可以晋升」推迟项推迟原因v2 晋升验收标准摘E1 substrate wiring5 个 skill 读档案并适配需要 v1 registry 证明持久性 真实观察数据校准 deltav1 registry 稳定 90 天inferred 维度跨 3 skill 稳定dogfood 验证档案驱动的默认值「感觉对」E3/plan-tune narrativevibe事件锚定叙述需要稳定档案否则输出「generic slop」档案多样性检查连续 2 周真实使用通过叙述测试证明引用的是具体事件而非陈词E4 blind-spot coach与 E1/E6 在缺少 interaction-budget 设计时逻辑冲突交互预算 升级规则的设计 specdogfood 确认是 coaching 而非 naggingE5 LANDED 庆祝页不能放在 preamble热路径副作用延迟、认证失败、意外开浏览器晋升后必须是显式命令或 post-ship hook绝不被动检测E6 基于 mismatch 的自动调整需要双轨档案先稳定v1 真实 mismatch 数据呈现一致模式建议 UX 单独设计psychographic 驱动 auto-decidev1 零行为变化真实使用表明显式偏好已覆盖大多数场景被彻底否决的方案「Codex was right」也值得记录substrate-as-prompt-convention不可强制执行的约定是沙子、declared 维度 ±0.2 clamp与 mismatch 检测逻辑互斥改为双轨独立追踪、运行时 prose 解析 one-way door安全不能依赖措辞、单一事件 schema 文件混装四种域对象拆成三个文件、TTHW 遥测与 local-first 定位矛盾。实操速查与适用前提在已安装 gstack 的机器上日常交互面完全是自然语言想做的事说法等价快捷词底层命令启用/关闭turn it on / turn it offenable / disablegstack-config set question_tuning true/false看档案show my profileprofile / vibegstack-developer-profile --profile/--vibe看问题历史what have I been askedreview / stats读question-log.jsonl聚合设偏好stop asking me about Xauditgstack-question-preference --write ...看差距show the gapgapgstack-developer-profile --gap蒸馏自由文本dream cycledistill / dreamgstack-distill-free-text/gstack-distill-apply重跑 5 问setup5-Q setup 流程适用前提与限制均来自文档与源码的可验证事实v1 是观察型的偏好never-ask 等立即生效并参与 AUTO_DECIDE但五维画像本身不驱动任何 skill 行为「No behavior adaptation in v1. This skill INSPECTS and CONFIGURES.」所有路径基于~/.claude/skills/gstack/bin/的安装布局GSTACK_STATE_ROOT可覆盖状态根测试隔离用见 bin/gstack-developer-profile 中的GSTACK_HOME${GSTACK_STATE_ROOT:-...}。one-way door 问题在任何偏好下都会提问这是设计内的安全覆盖不是 bug。该 skill 属于 gstack 23 个工具之一项目定位为「Use Garry Tans exact Claude Code setup」其完整调用链——preamble 环境探测、AskUserQuestion 决策简报格式ELI10 / Recommendation / Completeness / Net 结构、plan-mode 下的 prose fallback——见 plan-tune/SKILL.md 全文与 docs/askuserquestion-split.md 中的 5 选项拆分规则。【免费下载链接】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），仅供参考