Evidence-Grounded Cross-Tool Prompt Portability Review

Public field comparison

Cross-Tool Prompt Portability Review

Evidence-Grounded Cross-Tool Prompt Portability Review

Review a prompt for portability across AI tools and produce model-specific adaptation guidance, quality controls, testing checks, and a reusable master template.

Evaluate a prompt across specified AI tools, identify capability and instruction risks, design tool-specific variants, and define evidence-based portability tests without claiming unexecuted validation.

Use this to adapt a valuable prompt for multiple AI tools without losing intent, structure, constraints, or quality controls.

Use this prompt to adapt an important prompt across AI tools while preserving its intent, output contract, safeguards, evidence requirements, and review gates.

Cross-Tool Prompt Review
Prompt Portability Testing
Model-Specific Prompt Adaptation
Prompt Quality Control
Prompt Template Improvement
AI Workflow Standardization
ChatGPT to Claude Adaptation
Claude to Gemini Adaptation
Perplexity Prompt Adaptation
Prompt Evaluation Matrix

Evidence-based cross-tool prompt review
Tool-specific prompt variant design
Prompt portability risk assessment
Cross-model acceptance-test planning
Reconciliation of prompt test evidence

Original prompt
Target AI tools
Primary use case
Required output format
Known failure modes
Context length needs
Tool-specific strengths
Safety constraints
Evaluation examples
Success criteria
User skill level
Source or citation needs
Workflow environment
Reuse requirements

Original prompt
Target AI tools
Primary use case
Required output contract
Tool capability evidence
Success criteria
Known failure modes
Evaluation cases
Safety and review requirements
Source and citation requirements
Workflow environment
Reuse requirements
Execution evidence

Paste the original prompt, target AI tools, primary use case, required output format, known failure modes, context length needs, tool-specific strengths, safety constraints, evaluation examples, and success criteria. Use the output to adapt the prompt for ChatGPT, Claude, Gemini, Perplexity, Codex, or other AI tools while preserving quality controls.

Open any capable AI assistant. Replace every bracketed variable with the relevant information, and provide the original prompt plus capability documentation, output schemas, evaluation fixtures, prior run outputs, logs, screenshots, and other available evidence. Then run the prompt. If tests are later executed in target tools, return their exact configurations and captured outputs for evidence-based reconciliation.

A consultant wants one research synthesis prompt to work reliably across ChatGPT, Claude, Gemini, and Perplexity without losing source requirements, output structure, verification checks, or human review gates.

A prompt owner needs a research-synthesis workflow to operate across ChatGPT, Claude, Gemini, and Perplexity. They supply the current prompt, citation requirements, structured deliverable, vendor capability documentation, edge-case fixtures, and prior outputs. The review produces a traceable master prompt, tool-specific variants, capability gaps, and a test matrix whose results remain Not run until actual evidence is returned.

Advanced

Advanced

General AI

General AI

evaluation

evaluation

prompt-portability
general-ai
cross-tool
prompt-evaluation
model-adaptation
quality-control
prompt-template
ai-workflows
testing-matrix
prompt-optimization
chatgpt
claude
gemini
perplexity

prompt-portability
cross-tool-evaluation
prompt-engineering
model-adaptation
capability-evidence
acceptance-testing
quality-control
structured-output
human-review

Cross-Tool Prompt Portability Review Prompt

Evidence-Grounded Cross-Tool Prompt Portability Review

Review a prompt for portability across AI tools and create model-specific adaptation guidance, quality controls, testing checks, and a reusable master template.

Adapt and evaluate prompts across AI tools with capability evidence, traceable variants, risk controls, and tests that distinguish drafted from verified work.

Prompt-body line comparison

Removed Added Unchanged context

−You are a prompt engineering specialist focused on cross-tool prompt portability, model-specific adaptation, output quality control, prompt evaluation, workflow consistency, and reusable prompt template design.
−
−Your task is to analyze a prompt and recommend how to adapt it for different AI tools while preserving the original intent, required structure, constraints, quality controls, and expected output.
−
−Context:
−Use the context below. If any important detail is missing, list it under “Missing Inputs” and make a conservative assumption before continuing.
−
−* Original prompt: [Original prompt]
−* Target AI tools: [Target AI tools]
−* Primary use case: [Primary use case]
−* Required output format: [Required output format]
−* Known failure modes: [Known failure modes]
−* Context length needs: [Context length needs]
−* Tool-specific strengths: [Tool-specific strengths]
−* Safety constraints: [Safety constraints]
−* Evaluation examples: [Evaluation examples]
−* Success criteria: [Success criteria]
−* User skill level: [User skill level]
−* Source or citation needs: [Source or citation needs]
−* Workflow environment: [Workflow environment]
−* Reuse requirements: [Reuse requirements]
−
−Important constraints:
−
−* Do not assume all AI tools behave the same way.
−* Do not invent tool capabilities, browsing ability, file handling, citation ability, memory behavior, context limits, image ability, code execution, or external tool access.
−* Separate confirmed tool requirements from assumptions.
−* Preserve the original prompt’s goal, constraints, output format, and quality checks unless there is a clear reason to revise them.
−* Flag instructions that may work well in one tool but fail or weaken in another.
−* Flag prompts that rely too heavily on hidden assumptions, long context, fragile formatting, tool-specific names, unsupported features, or vague success criteria.
−* Include human review gates for public-facing, legal, financial, security, medical, HR, compliance, or other high-impact outputs.
−* Do not make generic recommendations. Tie every adaptation to a target tool, known failure mode, or quality requirement.
−* Keep the final template reusable for future prompt adaptation work.
−
−Task:
−Create a cross-tool prompt portability review that helps the user adapt the original prompt for multiple AI tools while preserving quality.
−
−Output format:
−
−### 1. Prompt Diagnosis
−
−Analyze the original prompt.
−Include:
−
−* Main objective
−* Intended user
−* Required input context
−* Required output format
−* Strong parts of the prompt
−* Weak or fragile parts
−* Hidden assumptions
−* Missing quality controls
−* Known failure modes
−* Reuse risks
+Evaluate the supplied prompt for portability across the named AI tools. Produce adaptations and a testable review package, not unsupported assurances that the prompt works.
 
−### 2. Portability Risks
+## Inputs
 
−Create a table with:
+Blocking prerequisites:
+- Original prompt: [Original prompt]
+- Target AI tools, including product, model, mode, or version when known: [Target AI tools]
+- Primary use case and intended users: [Primary use case]
+- Required deliverable, schema, formatting, and downstream interface requirements: [Required output contract]
+- Evidence for relevant capabilities, limits, enabled features, and access: [Tool capability evidence]
+- Observable acceptance criteria: [Success criteria]
 
−* Risk
−* Why it matters
−* Which tools may be affected
−* Severity
−* Example failure
−* Recommended fix
−* Human review note
+Useful optional context:
+- Known failures, regressions, or fragile behavior: [Known failure modes]
+- Representative normal, edge, adversarial, and high-impact examples: [Evaluation cases]
+- Privacy, safety, compliance, approval, and human-review rules: [Safety and review requirements]
+- Citation, attribution, freshness, and source-quality rules: [Source and citation requirements]
+- Calling interface, files, retrieval, browsing, code execution, orchestration, and downstream workflow: [Workflow environment]
+- Parameterization, maintainability, localization, and reuse needs: [Reuse requirements]
+- Outputs, logs, screenshots, test records, or other evidence from runs already performed: [Execution evidence]
 
−### 3. Tool-Specific Adaptations
+If the original prompt, target tools, primary use case, required output contract, or observable success criteria are missing or materially ambiguous, ask focused clarification questions before producing tool variants. If clarification is unavailable, perform only the portions supported by the inputs, preserve each unknown explicitly, and mark affected conclusions blocked or provisional. Do not silently resolve conflicting requirements.
 
−For each target AI tool, provide:
+## Operating boundaries
 
−* Recommended prompt adjustment
−* Why the adjustment is needed
−* Instructions to keep unchanged
−* Instructions to simplify
−* Instructions to strengthen
−* Formatting guidance
−* Source or citation guidance, if relevant
−* Limitations to warn the user about
+Treat “General AI” as the environment used to inspect the supplied text and evidence, reason about portability, draft variants, and design tests. Use only capabilities actually available in the current session and explicitly supplied evidence. Do not imply access to vendor documentation, model settings, files, browsing, APIs, applications, private data, execution environments, or target tools unless that access is present and observable.
 
−### 4. Output Format Preservation
+Do not run, submit, publish, deploy, approve, or integrate any prompt unless the user separately authorizes that action and the current environment supports it. A generated test matrix is not an executed test. A drafted variant is not implemented. If execution evidence is supplied, evaluate only what that evidence demonstrates and identify gaps in provenance, version, settings, inputs, or reproducibility.
 
−Review whether the required output format is likely to survive across tools.
−Include:
+Never invent model features, context windows, token limits, browsing behavior, citation reliability, memory, file support, multimodal support, code execution, structured-output enforcement, tool calling, privacy terms, or safety behavior. Label capability statements as one of:
+- Confirmed: supported by supplied, attributable evidence.
+- Observed: demonstrated in supplied execution evidence.
+- Assumed: plausible but not established.
+- Unknown: not enough evidence.
+- Conflicting: sources or observations disagree.
 
−* Sections that should remain fixed
−* Sections that may need simplification
−* Tables or lists that need clearer structure
−* Citation or evidence handling
−* Verification checks
−* Final handoff requirements
+For public-facing or legal, medical, financial, employment, security, compliance, privacy-sensitive, or otherwise high-impact outputs, preserve required human review and approval. Recommend redaction or synthetic fixtures when tests could expose secrets, personal data, confidential content, or unsafe instructions. Stop and request guidance if adaptation would remove a mandatory safeguard, violate a required schema, expose protected data, or materially change the prompt’s objective.
 
−### 5. Testing Matrix
+## Review method
 
−Create a prompt testing matrix with:
+1. Normalize the prompt contract.
+Extract the objective, intended user, required inputs, instruction hierarchy, mandatory constraints, output schema, evidence rules, safety controls, review gates, and downstream dependencies. Separate invariant requirements from preferences and tool-dependent mechanisms. Identify contradictions, vague terms, hidden assumptions, prompt-injection exposure, context dependencies, fragile delimiters, and requirements that cannot be objectively checked.
 
−* Test case
−* Tool to test
−* Input example
−* Expected output behavior
−* Failure signal
−* Pass criteria
−* Suggested improvement if it fails
+2. Build a capability-to-requirement map.
+For every target tool, map each material prompt requirement to confirmed, observed, assumed, unknown, conflicting, or unsupported capability evidence. Distinguish the AI product from a specific model, mode, account tier, integration, or enabled feature. Do not generalize observations from one configuration to another.
 
−### 6. Recommended Master Template
+3. Diagnose portability risks.
+Assess risks involving instruction hierarchy, context truncation, structured-output adherence, delimiter handling, file and image ingestion, retrieval or browsing, citation provenance, tool calls, code execution, memory, parameter support, refusal behavior, nondeterminism, data handling, and workflow integration when relevant. Connect every risk to a requirement, target tool, plausible failure signal, and mitigation.
 
−Create a cleaned-up master version of the prompt that can be adapted across tools.
−Include:
+4. Decide the adaptation strategy.
+For each tool, classify the prompt as:
+- Portable as written
+- Portable with wrapper changes
+- Portable with substantive adaptation
+- Requires workflow redesign
+- Blocked pending capability evidence or clarification
 
−* Role
−* Task
−* Context placeholders
−* Constraints
−* Output format
−* Verification checklist
−* Final instruction to begin
+Preserve invariants unless the user authorizes a changed contract. Prefer explicit input boundaries, stable section names, schema definitions, validation instructions, and staged processing over vendor-specific slogans. Explain trade-offs such as strict formatting versus reasoning flexibility, comprehensive context versus truncation risk, and source breadth versus citation reliability.
 
−### 7. Tool-Specific Prompt Variants
+5. Draft the portable artifacts.
+Create one vendor-neutral master prompt and a variant for each target tool. Do not add a generic persona or headings named Role or Task. Keep shared invariants traceable across variants. Isolate tool-specific instructions so they can be updated without rewriting the entire prompt. Where a requested feature is unsupported or unknown, provide a safe fallback or mark the variant blocked rather than pretending equivalence.
 
−Create short adaptation notes or prompt variants for each target tool.
−For each variant, include:
+6. Design verification.
+Create tests that cover a representative baseline, missing input, conflicting instructions, long context, required structure, source handling, known failures, safety boundaries, and relevant edge cases. Each test must define the fixture, configuration, expected observable behavior, prohibited behavior, pass criteria, evidence to retain, and remediation path. Do not fabricate actual observations.
 
−* Tool name
−* What to change
−* What to keep
−* Special instruction to add
−* Limitation to mention
+7. Reconcile available execution evidence.
+When execution evidence exists, record the exact tool or model, mode or version if known, settings, input fixture, date if supplied, actual observation, and evidence reference. Compare actual observations with expected behavior. Mark a test Passed, Failed, Inconclusive, or Not run. Use Passed only when retained evidence satisfies every stated pass criterion; otherwise preserve the unresolved state.
 
−### 8. Quality Control Checklist
+## Required deliverable
 
−Create a checklist for:
+### 1. Input and Evidence Ledger
+Provide a table with: item, supplied value, source or evidence reference, evidence status, conflict or limitation, and effect on confidence. Follow it with blocking questions, non-blocking unknowns, and bounded assumptions.
 
−* Intent preservation
−* Input completeness
−* Output structure
−* Constraint compliance
−* Citation or evidence handling
−* Safety and review gates
−* Tool capability fit
−* Reusability
−* Evaluation readiness
+### 2. Normalized Prompt Contract
+Document: objective, intended user, required inputs, invariant instructions, preferred instructions, output schema, evidence and citation rules, safety controls, human approval gates, downstream dependencies, and measurable acceptance criteria. Identify contradictions requiring owner decisions.
 
−### 9. Final Recommendation
+### 3. Capability-to-Requirement Matrix
+For every target tool, provide: requirement, relevant capability, evidence status, evidence reference, configuration scope, compatibility assessment, fallback, and confirmation needed. Keep unsupported, unknown, and conflicting capabilities visibly distinct.
 
−Provide:
+### 4. Portability Risk Register
+Provide: risk ID, affected requirement, affected tools, trigger, example failure signal, likelihood, impact, priority, mitigation, residual risk, human-review need, and owner decision. Prioritize contract-breaking and high-impact risks over cosmetic differences.
 
−* Whether the prompt is portable as-is
−* What must be changed before reuse
−* Which tool is likely to perform best and why
−* Which tool needs the most adaptation
−* Testing priority
−* Human review needs
−* Final implementation notes
+### 5. Adaptation Decisions by Tool
+For each target tool, state the portability classification and confidence. List what remains invariant, what changes, why it changes, what must be simplified or strengthened, formatting and citation guidance, workflow dependencies, capability warnings, safeguards, and unresolved decisions. Tie each change to the contract, evidence, or a named risk.
 
−### 10. Missing Inputs and Assumptions
+### 6. Vendor-Neutral Master Prompt
+Produce a complete reusable prompt containing explicit input boundaries, invariant requirements, output contract, evidence rules, missing-input behavior, safety and approval gates, and a final verification pass. Do not claim the template has been validated unless supported by execution evidence.
 
−List:
+### 7. Tool-Specific Variants
+Provide a complete usable variant for each target tool, not merely generic advice. Precede each variant with a change log containing: linked master section, change, reason, evidence status, risk addressed, and consequence. Preserve traceability to the normalized contract.
 
−* Missing inputs
−* Assumptions made
−* Tool limitations that need confirmation
−* Tests the user should run manually
−* Risks that remain after adaptation
+### 8. Portability Test Matrix
+Provide: test ID, requirement or risk covered, tool and configuration, input fixture, expected observation, prohibited observation, pass criteria, evidence to capture, execution status, actual observation, result, and remediation. Use Not run when no execution occurred and Inconclusive when evidence cannot establish a result.
 
−Verification:
−Before finalizing, confirm that:
+### 9. Acceptance and Handoff
+Report acceptance criterion, supporting test IDs, expected result, actual supported result, status, evidence reference, and gap. Then state separately:
+- What is drafted
+- What was actually executed
+- What is verified by retained evidence
+- What remains unverified or blocked
+- Required owner decisions
+- Recommended testing order
+- Human review or approval required before operational use
 
−* The original prompt’s purpose is preserved.
−* Adaptations do not rely on capabilities a target tool does not have.
−* Tool-specific limitations are clearly stated.
−* Known failure modes are addressed.
−* The testing matrix is practical.
−* The recommended master template is reusable.
−* Any high-impact use case includes human review guidance.
+Do not name a “best” tool without criteria and evidence. If evidence is insufficient, provide a conditional recommendation based on explicit requirements and identify the tests needed to decide.
 
−Begin now. If required context is missing, state the missing inputs first, then continue with conservative assumptions.
+### 10. Integrity Check
+Before finalizing, confirm that the objective and invariant contract remain traceable across all variants; no capability is asserted without a status; every adaptation addresses a requirement or risk; every test has observable criteria; sensitive fixtures are protected; and drafted, executed, verified, approved, and deployed states remain distinct. Correct discrepancies you can resolve from supplied evidence and list all others as unresolved.