A MyKit skill · v1.0

/mk:xia.

Extract, compare, port, or adapt a feature from any GitHub repository or local repo path — without dragging the rest of the codebase along with it.

Understandbefore you copy.
Challengebefore you implement.
Adaptdon't transplant.
§ 01 — Modes

Four ways to borrow, one rule: never blindly.

Pick the mode that matches your intent. If intent is ambiguous, xia defaults to --compare before recommending any implementation work.

--compare

Side by side

Architectural diff and trade-off report. No plan, no code — just clarity.

--copy

Transplant

Bring the feature in with the minimum adaptation needed to compile.

--improve

Refactor in flight

Copy, then refactor for the local codebase. Replace anti-patterns on entry.

--port

Idiomatic rewrite

Translate into the local stack's idioms. Behavior preserved, shape redrawn.

§ 02 — Workflow

Six phases. One hard gate.

Recon, map, analyze, challenge, plan, deliver. Phase 4 must complete before Phase 5 — confront the trade-offs before you draw the plan.

01 — RECON

Locate

Pack the source with repomix, read the README, map the local integration surface.

02 — MAP

Dissect

Inventory components. Build a dependency matrix: EXISTS, NEW, CONFLICT.

03 — ANALYZE

Trace why

Walk execution paths, name implicit contracts, mark transaction boundaries.

04 — CHALLENGE

Confront

Five questions, minimum. Source answer, local answer, risk if wrong.

Hard gate
05 — PLAN

Hand off

Delegate to /mk:plan with manifest, matrices, decisions, risk score.

06 — DELIVER

Front door

Xia produces the analysis. Implementation handoff goes to /mk:cook.

Phase 4 · Rule

Do not plan implementation before confronting trade-offs. xia is a front door — not a second orchestration stack.

§ 03 — Challenge framework

Five questions you must answer.

Before any plan is drawn, xia produces five challenge questions and a decision matrix. Each one names a source answer, a local answer, and the risk if the assumption is wrong.

  1. NecessityDoes the project need this feature, or is it scope creep dressed in a pull request?
  2. Simpler alternativeIs there a smaller path — a flag, a config, a 30-line helper — that solves 80% of the same problem?
  3. Existing overlapWhat in the local codebase already solves part of this? What gets deprecated, what stays?
  4. Maintenance burdenWho owns this code in three months? Does the team have the context to debug it cold?
  5. Dependency chainWhat new packages, runtimes, or services come along for the ride? What breaks on update?
Decision matrix · sample
DecisionSourceLocalRecommendation
AuthTheir auth stackExisting authPrefer local
PersistenceTheir schemaExisting schemaAdapt
StreamingSSE + customWebSocketPort idiom
low · 0–2 medium · 3–4 high · 5+
§ 04 — Usage

One line in. A plan out.

Point xia at a GitHub URL, an owner/repo, or a local path. Add a feature hint to narrow scope. Pick a mode, or let intent detection choose.

Syntax /mk:xia <source> [feature] [--compare|--copy|--improve|--port] [--auto|--fast]

Examples # compare two queue implementations
/mk:xia bullmq/bullmq "retry strategy" --compare

# port streaming idiomatically
/mk:xia https://github.com/vercel/ai streaming --port

# skip approval gates, keep workflow
/mk:xia ../sister-repo "webhook signing" --improve --auto

"Xia is a front door, not a second orchestration stack. Keep planning and delivery where they belong."

For

Feature extraction · cross-stack porting · implementation comparison · architectural adaptation.

Not for

Full project cloning · simple file copy · package installation.