Back to Details

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：设计新的持久化层

  1. Read 
    references/design-patterns.md
    and 
    references/decision-framework.md
  2. Ask the user about entity types, expected volumes, creation method, and lifecycle
  3. Walk through the 8 decisions in 
    references/decision-framework.md
    with the user
  4. Propose a directory structure, naming conventions, and metadata schema
  5. Produce a persistence specification using the template in 
    references/persistence-spec.md
  6. Validate every decision against the principles in 
    references/principles.md
Expected output: A complete persistence specification document.
  1. 阅读
    references/design-patterns.md
    和
    references/decision-framework.md
  2. 向用户询问实体类型、预期数据量、创建方式及生命周期
  3. 与用户一起完成
    references/decision-framework.md
    中的8项决策步骤
  4. 提出目录结构、命名约定及元数据模式
  5. 使用
    references/persistence-spec.md
    中的模板生成持久化规范
  6. 根据
    references/principles.md
    中的原则验证每一项决策
预期输出：完整的持久化规范文档。

Step 2B: Audit an Existing System

步骤2B：审计现有系统

  1. Read 
    references/auditor-rubric.md
    for the 60-point scoring criteria
  2. Ask the user to describe their current persistence approach
  3. Score each of the 20 criteria (6 categories) from 0-3
  4. Identify lock-in points, proprietary dependencies, and portability risks
  5. Produce a scored audit report with specific remediation recommendations
  6. If migration is needed, propose incremental steps
Expected output: An audit report with scores, findings, and remediation plan.
  1. 阅读
    references/auditor-rubric.md
    中的60分评分标准
  2. 请用户描述其当前的持久化方案
  3. 对20项标准（6个类别）分别进行0-3分的评分
  4. 识别锁定风险点、专有依赖项及可移植性风险
  5. 生成包含具体整改建议的评分审计报告
  6. 若需要迁移，提出渐进式迁移步骤
预期输出：包含评分、发现问题及整改计划的审计报告。

Step 2C: Co-Design a Specific Decision

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

  1. Read the relevant reference files for the decision area
  2. Propose 2-3 architectural options with explicit tradeoff analysis
  3. Stress-test each option against the principles in 
    references/principles.md
  4. Help the user arrive at a decision with clear rationale
  5. Document the decision as an Architecture Decision Record: Context → Decision → Consequences → Alternatives Considered
Expected output: An ADR documenting the decision and reasoning.
  1. 阅读与决策领域相关的参考文件
  2. 提出2-3种架构方案并明确分析其取舍
  3. 根据
    references/principles.md
    中的原则对每个方案进行压力测试
  4. 协助用户基于清晰的理由做出决策
  5. 将决策记录为ADR： 背景 → 决策 → 影响 → 备选方案
预期输出：记录决策及推理过程的ADR文档。

Step 3: Validate Output

步骤3：验证输出

Before finalizing any deliverable, verify:
  • Every design decision can answer: "If the app disappears, is the data still usable?"
  • No proprietary binary formats are required for core functionality
  • Derived data (indices, caches) is explicitly marked as regenerable
  • Application config is separated from user content
  • File paths serve as identifiers, not UUIDs or database keys
  • Non-standard syntax degrades gracefully to readable text in other tools
在最终确定任何交付成果之前，需验证以下内容：
  • 每一项设计决策都能回答：“如果应用消失，数据是否仍可使用？”
  • 核心功能不依赖任何专有二进制格式
  • 衍生数据（索引、缓存）被明确标记为可重新生成
  • 应用配置与用户内容分离
  • 文件路径作为标识符，而非UUID或数据库键
  • 非标准语法在其他工具中可优雅降级为可读文本

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:
  1. Read design-patterns.md — identify Patterns 1, 2, 3, 6, 8 as applicable
  2. Walk through entity modeling: bookmark entities with source metadata
  3. Propose hybrid directory structure: by source type + temporal partitioning
  4. Define frontmatter schema with mandatory fields (type, source, created, url)
  5. 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总结。我该如何结构化这些数据？”
操作步骤：
  1. 阅读design-patterns.md — 确定模式1、2、3、6、8适用
  2. 完成实体建模：带来源元数据的书签实体
  3. 提出混合目录结构：按来源类型+时间分区
  4. 定义包含必填字段（类型、来源、创建时间、URL）的前置元数据模式
  5. 生成持久化规范
结果：包含目录布局、命名约定、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:
  1. Read auditor-rubric.md
  2. Score Notion against 20 criteria (typical result: ~18/60, F rating)
  3. Identify critical lock-in: cloud-only, proprietary block model, limited export
  4. Propose migration path: Notion export → Markdown conversion → open vault
Result: Audit report with scores and a step-by-step migration plan.
用户提问：“我的团队所有工作都用Notion。我们的锁定风险有多高？”
操作步骤：
  1. 阅读auditor-rubric.md
  2. 对照20项标准对Notion进行评分（典型结果：约18/60分，F级）
  3. 识别关键锁定点：仅支持云端、专有块模型、导出受限
  4. 提出迁移路径：Notion导出 → Markdown转换 → 开放库
结果：包含评分及分步迁移计划的审计报告。

Example 3: Choosing a Link Resolution Strategy

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

User says: "Should I use relative paths or shortest-path for internal links?"
Actions:
  1. Read obsidian-spec.md section on link resolution
  2. Present 3 options with tradeoff matrix (shortest path, relative, absolute)
  3. Recommend based on user's context (human-authored vs. machine-generated)
  4. Document as an ADR
Result: Architecture Decision Record with clear rationale.
用户提问：“我应该使用相对路径还是最短路径处理内部链接？”
操作步骤：
  1. 阅读obsidian-spec.md中关于链接解析的章节
  2. 呈现3种选项及取舍矩阵（最短路径、相对路径、绝对路径）
  3. 根据用户场景（人工编写 vs 机器生成）给出推荐
  4. 将决策记录为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.
原因：本技能生成规范，而非实现代码。 解决方案：先生成规范，再转交至合适的编码工具。规范可作为实现的需求文档。