Integrate With Yalc

Integrate with YALC

The user has an existing Claude Code repo — their own skills, CLAUDE.md, project rules — and wants to run it alongside YALC without breaking either. This skill reads both sides, flags every conflict, and produces a written integration plan the user can review before anything changes.

Read-only by default. Nothing is moved or written until the user explicitly confirms the apply step.

When This Skill Applies

• "integrate my repo with YALC"
• "I have my own Claude Code setup, how do I add YALC"
• "merge my repo with YALC"
• "how do I bolt YALC onto my existing skills"
• "I want to use my own skills alongside YALC"
• "I already have a .claude/ folder — can I still use YALC?"

NOT this skill (use icp-import instead):

• User just wants to import their ICP/voice/context — no skills to reconcile.

NOT this skill (use yalc-orientation instead):

• User is new to YALC and has no existing repo to integrate.

Inputs

Ask for both in a single message if not provided:

1. Absolute path to your existing repo (e.g. /Users/alice/my-claude-setup) — the root directory where your .claude/ folder lives.
2. One-line description of what your repo does (optional but useful — e.g. "agency operations brain for B2B SaaS GTM").

If the user already provided the path in their message, use it directly. Don't ask for it again.

Procedure

Step 0 — Validate inputs

Confirm the path exists and contains a .claude/ directory:

test -d "<user-repo-path>/.claude" && echo "OK" || echo "MISSING"

If MISSING: tell the user the path doesn't look like a Claude Code repo (no .claude/ folder found) and ask them to double-check.

Step 1 — Read the user repo (read-only)

Collect the following. If any are absent, note it but continue — absence is informative.

a) Directory tree (top two levels):

find "<user-repo-path>" -maxdepth 2 -not -path '*/.git/*' | sort

b) All skill names + descriptions + trigger phrases:

find "<user-repo-path>/.claude/skills" -name "SKILL.md" 2>/dev/null | sort | xargs -I{} sh -c 'echo "=== {} ===" && head -40 {}'

For each SKILL.md, extract:

• name: from frontmatter
• description: from frontmatter
• Lines under "When This Skill Applies" or equivalent trigger-phrase section

c) CLAUDE.md and nested CLAUDE.mds:

find "<user-repo-path>" -name "CLAUDE.md" -not -path '*/.git/*' | xargs cat 2>/dev/null

d) .claude/rules/ if present:

find "<user-repo-path>/.claude/rules" -name "*.md" 2>/dev/null | xargs cat

Step 2 — Read the YALC side

YALC skill registry:

find /Users/ifarahi/Desktop/yalc-internal/.claude/skills -name "SKILL.md" | sort | xargs -I{} sh -c 'echo "=== {} ===" && head -20 {}'

For each YALC skill, extract: name, description, trigger phrases.

Step 3 — Analyse conflicts and opportunities

Build four internal lists before writing the plan:

A. Skill name collisions — user skill name: exactly matches a YALC skill name:. These are hard conflicts: at runtime, whichever skill file Claude Code loads last wins (or both are presented and the model picks). Flag every one.

B. Trigger phrase overlaps — user trigger phrases that share significant keywords with YALC trigger phrases, even if the skill names differ. These are soft collisions: Claude Code routing is model-driven and fuzzy, so overlap creates ambiguity, not a guaranteed winner. Flag as WARN, not ERROR.

C. Context to migrate — user repo content that belongs in ~/.gtm-os/:

• Voice / tone of voice files → ~/.gtm-os/_preview/voice/
• ICP definitions, segment descriptions → ~/.gtm-os/_preview/icp/
• Outreach templates, campaign templates → ~/.gtm-os/_preview/campaign_templates.yaml
• Qualification rules → ~/.gtm-os/_preview/qualification_rules.md

D. Orchestration pairs — identify 2–4 plausible chains where one of the user's skills hands off to a YALC skill (or vice versa). Base these on actual skill descriptions — don't invent fake ones. A valid pair needs a clear data handoff (e.g. "your research-client skill → YALC's campaign-strategy").

Step 4 — Write the integration plan

Render the plan in chat under these six sections, then save it to disk.

1. Workspace Setup (one paragraph)

Recommend one of these layouts based on what you found:

• Recommended: Separate folders, single VS Code workspace. Add both repo paths to a .code-workspace file. YALC's .claude/ and the user's .claude/ stay separate on disk; Claude Code loads both. Skills from each are available in chat. No file moves needed to get started.
• Alternative: User repo as additionalDirectory. If the user repo is purely a context/knowledge base (no skills, no CLAUDE.md rules that would conflict), configure it as additionalDirectory in YALC's ~/.gtm-os/config.yaml. Simpler, but loses the ability to invoke the user repo's own Claude Code skills.

State which layout you recommend and why in one sentence.

2. Skill Conflicts

For each Hard conflict, give a concrete recommendation: which one wins by default and what to rename the other to.

For Soft conflicts: be explicit that Claude Code's routing is model-driven and fuzzy — the table flags likely ambiguity, not guaranteed wrong behaviour. Instruct the user to test by saying the trigger phrase in chat after integration, observe which skill fires, and rename if needed.

If zero conflicts: say so and move on.

3. Context Mapping

Three columns:

Also state explicitly what is not touched:

YALC will not touch: your repo's CLAUDE.md, your existing trigger phrases, your project rules, your .env files, or any code outside ~/.gtm-os/. Integration is additive.

If voice or ICP content is found, offer to chain into icp-import immediately:

"I found what looks like ICP/voice content in your repo. Want me to run icp-import on it now to map it into ~/.gtm-os/_preview/?"