vedic-destiny
by @seanding1998
吠陀命盘分析中文入口。用于完整命盘研判、命主盘 Rashi chart 与九分盘 Navamsha chart 联读、既往事件回看、出生时间稳定度判断、事业主题、婚姻主题、时间与场域联合分析，以及基于 Jagannatha Hora PDF、星盘截图或文本命盘数据的系统拆盘。当用户提到完整星盘、事业方向、婚姻问题...
clawhub install vedic-destiny📖 About This Skill
name: vedic-chart-analysis-zh description: 吠陀命盘分析中文入口。用于完整命盘研判、命主盘 Rashi chart 与九分盘 Navamsha chart 联读、既往事件回看、出生时间稳定度判断、事业主题、婚姻主题、时空盘专题，以及基于 Jagannatha Hora PDF、星盘截图或文本命盘数据的系统拆盘。当用户提到完整星盘、事业方向、婚姻问题、关系窗口、桃花时间、迁移地点、城市比较、时间窗口，或吠陀占星、Jyotish、Jaimini、Parashari 相关请求时触发。
吠陀命盘研判系统
这是一套中文总入口 skill。先判断用户到底要看整张盘、某个专题，还是时间与地点的联合问题，再只读取当前任务真正需要的 reference。
导航方式
按问题最小化加载：
references/总盘.md
references/事业.md
references/婚姻.md
references/时空盘.md
references/术语框架.md
scripts/build_report_html.py不要一次性载入全部 reference。先判断问题重心，再只读最相关的一组。
执行硬约束
这些约束优先级高于各专题 reference。能算的就算，能核的就核，不能核的就降级，不允许用空泛措辞把缺口糊过去。
1. 先判问题类型，再锁最低交付
不要把完整问题答成几段松散短评，也不要把专题问题答成只有性格描述的泛泛解释。
2. 只要用了数字结论，就必须有校验来源
只要回答里出现下面这类精确结论：
就必须先调用本地工具或明确引用当前对话里已经算过的结果。对于原始命盘资料，默认优先运行：
python "scripts/chart_sanity_check.py"
这个脚本现在可以直接读取 JHora 导出的 markdown，不必先手工改写成 JSON。
SAV/BAV 矩阵是必须尝试的项目，不是可选加分项：
术语框架.md）如果因为缺数据无法执行完整校验，要明确写出：
3. 重大判断必须有至少两类证据支撑
任何主要结论都不能只靠一句抽象判断。至少要落到下面两类证据中的两类：
禁止这类松答：
4. 缺数据时必须降级，而不是硬推
如果关键字段缺失、互相冲突，或出生时间明显不稳：
不要把低置信度问题包装成确定判断。
5. 时间问题必须落到具体窗口
只要用户问：
就不能只回答“未来几年”“最近会有机会”这类模糊话。最低要求：
5.1 用户已经给了事件时间线时，直接进入回看直评
如果用户已经把既往事件按年份或区间列出来：
统一使用这三档命中等级：
高贴合：时间和事件性质都明显对上有限贴合：时间接近，但事件级别、强度或主题更宽失配：盘面很难为这条事件提供有效支撑5.2 细节必须分层，不要一口气跳到专名
解释事件时，先分清下面三层：
结构层：技术型、大机构、异地、边工边学、高压慢回报窗口层：某段时间职业定向、离职、迁移、承压、进修专名层：具体公司、具体国家、具体病名、某一个人做了什么命盘最稳的是结构层，其次是窗口层。专名层只能在外部事实已经给出、且盘面确有支撑时作为对照结果引用，不能反过来冒充盘里本来就能直接读出的结论。
6. 报告型请求强制交付完整产物
如果请求规模已经达到完整报告或大型专题，遵循两阶段纪律（详见 总盘.md 验证闸门）：
第一阶段（验证闭环）：
report.meta.json（status 标记为 verifying）sections/（01 到 04）第二阶段（完整拆盘）：
sections/（05 到 13）report.meta.json（status 标记为 complete）report.html如果验证闸门未通过，报告停留在第一阶段，report.meta.json 的 status 标记为 pending_verification，不生成 report.html。
7. 输出必须先说现实判断，再给盘面抓手
每个主要小节都必须先把结论翻成普通人能懂的话，再上证据。表格、缩写和术语不能单独悬空出现。
共通准则
1. 不要向用户转播内部路由
不要说下面这类话：
我先加载总盘 reference我切到事业专题我按时空盘规则处理我完成了内部检查步骤用户只需要看到判断、提问、结论和限制，不需要看到 skill 内部导航。
2. 报告型请求默认交付整套产物（两阶段）
只要问题已经达到完整报告或大型专题的规模，默认交付物应当按两阶段组织（详见 总盘.md 验证闸门）：
第一阶段交付（验证闭环）：
report.meta.json（status: verifying）sections/01 到 04（基础盘面、一致性检查、既往事件回看、出生时间稳定度）验证闸门通过后，进入第二阶段：
sections/05 到 13report.meta.json status 更新为 completereport.html如果验证闸门未通过，停留在第一阶段，status 标记为 pending_verification，不生成 HTML。
3. 可精确计算的内容优先调用本地工具
只要本地 Python 可用，就不要把能精确核算的项目留给口算或主观估算。
必须工具化的项目包括：
真正适合人工判断的部分包括：
优先使用的辅助脚本：
python "scripts/chart_sanity_check.py"
如果原始资料只给了部分数字，也照样对已有部分做检查，并明确写出哪些项目因为缺数而跳过。缺数据时要降级置信度，不要硬补精确结论。
4. 先给现实判断，再拆盘面抓手
每个主要小节都先回答：
现实判断之后，再补盘面抓手：
5. 复用当前对话上下文
如果当前对话里已经有可用的总盘结果：
6. 不要编造数据
如果原始资料不完整或互相冲突：
输入处理
接受这些输入形式：
如果用户只问一个窄问题，只收集这个问题真正需要的关键字段。
输出契约
每个主要小节都遵守同一结构：
1. 现实判断
2. 盘面抓手
3. 使用提醒
表格可以保留，但前面必须先有一小段普通人能看懂的解释。
报告包装
HTML 生成和解读流程分开。只有在 markdown 报告内容已经存在时，才使用脚本。
报告两阶段纪律：完整研判分两阶段出。第一阶段（验证闭环）闭合且验证闸门通过后，才生成第二阶段内容。report.html 在第二阶段 markdown 全部完成后才打包，不要在第一阶段就生成完整 HTML。
对于完整研判，默认在分析完成后主动生成整套报告目录与 HTML。
默认目录命名建议：
./命盘报告--/
目录契约：
report-folder/
report.meta.json
sections/
01-基础盘面.md
02-主题拆盘.md
report.meta.json 必填字段：
{
"lang": "cn 或 en",
"client_name": "字符串",
"lagna": "字符串",
"gender": "字符串",
"status": "verifying | pending_verification | complete",
"report_kind": "字符串",
"source_system": "字符串",
"notes": ["可选", "字符串数组"]
}
运行：
python "scripts/build_report_html.py"
脚本输出单个自包含 HTML，不负责 PDF。
完整研判分两阶段出，验证闸门见 总盘.md。第一阶段闭合后才允许生成第二阶段和 report.html。
# === 第一阶段：验证闭环 ===
生成后先让用户确认既往事件回看和出生时间稳定度。
验证闸门未通过时，报告到此为止，不要生成 HTML。
sections/
01-基础盘面.md # 上升、九大行星、当前 dasha、九分盘可用度
02-一致性检查.md # 已核 / 跳过 / 影响
03-既往事件回看.md # 提问模式或直评模式，逐条命中等级
04-出生时间稳定度.md # 稳定 / 中等 / 明显不稳
=== 第二阶段：完整拆盘 ===
验证闸门通过后才生成。出生时间不稳则本阶段降级。
sections/
05-行星拆盘A.md # Sun / Moon / Mars
06-行星拆盘B.md # Mercury / Jupiter / Venus
07-行星拆盘C.md # Saturn / Rahu / Ketu
08-九分盘兑现复核.md
09-宫位主轴.md
10-人生主线上篇.md
11-人生主线下篇.md
12-时空盘专题.md # 选配
13-落地提醒.md
如果只是事业或婚姻专题，但内容已经达到完整报告规模，4 节就够：
sections/
01-主题判断.md
02-盘面抓手.md
03-时间与场景.md
04-使用提醒.md