ide-bootstrapper

name	ide-bootstrapper
description	MANDATORY: Invoke this skill when adding support for a BRAND NEW AI IDE (e.g., VS Code Copilot, Windsurf) to the agent.files repository. It automates the creation of IDE-specific Host Shells by translating universal _core philosophies into the new IDE's dialect.
disable-model-invocation	true

IDE Bootstrapper: Cross-Platform Expansion Protocol

SCOPE CONSTRAINT (CRITICAL): You have been invoked to bootstrap a new IDE target within the agent.files architecture. Before proceeding, you MUST internalize the underlying architecture of this repository. If you do not understand the Directory Paradigm, the Lexical Ban, and the <!-- @import --> macro compilation system, you will break the compiler pipeline.

---

1. The Architectural Foundation (The AUPC Paradigm)

This project uses a custom Zig compiler (agentc) to generate system prompts and commands for multiple AI IDEs from a Single Source of Truth (_core/).

A. The Universal Source (_core/)

• Purpose: Abstract software engineering philosophies, shared skills, and shared command logic.
• The Goal-Oriented Philosophy (Lexical Ban): Files in _core/ MUST NEVER contain IDE-specific mechanics (e.g., glob, grep, Task tool, YAML frontmatter, .mdc). Instead of micromanaging tools (e.g., "Use the bash tool to run X"), core macros must state the goal (e.g., "Run X").
• Built-in Subagent Awareness: Acknowledge that modern IDEs automatically route to built-in subagents (like Explore/Bash/Browser). Core macros must not explicitly orchestrate them.

B. The Host Shells (The Target IDE Directories)

• Purpose: The physical adapters. They contain the YAML frontmatter, JSON configurations, tool permissions, and routing mechanics unique to that IDE.
• Macro Injection: These files assemble the final prompt by calling <!-- @import _core/... --> tags.

C. The Compiled Output (dist/)

• NEVER edit files in dist/. They are ephemeral, generated by agentc.

---

2. Pre-Flight Check & Context Acquisition

The user must manually create a new root directory for the target IDE (e.g., windsurf/ or copilot/) and provide the essential blueprints.

A. Strict Blueprint Verification

Before you propose or generate ANY files, you MUST VERIFY the existence of the following items in the target IDE directory:

1. [new-ide]/README.md (Must contain the schema, routing mechanics, and architectural quirks of the new IDE).
2. [new-ide]/.examples/ (Must contain reference templates for how prompts should be formatted).

CRITICAL HALT CONDITION: If you cannot find the README.md or the .examples/ directory inside the user-specified target folder, YOU MUST STOP AND ASK THE HUMAN. Do not hallucinate or guess the structure of the new IDE. State explicitly: "I cannot proceed. Please create [new-ide]/README.md and [new-ide]/.examples/ with the required schema documentation."

B. Analyze the Architectural Paradigm

If the blueprints exist, thoroughly analyze them. You must determine the IDE's core routing paradigm to ensure capability parity:

• Multi-Agent Routing (like OpenCode): Does it require explicit subagent files with strict JSON/YAML permission blocks to prevent execution deadlocks?
• Dual-Engine Routing (like Cursor): Does it separate Contextual Rules (file-scoped via globs) from Isolated Subagents (invoked via slash commands)?
• Monolithic Routing: Does it rely on a single massive system prompt?

---

3. Capability Parity Mapping

You must ensure the new IDE receives the same level of capability as our existing targets (Cursor, OpenCode), mapped perfectly to its native paradigm.

• Agents/Roles: How will you recreate the primary planning, building, verifying, and security-auditing personas in the new IDE?
• Domain Standards: How will you map the _core/3_engineering/ standards so the new IDE applies them automatically to the relevant files?
• Commands: How will you translate interactive slash commands (/refactor, /test) into the new IDE's native format?

---

4. Host Shell Generation & Macro Injection

Draft the new files for the [new-ide]/ directory.

A. Strict Schema Adherence

Follow the exact schema defined in [new-ide]/README.md. If the IDE requires YAML frontmatter, ensure it is perfectly formatted. Do not hallucinate fields that were not defined in the blueprints.

B. The Body (Execution Mechanics)

Write the IDE-specific execution mechanics.

• CRITICAL: If the IDE has read/write permission models (like OpenCode), you MUST ensure prompt instructions perfectly align with the permissions to prevent deadlocks.
• If the IDE requires specific workarounds (like read-before-edit timestamp checks), implement them in the shell, NOT in the _core/ macros.

C. The Soul (Macro Injection)

You MUST append the appropriate <!-- @import _core/... --> macros to these new host shell files to inherit the universal philosophies.

• Anti-Pattern Guard: Never import the same _core/ macro twice within the same execution context (e.g., do not inject testing standards into both a global file and a file-scoped rule simultaneously).

---

5. Execution Workflow (Strict HITL)

DO NOT write any files to the file system yet. You must follow a strict "Propose -> Approve -> Execute" workflow.

1. Output the Expansion Plan: Present a highly structured Markdown plan detailing every directory and file you intend to create within the [new-ide]/ folder.
2. Show the Source Code: For each proposed file, output the exact text you will write, including the specific metadata (YAML/headers) and the <!-- @import --> macros.
3. WAIT: Stop and explicitly ask the user for approval ("Do you approve this IDE expansion plan?") before executing the file creation.

Acknowledge: By reading this skill, your expansion protocols are armed with the latest AUPC architecture standards. If a target directory was provided via command arguments, begin Phase 2 Pre-Flight Check immediately. Otherwise, ask the user for the name of the new IDE directory.