Conciseness

The body is efficient and assumes Claude's competence — no concept explanations, just directives, commands, and code. Minor trimmable redundancy holds it below the 'every token earns its place' anchor: the "cd -- '<working_dir>' || { echo \"BLOCKED…\"; exit 1; }" guard repeats verbatim in every bash block, and hard rules (MSAL-only, no package installs, default table) are restated across sections 2, 2a, and 5. It is well above the 3 anchor, which requires genuinely unnecessary explanation.

Actionability

Fully executable throughout: exact bash verification commands with expected outputs ("One row returned: capture LogicalName", "Empty value: []"), the precise default table "msdyn_locationrecords" and nine named msdyn_* columns, and a complete copy-paste TypeScript wrapper with error classification. Specific usage example covers the common case; nothing is pseudocode.

Workflow Clarity

Steps 1, 2, 2a, 3, 4, 5 are clearly sequenced with explicit validation checkpoints at every stage — package presence, table existence, column existence, artifact compatibility, then "npx --no-install tsc --noEmit". Each check has explicit failure handling ("BLOCKED (target table missing)", "UNVERIFIED (target table not checked)") with recovery direction, and Step 5 adds a final recheck of the full contract before reporting READY. This matches the feedback-loop anchor, not merely the 'most checkpoints present' 4 anchor.

Progressive Disclosure

Good structure: clearly signaled one-level-deep markdown links to shared-instructions.md and native-artifact-compatibility.md (with step anchors), plus referenced scripts (resolve-environment.js, dataverse-request.js). The ~100-line inline wrapper is the deliverable artifact itself, so inlining is appropriate, but it plus the detailed step-by-step verification prose make the body heavier than a lean overview, and some step text overlaps the shared compatibility contract — minor organization gaps versus the 'easy navigation, content appropriately split' 5 anchor.

Specificity

The description lists several concrete capabilities — "native background GPS tracking with durable storage and Dataverse sync using @microsoft/power-apps-native-bglocation" — naming the exact package and three specific functions. It stops short of comprehensive coverage (no mention of the wrapper, table verification, or permission handling), matching the 'several specific actions; minor gaps' anchor rather than the fully comprehensive anchor above.

Completeness

It explicitly answers both questions: what it does ("native background GPS tracking with durable storage and Dataverse sync") and when it applies ("Internal implementation skill invoked by /add-native"). The 'when' is a concrete, explicit trigger equivalent to a 'Use when' clause, matching the 5 anchor; it is not merely implied as in the 4 anchor.

Trigger Term Quality

Good natural keyword coverage: "background GPS tracking", "Dataverse", "durable storage", the parent command "/add-native", and the full package name. A few natural synonyms users would say are missing (e.g., "location tracking", "geolocation"), so it fits the 'good coverage; a few natural terms missing' anchor rather than the comprehensive synonym coverage of 5 or the sparse keyword sets of 3.

Distinctiveness Conflict Risk

It carves a clear niche — background GPS tracking gated behind a specific parent command and a named package — minimizing overlap with sibling skills like a foreground location read. The 4 anchor's 'minor overlap risk' would apply if the background/continuous scope were not stated, but it is.