integrate-with-yalc

name	integrate-with-yalc
description	Points at the user's existing Claude Code repo, analyses what's already there, and produces a plan for how to make it work alongside YALC without conflicts. Covers workspace layout, skill trigger collisions, context migration, and orchestration examples. Read-only by default — a separate apply step moves files only after the user confirms. Use when someone says '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', or 'I want to use my own skills alongside YALC'.
version	1.0.0

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

User Skill	YALC Skill	Collision Type	Recommended Action
name	name	Hard (identical name)	Keep user's / Keep YALC's / Rename user's to <name>-custom
name	name	Soft (trigger overlap)	Test empirically after integration; rename if wrong skill fires

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:

Item found in user repo	Action	Target in YALC
voice/tone.md	Copy to _preview/ for review + commit	~/.gtm-os/_preview/voice/tone-of-voice.md
icp.yaml	Run icp-import on it	~/.gtm-os/_preview/icp/
templates/outreach.md	Copy to _preview/ for review + commit	~/.gtm-os/_preview/campaign_templates.yaml
src/custom-logic.ts	Leave in user repo	— not a YALC concern
CLAUDE.md rules about X	Leave in user repo CLAUDE.md	— YALC loads both CLAUDE.mds in a multi-root workspace

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/?"

4. Orchestration Examples

List 2–4 real chains derived from actual skill pairs found in step 3D. Format:

"[trigger phrase the user could type]" → Your <user-skill> runs first (does X), then YALC's <yalc-skill> picks up the result (does Y).

Example shape (fill with real pairs):

"Research this prospect, then build me a strategy for reaching them" → Your research-prospect-custom skill enriches the company profile, then YALC's campaign-strategy reads it and proposes angle + copy devices.

If fewer than 2 real pairs exist, say so — don't invent hypothetical ones.

5. What to Leave Alone

Explicit list of things the integration plan does NOT touch:

• Your existing CLAUDE.md — it stays in your repo and coexists with YALC's CLAUDE.md under multi-root workspace.
• Your project rules in .claude/rules/ — they load per-directory and don't conflict with YALC's rules unless you're in the same directory.
• Your git history, .env, or any credentials.
• Any skill in your repo that has no collision — it continues working exactly as before.
• YALC's live ~/.gtm-os/ files — all context migration goes through _preview/ first.

6. Migration Steps

Ordered list of actions needed to complete the integration. Mark each as [auto] (the apply step can do it) or [manual] (user must do it):

1. [manual] Add both repo paths to a shared .code-workspace file (workspace setup)
2. [auto] Rename <user-skill> to <user-skill>-custom (resolve hard conflict)
3. [auto] Copy <file> to ~/.gtm-os/_preview/<target> (context migration)
4. [manual] Run yalc-gtm start --commit-preview after reviewing _preview/
5. [manual] Test ambiguous trigger phrases listed in Skill Conflicts §2

End with:

Next step: reply apply to run the [auto] steps above, or ask me to adjust anything first.

---

Step 5 — Save the plan to disk

PLAN_DATE=$(date +%Y-%m-%d)
PLAN_PATH=~/.gtm-os/integration-plan-${PLAN_DATE}.md

Write the rendered plan (all six sections) as markdown to $PLAN_PATH. Tell the user where it landed.

Step 6 — Wait for apply confirmation

After rendering the plan in chat, wait. Do NOT apply anything yet.

If the user replies apply or "yes, apply the auto steps":

Apply step — run in order:

For each [auto] step:

1. Skill renames: copy the SKILL.md to the new name, confirm with the user before deleting the original:

   cp "<user-repo-path>/.claude/skills/<old-name>/SKILL.md" \
      "<user-repo-path>/.claude/skills/<new-name>/SKILL.md"
   

   Then ask: "OK to remove the old <old-name> directory?"

2. Context migration to _preview/:

   mkdir -p ~/.gtm-os/_preview/<section>/
   cp "<user-repo-path>/<source-file>" ~/.gtm-os/_preview/<section>/<target-file>
   

3. After all copies: tell the user to run yalc-gtm start --commit-preview to promote the previewed context into the live ~/.gtm-os/ files.

4. If ICP/voice content was migrated: offer to chain into icp-import to structure it properly.

Never delete source files without explicit per-file confirmation.

Step 7 — Surface any errors verbatim

If a find or cp fails, print stderr unchanged. Common failure modes:

• No such file or directory — path was mistyped; ask the user to re-confirm.
• Permission denied — the user may need to chmod the directory.

Hard Rules

1. Read-only until explicitly confirmed. Never move, rename, or write files before the user replies apply or equivalent.
2. Collision detection is probabilistic, not deterministic. Never tell the user a collision is "resolved" — always instruct them to test empirically. The table flags risk; it doesn't prove runtime behaviour.
3. Context migration goes through _preview/ only. Never write directly to live ~/.gtm-os/ files.
4. Orchestration examples must be grounded in real skill pairs. If fewer than 2 real pairs exist, say so.
5. Never delete a source file without per-file confirmation, even in the apply step.
6. The "What to Leave Alone" section is mandatory. Users get anxious about integration overwriting their setup — surface the guarantee explicitly every time.