name: exclude-prompt-data
description: 'Ensures AI output contains only the result, not the prompt. Use when writing code, documentation, or content where prompt instructions, rationale, or meta-commentary must not leak into the output. Applies to all file types to prevent phrases like "as requested", "per the prompt", or change announcements from appearing in generated content.'

Exclude Prompt Data

When a prompt contains instructional or contextual data used to guide a change,
that data must not appear in the file being updated. The output must reflect
only the result of the instruction — not the instruction itself, the
reasoning behind it, or any acknowledgment that it was applied.

When to Use This Skill

• Writing code, documentation, or any file content from a prompt
• Generating output that should appear production-ready and self-contained
• Any situation where prompt leakage would compromise output quality

Core Rule

Never echo prompt content into the file being changed.

Only write the outcome. Strip any meta-commentary, rationale, or framing that

originated in the prompt.

What Counts as Prompt Data

Prompt data is any content the user provides as instruction or context rather
than as intended file content:

• Descriptions of what to add or change ("add a --verbose flag that...")
• Inline rationale or motivation ("because the old behavior caused...")
• References to the prompt itself ("as requested", "per the prompt",

"the new feature has been added as")

• Meta-commentary about the update

("This section has been updated to reflect...")

• Code comments that narrate a change rather than describe the code

("// Added email validation as requested",
"// Now validates the input per the new requirement")

• Structural scaffold labels used as section markers or template slots

(the word this in ## this Title is scaffolding, not heading text)

What Belongs in the Output

The output file should contain only:

• The feature, fix, or content the prompt requested — written as if it always

belonged there

• Documentation or code that a reader would find useful independent of how the

change was requested

• Generic, cliche placeholder data in examples (e.g., Jane Doe,

jane.doe@example.com, Acme Corp, example.com) — never real names,
emails, domains, or organization identifiers pulled from the prompt or local
configuration

• Language formatting applied to terms in the prompt carries through to the

output — if the prompt wraps a term in backticks or uses a specific syntax
convention, follow that same convention in the output

Output Quality

The prompt's writing quality does not set the bar for the output. Regardless
of how a prompt is phrased, the result must be polished and production-ready:

• Correct grammar, capitalization, and punctuation throughout
• No draft-quality prose or casually written sections
• Informal or sloppy phrasing in the prompt must not carry into the output

Use Cases

Adding a Feature Flag to Documentation

Prompt

Update file.ext with new feature --new-opt <argument>, documenting the new
feature in features.md

Acceptable result — features.md

### --new-opt

Enables extended output. Requires a value argument. Example:

    ```bash
    file --new-opt foo

**Unacceptable result — `features.md`**

```text
### --new-opt

The new feature `--new-opt` requiring an argument has now been added as
requested. The feature is documented as such.

Enables extended output. Requires a value argument. Example:

    ```bash
    file --new-opt foo

The unacceptable version echoes the prompt's framing
(`"has now been added as requested"`, `"The feature is documented as such"`).
That language belongs in the prompt, not the file.

---

### Updating a Code File

**Prompt**

```text
Add input validation to the createUser function — email must be a valid format.

Acceptable result

function createUser(name, email) {
  // Rejects addresses missing a local part, @ sign, or domain
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    throw new Error('Invalid email address.');
  }
  // ...
}

Unacceptable result

// Added email validation as requested in the prompt
function createUser(name, email) {
  // Per the instruction, we now validate that email must be a valid format
  if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
    throw new Error('Invalid email address.');
  }
  // ...
}

The unacceptable version leaks prompt phrasing into code comments. Code
comments and documentation updates are appropriate and encouraged — they should
describe what the code does, its constraints, or its intent. What they must
never do is narrate the change, reference the prompt, or report back as if
responding to the user who requested it.

Exceptions

A small number of cases legitimately require prompt content to appear in the
file. Treat these as exceptions, not loopholes:

• Verbatim transcription requested. The user explicitly asks for prompt

text to be inserted as-is (e.g., "paste this block into the README under
## Notice"). Insert exactly what was requested and nothing more.

• **The file is a prompt or instruction artifact.** When editing prompt

files, skill definitions, or instruction files, instructional content is the
intended payload. The rule still applies one level up: do not add
meta-commentary about this edit into those files.

• Changelog or release-note entries. A short, factual line describing the

change is appropriate. Keep it about the change, not about the request
(Added --verbose flag / Added --verbose flag as requested by user).

Self-Check Before Saving

Before committing an edit produced from a prompt, scan the diff for any of the
following and remove what you find:

• [ ] Phrases like "as requested", "per the prompt", "per your instruction",

"as you asked"

• [ ] Sentences that announce a change rather than describe the subject

("This section now covers...", "Updated to include...")

• [ ] Comments that explain why code was written instead of what it does
• [ ] Verbatim restatement of the user's request inside the file
• [ ] Acknowledgments of the prompt's existence at all

If any of these appear, rewrite the affected section so a fresh reader — with
no knowledge of the prompt — would find the content natural and self-contained.

Troubleshooting

| Symptom | Fix |
|---|---|
| Output contains "as requested" or "per the prompt" | Remove it |
| Docs announce a change instead of documenting it | Rewrite directly |
| Code comments narrate the change | Describe the code's behavior |
| Prompt scaffold labels appear in output headings | Replace with original |

Summary

Write the result, not the story of how you got there. A reader of the
output file should see clean, useful content — with no trace of the prompt
that produced it.