decontextualize-text

Skill: Decontextualize Text

Purpose

Transformcontent that depends on private context, implicit assumptions, or specific environmental detailsintogeneric, reusable wording. Main scenario:Project decontextualization — Prepare a project for handover, open source, or cross-organization use. By removing or replacing specific identifiers (including path strings and file/folder names that appear in the text), the content can be correctly understood in different contexts while protecting organizational privacy.

Core Objective

Primary objective: Generate decontextualized text that preserves the core logic and structure while removing all organizational identifiers and private context.

Success criteria(all requirements must be met):

✅ Replace all sensitive terms: Company names, project code names, internal URLs, personnel names, path strings, and file/folder names with internal context are all identified and replaced with generic equivalents
✅ Preserve core logic: The essence of what is done and why remains unchanged; no functional information is lost
✅ The content is self-contained: The text can be fully understood without the original context; implicit assumptions are made explicit or removed
✅ Preserve structure: Markdown formatting, paragraph structure, logical hierarchy, and functional instructions remain unchanged
✅ No re-identification residue: The output does not contain anything that can re-identify an organization or individual (no unique IDs, internal process numbers, non-public terminology)

Acceptance test: Can a person from a different organization understand and use this content without asking clarifying questions about the original context?

Usage scenarios (use cases)

Project decontextualization: Prepare a project for handover or open source—decontextualize documentation, READMEs, and comments; replace path strings and file/folder names (as they appear in the text) with generic equivalents (e.g. acme-internal/config.yaml → project-root/config.yaml）。
Generalization: Turn lessons learned from a specific project into generic methods or best practices.
Cross-team collaboration: Remove terminology or code names that only one team understands so that others can read the documentation without additional context.
De-identification: Before sharing case studies or blog posts, remove sensitive project names, personnel, and internal addresses.
Release preparation: Final cleanup before externally publishing internal content (e.g., open source, handover).
Documentation synchronization: After forking or merging cross-organization repositories, clean up outdated environment-specific descriptions.

When to use: When you need to eliminate "understanding barriers caused by environmental differences" or "information security boundaries".

Behavior (Behavior)

Principles (Principles)

Preservewhat was doneandwhy。
Removewho、whereandwhich internal conditions。
Replace proper nouns with generic descriptions (e.g., "internal system", "the given workflow").
Make implicit assumptions explicit or discard them.

Interaction Policy

Uncertain Terminology: When you find potentially sensitive or internal terminology (e.g., unclear abbreviations, internal server names),list themand ask the user to confirm before rewriting.
Alternatives: For core logic, provide 2-3 rewrite options at different levels of abstraction for the user to choose from.

Steps

Identify Sensitive Terminology: Scan for company names, project code names, internal URLs, personal names,path stringsandfile/folder namesthat contain internal context (e.g., acme-internal/、team-alpha-output/）。
Extract Core Logic: Determine the essence of the step (e.g., "JIRA approval" → "task status change review").
General Rewrite: Use neutral wording for the identified parts.
Preserve Structure: Preserve the paragraph structure and capability boundaries; do not discard information.

Input & Output

Input

Text containing one or more of the following:
- 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 hold only in a specific environment.

Output

Generic Version: Text with private context removed or replaced.
Preserve Structure: The logical hierarchy, Markdown, and functional instructions must be preserved.
Reusable: The output should be usable without additional context.

Restrictions

Hard Boundaries

No Invention: Do not invent context or functionality that is not in the original content.
No Inference: Do not add unstated facts or conclusions.
No New Semantics: Do not introduce new business meaning.
No Residue: Do not leave behind anything that could re-identify an organization or individual (e.g., unique IDs, internal process numbers, non-public terminology).

Skill Boundaries (Avoid Overlap)

Do not do these (other skills can handle them)：

Documentation Generation: Create a new README or project documentation from scratch → use generate-standard-readme
Content Writing: Write original content or documentation → use writing/documentation skills
Code Refactoring: Change code structure or variable names → use code refactoring techniques
Translation: Convert text between human languages → use translation techniques
Summarization: Compress content while preserving context → use summarization skills (this skill removes context rather than compressing it)

When to Stop and Hand Off：

User asks "Can you generate a README for this?" → Hand off to "Generate Standard README"
User asks "Can you write documentation?" → Hand off to Documentation Writing Techniques
User provides decontextualized code → Focus only on comments and strings; propose code refactoring techniques for identifiers in the code structure
Content is already generic → No decontextualization needed; confirm with the user and finish

Self-Check

Core Success Criteria (all criteria must be met)

All sensitive terms have been replaced: Company names, project code names, internal URLs, personnel names, path strings, and file/folder names with internal context have all been identified and replaced with generic equivalents
Preserve core logic: The essence of what is done and why remains unchanged; no functional information is lost
Content can be understood independently: The text can be fully understood without the original context; implicit assumptions have been made explicit or removed
Preserve structure: Markdown formatting, paragraph structure, logical hierarchy, and functional instructions remain unchanged
No re-identification residue: The output does not contain anything that could re-identify an organization or individual (no unique IDs, internal process numbers, non-public terminology)

Process Quality Check

Confirm uncertain terms: When potentially sensitive or internal terms are found (unclear abbreviations, internal server names), do I list them and ask the user to confirm before rewriting?
Provided alternatives: For core logic rewrites, do I provide 2-3 rewrite options at different levels of abstraction for the user to choose from?
No invention: Do I avoid inventing context or functionality that was not in the original content?
No inference: Do I avoid adding facts or conclusions not stated in the original text?

Acceptance Test

Can people from different organizations understand and use this content without asking clarifying questions about the original context?

If no: Decontextualization is incomplete. Check for remaining context dependencies or unclear generic terms.

If yes: Decontextualization is complete.

Examples

Example 1: Internal process → Generic

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

Example 2: System and API → Neutral

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

Example 3: Team-specific rules → Summary

Original	Decontextualized
According to Kiro team policy, Python must pass "pylint" with a score ≥ 9.0 before it can be merged into "master".	According to the code quality policy, the code should pass static checks (e.g., "pylint") and meet the required threshold before being merged into the main branch.

Example 4: Paths and file/folder names in documentation

Original	Out of context
The configuration is located in "acme-internal/settings.yaml". Output goes into "team-alpha/output/".	The configuration is located in "project-root/settings.yaml" (or "config/settings.yaml"). Output goes to "output/".