claudecode-omc 4.9.3 → 4.9.5

package/README.md

@@ -1,12 +1,14 @@
 English | [한국어](README.ko.md) | [中文](README.zh.md) | [日本語](README.ja.md) | [Español](README.es.md) | [Tiếng Việt](README.vi.md) | [Português](README.pt.md)
 
+> **Note:** This is a fork of [oh-my-claudecode](https://github.com/Yeachan-Heo/oh-my-claudecode) by [@Yeachan-Heo](https://github.com/Yeachan-Heo). This fork includes custom modifications and enhancements.
+
 # oh-my-claudecode
 
 [![npm version](https://img.shields.io/npm/v/oh-my-claude-sisyphus?color=cb3837)](https://www.npmjs.com/package/oh-my-claude-sisyphus)
 [![npm downloads](https://img.shields.io/npm/dm/oh-my-claude-sisyphus?color=blue)](https://www.npmjs.com/package/oh-my-claude-sisyphus)
-[![GitHub stars](https://img.shields.io/github/stars/Yeachan-Heo/oh-my-claudecode?style=flat&color=yellow)](https://github.com/Yeachan-Heo/oh-my-claudecode/stargazers)
+[![GitHub stars](https://img.shields.io/github/stars/materialofair/oh-my-claudecode?style=flat&color=yellow)](https://github.com/materialofair/oh-my-claudecode/stargazers)
 [![License: MIT](https://img.shields.io/badge/License-MIT-green.svg)](https://opensource.org/licenses/MIT)
-[![Sponsor](https://img.shields.io/badge/Sponsor-❤️-red?style=flat&logo=github)](https://github.com/sponsors/Yeachan-Heo)
+[![Sponsor](https://img.shields.io/badge/Sponsor-❤️-red?style=flat&logo=github)](https://github.com/sponsors/materialofair)
 [![Discord](https://img.shields.io/discord/1452487457085063218?color=5865F2&logo=discord&logoColor=white&label=Discord)](https://discord.gg/PUwSMR9XNk)
 
 > **For Codex users:** Check out [oh-my-codex](https://github.com/Yeachan-Heo/oh-my-codex) — the same orchestration experience for OpenAI Codex CLI.
@@ -26,7 +28,7 @@ _Don't learn Claude Code. Just use OMC._
 Marketplace/plugin install (recommended for most Claude Code users):
 
 ```bash
-/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
+/plugin marketplace add https://github.com/materialofair/oh-my-claudecode
 /plugin install oh-my-claudecode
 ```
 
@@ -457,13 +459,13 @@ Top personal non-fork, non-archived repos from all-time OMC contributors (100+ G
 
 ## Star History
 
-[![Star History Chart](https://api.star-history.com/svg?repos=Yeachan-Heo/oh-my-claudecode&type=date&legend=top-left)](https://www.star-history.com/#Yeachan-Heo/oh-my-claudecode&type=date&legend=top-left)
+[![Star History Chart](https://api.star-history.com/svg?repos=materialofair/oh-my-claudecode&type=date&legend=top-left)](https://www.star-history.com/#materialofair/oh-my-claudecode&type=date&legend=top-left)
 
 ## 💖 Support This Project
 
 If Oh-My-ClaudeCode helps your workflow, consider sponsoring:
 
-[![Sponsor on GitHub](https://img.shields.io/badge/Sponsor-❤️-red?style=for-the-badge&logo=github)](https://github.com/sponsors/Yeachan-Heo)
+[![Sponsor on GitHub](https://img.shields.io/badge/Sponsor-❤️-red?style=for-the-badge&logo=github)](https://github.com/sponsors/materialofair)
 
 ### Why sponsor?
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claudecode-omc",
-  "version": "4.9.3",
+  "version": "4.9.5",
   "description": "Multi-agent orchestration system for Claude Code - Inspired by oh-my-opencode",
   "type": "module",
   "main": "dist/index.js",

package/skills/conductor/SKILL.md

@@ -1,200 +1,231 @@
 ---
 name: conductor
-description: Structured Context -> Spec & Plan -> Implement workflow
+description: Use when user wants durable Context->Spec->Plan->Implement tracks ('conductor', 'structured workflow', 'track this', 'context then plan'). Creates and governs `.omc/conductor/` artifacts for Claude Code multi-session delivery.
+argument-hint: "<subcommand | track-goal>"
+level: 4
 ---
 
+# Conductor
+
 <Purpose>
-Conductor provides a structured workflow for complex feature development through explicit phases: context gathering, specification creation, planning, and implementation. It emphasizes deliberate tracking of requirements and constraints before execution, making it ideal for large features where clarity and documentation are crucial.
+Conductor is a durable track-management workflow for Claude Code. It preserves long-lived context on disk, turns ambiguous requests into spec+plan artifacts, and controls implementation/review so work can safely span multiple sessions.
+
+Primary loop:
+`Setup -> Track -> Spec -> Plan -> Implement -> Review -> Reconcile`
 </Purpose>
 
 <Use_When>
-- User wants a structured, tracked workflow with explicit spec and plan phases
-- User says "conductor", "structured workflow", "track this", "conductor setup"
-- Task requires careful context gathering before implementation
-- User wants to build up requirements incrementally before executing
-- Project needs clear documentation of what's being built and why
+- User explicitly asks for `conductor`, `structured workflow`, or `track this`
+- Work needs persistent artifacts and traceability across sessions
+- Feature scope is large enough that spec and plan should be reviewed before coding
+- Team needs deterministic progress reporting and reversible checkpoints
 </Use_When>
 
 <Do_Not_Use_When>
-- User wants immediate autonomous execution -- use `autopilot` instead
-- User wants hands-off execution without tracking phases -- use `ultrapilot` or `swarm`
-- Task is a quick fix or single-file change -- use direct executor delegation
-- User wants to explore options or brainstorm -- use `plan` skill instead
-- User wants self-correcting execution loops -- use `ralph` instead
+- Small one-off bugfix or single-file change (use direct executor flow)
+- User wants immediate end-to-end autonomous build (use `autopilot`)
+- User is still exploring alternatives with no commitment to tracked artifacts (use `omc-plan`/`ralplan` first)
 </Do_Not_Use_When>
 
-<Why_This_Exists>
-Many complex features benefit from a deliberate, phased approach where context is gathered first, then a spec is created, then a plan is reviewed, and finally implementation begins. Conductor makes this workflow explicit and trackable, with clear subcommands for each phase and the ability to review, revert, or adjust at each step.
-</Why_This_Exists>
+<Compatibility>
+This skill is aligned to the stronger Conductor protocol in `oh-my-codex` and adapted to Claude runtime primitives.
+
+Preserved Conductor invariants:
+- Durable context is on disk, not only in chat memory
+- Work is represented as tracks
+- Important tracks carry both spec and plan artifacts
+- Review is a first-class stage before closure
+
+Claude-specific adaptation:
+- Use `Task(subagent_type="oh-my-claudecode:...")` for delegation
+- Use `.omc/conductor/` paths used by OMC hooks
+- Use `AskUserQuestion` for gated approvals when user decisions are required
+</Compatibility>
 
 <Execution_Policy>
-- All context, specs, and plans are stored in `.omc/conductor/` directory
-- Each phase must be explicitly transitioned using subcommands
-- Users can review outputs at each phase before proceeding
-- Revert is available to go back to previous phases if needed
-- Implementation phase runs with full verification and QA checks
+- Keep a single active track by default unless user explicitly asks for parallel tracks
+- Retrieval-first: read repository facts before proposing architecture or implementation
+- Plan is the execution source of truth; do not silently drift from accepted plan
+- Prefer minimal, reversible edits and checkpoint after each completed task cluster
+- If tool calls fail, stop that phase, report blocker, and avoid speculative continuation
 </Execution_Policy>
 
-<Steps>
-1. **Setup Phase**: Initialize conductor state and directory structure
-   - Subcommand: `setup` or `init`
-   - Creates `.omc/conductor/` directory
-   - Initializes `conductor-state.json` with `phase: "context"`
-   - Output: State file confirming setup
-
-2. **Context Gathering Phase**: Collect requirements, constraints, and domain knowledge
-   - Subcommand: `track <context>`
-   - User provides context incrementally using `track` subcommand
-   - Each track call appends to `.omc/conductor/context.md`
-   - Context includes: requirements, constraints, domain terms, dependencies, non-functional requirements
-   - Output: Updated context file
-
-3. **Specification Phase**: Generate structured specification from gathered context
-   - Subcommand: `spec` or auto-transition when ready
-   - Analyst (Opus): Extract and structure requirements from context
-   - Architect (Opus): Define technical approach, components, and interfaces
-   - Output: `.omc/conductor/spec.md`
-   - State transition: `phase: "context"` -> `phase: "spec"`
-
-4. **Planning Phase**: Create detailed implementation plan from specification
-   - Subcommand: `plan` or auto-transition
-   - Planner (Opus): Break down spec into implementation tasks
-   - Architect (Opus): Validate plan against constraints
-   - Output: `.omc/conductor/plan.md`
-   - State transition: `phase: "spec"` -> `phase: "plan"`
-
-5. **Review Phase**: User reviews plan before implementation
-   - Subcommand: `review`
-   - Display plan content for user review
-   - User can approve, request changes, or revert
-   - Provides checkpoint before execution
-
-6. **Implementation Phase**: Execute the plan with verification
-   - Subcommand: `implement`
-   - Executor agents (Haiku/Sonnet/Opus) based on task complexity
-   - Includes test execution and verification
-   - State transition: `phase: "plan"` -> `phase: "implement"`
-
-7. **Status Check**: View current phase and progress
-   - Subcommand: `status`
-   - Shows current phase, files created, and next steps
-   - No state changes
-
-8. **Revert**: Go back to previous phase
-   - Subcommand: `revert`
-   - Moves back one phase in the workflow
-   - Preserves existing outputs for reference
-</Steps>
-
-<Tool_Usage>
-- Use `state_write` and `state_read` with mode `'conductor'` for phase tracking
-- Store all outputs in `.omc/conductor/` directory (context.md, spec.md, plan.md)
-- Delegate to specialist agents: `analyst`, `architect`, `planner`, `executor`
-- Use model routing: `opus` for spec/plan phases, `sonnet/haiku` for implementation
-- Optional: Use `ask_codex` for validation if MCP is configured
-</Tool_Usage>
+<Directory_Contract>
+Use this Claude/OMC file layout:
+
+```text
+.omc/conductor/
+  conductor-state.json
+  context/
+    product.md
+    tech-stack.md
+    workflow.md
+    styleguides/*.md
+  specs/
+    <track-slug>.md
+  plans/
+    <track-slug>.md
+  reviews/
+    <track-slug>.md
+  research/
+    <track-slug>/
+      state.json
+      findings.md
+```
+
+State reference:
+- `conductor-state.json` stores `active`, `activeTrack`, `tracks`, context pointers, and metadata.
+- Track phases should stay consistent with runtime types: `setup | idle | spec | planning | implementing | reviewing | complete`.
+</Directory_Contract>
 
 <Subcommand_Routing>
-Conductor uses subcommand-based routing for all operations:
-
-- `setup` | `init` -> Initialize conductor state and directories
-- `track <context>` -> Add context to context.md
-- `spec` -> Generate specification from context (transition: context -> spec)
-- `plan` -> Generate implementation plan (transition: spec -> plan)
-- `review` -> Display plan for user review
-- `implement` -> Execute the plan (transition: plan -> implement)
-- `status` -> Show current phase and progress
-- `revert` -> Go back to previous phase
-
-Each subcommand validates the current phase and ensures proper sequencing.
+Native command hooks currently support:
+- `setup`
+- `track <title> [description]`
+- `plan <slug>`
+- `review <slug>`
+- `status [slug]`
+
+Conductor workflow operations (can be executed by skill protocol even if no dedicated slash command exists):
+- `implement <slug|active>`
+- `refresh [scope]`
+- `revert <slug>`
 </Subcommand_Routing>
 
-<Examples>
-<Good>
-User: "conductor setup"
-Why good: Explicit initialization of conductor workflow. Sets up state and directory structure.
-</Good>
+<Workflow>
+1. **Setup / Resume**
+   - If `conductor-state.json` exists and `active=true`, resume.
+   - Otherwise initialize `.omc/conductor/` and context documents.
+   - Bootstrap tech stack from `.omc/project-memory.json` when available.
+
+2. **Track Selection**
+   - If user provided slug/title, resolve it.
+   - Else choose active track first, otherwise earliest non-complete track.
+   - If no track exists, create one from user goal (`track` stage).
+
+3. **Preflight Context**
+   - Read in order: context docs -> active spec -> active plan -> relevant code/config.
+   - Output compact brief: goal, accepted constraints, current phase, next task.
+
+4. **Spec Generation**
+   - Delegate to `analyst` (sonnet/opus) for requirements structure.
+   - Delegate to `architect` (opus) for system boundaries and risks.
+   - Persist to `.omc/conductor/specs/<slug>.md`.
+
+5. **Plan Generation**
+   - Delegate to `planner` (sonnet/opus) for phased tasks.
+   - Require testable acceptance criteria and explicit verification commands.
+   - Persist to `.omc/conductor/plans/<slug>.md`.
+
+6. **Implement**
+   - Execute tasks in small slices via `executor`.
+   - Keep plan checkboxes in sync (`[ ]`, `[~]`, `[x]`).
+   - Run deterministic checks per slice (lint/type/test/build as applicable).
+
+7. **Review**
+   - Use `code-reviewer` and `verifier` as default review pair.
+   - Add `security-reviewer` when auth, secrets, trust-boundaries, or user input changed.
+   - Persist verdict to `.omc/conductor/reviews/<slug>.md`.
+
+8. **Reconcile / Close**
+   - If review fails, reopen tasks and return to implement.
+   - If review passes, mark track complete and record concise evidence.
+</Workflow>
+
+<Research_Integration>
+When uncertainty is high (new SDKs, conflicting docs, unknown architecture edges), run a research pass before locking spec/plan.
+
+Trigger examples:
+- External dependency behavior changed recently
+- Two plausible architectural options with unclear tradeoffs
+- Security/compliance requirement needs primary-source confirmation
+
+Research protocol (adapted from `research` skill):
+1. **Decompose** into 3-5 stages.
+2. **Parallel execute** stage analysis with `scientist` agents (max 5 concurrent).
+3. **Verify** contradictions; output `[VERIFIED]` or `[CONFLICTS:<list>]`.
+4. **Synthesize** into a decision note appended to spec/plan.
+
+Persist research artifacts:
+- `.omc/conductor/research/<track-slug>/state.json`
+- `.omc/conductor/research/<track-slug>/findings.md`
+</Research_Integration>
+
+<Research_Evidence_Format>
+Use structured evidence blocks:
+
+```text
+[FINDING:<id>] <title>
+<analysis>
+[/FINDING]
+
+[EVIDENCE:<id>]
+- Source: <url or file>
+- Date: <YYYY-MM-DD>
+- Relevance: <why it matters>
+[/EVIDENCE]
+
+[CONFIDENCE:HIGH|MEDIUM|LOW]
+<brief rationale>
+```
 
+Quality gates:
+- Every `[FINDING]` must include `[EVIDENCE]`
+- Unsupported claims must be downgraded or removed
+- Unresolved contradictions must remain explicit
+</Research_Evidence_Format>
+
+<Agent_Routing>
+- Setup/context scan: `explore` (haiku/sonnet)
+- Requirements/spec: `analyst` + `architect` (sonnet/opus)
+- Plan refinement: `planner` + `critic` (sonnet/opus)
+- Implementation: `executor` (sonnet by default)
+- Test strategy/fixes: `test-engineer` (sonnet)
+- Review/validation: `code-reviewer` + `verifier` (+ `security-reviewer` when needed)
+- Research branches: `scientist` (haiku/sonnet/opus by tier)
+</Agent_Routing>
+
+<Status_Contract>
+`status` output should always include:
+- active track
+- track phase
+- progress summary (completed/in-progress/pending)
+- next concrete action
+- blockers (or `None`)
+- latest review verdict (if present)
+- research verification status (if research was run)
+</Status_Contract>
+
+<Failure_Handling>
+- If setup/context files are missing: stop and run setup first
+- If plan is missing: do not implement; return to plan phase
+- If verification fails: reopen related tasks and continue implementation
+- If evidence is insufficient in research mode: emit `[PROMISE:RESEARCH_BLOCKED]` with blocker details
+</Failure_Handling>
+
+<Examples>
 <Good>
-User: "conductor track: API needs to support real-time updates via WebSocket"
-Why good: Incremental context addition. User builds up requirements before spec generation.
+User: "conductor track payment-webhook-retry and plan it"
+Why good: Explicit track+planning request with durable artifacts.
 </Good>
 
 <Good>
-User: "conductor structured workflow for building a multi-tenant authentication system"
-Why good: Clear indication of wanting structured approach for a complex feature.
+User: "conductor for this multi-service auth refactor; do research first"
+Why good: High-uncertainty, multi-session scope benefits from research-integrated conductor flow.
 </Good>
 
 <Bad>
-User: "conductor fix the login bug"
-Why bad: Single bug fix doesn't benefit from multi-phase workflow. Use direct executor or ralph instead.
-</Bad>
-
-<Bad>
-User: "conductor build me a TODO app"
-Why bad: While conductor could handle this, "build me" pattern is better suited for autopilot's autonomous execution.
+User: "conductor fix typo in README"
+Why bad: Tiny one-off task; overhead exceeds benefit.
 </Bad>
 </Examples>
 
-<State_Schema>
-Conductor state stored in `.omc/state/conductor/conductor-state.json`:
-
-```json
-{
-  "active": true,
-  "phase": "context" | "spec" | "plan" | "implement" | "complete",
-  "startedAt": "ISO timestamp",
-  "context_file": ".omc/conductor/context.md",
-  "spec_file": ".omc/conductor/spec.md",
-  "plan_file": ".omc/conductor/plan.md",
-  "implementation_started": false,
-  "last_subcommand": "string",
-  "session_id": "optional session ID"
-}
-```
-</State_Schema>
-
 <Final_Checklist>
-- [ ] Setup completed with state file and directories created
-- [ ] Context gathered and documented in context.md
-- [ ] Specification generated from context and reviewed
-- [ ] Implementation plan created and approved
-- [ ] Implementation executed with tests passing
-- [ ] All outputs preserved in `.omc/conductor/` for reference
-- [ ] State file shows `phase: "complete"`
+- [ ] Conductor state initialized or resumed correctly
+- [ ] Active track resolved deterministically
+- [ ] Spec and plan artifacts exist and are current
+- [ ] Implementation updates map back to plan tasks
+- [ ] Review artifacts recorded with clear verdict
+- [ ] Research evidence attached for high-uncertainty decisions
+- [ ] Status reports actionable next step and blockers
 </Final_Checklist>
-
-<Advanced>
-## Phase Transitions
-
-Conductor enforces explicit phase ordering:
-- `context` -> `spec` (via `spec` subcommand)
-- `spec` -> `plan` (via `plan` subcommand)
-- `plan` -> `implement` (via `implement` subcommand)
-- `implement` -> `complete` (automatic on success)
-
-Use `revert` to go backwards if needed.
-
-## Resume Support
-
-If conductor is interrupted, invoke the skill again with the same working directory. Conductor will detect existing state and resume from the last completed phase.
-
-## Integration with Other Modes
-
-Conductor is non-exclusive and can run alongside other modes like `ralph`, `ultrawork`, or `ecomode`. It provides the workflow structure while other modes can be used during the implementation phase.
-
-## Best Practices
-
-1. **Gather context thoroughly**: Use multiple `track` calls to build comprehensive context before generating spec
-2. **Review before implementing**: Always review the plan using `review` subcommand before running `implement`
-3. **Incremental refinement**: Use `revert` if spec or plan needs adjustment based on new information
-4. **Document constraints**: Include technical constraints, dependencies, and non-functional requirements in context
-
-## Troubleshooting
-
-**Stuck in a phase?** Use `conductor status` to see current phase and next available subcommands.
-
-**Need to change the spec?** Use `conductor revert` to go back to context phase, add more context with `track`, then regenerate spec.
-
-**Implementation failing?** Review `.omc/conductor/plan.md` for potential issues. Consider reverting to plan phase to refine the approach.
-</Advanced>

package/skills/planning-with-files/scripts/check-complete.ps1

@@ -1,28 +1,28 @@
-param(
-    [string]$PlanFile = "task_plan.md"
-)
-
-if (-not (Test-Path $PlanFile)) {
-    Write-Host "ERROR: $PlanFile not found"
-    exit 1
-}
-
-$content = Get-Content $PlanFile -Raw
-$total = ([regex]::Matches($content, "### Phase")).Count
-$complete = ([regex]::Matches($content, "\*\*Status:\*\* complete")).Count
-$inProgress = ([regex]::Matches($content, "\*\*Status:\*\* in_progress")).Count
-$pending = ([regex]::Matches($content, "\*\*Status:\*\* pending")).Count
-
-Write-Host "Total phases: $total"
-Write-Host "Complete: $complete"
-Write-Host "In progress: $inProgress"
-Write-Host "Pending: $pending"
-
-if ($total -gt 0 -and $complete -eq $total) {
-    Write-Host "ALL PHASES COMPLETE"
-    exit 0
-}
-
-Write-Host "TASK NOT COMPLETE"
-exit 1
-
+param(
+    [string]$PlanFile = "task_plan.md"
+)
+
+if (-not (Test-Path $PlanFile)) {
+    Write-Host "ERROR: $PlanFile not found"
+    exit 1
+}
+
+$content = Get-Content $PlanFile -Raw
+$total = ([regex]::Matches($content, "### Phase")).Count
+$complete = ([regex]::Matches($content, "\*\*Status:\*\* complete")).Count
+$inProgress = ([regex]::Matches($content, "\*\*Status:\*\* in_progress")).Count
+$pending = ([regex]::Matches($content, "\*\*Status:\*\* pending")).Count
+
+Write-Host "Total phases: $total"
+Write-Host "Complete: $complete"
+Write-Host "In progress: $inProgress"
+Write-Host "Pending: $pending"
+
+if ($total -gt 0 -and $complete -eq $total) {
+    Write-Host "ALL PHASES COMPLETE"
+    exit 0
+}
+
+Write-Host "TASK NOT COMPLETE"
+exit 1
+

package/skills/planning-with-files/scripts/init-session.ps1

@@ -1,31 +1,31 @@
-param(
-    [string]$ProjectName = "project"
-)
-
-$date = Get-Date -Format "yyyy-MM-dd"
-Write-Host "Initializing planning files for: $ProjectName"
-
-if (-not (Test-Path "task_plan.md")) {
-    Copy-Item "skills/planning-with-files/templates/task_plan.md" "task_plan.md"
-    Write-Host "Created task_plan.md"
-} else {
-    Write-Host "task_plan.md already exists, skipping"
-}
-
-if (-not (Test-Path "findings.md")) {
-    Copy-Item "skills/planning-with-files/templates/findings.md" "findings.md"
-    Write-Host "Created findings.md"
-} else {
-    Write-Host "findings.md already exists, skipping"
-}
-
-if (-not (Test-Path "progress.md")) {
-    Copy-Item "skills/planning-with-files/templates/progress.md" "progress.md"
-    (Get-Content "progress.md") -replace "\[DATE\]", $date | Set-Content "progress.md"
-    Write-Host "Created progress.md"
-} else {
-    Write-Host "progress.md already exists, skipping"
-}
-
-Write-Host "Planning files initialized."
-
+param(
+    [string]$ProjectName = "project"
+)
+
+$date = Get-Date -Format "yyyy-MM-dd"
+Write-Host "Initializing planning files for: $ProjectName"
+
+if (-not (Test-Path "task_plan.md")) {
+    Copy-Item "skills/planning-with-files/templates/task_plan.md" "task_plan.md"
+    Write-Host "Created task_plan.md"
+} else {
+    Write-Host "task_plan.md already exists, skipping"
+}
+
+if (-not (Test-Path "findings.md")) {
+    Copy-Item "skills/planning-with-files/templates/findings.md" "findings.md"
+    Write-Host "Created findings.md"
+} else {
+    Write-Host "findings.md already exists, skipping"
+}
+
+if (-not (Test-Path "progress.md")) {
+    Copy-Item "skills/planning-with-files/templates/progress.md" "progress.md"
+    (Get-Content "progress.md") -replace "\[DATE\]", $date | Set-Content "progress.md"
+    Write-Host "Created progress.md"
+} else {
+    Write-Host "progress.md already exists, skipping"
+}
+
+Write-Host "Planning files initialized."
+

package/dist/__tests__/marketplace-metadata.test.d.ts

@@ -1,2 +0,0 @@
-export {};
-//# sourceMappingURL=marketplace-metadata.test.d.ts.map

package/dist/__tests__/marketplace-metadata.test.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"marketplace-metadata.test.d.ts","sourceRoot":"","sources":["../../src/__tests__/marketplace-metadata.test.ts"],"names":[],"mappings":""}

package/dist/__tests__/marketplace-metadata.test.js

@@ -1,20 +0,0 @@
-import { describe, it, expect } from 'vitest';
-import { readFileSync } from 'fs';
-import { dirname, join } from 'path';
-import { fileURLToPath } from 'url';
-function getPackageDir() {
-    const __filename = fileURLToPath(import.meta.url);
-    const __dirname = dirname(__filename);
-    return join(__dirname, '..', '..');
-}
-describe('marketplace metadata', () => {
-    it('matches package.json version', () => {
-        const packageDir = getPackageDir();
-        const packageJson = JSON.parse(readFileSync(join(packageDir, 'package.json'), 'utf-8'));
-        const marketplaceJson = JSON.parse(readFileSync(join(packageDir, '.claude-plugin', 'marketplace.json'), 'utf-8'));
-        expect(marketplaceJson.version).toBe(packageJson.version);
-        expect(marketplaceJson.plugins).toHaveLength(1);
-        expect(marketplaceJson.plugins[0].version).toBe(packageJson.version);
-    });
-});
-//# sourceMappingURL=marketplace-metadata.test.js.map

package/dist/__tests__/marketplace-metadata.test.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"marketplace-metadata.test.js","sourceRoot":"","sources":["../../src/__tests__/marketplace-metadata.test.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAC9C,OAAO,EAAE,YAAY,EAAE,MAAM,IAAI,CAAC;AAClC,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAC;AACrC,OAAO,EAAE,aAAa,EAAE,MAAM,KAAK,CAAC;AAEpC,SAAS,aAAa;IACpB,MAAM,UAAU,GAAG,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IAClD,MAAM,SAAS,GAAG,OAAO,CAAC,UAAU,CAAC,CAAC;IACtC,OAAO,IAAI,CAAC,SAAS,EAAE,IAAI,EAAE,IAAI,CAAC,CAAC;AACrC,CAAC;AAED,QAAQ,CAAC,sBAAsB,EAAE,GAAG,EAAE;IACpC,EAAE,CAAC,8BAA8B,EAAE,GAAG,EAAE;QACtC,MAAM,UAAU,GAAG,aAAa,EAAE,CAAC;QACnC,MAAM,WAAW,GAAG,IAAI,CAAC,KAAK,CAAC,YAAY,CAAC,IAAI,CAAC,UAAU,EAAE,cAAc,CAAC,EAAE,OAAO,CAAC,CAAC,CAAC;QACxF,MAAM,eAAe,GAAG,IAAI,CAAC,KAAK,CAChC,YAAY,CAAC,IAAI,CAAC,UAAU,EAAE,gBAAgB,EAAE,kBAAkB,CAAC,EAAE,OAAO,CAAC,CAC9E,CAAC;QAEF,MAAM,CAAC,eAAe,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,WAAW,CAAC,OAAO,CAAC,CAAC;QAC1D,MAAM,CAAC,eAAe,CAAC,OAAO,CAAC,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC;QAChD,MAAM,CAAC,eAAe,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,CAAC,IAAI,CAAC,WAAW,CAAC,OAAO,CAAC,CAAC;IACvE,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC"}