open-data

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Open Data Architect

开放数据架构师

A skill for designing persistence systems where user data outlives any particular application. The governing philosophy: the file system is the database, plain text is the schema, and conventions replace proprietary formats.

这是一项用于设计持久化系统的技能，确保用户数据不依赖于特定应用而长期可用。核心理念：文件系统即数据库，纯文本即模式，用约定替代专有格式。

Instructions

操作指南

Before producing any output, read the relevant reference files:

```
references/principles.md
```
— The 7 non-negotiable futureproof principles
```
references/design-patterns.md
```
— 8 reusable persistence patterns with tradeoffs
```
references/decision-framework.md
```
— Step-by-step architectural decision guide
```
references/obsidian-spec.md
```
— Obsidian data model technical reference

Then choose the appropriate workflow below based on what the user needs.

在生成任何输出之前，请阅读相关参考文件：

```
references/principles.md
```
— 7项不可妥协的未来兼容性原则
```
references/design-patterns.md
```
— 8种可复用的持久化模式及取舍分析
```
references/decision-framework.md
```
— 分步式架构决策指南
```
references/obsidian-spec.md
```
— Obsidian数据模型技术参考

然后根据用户需求选择以下合适的工作流程。

Step 1: Understand the Request

步骤1：理解需求

Determine what the user is asking for:

Designing a new system? → Go to Step 2A
Evaluating an existing system? → Go to Step 2B
Thinking through a specific tradeoff? → Go to Step 2C

Ask clarifying questions if the domain, entity types, or constraints are unclear. Do not assume — the user's domain matters enormously.

确定用户的请求类型：

设计新系统？ → 进入步骤2A
评估现有系统？ → 进入步骤2B
探讨特定取舍问题？ → 进入步骤2C

如果领域、实体类型或约束条件不明确，请提出澄清问题。不要主观假设——用户的业务领域至关重要。

Step 2A: Design a New Persistence Layer

步骤2A：设计新的持久化层

Read

references/design-patterns.md

and

references/decision-framework.md

Ask the user about entity types, expected volumes, creation method, and lifecycle
Walk through the 8 decisions in
```
references/decision-framework.md
```
with the user
Propose a directory structure, naming conventions, and metadata schema
Produce a persistence specification using the template in
```
references/persistence-spec.md
```
Validate every decision against the principles in
```
references/principles.md
```

Expected output: A complete persistence specification document.

阅读

references/design-patterns.md

和

references/decision-framework.md

向用户询问实体类型、预期数据量、创建方式及生命周期
与用户一起完成
```
references/decision-framework.md
```
中的8项决策步骤
提出目录结构、命名约定及元数据模式
使用
```
references/persistence-spec.md
```
中的模板生成持久化规范
根据
```
references/principles.md
```
中的原则验证每一项决策

预期输出：完整的持久化规范文档。

Step 2B: Audit an Existing System

步骤2B：审计现有系统

Read
```
references/auditor-rubric.md
```
for the 60-point scoring criteria
Ask the user to describe their current persistence approach
Score each of the 20 criteria (6 categories) from 0-3
Identify lock-in points, proprietary dependencies, and portability risks
Produce a scored audit report with specific remediation recommendations
If migration is needed, propose incremental steps

Expected output: An audit report with scores, findings, and remediation plan.

阅读
```
references/auditor-rubric.md
```
中的60分评分标准
请用户描述其当前的持久化方案
对20项标准（6个类别）分别进行0-3分的评分
识别锁定风险点、专有依赖项及可移植性风险
生成包含具体整改建议的评分审计报告
若需要迁移，提出渐进式迁移步骤

预期输出：包含评分、发现问题及整改计划的审计报告。

Step 2C: Co-Design a Specific Decision

步骤2C：协同设计特定决策

Read the relevant reference files for the decision area
Propose 2-3 architectural options with explicit tradeoff analysis
Stress-test each option against the principles in
```
references/principles.md
```
Help the user arrive at a decision with clear rationale
Document the decision as an Architecture Decision Record: Context → Decision → Consequences → Alternatives Considered

Expected output: An ADR documenting the decision and reasoning.

阅读与决策领域相关的参考文件
提出2-3种架构方案并明确分析其取舍
根据
```
references/principles.md
```
中的原则对每个方案进行压力测试
协助用户基于清晰的理由做出决策
将决策记录为ADR：背景 → 决策 → 影响 → 备选方案

预期输出：记录决策及推理过程的ADR文档。

Step 3: Validate Output

步骤3：验证输出

Examples

示例

Example 1: Designing a Knowledge Management System

示例1：设计知识管理系统

User says: "I'm building a tool that ingests bookmarks from Twitter, GitHub stars, and Reddit saves into LLM-generated summaries. How should I structure the data?"

Actions:

Read design-patterns.md — identify Patterns 1, 2, 3, 6, 8 as applicable
Walk through entity modeling: bookmark entities with source metadata
Propose hybrid directory structure: by source type + temporal partitioning
Define frontmatter schema with mandatory fields (type, source, created, url)
Produce persistence specification

Result: Complete spec with directory layout, naming conventions, YAML schema, and index strategy — all in plain Markdown files.

用户提问：“我正在构建一个工具，将Twitter书签、GitHub星标和Reddit收藏导入并生成LLM总结。我该如何结构化这些数据？”

操作步骤：

阅读design-patterns.md — 确定模式1、2、3、6、8适用
完成实体建模：带来源元数据的书签实体
提出混合目录结构：按来源类型+时间分区
定义包含必填字段（类型、来源、创建时间、URL）的前置元数据模式
生成持久化规范

结果：包含目录布局、命名约定、YAML模式及索引策略的完整规范——全部采用纯Markdown文件。

Example 2: Auditing a Notion-Based System

示例2：审计基于Notion的系统

User says: "My team uses Notion for everything. How locked in are we?"

Actions:

Read auditor-rubric.md
Score Notion against 20 criteria (typical result: ~18/60, F rating)
Identify critical lock-in: cloud-only, proprietary block model, limited export
Propose migration path: Notion export → Markdown conversion → open vault

Result: Audit report with scores and a step-by-step migration plan.

用户提问：“我的团队所有工作都用Notion。我们的锁定风险有多高？”

操作步骤：

阅读auditor-rubric.md
对照20项标准对Notion进行评分（典型结果：约18/60分，F级）
识别关键锁定点：仅支持云端、专有块模型、导出受限
提出迁移路径：Notion导出 → Markdown转换 → 开放库

结果：包含评分及分步迁移计划的审计报告。

Example 3: Choosing a Link Resolution Strategy

示例3：选择链接解析策略

User says: "Should I use relative paths or shortest-path for internal links?"

Actions:

Read obsidian-spec.md section on link resolution
Present 3 options with tradeoff matrix (shortest path, relative, absolute)
Recommend based on user's context (human-authored vs. machine-generated)
Document as an ADR

Result: Architecture Decision Record with clear rationale.

用户提问：“我应该使用相对路径还是最短路径处理内部链接？”

操作步骤：

阅读obsidian-spec.md中关于链接解析的章节
呈现3种选项及取舍矩阵（最短路径、相对路径、绝对路径）
根据用户场景（人工编写 vs 机器生成）给出推荐
将决策记录为ADR

结果：记录决策及理由的ADR文档。

Troubleshooting

故障排除

Output is too abstract

输出过于抽象

Cause: Not enough domain context from the user. Solution: Ask specific questions — entity types, volumes, creation method, query patterns, team size. The decision framework requires concrete answers.

原因：缺乏足够的用户领域背景信息。解决方案：提出具体问题——实体类型、数据量、创建方式、查询模式、团队规模。决策框架需要具体的答案。

Principles conflict with user constraints

原则与用户约束冲突

Cause: Real-world systems sometimes need pragmatic tradeoffs. Solution: Document the deviation explicitly. State which principle is being relaxed, why, and what the migration cost would be to fix it later.

原因：现实系统有时需要务实的取舍。解决方案：明确记录偏差。说明放宽了哪项原则、原因是什么，以及后续修复的迁移成本。

User wants code, not architecture

用户需要代码而非架构方案

Cause: This skill produces specifications, not implementations. Solution: Produce the spec first, then hand off to appropriate coding tools. The spec serves as the requirements document for implementation.

原因：本技能生成规范，而非实现代码。解决方案：先生成规范，再转交至合适的编码工具。规范可作为实现的需求文档。