Use this skill when the user requests inspection, organization, hygiene management, correction, finishing, or quality checking of artifacts generated during the current work session.
This skill is especially important when artifacts have been created through collaborative work involving iterative prompting, correction instructions, concrete examples, constraints, or a coding style matched to the atmosphere.
Goal
Scrutinize and correct the content of the artifact so that it stands on its own as a final deliverable.
This artifact must not unnecessarily include the following elements:
- The content of the user's prompts
- Conversation history
- Intermediate reasoning processes
- Implementation constraints
- The choice of tools used
- Approaches that were not adopted
- Instructions related to prompt creation
- Scaffolding templates used during the production process
- Concrete examples provided solely for the purpose of conveying intent
- Correction feedback given during the conversation
The final deliverable must maintain an appearance of not having been merely assembled from the conversation, as if it were intentionally designed for the intended target users.
Basic Principles
Treat this conversation not as the content of the artifact, but as the context of the production process.
Before preserving any statement in the artifact, classify it into one of the following categories:
- User-facing content that the artifact's target users truly need
- Production guidelines that should influence the artifact (but do not need to be directly displayed)
- Incidental conversational residue that should be deleted
Only content falling under Category 1 should be directly reflected in the artifact.
For Category 2, reflect it indirectly through structure, expression, scope, preconditions, default values, concrete examples, naming conventions, design choices, and so on.
Delete all content falling under Category 3.
Content to Delete or Rewrite
Look for expressions that unnecessarily include or imply the following content, and delete them or rewrite them into appropriate expressions:
- "Based on your request..."
- "In accordance with your instructions..."
- "We do not use..."
- "This allows you to avoid..."
- "Unlike the previous version..."
- "At the user's request..."
- "This document assumes..."
- "Due to constraints..."
- "Git/Homebrew/CLI/etc. are not used..."
- "This part has been changed to..."
- "In the previous exchanges..."
- "The reason I added this section is..."
- "In order to satisfy the requirements..."
Do not mechanically delete content like this. Retain it appropriately only when the intended readers truly need to know it.
The difference between concrete examples and intent
When a user presents a concrete example to convey their intent, do not transcribe that concrete example directly into the artifact. However, this excludes cases where the artifact itself explicitly requires that concrete example.
Concrete examples obtained from the conversation should generally be treated not as final content but as diagnostic material.
Use concrete examples to infer the following points:
- The desired level of abstraction
- The target audience
- The tone of expression
- The types of information leakage to avoid
- Unnatural expressions that should be removed
- Design constraints that should be taken into consideration
Be careful that concrete examples do not unintentionally become the main content of the artifact.
Constraints are usually invisible
User-facing constraints usually influence the design of the artifact and should not be displayed as explicit disclaimers.
To give a concrete example:
Bad example:
This guide does not use Git, Homebrew, or any other CLI tools.
Good example:
Please share the project folder on Google Drive.
The latter version applies the constraint but does not explicitly display it as a formal rule.
Checklist
When refining an artifact, check the following points:
- Is the content naturally understandable to someone who has never seen that conversation?
- Does it contain sentences explaining why the artifact was created in this format?
- Are there any unnecessary references to tool usage, exclusions, constraints, avoided alternatives, and the like?
- Have example prompts been mistakenly included in the deliverable?
- Are there any parts that look patched together after multiple rounds of feedback?
- Are the style, terminology, and assumptions consistent throughout?
- Are the headings and annotations written for the target audience rather than for the creator?
- Does it contain meta-commentary relevant only to the production process?
- Are disclaimers and cautions included only for readers who truly need them?
- Does the artifact use unified, clear expression?
Revision strategy
Prioritize rewriting over explaining.
Do not add reports about sanitized content unless the user explicitly requests it.
In editing work, preserve the artifact's original purpose, technical accuracy, and the requirements necessary for the user.
Remove residues generated in the production process by converting them into a natural artifact design.
Specific examples:
- Rewrite "avoid using technical jargon" into plain expressions
- Replace "avoid a CLI black box" with concrete and clear procedures
- Convert "use Google Drive instead of Git" into Drive-based workflow procedures
- Explain "for beginners" using pacing, definitions, and concrete examples
- Fix "do not mention X" not as a statement that X is omitted, but by actually omitting X
Output rules
When asked to sanitize an artifact, output the corrected artifact itself.
Do not include comments about the processing content, such as the following, before the artifact:
- "Removed the meta-instructions"
- "Fixed the prompt leakage"
- "The sanitized version is shown below"
Concise labels may be included only when necessary for clarity.
If the user requests both the sanitized artifact and a summary of the changes, write the artifact first, followed by the summary.
Quality standards
A properly sanitized artifact should be intentional, consistent, and naturally resonate with the target audience.
Readers must not be able to infer the history of instructions, internal constraints, conversation content for corrections, etc., unless they are actually included as part of the deliverable.