@codenhub/skills 0.0.2

package/src/agents-md-improver/references/update-guidelines.md

@@ -0,0 +1,155 @@
+# AGENTS.md Update Guidelines
+
+## Core Principle
+
+Only add information that will genuinely help future agent sessions. Attention
+and context are limited, so every line must earn its place.
+
+## What TO Add
+
+### 1. Commands or Workflows Discovered
+
+```markdown
+## Build
+
+`npm run build:prod` - Full production build with optimization
+`npm run build:dev` - Fast development build without minification
+```
+
+Why: Saves future sessions from rediscovering these commands.
+
+### 2. Gotchas and Non-Obvious Patterns
+
+```markdown
+## Gotchas
+
+- Tests must run sequentially (`--runInBand`) due to shared DB state
+- `yarn.lock` is authoritative; delete `node_modules` if deps mismatch
+```
+
+Why: Prevents repeated debugging sessions.
+
+### 3. Package Relationships
+
+```markdown
+## Dependencies
+
+The `auth` module depends on `crypto` being initialized first.
+Import order matters in `src/bootstrap.ts`.
+```
+
+Why: Captures architecture knowledge that is not obvious from the code alone.
+
+### 4. Testing Approaches That Worked
+
+```markdown
+## Testing
+
+For API endpoints: Use `supertest` with the helper in `tests/setup.ts`
+Mocking: Factory functions in `tests/factories/` instead of inline mocks
+```
+
+Why: Establishes patterns that are known to work.
+
+### 5. Configuration Quirks
+
+```markdown
+## Config
+
+- `NEXT_PUBLIC_*` variables must be set at build time, not runtime
+- Redis connection requires the `?family=0` suffix for IPv6
+```
+
+Why: Preserves environment-specific knowledge.
+
+## What NOT to Add
+
+### 1. Obvious Code Information
+
+Bad:
+
+```markdown
+The `UserService` class handles user operations.
+```
+
+The class name already tells us this.
+
+### 2. Generic Best Practices
+
+Bad:
+
+```markdown
+Always write tests for new features.
+Use meaningful variable names.
+```
+
+This is universal advice, not project-specific guidance.
+
+### 3. One-Off Fixes
+
+Bad:
+
+```markdown
+We fixed a bug in commit abc123 where the login button did not work.
+```
+
+It will not help future sessions and only adds clutter.
+
+### 4. Verbose Explanations
+
+Bad:
+
+```markdown
+The authentication system uses JWT tokens. JWT (JSON Web Tokens) are
+an open standard that defines a compact and self-contained way for securely
+transmitting information between parties as a JSON object. In our
+implementation, we use the HS256 algorithm which...
+```
+
+Good:
+
+```markdown
+Auth: JWT with HS256, tokens in `Authorization: Bearer <token>`.
+```
+
+## Diff Format for Updates
+
+For each suggested change:
+
+### 1. Identify the File
+
+```text
+File: ./AGENTS.md
+Section: Commands (new section after ## Architecture)
+```
+
+### 2. Show the Change
+
+```diff
+ ## Architecture
+ ...
+
++## Commands
++
++| Command | Purpose |
++|---------|---------|
++| `npm run dev` | Dev server with HMR |
++| `npm run build` | Production build |
++| `npm test` | Run test suite |
+```
+
+### 3. Explain Why
+
+> **Why this helps:** The build commands were not documented, which forces
+> future sessions to inspect `package.json` before they can work efficiently.
+
+## Validation Checklist
+
+Before finalizing an update, verify:
+
+- [ ] Each addition is project-specific
+- [ ] There is no generic advice or obvious information
+- [ ] Commands are tested or otherwise verified
+- [ ] File paths are accurate
+- [ ] A new agent session would actually find this helpful
+- [ ] This is the most concise way to express the information

package/src/brainstorming/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: brainstorming
+description: "Use when the work needs collaborative design before implementation, especially for new features, behavior changes, or unclear requirements. Explores user intent, requirements, and design before implementation."
+metadata:
+  short-description: Brainstorm ideas into approved designs
+---
+
+# Brainstorming Ideas Into Designs
+
+Help turn ideas into fully formed designs through natural collaborative dialogue. Start by understanding the current project context, then ask simple, direct questions to refine the idea.
+
+Once you understand what you're building, present the design and get user approval before any implementation action. Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. Design approval does not approve the spec, the plan, or implementation. After approval, invoke `writing-specs` when the user wants the design documented or wants to continue through the default spec-first pipeline. If the user explicitly wants brainstorming only, stop after the approved design. If the next step is unclear, ask one short question such as `Do you want more planning first, or should I proceed to the change?` instead of assuming a handoff.
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+Do not skip design just because something looks simple if there is any meaningful choice about behavior, interface, structure, or constraints.
+
+For trivial, low-risk work with one obvious shape, keep the design lightweight: confirm the goal, state the intended approach briefly, and get acknowledgement before moving on. If you are unsure whether the work is trivial, treat it as non-trivial.
+
+## Checklist
+
+Use these stages as the default flow. For complex work, cover them all. For simple work, collapse them into the lightest version that still confirms the design before implementation. Track them explicitly when the environment supports task tracking:
+
+1. **Explore project context** - inspect enough of the project to understand current patterns and constraints; if the request is obviously too large for one design/spec, do only enough to confirm that and decompose first
+2. **Ask clarifying questions** - keep them simple and direct; group closely related easy questions when they can be answered together; separate questions that need discussion
+3. **Propose options** - compare 2-3 approaches when there are meaningful choices; otherwise state the single obvious approach and why it is sufficient
+4. **Present design** - for complex work, present the design in sections, get a response on each section, revisit any deferred or partial approvals, then give a short summary of the full design and get one final approval; for simple work, a single concise design and one approval is enough
+5. **Transition or stop** - invoke `writing-specs` when the approved design should be documented or carried forward in the default pipeline; if the user wants to proceed directly, complete brainstorming and hand off to implementation outside this skill; if the user explicitly wants brainstorming only, stop after the approved design; if the next step is unclear, ask one short question
+
+## Tool Compatibility
+
+- Keep instructions tool-agnostic and avoid provider-specific wording.
+- When behavior differs across tools, resolve conflicts in this order: OpenCode > Claude Code > Codex CLI > Gemini CLI.
+
+## Process Flow
+
+```text
+Explore project context
+  -> If the request is too large for one design/spec: decompose it immediately, recommend the first sub-project, get agreement on that slice, then continue
+  -> Ask simple, direct questions
+  -> Propose options when there are real choices
+  -> Present design
+     -> complex work: section response -> revisit deferred/partial items -> final summary -> final approval
+     -> simple work: concise design -> approval
+  -> Final design approved?
+     -> no: revise and continue
+     -> yes + wants documentation or wants to continue in the default pipeline: invoke writing-specs
+     -> yes + wants to proceed directly: brainstorming complete; end this skill and hand off to the implementation phase
+     -> yes + explicitly wants brainstorming only: stop after the approved design
+     -> yes + next step unclear: ask one short question
+```
+
+Do NOT invoke `frontend-design` or any other implementation skill from brainstorming. If the user wants to proceed directly, finish brainstorming first, then let implementation happen as the next phase outside this skill.
+
+Invoke `writing-specs` only when the approved design should be documented or used to continue into the default pipeline. If the user explicitly wants to stop at brainstorming, defer documentation, or proceed directly to the change, do not force it. When the user's intent is unclear after final design approval, ask one short question such as `Do you want more planning first, or should I proceed to the change?`.
+
+## The Process
+
+**Understanding the idea:**
+
+- Inspect enough of the current project state first: relevant files, docs, or recent commits when helpful. If the request is obviously too large for one design/spec, do only enough inspection to confirm that and move straight to decomposition.
+- Decide whether the request needs the full brainstorming flow or a lightweight design confirmation. Use the full flow for new functionality, behavior changes, unclear requirements, multiple reasonable approaches, or work that spans multiple components. For trivial, low-risk, self-evident changes with one obvious path, keep the design brief but still confirm it before moving on. If unsure, use the full flow.
+- Before asking detailed questions, assess scope. If the request describes multiple independent subsystems, for example "build a platform with chat, file storage, billing, and analytics", flag this immediately. Do not spend questions refining details of a project that needs to be decomposed first.
+- If the project is too large for a single spec, decompose it into sub-projects, recommend the first sub-project to tackle, and get agreement on that slice before going deeper. Then brainstorm that sub-project through the normal design flow. In the default workflow, each sub-project gets its own spec-first cycle before implementation; if the user wants a different handoff, follow that intent.
+- For appropriately scoped projects, ask simple, direct questions to refine the idea.
+- Group closely related easy questions when the user can answer them together. If a question is complex, high-impact, or likely to need back-and-forth, ask it by itself.
+- Prefer multiple choice questions when possible, but open-ended is fine too.
+- Focus on understanding: purpose, constraints, success criteria.
+
+**Exploring approaches:**
+
+- When there are materially different reasonable options, propose 2-3 different approaches with trade-offs.
+- For trivial or single-path work, state the chosen approach and why it is sufficient.
+- Present options conversationally with your recommendation and reasoning.
+- Lead with your recommended option and explain why.
+
+**Presenting the design:**
+
+- Once you believe you understand what you're building, present the design.
+- For complex work with multiple decisions or issues, split the design into sections. Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced.
+- Ask after each section whether it looks right so far.
+- Partial approvals and deferrals are fine, but track every unresolved point and revisit it before the final summary.
+- After the last section, give a short summary of the whole design and ask for one final approval. Do not treat the design as fully approved until this final approval happens.
+- For simple, obvious work, skip the sectioned flow and present one concise design for approval.
+- For complex work, cover architecture, components, data flow, error handling, and testing. For simple work, cover only the parts that matter.
+- Be ready to go back and clarify if something does not make sense.
+
+**Design for isolation and clarity:**
+
+- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently.
+- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
+- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
+- Smaller, well-bounded units are also easier for you to work with. You reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that is often a signal that it is doing too much.
+
+**Working in existing codebases:**
+
+- Explore the current structure before proposing changes. Follow existing patterns.
+- Where existing code has problems that affect the work, for example a file that has grown too large, unclear boundaries, or tangled responsibilities, include targeted improvements as part of the design, the way a good developer improves code they are working in.
+- Do not propose unrelated refactoring. Stay focused on what serves the current goal.
+
+## After the Design
+
+**Documentation:**
+
+- Invoke `writing-specs` to write the validated design to a spec document when the approved design should be documented or carried forward.
+- If the user explicitly wants brainstorming only or to defer documentation, stop after the approved design instead of forcing a handoff.
+- If the user wants to keep going but it is unclear whether they want more planning or direct implementation, ask `Do you want more planning first, or should I proceed to the change?`.
+- If the user explicitly wants to proceed directly, do not force `writing-specs`.
+- Keep `writing-specs` as the default handoff for documented, spec-first work. If the user explicitly asks to do planning next, you may invoke `writing-plans` directly instead.
+
+## Key Principles
+
+- **Simple questions first** - Ask simple, direct questions. Group closely related easy questions when useful, and separate questions that need discussion.
+- **Multiple choice preferred** - Easier to answer than open-ended when possible.
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs.
+- **Explore alternatives** - Propose 2-3 approaches when there are real choices; otherwise state the single obvious approach.
+- **Incremental validation** - For complex work, get section responses, revisit any deferred or partial items, and always finish with final whole-design approval. For simple work, one approval is enough.
+- **Be flexible** - Go back and clarify when something does not make sense.

package/src/brainstorming/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Brainstorming"
+  short_description: "Turn ideas into approved designs before coding"
+  default_prompt: "Use $brainstorming to explore the idea before coding: inspect enough context to understand the request, ask simple direct questions, group closely related easy questions when useful, and compare meaningful approaches. If the request is too large for one design, decompose it immediately, recommend the first slice, and get agreement on that slice before going deeper. For complex work, present the design in sections, revisit deferred or partial approvals, then give a short final summary and require final approval before treating the design as approved. For simple work, keep it lightweight. After approval, invoke `writing-specs` only when the user wants documentation or the default pipeline, and invoke `writing-plans` directly when the user explicitly asks to plan next; if the user wants to proceed directly, end brainstorming and hand off to implementation, and if the next step is unclear, ask whether they want more planning or you should proceed to the change."

package/src/caveman/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: caveman
+description: Ultra-compressed communication mode. Supports intensity levels: lite, full (default), ultra. Use when user explicitly requests or token efficiency is requested.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE. No revert after many turns. No filler drift. Still active if unsure. Off only: "stop caveman" / "normal mode".
+
+Default: **full**. Switch (lite|full|ultra) only if user explicitly asks.
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Technical terms exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+## Intensity
+
+| Level     | What change                                                                                                                  |
+| --------- | ---------------------------------------------------------------------------------------------------------------------------- |
+| **lite**  | No filler/hedging. Keep articles + full sentences. Professional but tight                                                    |
+| **full**  | Drop articles, fragments OK, short synonyms. Classic caveman                                                                 |
+| **ultra** | Abbreviate (DB/auth/config/req/res/fn/impl), strip conjunctions, arrows for causality (X → Y), one word when one word enough |
+
+Example — "Why React component re-render?"
+
+- lite: "Your component re-renders because you create a new object reference each render. Wrap it in `useMemo`."
+- full: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
+- ultra: "Inline obj prop → new ref → re-render. `useMemo`."
+
+Example — "Explain database connection pooling."
+
+- lite: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake overhead."
+- full: "Pool reuse open DB connections. No new connection per request. Skip handshake overhead."
+- ultra: "Pool = reuse DB conn. Skip handshake → fast under load."
+
+## Auto-Clarity
+
+Drop caveman for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.
+
+Example — destructive op:
+
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+>
+> ```sql
+> DROP TABLE users;
+> ```
+>
+> Caveman resume. Verify backup exist first.
+
+## Boundaries
+
+Code/commits/PRs: write normal. "stop caveman" or "normal mode": revert. Level persist until changed or session end.

package/src/caveman/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Caveman"
+  short_description: "Speak tersely with full technical accuracy"
+  default_prompt: "Use $caveman to respond in ultra-compressed caveman mode with full technical accuracy, default to full intensity unless the user explicitly asks for lite or ultra, keep code and formal artifacts in normal style, and switch to clearer prose whenever safety or sequencing matters more than brevity."

package/src/caveman-commit/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: caveman-commit
+description: Ultra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. Use when user says "write a commit", "commit message", "generate commit". Auto-triggers when staging changes.
+---
+
+Write commit messages terse and exact. Conventional Commits format. No fluff. Why over what.
+
+## Rules
+
+**Subject line:**
+
+- `<type>(<scope>): <imperative summary>` — `<scope>` optional
+- Types: `feat`, `fix`, `refactor`, `perf`, `docs`, `test`, `chore`, `build`, `ci`, `style`, `revert`
+- Imperative mood: "add", "fix", "remove" — not "added", "adds", "adding"
+- ≤50 chars when possible, hard cap 72
+- No trailing period
+- Match project convention for capitalization after the colon
+
+**Body (only if needed):**
+
+- Skip entirely when subject is self-explanatory
+- Add body only for: non-obvious _why_, breaking changes, migration notes, linked issues
+- Wrap at 72 chars
+- Bullets `-` not `*`
+- Reference issues/PRs at end: `Closes #42`, `Refs #17`
+
+**What NEVER goes in:**
+
+- "This commit does X", "I", "we", "now", "currently" — the diff says what
+- "As requested by..." — use Co-authored-by trailer
+- "Generated with Claude Code" or any AI attribution
+- Emoji (unless project convention requires)
+- Restating the file name when scope already says it
+
+## Examples
+
+Diff: new endpoint for user profile with body explaining the why
+
+- ❌ "feat: add a new endpoint to get user profile information from the database"
+- ✅
+
+  ```
+  feat(api): add GET /users/:id/profile
+
+  Mobile client needs profile data without the full user payload
+  to reduce LTE bandwidth on cold-launch screens.
+
+  Closes #128
+  ```
+
+Diff: breaking API change
+
+- ✅
+
+  ```
+  feat(api)!: rename /v1/orders to /v1/checkout
+
+  BREAKING CHANGE: clients on /v1/orders must migrate to /v1/checkout
+  before 2026-06-01. Old route returns 410 after that date.
+  ```
+
+## Auto-Clarity
+
+Always include body for: breaking changes, security fixes, data migrations, anything reverting a prior commit. Never compress these into subject-only — future debuggers need the context.
+
+## Boundaries
+
+Only generates the commit message. Does not run `git commit`, does not stage files, does not amend. Output the message as a code block ready to paste. "stop caveman-commit" or "normal mode": revert to verbose commit style.

package/src/caveman-commit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Caveman Commit"
+  short_description: "Generate terse Conventional Commit messages"
+  default_prompt: "Use $caveman-commit to generate a terse Conventional Commit message focused on why over what, keep the subject concise, add a body only when needed, and always include fuller context for breaking changes, security fixes, data migrations, or reverts."

package/src/caveman-review/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: caveman-review
+description: Ultra-compressed code review comments. Cuts noise from PR feedback while preserving actionable signal. Each comment is one line: location, problem, fix. Use when explicitly requested by the user or when reviewing PRs.
+---
+
+Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
+
+## Rules
+
+**Format:** `L<line>: <problem>. <fix>.` — or `<file>:L<line>: ...` when reviewing multi-file diffs.
+
+**Severity prefix (optional, when mixed):**
+
+- `🔴 bug:` — broken behavior, will cause incident
+- `🟡 risk:` — works but fragile (race, missing null check, swallowed error)
+- `🔵 nit:` — style, naming, micro-optim. Author can ignore
+- `❓ q:` — genuine question, not a suggestion
+
+**Drop:**
+
+- "I noticed that...", "It seems like...", "You might want to consider..."
+- "This is just a suggestion but..." — use `nit:` instead
+- "Great work!", "Looks good overall but..." — say it once at the top, not per comment
+- Restating what the line does — the reviewer can read the diff
+- Hedging ("perhaps", "maybe", "I think") — if unsure use `q:`
+
+**Keep:**
+
+- Exact line numbers
+- Exact symbol/function/variable names in backticks
+- Concrete fix, not "consider refactoring this"
+- The _why_ if the fix isn't obvious from the problem statement
+
+## Examples
+
+❌ "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."
+
+✅ `L42: 🔴 bug: user can be null after .find(). Add guard before .email.`
+
+❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."
+
+✅ `L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.`
+
+❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."
+
+✅ `L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).`
+
+## Auto-Clarity
+
+Drop terse mode for: security findings (CVE-class bugs need full explanation + reference), architectural disagreements (need rationale, not just a one-liner), and onboarding contexts where the author is new and needs the "why". In those cases write a normal paragraph, then resume terse for the rest.
+
+## Boundaries
+
+Reviews only — does not write the code fix, does not approve/request-changes, does not run linters. Output the comment(s) ready to paste into the PR. "stop caveman-review" or "normal mode": revert to verbose review style.

package/src/caveman-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Caveman Review"
+  short_description: "Write terse one-line code review findings"
+  default_prompt: "Use $caveman-review to write terse actionable code review comments, one line per finding with exact line or file references, problem, and fix; only expand into normal prose for security issues, architectural disagreements, or other cases where the rationale needs more explanation."

package/src/cli.test.ts

@@ -0,0 +1,102 @@
+import * as fs from "fs";
+import * as os from "os";
+import * as path from "path";
+
+import { describe, it, expect, beforeEach, afterEach } from "vitest";
+
+import { parseFrontmatter, getSkills, copyRecursiveSync } from "./cli.js";
+
+describe("Skills Helper functions", () => {
+  let tempDir: string;
+
+  beforeEach(() => {
+    tempDir = fs.mkdtempSync(path.join(os.tmpdir(), "codenhub-skills-test-"));
+  });
+
+  afterEach(() => {
+    fs.rmSync(tempDir, { recursive: true, force: true });
+  });
+
+  describe("parseFrontmatter", () => {
+    it("should parse valid frontmatter", () => {
+      const content = `---\nname: test-skill\ndescription: A test skill description\n---\nSome markdown here`;
+      const meta = parseFrontmatter(content);
+      expect(meta).toEqual({
+        name: "test-skill",
+        description: "A test skill description",
+      });
+    });
+
+    it("should return empty object if no frontmatter", () => {
+      const content = "no frontmatter here";
+      const meta = parseFrontmatter(content);
+      expect(meta).toEqual({});
+    });
+  });
+
+  describe("getSkills", () => {
+    it("should return skills list from directory", () => {
+      const skill1Dir = path.join(tempDir, "skill-1");
+      fs.mkdirSync(skill1Dir, { recursive: true });
+      fs.writeFileSync(path.join(skill1Dir, "SKILL.md"), `---\nname: Skill One\ndescription: First skill\n---\n`);
+
+      const skill2Dir = path.join(tempDir, "skill-2");
+      fs.mkdirSync(skill2Dir, { recursive: true });
+      fs.writeFileSync(path.join(skill2Dir, "SKILL.md"), `---\nname: Skill Two\ndescription: Second skill\n---\n`);
+
+      // Non-skill dir (no SKILL.md)
+      const otherDir = path.join(tempDir, "other");
+      fs.mkdirSync(otherDir, { recursive: true });
+
+      const skills = getSkills(tempDir);
+      expect(skills).toHaveLength(2);
+      expect(skills.find((s) => s.id === "skill-1")).toEqual({
+        id: "skill-1",
+        name: "Skill One",
+        description: "First skill",
+        path: skill1Dir,
+      });
+    });
+
+    it("should return empty array if directory does not exist", () => {
+      const skills = getSkills(path.join(tempDir, "non-existent"));
+      expect(skills).toEqual([]);
+    });
+  });
+
+  describe("copyRecursiveSync", () => {
+    it("should recursively copy files and folders", () => {
+      const srcDir = path.join(tempDir, "src");
+      const destDir = path.join(tempDir, "dest");
+
+      fs.mkdirSync(path.join(srcDir, "subdir"), { recursive: true });
+      fs.writeFileSync(path.join(srcDir, "file1.txt"), "content 1");
+      fs.writeFileSync(path.join(srcDir, "subdir", "file2.txt"), "content 2");
+
+      copyRecursiveSync(srcDir, destDir);
+
+      expect(fs.existsSync(path.join(destDir, "file1.txt"))).toBe(true);
+      expect(fs.readFileSync(path.join(destDir, "file1.txt"), "utf8")).toBe("content 1");
+      expect(fs.existsSync(path.join(destDir, "subdir", "file2.txt"))).toBe(true);
+      expect(fs.readFileSync(path.join(destDir, "subdir", "file2.txt"), "utf8")).toBe("content 2");
+    });
+
+    it("should ignore paths in ignoreList", () => {
+      const srcDir = path.join(tempDir, "src-ignore");
+      const destDir = path.join(tempDir, "dest-ignore");
+
+      fs.mkdirSync(path.join(srcDir, "subdir"), { recursive: true });
+      fs.mkdirSync(path.join(srcDir, "ignored-dir"), { recursive: true });
+      fs.writeFileSync(path.join(srcDir, "file1.txt"), "content 1");
+      fs.writeFileSync(path.join(srcDir, "subdir", "file2.txt"), "content 2");
+      fs.writeFileSync(path.join(srcDir, "ignored-dir", "file3.txt"), "content 3");
+
+      copyRecursiveSync(srcDir, destDir, ["ignored-dir"]);
+
+      expect(fs.existsSync(path.join(destDir, "file1.txt"))).toBe(true);
+      expect(fs.existsSync(path.join(destDir, "subdir", "file2.txt"))).toBe(true);
+      expect(fs.existsSync(path.join(destDir, "ignored-dir"))).toBe(false);
+      expect(fs.existsSync(path.join(destDir, "ignored-dir", "file3.txt"))).toBe(false);
+    });
+  });
+});