Back to Details

speak-with-dead

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Speak with Dead

Speak with Dead

Extract knowledge from abandoned, deprecated, or legacy systems.
从废弃、过时或遗留系统中提取知识。

What This Skill Does

该技能的作用

This spell is archaeology, not history research. It operates on specific artifacts from a specific dead system to answer specific questions. It is NOT general tech history, NOT interviewing living people, and NOT monitoring live systems. In this grimoire, Speak with Dead is treated as a metaphorical spell with a shipping-now delivery profile. Canonical reference input: Speak with Dead (spell).
此技能属于考古范畴，而非历史研究。它针对特定已停用系统的特定工件来解答特定问题。它不涉及通用技术历史、不采访在世人员，也不监控运行中的系统。 在这本魔法手册中，Speak with Dead被视为一个具备“即刻交付”特性的隐喻式技能。 标准参考输入：Speak with Dead (spell)。

When To Use

使用场景

  • Route to this spell when the user asks to extract knowledge from systems that are dead, abandoned, deprecated, or archived AND the people who built or maintained them are no longer available. The knowledge must be recoverable from existing artifacts (code, commits, docs, configs, databases, state files) rather than from living people or live systems.
  • 当用户请求从已停用、废弃、过时或归档的系统中提取知识，且构建或维护该系统的人员已无法联系时，调用此技能。知识必须可从现有工件（代码、提交记录、文档、配置、数据库、状态文件）中恢复，而非来自在世人员或运行中的系统。

Prerequisites

前提条件

  • No extra runtime dependencies beyond Hermes Agent and the normal toolset for this session.
  • 除了Hermes Agent和本次会话的常规工具集外，无需额外的运行时依赖。

Procedure

操作步骤

  1. Restate the target, the success condition, and any no-touch boundaries before taking action.
  2. Scope the dead system: Name the specific system, confirm it is actually dead/archived, and list the user's concrete questions.
  3. Inventory artifacts: Identify what remains — git history, commit messages, PR descriptions, README files, archived docs, config files, database schemas, state files, packet captures, ADRs. Note what is missing.
  4. Reconstruct from evidence: Trace intent through commit messages, code structure, config values, and data schemas. Separate what the artifacts directly state from what you are inferring.
  5. Return with confidence labels: For each answer, cite the specific artifact (file, commit hash, line, config key) and label it as evidence (directly stated) or inference (reasoned from patterns). Flag any gaps where the trail goes cold.
  6. Package the result as the deliverables below, with confidence, assumptions, and unresolved risk called out explicitly.
  1. 采取行动前，重述目标、成功条件以及任何不可触碰的边界。
  2. 界定目标系统范围：明确具体系统名称，确认其已停用/归档，并列出用户的具体问题。
  3. 清点工件：确定留存的内容——git历史、提交信息、PR描述、README文件、归档文档、配置文件、数据库 schema、状态文件、数据包捕获记录、ADRs。记录缺失的内容。
  4. 从证据中重建：通过提交信息、代码结构、配置值和数据 schema 追溯意图。区分工件直接记录的内容与推导的内容。
  5. 附带置信度标签返回结果：针对每个答案，引用具体工件（文件、提交哈希、行号、配置键），并标记为“证据（直接记录）”或“推导（从模式中推理得出）”。标注任何证据链中断的空白点。
  6. 按照以下交付成果打包结果，明确标注置信度、假设和未解决的风险。

Deliverables

交付成果

  • Answers to specific questions drawn from the dead system's artifacts.
  • A reconstruction of the system's original intent and known failure modes.
  • A clear separation between what the dead system actually recorded and what you are inferring.
  • 从已停用系统工件中提取的特定问题答案。
  • 对系统原始意图和已知故障模式的重建。
  • 清晰区分已停用系统实际记录的内容与推导的内容。

Pitfalls / Guardrails

注意事项/约束

  • Keep the metaphor anchored to a real mechanism instead of drifting into lore.
  • Never fabricate answers the artifacts do not support. Label inferences explicitly.
  • Note if the system may have been archived for security, legal, or compliance reasons — flag this to the user.
  • If artifacts are insufficient to answer the question, say so rather than guessing.
  • Do not use for: General tech history ("history of JavaScript frameworks," "evolution of REST APIs") → route to research/knowledge spells
  • Do not use for: Company lore from living people ("ask the team why we chose Postgres") → route to collaboration/survey spells
  • Do not use for: Live system observation ("what's happening on staging right now") → route to monitoring/observability spells
  • Do not use for: Competitor watching ("monitor their API for changes") → route to monitoring/automation spells
  • Do not use for: Active system debugging ("why is this production service failing") → route to debugging/troubleshooting spells
  • Do not use for: Generic code explanation ("explain what this function does") → route to code-understanding spells
  • 保持隐喻与实际机制绑定，避免偏离到无根据的传说。
  • 绝不要编造工件不支持的答案。明确标注推导内容。
  • 若系统可能因安全、法律或合规原因被归档，需向用户标记此情况。
  • 若工件不足以回答问题，如实告知，切勿猜测。
  • 请勿用于：通用技术历史（如“JavaScript框架的历史”、“REST API的演进”）→ 转至研究/知识类技能
  • 请勿用于：向在世人员了解公司内部信息（如“询问团队为何选择Postgres”）→ 转至协作/调查类技能
  • 请勿用于：运行中系统观测（如“ staging环境现在发生了什么”）→ 转至监控/可观测性类技能
  • 请勿用于：竞品监控（如“监控他们的API变化”）→ 转至监控/自动化类技能
  • 请勿用于：运行中系统调试（如“为什么这个生产服务故障了”）→ 转至调试/故障排查类技能
  • 请勿用于：通用代码解释（如“解释这个函数的作用”）→ 转至代码理解类技能

Verification

验证

  • Check that the result includes every deliverable promised above.
  • Check that confirmed facts, assumptions, and inferences are visibly separated.
  • Check that the metaphor still maps cleanly to a real operational mechanism.
  • 检查结果是否包含上述所有承诺的交付成果。
  • 检查已确认的事实、假设和推导是否清晰区分。
  • 检查隐喻是否仍能清晰映射到实际操作机制。

Example Invocation

调用示例

text
/speak-with-dead interrogate this legacy system and tell me what it knew, what it intended, and where the evidence runs out
text
/speak-with-dead interrogate this legacy system and tell me what it knew, what it intended, and where the evidence runs out