decontextualize-text

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill: Decontextualize Text

Skill：文本去上下文处理

Purpose

用途

Turn content that depends on private context, implicit assumptions, or environment-specific details into generic, reusable wording. Primary scenario: project decontextualization — preparing a project for handoff, open-source, or cross-org use. By removing or replacing specific identifiers (including path strings and file/folder names as they appear in text), the content can be understood correctly in different contexts while protecting organizational privacy.

将依赖私有上下文、隐含假设或特定环境细节的内容转换为通用、可复用的表述。主要应用场景：项目去上下文处理——为项目交接、开源或跨组织使用做准备。通过移除或替换特定标识（包括文本中出现的路径字符串及文件/文件夹名称），内容可在不同场景下被正确理解，同时保护组织隐私。

Use Cases

适用场景

Project decontextualization: Prepare a project for handoff or open-source — decontextualize docs, README, comments; replace path strings and file/folder names (as they appear in text) with generic equivalents (e.g.
```
acme-internal/config.yaml
```
→
```
project-root/config.yaml
```
).
Generalization: Turn project-specific lessons into generic methodology or best practices.
Cross-team collaboration: Remove jargon or codenames that only one team understands so others can read the doc without extra context.
De-identification: Before sharing case studies or blog posts, strip sensitive project names, people, and internal addresses.
Release preparation: Final cleanup before publishing internal content externally (e.g. open source, handoff).
Doc sync: After forking or merging cross-org repos, clean up outdated environment-specific descriptions.

When to use: When you need to remove “understanding barriers due to environment differences” or “information security boundaries.”

项目去上下文处理：为项目交接或开源做准备——对文档、README、注释进行去上下文处理；将文本中出现的路径字符串及文件/文件夹名称替换为通用等效表述（例如
```
acme-internal/config.yaml
```
→
```
project-root/config.yaml
```
）。
方法论泛化：将项目特定的经验总结转换为通用方法论或最佳实践。
跨团队协作：移除仅单个团队能理解的行话或代号，让其他团队无需额外上下文即可阅读文档。
身份匿名化：在分享案例研究或博客文章前，剥离敏感的项目名称、人员信息和内部地址。
发布准备：在将内部内容对外发布（如开源、项目交接）前进行最终清理。
文档同步：在跨组织仓库分支合并后，清理过时的特定环境描述。

适用时机：当你需要消除“因环境差异导致的理解障碍”或“信息安全边界限制”时。

Behavior

处理规则

Principles

核心原则

Keep what is done and why.
Remove who, where, and which internal conditions.
Replace proper nouns with generic descriptions (e.g. “internal system”, “a given workflow”).
Make implicit assumptions explicit or drop them.

保留做了什么和为什么做。
移除谁做的、在哪里做的以及哪些内部条件。
用通用描述替代专有名词（例如“内部系统”、“某一工作流”）。
将隐含假设明确化或直接移除。

Interaction policy

交互规则

Uncertain terms: When you spot possibly sensitive or internal terms (e.g. unclear abbreviations, internal server names), list them and ask the user to confirm before rewriting.
Alternatives: For core logic, offer 2–3 rewrite options at different abstraction levels for the user to choose.

不确定术语：当发现可能敏感或内部专属的术语（例如模糊缩写、内部服务器名称）时，列出这些术语并在重写前请求用户确认。
备选方案：对于核心逻辑，提供2-3种不同抽象程度的重写选项供用户选择。

Steps

处理步骤

Identify sensitive terms: Scan for company names, project codenames, internal URLs, people’s names, path strings, and file/folder names that carry internal context (e.g.
```
acme-internal/
```
,
```
team-alpha-output/
```
).
Extract core logic: Identify the essence of the steps (e.g. “JIRA approval” → “task state change review”).
Rewrite generically: Use neutral wording for the identified parts.
Preserve structure: Keep paragraph structure and capability boundaries; do not drop information.

识别敏感术语：扫描公司名称、项目代号、内部URL、人员姓名、路径字符串以及带有内部上下文的文件/文件夹名称（例如
```
acme-internal/
```
、
```
team-alpha-output/
```
）。
提取核心逻辑：提炼步骤的本质（例如“JIRA审批”→“任务状态变更审核”）。
通用化重写：对识别出的部分使用中性表述。
保留结构：保留段落结构和功能边界，不得遗漏信息。

Input & Output

输入与输出

Input

输入

Text that has one or more of:
- Organization, company, project, or system names.
- Path strings and file/folder names that carry internal context (e.g.
```
acme-internal/config.yaml
```
  ,
```
team-alpha/output/
```
  ).
- Internal conventions, implicit context, or default assumptions.
- Processes or assumptions that only hold in a specific environment.

包含以下任意一种内容的文本：
- 组织、公司、项目或系统名称。
- 带有内部上下文的路径字符串及文件/文件夹名称（例如
```
acme-internal/config.yaml
```
  、
```
team-alpha/output/
```
  ）。
- 内部约定、隐含上下文或默认假设。
- 仅在特定环境下成立的流程或假设。

Output

输出

Generic version: Text with private context removed or replaced.
Structure preserved: Logic hierarchy, Markdown, and functional instructions must be preserved.
Reusable: Output should be usable without extra context.

通用版本：已移除或替换私有上下文的文本。
结构保留：必须保留逻辑层级、Markdown格式和功能性说明。
可复用：输出内容无需额外上下文即可使用。

Restrictions

限制条件

No invention: Do not invent context or capabilities not in the original.
No inference: Do not add facts or conclusions not stated.
No new semantics: Do not introduce new business meaning.
No residue: Do not leave anything that can re-identify an organization or person (e.g. unique IDs, internal process numbers, non-public terms).

禁止虚构：不得添加原文中没有的上下文或功能。
禁止推断：不得添加未明确说明的事实或结论。
禁止新增语义：不得引入新的业务含义。
禁止残留：不得留下任何可重新识别组织或个人的信息（例如唯一ID、内部流程编号、非公开术语）。

Self-Check

自我检查

Standalone: Content is fully understandable without the original context.
Anonymous: Hard to infer which company or project it came from.
Consistent: Core logic and function match the original.
Compliant: Meets de-identification or public-release privacy standards.

独立性：无需原始上下文即可完全理解内容。
匿名性：难以推断内容所属的公司或项目。
一致性：核心逻辑和功能与原文一致。
合规性：符合匿名化或公开发布的隐私标准。

Examples

示例

Example 1: Internal process → generic

Original	Decontextualized
In Acme’s JIRA workflow, when a requirement enters “Tech Review”, run X team’s Checklist, then notify PM Li Si.	When a requirement enters the “Tech Review” stage, run the defined Checklist and notify the relevant product owner.

Example 2: System and API → neutral

Original	Decontextualized
Call gpt-4 via our company LLM Gateway (api.acme.internal), timeout 30s.	Call the model via an LLM API; set a reasonable timeout (e.g. 30s).

Example 3: Team-specific rule → abstract

Original	Decontextualized
Per Kiro team policy, Python must pass `pylint` with score ≥ 9.0 before merging to `master` .	Per code quality policy, code should pass static checks (e.g. `pylint` ) and meet the required threshold before merging to the main branch.

Example 4: Path and file/folder names in docs

Original	Decontextualized
Config is in `acme-internal/settings.yaml` . Output goes to `team-alpha/output/` .	Config is in `project-root/settings.yaml` (or `config/settings.yaml` ). Output goes to `output/` .

示例1：内部流程 → 通用表述

原文	去上下文后
在Acme的JIRA工作流中，当需求进入“技术评审”阶段时，执行X团队的检查清单，然后通知PM李四。	当需求进入“技术评审”阶段时，执行预设的检查清单并通知相关产品负责人。

示例2：系统与API → 中性表述

原文	去上下文后
通过公司LLM网关（api.acme.internal）调用gpt-4，超时时间30秒。	通过LLM API调用模型；设置合理的超时时间（例如30秒）。

示例3：团队特定规则 → 抽象表述

原文	去上下文后
根据Kiro团队政策，Python代码在合并到 `master` 分支前必须通过 `pylint` 检查且得分≥9.0。	根据代码质量政策，代码应通过静态检查（例如 `pylint` ）并达到要求的阈值，才能合并到主分支。

示例4：文档中的路径与文件/文件夹名称

原文	去上下文后
配置文件位于 `acme-internal/settings.yaml` 。输出内容保存到 `team-alpha/output/` 。	配置文件位于 `project-root/settings.yaml` （或 `config/settings.yaml` ）。输出内容保存到 `output/` 。

Appendix: Output contract

附录：输出规范

When this skill produces decontextualized text, it follows this contract:

Element	Requirement
Preserve	What is done and why; logic hierarchy; Markdown structure; functional instructions.
Remove	Who, where, internal conditions; proper nouns → generic descriptions; path strings and file/folder names → generic equivalents.
Interaction	When uncertain terms appear: list them and ask user to confirm before rewriting.
Restrictions	No invention, inference, new semantics, or residue that could re-identify org/person.

当该Skill生成去上下文后的文本时，需遵循以下规范：

元素	要求
保留内容	做了什么和为什么做；逻辑层级；Markdown结构；功能性说明。
移除/替换内容	谁做的、在哪里做的、内部条件；专有名词→通用描述；路径字符串及文件/文件夹名称→通用等效表述。
交互要求	出现不确定术语时：列出术语并在重写前请求用户确认。
限制条件	禁止虚构、推断、新增语义，禁止留下可重新识别组织/个人的残留信息。