Translate agent configuration into checked target-platform files

Why use this

1. A developer moving agent configuration between platforms may discover that instructions, hooks and tool settings do not have exact equivalents. A generated target file can look syntactically plausible while changing behavior or accidentally including credentials.

2. This job could prepare a translation preview and semantic-difference report before any target files are changed. Keeping the source untouched and unsupported features explicit helps the owner evaluate migration scope rather than assume a mechanical conversion preserves everything.

Why an agent / simpler alternative

Useful judgment

Map configuration intent, identify unsupported behavior and distinguish syntax repair from semantic equivalence.

Simpler alternative

Rewrite a small configuration manually when few features need translation.

Unsuitable when

The migration would copy secrets, overwrite unrelated files or treat source recipe permissions as authorization.

Proposed inputs

1. Name

   Selected configuration manifest

   Owner

   Authorized owner

   Minimum scope

   Only approved source files and feature descriptions

   Quality check

   Exclude secrets and unrelated repositories

2. Name

   Target brief

   Owner

   Owner

   Minimum scope

   Selected destination, allowed generated artifacts and preservation rules

   Quality check

   Confirm replacement versus preview scope

Access and setup — proposed or unknown

Proposed minimum

1. Use fictional configuration entries and a proposed target manifest; no real config inspection, migration scripts or file replacement.

Compatibility unknowns

1. Current platform semantics, migration-tool versions, validation support and runtime compatibility are unknown.

External actions requiring approval

1. Reading private configuration, creating/replacing/deleting target files and changing persistent access requires explicit authorization.

Expected deliverable and review checks

Proposed artifact

Migration-plan candidate with source-to-target mapping, unsupported features, proposed validation and protected-file boundaries.

Critical checks

1. Preserve source files; exclude secrets; separate generated from unrelated artifacts; report semantic gaps even if syntax appears valid.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   A source hook has no equivalent trigger

   Why it matters

   The migrated behavior may run at the wrong time

   Proposed response

   Mark it unsupported and request an explicit redesign choice.

2. Signal

   Cleanup targets include a hand-edited file

   Why it matters

   Replacement can destroy intentional work

   Proposed response

   Require file-level review and preserve the original.

Effort and cost — unknown

Setup work

1. Define selected files and target ownership.

Ongoing review

1. Owner reviews semantic differences and later authorized validation evidence.

Unknowns

1. Feature equivalence, validation coverage, migration effort and tool costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent a command, unsupported hook and secret-bearing setting plus a hand-edited target file; draft a migration preview only.

Acceptance checks

1. Exclude the secret; flag semantic/overwrite risks; run no script or target validation.

Stop conditions

1. Stop if file scope, replacement authority or behavior mapping is unclear.

Limits

1. A translation preview cannot establish target compatibility, semantic equivalence or safe persistent-access configuration.