Copy prompts that steer AI tools to work with placeholders — so you get useful answers without dumping secrets.
Debug without pasting secrets
When logs contain keys or tokens
I'm debugging an issue. I will describe the system and error using placeholders only.
Context:
- Service: [service_name]
- Environment: [staging|production]
- Error symptom: [what fails]
- Relevant config shape (no real secrets): [e.g. OPENAI_API_KEY=[api_key_openai], DATABASE_URL=postgresql://[db_user]:[db_password]@[host]/db]
Constraints:
- Do not ask me for raw API keys, passwords, tokens, or connection strings.
- Suggest fixes assuming secrets live in env vars / a secret manager.
- Ask clarifying questions that don't require secret values.
Error / stack outline:
[paste redacted stack trace]
Safe code review
Review PRs without leaking credentials
Review the following code for bugs, security issues, and maintainability.
Rules:
- Treat any credential-looking strings as already redacted placeholders.
- Flag if the code appears to hard-code secrets and suggest env-based alternatives.
- Do not invent or request real secret values.
Code:
```
[paste code with secrets already scrubbed]
```
Incident write-up helper
Postmortems / status updates
Help me draft a clear incident summary.
Facts (redacted):
- Start / detect time: [time]
- Impact: [user-facing impact]
- Suspected area: [service / component]
- Mitigations already taken: [list]
- Open questions: [list]
Constraints:
- Keep customer identifiers, tokens, and internal hostnames as placeholders.
- Write for [engineering|customers|executives].
- Include timeline, impact, root-cause hypotheses, and next steps.
Refactor hard-coded secrets
Move secrets out of source
I have code that may hard-code configuration secrets. Help me refactor it to use environment variables / a secret manager.
Goals:
- Identify secret-like values (keys, passwords, tokens, DSNs).
- Propose safe placeholder names (e.g. STRIPE_SECRET_KEY).
- Show the refactored pattern without needing the real values.
Code:
```
[paste code]
```
Support reply without PII dump
Customer emails / tickets
Draft a helpful support reply.
Ticket summary (PII redacted):
- Customer: [customer_name_or_id]
- Product area: [area]
- Issue: [problem]
- What we already checked: [steps]
Constraints:
- Do not include real emails, phone numbers, card data, or full account IDs.
- Keep tone [friendly|formal].
- Ask only for the minimum follow-up info needed.
Architecture advice with placeholders
System design without infra secrets
I need architecture advice. I'll describe components with placeholders only.
System:
- Clients: [web|mobile]
- APIs: [service list]
- Data stores: [db types]
- Third parties: [OpenAI|Stripe|etc] via keys stored in [secret manager]
- Constraints: [latency|compliance|budget]
Please propose an approach and call out security pitfalls around secret handling, logging, and AI tool usage.
Do not ask for production credentials.
Scrub first, then paste
Use the secret scrubber before sending — or install OmniShield to mask automatically at send time.
