Conciseness

The body is dense and assumes competence — no generic explanations of tests, git, or coverage — and almost every paragraph carries tool-specific knowledge (level thresholds like 0.7125, matchedBy semantics, readyToPort ordering). A few sentences carry heavy parenthetical loads (e.g. the JSON schema enumeration in the Measure section) that could be tightened, keeping it just below the leanest anchor.

Actionability

Concrete, copy-paste commands appear throughout (semantic-download, the compare invocation with --ignore globs, the JSON report run, a .gitignore block) alongside a full sample report and per-step instructions. The coverage-map construction — a core step — is described procedurally rather than with an executable example, which is the main gap versus the fully-executable anchor.

Workflow Clarity

The two-phase workflow is explicitly sequenced (coverage map → port tests → port code) with validation checkpoints and feedback loops at every turn: run ported tests and fix the port not the test, run coverage to confirm tests reach the new function, rerun the comparison to confirm the function left unmatched and its pair level, and rerun before each batch since the source may change. Progress reporting to the user is specified with a concrete format.

Progressive Disclosure

A single-file skill (~195 lines) with no bundle files; it is well-sectioned with clearly signaled one-level-deep cross-references to sibling skills ([compare-codebases](../compare-codebases/SKILL.md), [jscpd](../jscpd/SKILL.md)) and in-page anchor links. The Options, Reading pairs, and Misses sections are borderline content that could live in separate reference files, which keeps it below the ideal split.

Specificity

The description lists multiple concrete actions — 'Move code from one implementation to another function by function, tests first and code second', 'check two implementations of one app for parity', 'jscpd --compare as the progress measure and a coverage map binding each function to its tests' — covering both workflows comprehensively with the specific mechanism named.

Completeness

It explicitly answers both questions: what it does (move code function by function, tests first; check parity; measure with jscpd --compare and a coverage map) and when to use it ('Use when porting a library or app to another language or framework..., when asked what is left to port, or when comparing the Android and iOS versions of an app'). Third person is used throughout.

Trigger Term Quality

Natural phrases users would say are well covered: 'porting a library or app to another language or framework', 'what is left to port', 'comparing the Android and iOS versions of an app', plus concrete language pairs (Java to Kotlin, JavaScript to Rust, iOS to Android). Common synonyms like 'migrate', 'rewrite', or 'translate' are absent, which keeps it a notch below the comprehensive-synonyms anchor.

Distinctiveness Conflict Risk

The porting/migration niche with jscpd --compare is a clear, distinct trigger set, but 'when comparing the Android and iOS versions of an app' overlaps with a closely related compare-codebases skill, so a small risk of firing for a pure comparison task remains.