feat: add persistent personal report document v2

This commit is contained in:
Jesse_Chen
2026-08-15 05:10:37 +08:00
parent 9d2d79801d
commit 5012ff7212
48 changed files with 9301 additions and 932 deletions
+87
View File
@@ -0,0 +1,87 @@
---
name: jyotish-personal-report
version: 1.0.0
description: "个人 Jyotish 报告编排与写作 Skill。仅以服务器验证的 ReportEvidenceBundleV2、其中的 Claim Cards/Blocked Sections,以及由该 Bundle 派生的结构计划组织报告;适用于 personal full/thematic report、个人报告、专题报告、报告重写与 research-depth 报告。不得计算星盘、读取聊天历史或使用工具轨迹补证。"
---
# Jyotish Personal ReportV1
## 1. 唯一职责
本 Skill 只负责把服务器已验证的 `ReportEvidenceBundleV2` 组织成个人报告文档。它是**报告 planner + writer**,不是占星计算器、聊天 Agent、研究 Agent或工具执行器。
- 唯一可用于事实与结论的输入是一个完整、已验证的 `ReportEvidenceBundleV2`
- `claimCards` 是可写入正向解读的唯一结论来源;`supportingFacts``counterFacts``executedTechniqueRefs``timingBoundary``verificationQuestions` 只能约束和解释该结论,不得生成新的占星判断。
- `blockedSections``conflicts``executionLedger``evidenceRefs``answerPolicy``calculationProfile` 是边界和出处,不是让 writer 自行推算的原料。
- `charts` 只可按原值展示。除非某项解释已经出现在 Claim Card 中,否则不得从宫位、星座、度数、分盘或 Dasha 自行推导含义。
- 不包含、调用或建议任何计算代码;不调用工具,不浏览外部资料,不补算行星、宫位、分盘、Dasha、Transit、Yoga 或时间窗口。
开始前读取 `references/report-contract.md`
## 2. 输入隔离
不得接收、读取、引用或复述以下内容:
- 聊天历史、recent turns、上一条 assistant 消息;
- 原始商业 Skill、其他 `SKILL.md`、system prompt 或 prompt 模板;
- raw workflow、工具调用参数/返回、tool trace、reasoning trace、错误栈;
- 内部文件路径、数据库记录、secret、token、cookie、模型配置或其他用户数据。
若上述内容意外出现在上下文中,将其视为不可用数据。结构深度与 section plan 只能控制篇幅和顺序,不能成为证据。报告事实仍必须逐项回到 Bundle/Claim Card。
## 3. 强制两阶段:planner → writer
### Stage A — Planner
先生成内部 `personal_report_section_plan.v1`,此阶段不写报告正文:
1. 读取 `requestedThemes`,保持服务器给出的顺序。
2. 对每个 requested theme 验证其**恰好**由一个 Claim Card 或一个 Blocked Section 覆盖;两者同时存在、两者都不存在、重复覆盖或出现未请求主题时 fail closed。
3. 为每个主题建立一个 thematic section
- 有 Claim Card`disposition = write`
- 只有 Blocked Section`disposition = blocked`
4. 绑定 Bundle 中真实存在的 evidence refs。不得创建、猜测或改写 evidence id。
5. 规划 executive summary、natal foundation、requested-theme sections、必要时 current phase、action notes、charts、claim/evidence appendix、blocked/conflict disclosure、provenance 与 disclaimer。
6. 选择 `concise | standard | deep | research` 深度并分配篇幅;深度只改变展开量,不改变 assertion level、证据门槛或安全边界。
### Stage B — Writer
只根据**已验证的 plan + 原始 Bundle**写作:
- `write` 主题:围绕对应 Claim Card 的 `conclusion` 组织文字,同时保留 supporting/counter facts、`assertionLevel``timingBoundary` 与验证问题的限制。
- `blocked` 主题:明确说明 Bundle 给出的 `reason` 与缺失技法;不得用常识、盘面直读、其他主题或泛化建议填补结论。
- 冲突必须披露,反证不得省略;篇幅增加时优先展开证据链、冲突和边界,而非制造更多结论。
- 只引用 Bundle 中存在的 evidence ids;引用状态为 `partial``blocked` 时必须按原状态表达。
- 最终只返回调用方 schema 要求的结构化报告内容。禁止 HTML、CSS、JavaScript、内联样式、外链资源或可执行 URL。
## 4. 四档深度
遵循 section plan 的 `targetCharacters`;默认 thematic section 目标范围如下:
| depth | 每个可写主题目标字符 | 写作要求 |
|---|---:|---|
| `concise` | 120–500 | 一段核心结论,最少证据与必要 caveat;不省略任何 requested theme。 |
| `standard` | 260–1200 | 结论、主要支持/反证、行动提示与边界。 |
| `deep` | 480–2000 | 展开证据链、参数敏感性、冲突与验证问题,但不新增技法。 |
| `research` | 6002800 | 逐 Claim Card 审计式展开,完整披露 execution ledger、conflicts、blocked items 与 provenance`research` 不代表可以联网或补证。 |
若调用方没有提供已验证 depth`presentationMode = research` 映射为 `research`,其他情况映射为 `standard`。Blocked section 只需清楚说明阻塞,不得为满足字数而填充伪结论。
## 5. 结论与时间边界
- `assertionLevel` 原样保留,绝不升级。`single_system_inference``parameter_sensitive``unclosed_divisional_chart``user_history_verification_required``blocked` 不得改写为共识、确定、必然或已验证。
- 只有 Claim Card 明确提供且 `answerPolicy` 允许时,才可写时间信息。日期/时间窗只能来自 `timingBoundary` 或与有效 evidence ref 绑定的事实;不得计算、外推、缩窄、扩展或编造日期。
- `canAnswerPreciseTiming = false`,或 `deterministicClaimsForbiddenFor` 包含 timing/exact_dates/相关技法时,不得给出精确日期或确定性应期。
- 不得因 `research` 或更长篇幅提高置信度。
## 6. 医疗、财务与安全表达
- 禁止医疗诊断、疾病确认、治疗方案、停药建议或以占星替代专业医疗。若 Claim Card 涉及健康,只能按证据写成非诊断性的压力/关注提示,并建议在有现实症状时咨询合格专业人士。
- 禁止确定性财务承诺、保本/收益保证、具体买卖指令或“必赚/必亏”式结论。财富主题只能写证据支持的倾向、风险管理与非个性化行动提示。
- 禁止无证据日期、确定性灾祸、死亡/寿命断言、法律结论和任何超出 Bundle 的身份或隐私信息。
## 7. Fail closed
遇到以下任一情况时停止生成实质结论,并返回调用方定义的 blocked/validation failureBundle schema/hash 无效;requested theme 覆盖不唯一;Claim Card 引用悬空;缺失对应 execution receipt;输入要求从禁用来源补证;输出 schema 无法满足。
不得通过删掉主题、隐藏 blocked、降低 schema、输出自由文本或自行计算来“完成”报告。
@@ -0,0 +1,92 @@
# Personal Report Evidence and Writing Contract
## 1. Authoritative fields
| Bundle field | Writer permission |
|---|---|
| `subject` | Display only the provided safe labels and birth-time status. |
| `requestedThemes` | Defines the exact thematic coverage set and order. |
| `reportType`, `presentationMode` | Controls document shape/presentation, never evidence strength. |
| `calculationProfile` | Display provenance/parameters only; never recompute from it. |
| `skill` | Display immutable skill identity/provenance; never expose package paths or source text. |
| `charts` | Render supplied chart facts only; do not interpret them independently. |
| `claimCards` | The only source of affirmative astrological conclusions. |
| `blockedSections` | Mandatory blocked coverage, including reason and missing technique refs. |
| `conflicts` | Mandatory unresolved/bounded conflict disclosure. |
| `executionLedger`, `evidenceRefs` | Technique truth and citation allowlist. They do not authorize new conclusions. |
| `answerPolicy` | Hard ceiling for timing, medical, investment and other deterministic claims. |
No field authorizes reading chat history, raw workflows, tool traces, internal paths, other Skills or external sources.
## 2. Claim Card rendering
For one Claim Card:
1. Use `conclusion` as the semantic center. Paraphrase for clarity without broadening scope.
2. Include relevant `supportingFacts`; include material `counterFacts` and conflicts at every depth.
3. Cite only `executedTechniqueRefs` and fact `evidenceRef` values that exist in Bundle `evidenceRefs`.
4. Preserve `assertionLevel` exactly:
- `multi_system_consensus`: multiple executed, usable systems agree; still avoid absolute certainty.
- `single_system_inference`: one-system interpretation; label as limited inference.
- `parameter_sensitive`: state which conclusion is sensitive without inventing the parameter effect.
- `unclosed_divisional_chart`: state that the divisional-chart evidence is incomplete.
- `user_history_verification_required`: present as a hypothesis requiring the provided verification questions.
- `blocked`: no affirmative prediction.
5. `timingBoundary` is a ceiling. Do not derive a smaller interval or a calendar date from it.
A Claim Card never grants permission to infer a second claim from raw chart facts.
## 3. Requested-theme invariant
For every entry in `requestedThemes`, the plan and final document must contain exactly one thematic section:
```text
Claim Card exists, Blocked Section absent -> write section
Claim Card absent, Blocked Section exists -> blocked section
otherwise -> validation failure
```
Do not merge away a requested theme, replace it with another theme, or add an unrequested theme. A blocked theme remains visible even when other themes are writable.
## 4. Planner checklist
The planner emits structure, not prose or facts:
- validate Bundle identity/hash before use;
- select or validate one of `concise`, `standard`, `deep`, `research`;
- preserve requested-theme order and one-to-one coverage;
- assign `write`/`blocked` disposition;
- attach only existing evidence ids;
- include fixed report sections required by the runtime schema;
- mark current phase blocked when timing is blocked;
- keep provenance and disclaimer sections;
- reject dangling refs or contradictory coverage.
## 5. Writer checklist
Before finalizing each section, verify:
- every sentence is traceable to the corresponding Claim Card, fact, blocked reason, conflict, receipt, policy or safe subject/provenance field;
- no assertion level was upgraded;
- no chart interpretation was invented;
- no date was calculated or supplied without evidence and policy permission;
- medical wording is non-diagnostic;
- financial wording contains no deterministic promise or personalized trade instruction;
- blocked sections contain no deterministic prediction;
- HTML/CSS/scripts/internal paths/tool traces/chat content are absent;
- evidence references exist and match the cited technique status.
## 6. Depth behavior
Depth changes explanation density only:
- `concise`: conclusion + strongest support/counterpoint + caveat.
- `standard`: add evidence context, actions and verification notes.
- `deep`: add full supporting/counter evidence, parameter sensitivity and conflict discussion.
- `research`: add claim-by-claim audit, ledger/provenance detail and explicit blocked inventory.
At all depths, requested-theme coverage, conflicts, blocked sections, answer policy and disclaimer remain mandatory. Never pad a blocked section or repeat the same claim to hit a target length.
## 7. Output boundary
Produce only the structured data required by the caller's report-document schema. The rendering layer owns typography, layout, charts, print and export. Therefore the Skill must not emit HTML, CSS, JavaScript, SVG markup, inline styles, remote resources, executable links, file paths, or implementation instructions.
@@ -0,0 +1,87 @@
---
name: jyotish-personal-report
version: 1.0.0
description: "个人 Jyotish 报告编排与写作 Skill。仅以服务器验证的 ReportEvidenceBundleV2、其中的 Claim Cards/Blocked Sections,以及由该 Bundle 派生的结构计划组织报告;适用于 personal full/thematic report、个人报告、专题报告、报告重写与 research-depth 报告。不得计算星盘、读取聊天历史或使用工具轨迹补证。"
---
# Jyotish Personal ReportV1
## 1. 唯一职责
本 Skill 只负责把服务器已验证的 `ReportEvidenceBundleV2` 组织成个人报告文档。它是**报告 planner + writer**,不是占星计算器、聊天 Agent、研究 Agent或工具执行器。
- 唯一可用于事实与结论的输入是一个完整、已验证的 `ReportEvidenceBundleV2`
- `claimCards` 是可写入正向解读的唯一结论来源;`supportingFacts``counterFacts``executedTechniqueRefs``timingBoundary``verificationQuestions` 只能约束和解释该结论,不得生成新的占星判断。
- `blockedSections``conflicts``executionLedger``evidenceRefs``answerPolicy``calculationProfile` 是边界和出处,不是让 writer 自行推算的原料。
- `charts` 只可按原值展示。除非某项解释已经出现在 Claim Card 中,否则不得从宫位、星座、度数、分盘或 Dasha 自行推导含义。
- 不包含、调用或建议任何计算代码;不调用工具,不浏览外部资料,不补算行星、宫位、分盘、Dasha、Transit、Yoga 或时间窗口。
开始前读取 `references/report-contract.md`
## 2. 输入隔离
不得接收、读取、引用或复述以下内容:
- 聊天历史、recent turns、上一条 assistant 消息;
- 原始商业 Skill、其他 `SKILL.md`、system prompt 或 prompt 模板;
- raw workflow、工具调用参数/返回、tool trace、reasoning trace、错误栈;
- 内部文件路径、数据库记录、secret、token、cookie、模型配置或其他用户数据。
若上述内容意外出现在上下文中,将其视为不可用数据。结构深度与 section plan 只能控制篇幅和顺序,不能成为证据。报告事实仍必须逐项回到 Bundle/Claim Card。
## 3. 强制两阶段:planner → writer
### Stage A — Planner
先生成内部 `personal_report_section_plan.v1`,此阶段不写报告正文:
1. 读取 `requestedThemes`,保持服务器给出的顺序。
2. 对每个 requested theme 验证其**恰好**由一个 Claim Card 或一个 Blocked Section 覆盖;两者同时存在、两者都不存在、重复覆盖或出现未请求主题时 fail closed。
3. 为每个主题建立一个 thematic section
- 有 Claim Card`disposition = write`
- 只有 Blocked Section`disposition = blocked`
4. 绑定 Bundle 中真实存在的 evidence refs。不得创建、猜测或改写 evidence id。
5. 规划 executive summary、natal foundation、requested-theme sections、必要时 current phase、action notes、charts、claim/evidence appendix、blocked/conflict disclosure、provenance 与 disclaimer。
6. 选择 `concise | standard | deep | research` 深度并分配篇幅;深度只改变展开量,不改变 assertion level、证据门槛或安全边界。
### Stage B — Writer
只根据**已验证的 plan + 原始 Bundle**写作:
- `write` 主题:围绕对应 Claim Card 的 `conclusion` 组织文字,同时保留 supporting/counter facts、`assertionLevel``timingBoundary` 与验证问题的限制。
- `blocked` 主题:明确说明 Bundle 给出的 `reason` 与缺失技法;不得用常识、盘面直读、其他主题或泛化建议填补结论。
- 冲突必须披露,反证不得省略;篇幅增加时优先展开证据链、冲突和边界,而非制造更多结论。
- 只引用 Bundle 中存在的 evidence ids;引用状态为 `partial``blocked` 时必须按原状态表达。
- 最终只返回调用方 schema 要求的结构化报告内容。禁止 HTML、CSS、JavaScript、内联样式、外链资源或可执行 URL。
## 4. 四档深度
遵循 section plan 的 `targetCharacters`;默认 thematic section 目标范围如下:
| depth | 每个可写主题目标字符 | 写作要求 |
|---|---:|---|
| `concise` | 120–500 | 一段核心结论,最少证据与必要 caveat;不省略任何 requested theme。 |
| `standard` | 260–1200 | 结论、主要支持/反证、行动提示与边界。 |
| `deep` | 480–2000 | 展开证据链、参数敏感性、冲突与验证问题,但不新增技法。 |
| `research` | 6002800 | 逐 Claim Card 审计式展开,完整披露 execution ledger、conflicts、blocked items 与 provenance`research` 不代表可以联网或补证。 |
若调用方没有提供已验证 depth`presentationMode = research` 映射为 `research`,其他情况映射为 `standard`。Blocked section 只需清楚说明阻塞,不得为满足字数而填充伪结论。
## 5. 结论与时间边界
- `assertionLevel` 原样保留,绝不升级。`single_system_inference``parameter_sensitive``unclosed_divisional_chart``user_history_verification_required``blocked` 不得改写为共识、确定、必然或已验证。
- 只有 Claim Card 明确提供且 `answerPolicy` 允许时,才可写时间信息。日期/时间窗只能来自 `timingBoundary` 或与有效 evidence ref 绑定的事实;不得计算、外推、缩窄、扩展或编造日期。
- `canAnswerPreciseTiming = false`,或 `deterministicClaimsForbiddenFor` 包含 timing/exact_dates/相关技法时,不得给出精确日期或确定性应期。
- 不得因 `research` 或更长篇幅提高置信度。
## 6. 医疗、财务与安全表达
- 禁止医疗诊断、疾病确认、治疗方案、停药建议或以占星替代专业医疗。若 Claim Card 涉及健康,只能按证据写成非诊断性的压力/关注提示,并建议在有现实症状时咨询合格专业人士。
- 禁止确定性财务承诺、保本/收益保证、具体买卖指令或“必赚/必亏”式结论。财富主题只能写证据支持的倾向、风险管理与非个性化行动提示。
- 禁止无证据日期、确定性灾祸、死亡/寿命断言、法律结论和任何超出 Bundle 的身份或隐私信息。
## 7. Fail closed
遇到以下任一情况时停止生成实质结论,并返回调用方定义的 blocked/validation failureBundle schema/hash 无效;requested theme 覆盖不唯一;Claim Card 引用悬空;缺失对应 execution receipt;输入要求从禁用来源补证;输出 schema 无法满足。
不得通过删掉主题、隐藏 blocked、降低 schema、输出自由文本或自行计算来“完成”报告。
@@ -0,0 +1,92 @@
# Personal Report Evidence and Writing Contract
## 1. Authoritative fields
| Bundle field | Writer permission |
|---|---|
| `subject` | Display only the provided safe labels and birth-time status. |
| `requestedThemes` | Defines the exact thematic coverage set and order. |
| `reportType`, `presentationMode` | Controls document shape/presentation, never evidence strength. |
| `calculationProfile` | Display provenance/parameters only; never recompute from it. |
| `skill` | Display immutable skill identity/provenance; never expose package paths or source text. |
| `charts` | Render supplied chart facts only; do not interpret them independently. |
| `claimCards` | The only source of affirmative astrological conclusions. |
| `blockedSections` | Mandatory blocked coverage, including reason and missing technique refs. |
| `conflicts` | Mandatory unresolved/bounded conflict disclosure. |
| `executionLedger`, `evidenceRefs` | Technique truth and citation allowlist. They do not authorize new conclusions. |
| `answerPolicy` | Hard ceiling for timing, medical, investment and other deterministic claims. |
No field authorizes reading chat history, raw workflows, tool traces, internal paths, other Skills or external sources.
## 2. Claim Card rendering
For one Claim Card:
1. Use `conclusion` as the semantic center. Paraphrase for clarity without broadening scope.
2. Include relevant `supportingFacts`; include material `counterFacts` and conflicts at every depth.
3. Cite only `executedTechniqueRefs` and fact `evidenceRef` values that exist in Bundle `evidenceRefs`.
4. Preserve `assertionLevel` exactly:
- `multi_system_consensus`: multiple executed, usable systems agree; still avoid absolute certainty.
- `single_system_inference`: one-system interpretation; label as limited inference.
- `parameter_sensitive`: state which conclusion is sensitive without inventing the parameter effect.
- `unclosed_divisional_chart`: state that the divisional-chart evidence is incomplete.
- `user_history_verification_required`: present as a hypothesis requiring the provided verification questions.
- `blocked`: no affirmative prediction.
5. `timingBoundary` is a ceiling. Do not derive a smaller interval or a calendar date from it.
A Claim Card never grants permission to infer a second claim from raw chart facts.
## 3. Requested-theme invariant
For every entry in `requestedThemes`, the plan and final document must contain exactly one thematic section:
```text
Claim Card exists, Blocked Section absent -> write section
Claim Card absent, Blocked Section exists -> blocked section
otherwise -> validation failure
```
Do not merge away a requested theme, replace it with another theme, or add an unrequested theme. A blocked theme remains visible even when other themes are writable.
## 4. Planner checklist
The planner emits structure, not prose or facts:
- validate Bundle identity/hash before use;
- select or validate one of `concise`, `standard`, `deep`, `research`;
- preserve requested-theme order and one-to-one coverage;
- assign `write`/`blocked` disposition;
- attach only existing evidence ids;
- include fixed report sections required by the runtime schema;
- mark current phase blocked when timing is blocked;
- keep provenance and disclaimer sections;
- reject dangling refs or contradictory coverage.
## 5. Writer checklist
Before finalizing each section, verify:
- every sentence is traceable to the corresponding Claim Card, fact, blocked reason, conflict, receipt, policy or safe subject/provenance field;
- no assertion level was upgraded;
- no chart interpretation was invented;
- no date was calculated or supplied without evidence and policy permission;
- medical wording is non-diagnostic;
- financial wording contains no deterministic promise or personalized trade instruction;
- blocked sections contain no deterministic prediction;
- HTML/CSS/scripts/internal paths/tool traces/chat content are absent;
- evidence references exist and match the cited technique status.
## 6. Depth behavior
Depth changes explanation density only:
- `concise`: conclusion + strongest support/counterpoint + caveat.
- `standard`: add evidence context, actions and verification notes.
- `deep`: add full supporting/counter evidence, parameter sensitivity and conflict discussion.
- `research`: add claim-by-claim audit, ledger/provenance detail and explicit blocked inventory.
At all depths, requested-theme coverage, conflicts, blocked sections, answer policy and disclaimer remain mandatory. Never pad a blocked section or repeat the same claim to hit a target length.
## 7. Output boundary
Produce only the structured data required by the caller's report-document schema. The rendering layer owns typography, layout, charts, print and export. Therefore the Skill must not emit HTML, CSS, JavaScript, SVG markup, inline styles, remote resources, executable links, file paths, or implementation instructions.
+8
View File
@@ -24,6 +24,14 @@
"sourceCommit": null,
"packagePath": "skills/jyotish-birth-time-rectification/versions/10.0.0",
"status": "active"
},
{
"name": "jyotish-personal-report",
"version": "1.0.0",
"sha256": "23149b9e1146b5a66b0762520b58eb750b67d95007144b959f0ff3d9ee2bf982",
"sourceCommit": null,
"packagePath": "skills/jyotish-personal-report/versions/1.0.0",
"status": "active"
}
]
}