Evidence-Grounded Cross-Tool Prompt Portability Review

Public field comparison

Evidence-Grounded Cross-Tool Prompt Portability Review

Evidence-Grounded Cross-Tool Prompt Portability Review

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.

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 prompt to adapt an important prompt across AI tools while preserving its intent, output contract, safeguards, evidence requirements, and review gates.

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

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

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 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

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

Open General AI, 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.

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 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.

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
cross-tool-evaluation
prompt-engineering
model-adaptation
capability-evidence
acceptance-testing
quality-control
structured-output
human-review

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

Evidence-Grounded Cross-Tool Prompt Portability Review

Evidence-Grounded Cross-Tool Prompt Portability Review

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

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

 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.
 
 ## Inputs
 
 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]
 
 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]
 
 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.
 
 ## Operating boundaries
 
 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.
 
 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.
 
 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.
 
 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.
 
 ## Review method
 
 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.
 
 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.
 
 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.
 
 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
 
 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.
 
 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.
 
 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.
 
 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.
 
 ## Required deliverable
 
 ### 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.
 
 ### 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.
 
 ### 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.
 
 ### 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.
 
 ### 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.
 
 ### 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.
 
 ### 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.
 
 ### 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.
 
 ### 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
 
 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.
 
 ### 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.