kstack-generate-principles 是一个面向 Kriscard Stack 的技能，用来自动从已配置的 Obsidian 知识库中生成有证据支撑的改进候选，再只把用户选中的候选深化为针对 Kstack 原则、操作手册（playbook）或通用技能（generic skill）的提案。该技能面向 Kriscard Stack 及其通用技能，目标是改进 Kstack 的决策方式与工程执行方式。其核心取舍是不把每条有用笔记都转成产物，只纳入具备明确产物形态、且填补已证实缺口的候选。
使用方式与流程
该技能按七个步骤组织：建证据集、查现有归属、产物与技术双维扫描、候选排序呈现、深化所选候选、呈现提案、落地获批提案。
-
建立证据集：加载已安装知识库与记忆召回技能，遵循实时库结构。完整读取 index.md，解析并读取六个配置的知识视图（Career MOC、Dotfiles MOC、Productivity MOC、Software Development MOC、Work MOC 与 Weekly Learnings Base）及其 Base 定义。有 Obsidian 时物化各 Base，否则按文件夹与标签过滤文件系统元数据，不越出配置范围扫全库。合并去重所有浮现笔记，按标题、别名、标签、链接、目录摘要和可搜索正文检查，并用 QMD 与文件系统搜索跨全部浮现集合检索，不使用小规模 top-N 定义候选池。对每条笔记标注相关、不确定或排除及理由，完整阅读相关与不确定笔记，跟进支持或反驳潜在改进的实质链接、反向链接与原始来源。原始来源视为证据，智能体撰写的内容视为解释，有实质内容的用户文字视为用户明确的理解，空白、模板化或仅链接的骨架不算证据。在知识库与仓库之外创建临时覆盖回执，记录配置视图、Base 过滤与计数、每条浮现笔记及分类、完整阅读记录、查询族、技术镜头、命令、各产物类型与技术镜头扫描结果、跟进的证据来源以及不可用或失败的搜索面。面向用户只报告计数、过滤、失败与回执路径。若配置视图无法物化、有笔记未分类或相关或不确定笔记未读完，则停止并报告覆盖缺口。
-
生成候选前先查现有归属：通过根目录是否含 AGENTS.md、skills/README.md 和 skills/dev/kriscard-mode/SKILL.md 来定位 Kriscard Stack 检出，工作目录只作候选位置，含糊时询问路径并停止。读取 skills/README.md、skills/dev/ 下每个 Kstack 自有 SKILL.md 以及 kriscard-mode 的全部 playbooks，清点已安装技能描述，并读取 references/quality-benchmark.md。对每个浮现想法，找出处理相同触发、决策、用户任务、职责、流程、边界、输出或完成标准的所有现有产物，完整阅读每个可能匹配者后再纳入候选；仅名称相似既非必要条件也非充分条件。去掉已被良好处理的想法，幸存候选必须写明所查的每个可能匹配、最近的现有归属者和确切的缺失行为。
-
产物与技术双维扫描：对原则、操作手册、通用技能分别独立扫描，每个产物扫描内再分别搜索七个技术镜头：组件组合、组件 API 与可复用模式；软件架构、领域建模、边界与数据流；React、Next.js、React Server Components 等框架行为；设计工程、交互设计、无障碍、动画与视觉质量；逆向工程、运行时与追踪取证及代码理解；测试、性能、可靠性、安全与开发者工具；AI 辅助工程、评审、工作流与工程效率。原则候选可来自用户表达的持久工程信念、反复出现的 Kstack 失败、险情或纠正，或多条笔记同一教训，需通过原则基准，无法指出坏默认、触发、改变的决策、重要例外与可观察评估的建议应拒绝。操作手册候选寻找当前 Kriscard 模式路由处理不佳的重复工作，优先观察到的流程，由多笔记推断的流程须标为 Inferred 并排在同类观察流程之后，需通过操作手册基准，无法指出触发、当前路由缺口、归属者、有序阶段、门禁、真实证据、停止点与回复契约的流程应拒绝。通用技能候选寻找超出单一 Kstack 流程仍有用的重复用户任务，加载 writing-for-agents，完整阅读每个可能已安装技能后判断任务属于现有技能还是需要在 kriscard/Skills 中新建归属者，需通过通用技能基准，无法指出确切用户任务、所查已安装技能、缺失契约、流程、输出、边界与完成标准的候选应拒绝。空扫描须记录检查了哪些产物与证据及为何无通过者，不得为填充章节编造弱候选。
-
排序与呈现候选：主要按对用户工程信念的反映强度、改善真实工作的频率、填补当前缺口的清晰度与证据强度排序，提及笔记数量只是佐证而非排序规则。不设最低数量，总共最多呈现十个候选。若多章节均有通过候选，先纳入各章节最强候选再按总排名补满；若有技术镜头存在通过的领域特定候选，先纳入最强此类候选再用更宽泛的流程候选补满。候选始终按“原则、操作手册、通用技能”顺序组织，每节内分“新建”与“更新”子标题。每个候选须包含：新建或更新、通俗动作名称、技术镜头、证据路径与支持链接或路径、所查可能现有产物、最近现有归属者、确切缺失行为、为何能改善用户工程工作，以及各类产物的专门证明（原则：坏默认、触发、改变的决策与例外；操作手册：观察或推断、工作、当前路由缺口、主要阶段与门禁；通用技能：确切用户任务、所查已安装技能与缺失契约）。空子节写“无候选”并简述检查了什么及为何无通过者。此步骤只给候选证明，不写完整产物草稿或评估用例。呈现后停止，请用户选择候选、要求其他搜索方向或结束，只有被选中的候选才继续。
-
深化所选候选：仅对被选候选确定确切的归属仓库与路径。原则与 Kriscard 模式操作手册归 Kriscard Stack，通用技能归 kriscard/Skills。对照当前产物与质量基准重新检查每个被选候选，将其分类为：新增（无当前产物拥有所需行为）、更新（当前产物拥有该行为但存在已证实的契约缺口）或无变化（更深入检查显示行为已被覆盖、缺乏证据或属项目特定）。在推荐位置前应用 principle-boundary-discipline，不要把通用技能复制到 Kriscard Stack。每个被选候选须有一个结论、一个归属者、一个产物类型与明确的重叠理由。
-
呈现所选提案：在原则、操作手册、通用技能下呈现提案，每个包含：结论与产物类型；建议名称与确切路径；改变的重复工作或决策；触发、规则或流程、限制、输出与可观察变化；知识库证据；比较过的现有产物与已证缺口；矛盾、置信度与缺失证据；基准结果及未通过问题；所属仓库中会改变的确切文件；正例、反例与边界评估用例。须区分知识库陈述与推荐建议，并请求用户对确切的新增或更新集合明确批准。
-
落地获批提案：获批后加载 writing-for-agents，仅编辑获批的、归 Kriscard Stack 所有的原则与操作手册。通用技能提案止于向 kriscard/Skills 的获批交接，不从本工作流编辑或复制该归属者的文件。须匹配现有产物形态与适用基准，知识库引用保留在提案中，不让运行时产物依赖知识库访问。在能保护可发现性或必要契约时新增或更新可执行仓库测试，遵循仓库格式、检查与验证说明。若仓库证据与获批提案冲突，应用 principle-stop-on-plan-drift 并在改设计前回到用户。完成后仅获批文件被改动，检查通过或已报告确切阻塞项，最终报告将每项改动映射到获批提案。
适用场景
适用于已经在 Obsidian 中维护知识库、使用 Kriscard Stack 技能体系，并希望把长期积累的工程信念、重复工作与跨流程用户任务，选择性地沉淀为原则、操作手册或通用技能的场景。也适合在提出新技能或改技能前，先做系统性证据梳理与现有归属检查的场景。
限制
该技能要求知识库结构配置完整且可物化，否则会停止并报告覆盖缺口；依赖 Kriscard Stack 检出目录含指定文件，路径含糊时需询问；候选最多十个且最终落地仅限获批文件，通用技能不直接编辑。