moicle 1.6.0 → 2.0.0

package/assets/skills/research/web/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: research-web
+description: Research solutions on the internet for a given topic or the current conversation context. Use when user says "research", "tìm giải pháp", "search solution", "investigate", "find best practice", "so sánh giải pháp".
+args: "[TOPIC]"
+---
+
+# Research Solutions
+
+Research solutions on the internet for a specific problem — from an explicit topic argument or by analyzing the current conversation context. **Research and propose only — do NOT implement.**
+
+**ARGUMENTS:** (optional) Topic or question to research. If omitted, analyze the current conversation (recent messages, IDE selection, task at hand) to determine what to research.
+
+## When to use this skill
+
+- ✅ You don't know the right solution / library / pattern yet
+- ✅ Need to compare multiple approaches before committing
+- ✅ Stack / framework changed and best practices may have shifted
+- ❌ You already know the approach → use `/feature:new` or `/fix:hotfix`
+- ❌ You want to validate the approach by building → use `/research:spike`
+- ❌ Debugging a known bug → use `/fix:root-cause`
+
+---
+
+## Workflow
+
+```
+IDENTIFY → DETECT STACK → SEARCH → SYNTHESIZE → PROPOSE
+```
+
+---
+
+## Step 1: Identify what to research
+
+### Mode 1 — Argument provided
+- Use the argument directly as the topic
+- If too broad, narrow it down using project context (stack, architecture, current task) BEFORE searching
+
+### Mode 2 — No argument
+- Analyze the current conversation: recent messages, IDE file selection, active task
+- Identify: what is the user doing, what problem they hit, what solution they need
+- **Summarize the problem back to the user and get confirmation** before burning search budget
+
+### Gate
+- [ ] Problem statement clear and confirmed (Mode 2)
+- [ ] Scope narrow enough to research in <10 queries
+
+---
+
+## Step 2: Detect project context
+
+Detect the project's tech stack so results can be filtered for relevance.
+
+| File | Stack |
+|------|-------|
+| `go.mod` | Go (note version from `go` directive) |
+| `package.json` | Node.js — inspect dependencies to pick framework (NestJS / Vite+React / Remix / etc.) |
+| `pubspec.yaml` | Flutter / Dart |
+| `composer.json` | PHP / Laravel |
+| `Cargo.toml` | Rust |
+| `pyproject.toml` / `requirements.txt` | Python |
+
+Also check `.claude/architecture/` for the architecture doc in use — this shapes which patterns are idiomatic for the project.
+
+### Gate
+- [ ] Stack + version identified
+- [ ] Architecture context noted (if any)
+
+---
+
+## Step 3: Search the internet
+
+Use **WebSearch** and **WebFetch**.
+
+### Search strategy
+1. **Broad first** — overview, best practices, common approaches
+2. **Deep dive** — official docs, GitHub issues, Stack Overflow, authoritative blogs
+3. **Compare** — if multiple solutions exist, list pros / cons of each
+
+### Source priority
+1. Official documentation
+2. GitHub issues / release notes (quirks, known bugs)
+3. Stack Overflow (accepted answers with high scores)
+4. Authoritative blogs (Anthropic, framework authors, well-known engineers)
+5. Recent > old — prefer last 2 years unless evergreen
+
+### Search tips
+- **Prefer English queries** — richer, more recent results
+- Include library + version when version-sensitive (e.g., `nestjs 10 typeorm migrations`)
+- Cross-validate across at least 2–3 independent sources
+- When sources conflict, prefer most recent + most authoritative; note the conflict
+
+### Gate
+- [ ] At least 2 independent sources for the recommendation
+- [ ] Sources are < 2 years old (or "evergreen" justified)
+
+---
+
+## Step 4: Synthesize results
+
+Present findings in this format:
+
+```markdown
+## Problem
+{Short summary of the problem, with project context — stack, constraints, goal}
+
+## Solutions Found
+
+### Solution 1: {Name}
+- **Description:** {How it works}
+- **Pros:** {...}
+- **Cons:** {...}
+- **Fit for this project:** {High / Medium / Low — why}
+- **Source:** {link}
+
+### Solution 2: {Name} (if applicable)
+- ...
+
+## Recommendation
+{Which solution fits best and why — reference architecture doc / stack conventions}
+
+## Code Example (if applicable)
+{Minimal snippet showing the recommended approach, adapted to the project's stack}
+
+## Caveats / Known Issues
+- {Gotcha 1}
+- {Gotcha 2}
+
+## References
+- {link 1} — {what this source gave us}
+- {link 2} — {...}
+```
+
+---
+
+## Hard Rules
+
+- **Research and propose — do NOT implement.** Wait for user confirmation before touching code
+- **Consider project context:** stack, architecture, conventions. A solution idiomatic in one project can be wrong in another
+- **Narrow scope when too broad:** if the topic is too wide (e.g., "how to do auth"), ask the user to narrow it
+- **Flag stale answers:** if top answers are 3+ years old and the library has had major versions since, mention it and check release notes
+- **No hallucinated APIs:** if uncertain whether a method / option exists, verify in official docs before recommending
+- **Cite sources:** every non-trivial claim should have a link
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| You want to prototype the chosen approach | `/research:spike` |
+| You already know the approach and want to implement | `/feature:new` / `/fix:hotfix` |
+| You're debugging a known bug (not researching options) | `/fix:root-cause` |
+| You want to write the research up as a design doc | `/docs:write` |
+
+---
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| Search | `@docs-writer` | Frame the research output as a design note |
+| Synthesize | `@api-designer` | If researching API patterns |
+| Synthesize | `@security-audit` | If researching anything auth / crypto / data handling |

package/assets/skills/{architect-review → review/architect}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: architect-review
+name: review-architect
 description: DDD architecture compliance review with automated checks and review loop. Use when user says "architect-review", "architecture review", "review architecture", "check architecture", "review ddd", "ddd review".
 args: "[ARCHITECTURE_NAME] [DOMAIN]"
 ---
@@ -8,12 +8,21 @@ args: "[ARCHITECTURE_NAME] [DOMAIN]"
 
 Review codebase against DDD architecture guidelines with automated checks and a review loop that keeps fixing until all checks pass.
 
+## When to use this skill
+
+- ✅ Verify DDD compliance for a domain after `/feature:new` or `refactor`
+- ✅ Periodic audit of an existing codebase
+- ✅ As a quality gate before merging architectural changes
+- ❌ Reviewing a PR end-to-end (code quality + arch) → use `/review:pr`
+- ❌ Reviewing own branch before push → use `/review:branch`
+- ❌ Looking for security bugs → use `@security-audit` agent
+
 ## Usage
 
 ```bash
-/architect-review go-backend wallet
-/architect-review react-frontend
-/architect-review
+/review:architect go-backend wallet
+/review:architect react-frontend
+/review:architect
 ```
 
 ## Supported Architectures
@@ -346,15 +355,15 @@ LOOP:
 
 ## Calling from Other Skills
 
-This skill is designed to be called by `new-feature` and `refactor` skills at the end of their workflows:
+This skill is designed to be called by `/feature:new` and `/feature:refactor`s at the end of their workflows:
 
 ```
 # From new-feature skill, after Phase 5 (registration):
-→ Run /architect-review {detected_stack} {domain}
+→ Run /review:architect {detected_stack} {domain}
 → Review loop until score >= B
 
 # From refactor skill, after Phase 4 (cleanup):
-→ Run /architect-review {detected_stack} {domain}
+→ Run /review:architect {detected_stack} {domain}
 → Review loop until score >= B
 ```
 
@@ -391,3 +400,24 @@ P: Ports                  EV: Events         U: UseCases
 SVC: Services             H: Handlers        L: Listeners
 I: Infrastructure
 ```
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Full PR review (arch + code quality + security + tests) | `/review:pr` |
+| Self-review own branch before push | `/review:branch` |
+| Refactor to fix violations found here | `refactor` |
+| Add tests if missing | `/review:tdd` |
+| Called from `/feature:new` / `refactor` review loop | (automatic — no manual invoke) |
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| LOAD | `@clean-architect` | Interpret architecture rules |
+| AUTOMATED CHECKS | `@devops` | Build / lint / test scripts |
+| MANUAL REVIEW | `@code-reviewer` | Spot violations |
+| FIX | Stack-specific dev agent | Apply fixes |

package/assets/skills/{review-changes → review/branch}/SKILL.md

@@ -1,15 +1,24 @@
 ---
-name: review-changes
+name: review-branch
 description: Review local branch changes for architecture compliance, conventions, and code quality before pushing/PR. Stack-aware — detects the project stack and applies the matching rules. Use when user says "review changes", "review branch", "check branch", "check changes", "review my code", "review before pr".
 args: "[BASE_BRANCH]"
 ---
 
 # Review Local Branch Changes
 
-Review all code changes on the current branch (vs a base branch) for **architecture compliance**, **stack conventions**, and **code quality**. Focus on changed files only — not the entire codebase. This is the pre-PR companion to `pr-review` (which reviews remote PRs).
+Review all code changes on the current branch (vs a base branch) for **architecture compliance**, **stack conventions**, and **code quality**. Focus on changed files only — not the entire codebase.
 
 **ARGUMENTS:** (optional) base branch to compare against. Default: `main` (or `master` if `main` does not exist).
 
+## When to use this skill
+
+- ✅ Before pushing your branch / opening a PR (self-review)
+- ✅ Before asking a teammate to review (catch easy issues first)
+- ✅ Quick sanity check on a feature you've been working on
+- ❌ Reviewing someone else's PR → use `/review:pr`
+- ❌ Only checking architecture compliance → use `/review:architect`
+- ❌ Hunting for security issues only → use `@security-audit` agent
+
 ---
 
 ## Phase 0: Detect Stack & Load Architecture
@@ -302,11 +311,22 @@ If user says to fix:
 
 ---
 
-## Relationship to Other Skills
+## Related Skills
 
 | Skill | When to use |
 |-------|-------------|
-| `review-changes` (this) | Local branch changes, pre-push / pre-PR |
-| `pr-review` | Remote PR review via `gh pr` — includes posting feedback to GitHub |
-| `architect-review` | Deep DDD architecture audit of a domain (not just changes) |
-| `fix-pr-comment` | Fix feedback posted on an existing PR |
+| `/review:branch` (this) | Local branch changes, pre-push / pre-PR |
+| `/review:pr` | Remote PR review via `gh pr` — includes posting feedback to GitHub |
+| `/review:architect` | Deep DDD architecture audit of a domain (not just changes) |
+| `/fix:pr-comment` | Fix feedback posted on an existing PR |
+| `/fix:hotfix` | Fixing the issues found here |
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| Phase 3 (architecture) | `@clean-architect` | DDD compliance |
+| Phase 4 (security) | `@security-audit` | Vulnerability check |
+| Phase 5 (quality) | `@code-reviewer` | Code smells |
+| Phase 6 (tests) | `@test-writer` | Test coverage check |
+| Phase 8 (fix) | Stack-specific dev agent | Apply fixes |

package/assets/skills/{pr-review → review/pr}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pr-review
+name: review-pr
 description: Thorough pull request review workflow with architecture compliance checks. Use when reviewing pull requests, checking code changes, or when user says "review pr", "check pr", "review code", "pr review", "review pull request".
 ---
 
@@ -7,38 +7,18 @@ description: Thorough pull request review workflow with architecture compliance
 
 Comprehensive workflow for reviewing pull requests with architecture compliance and quality gates.
 
-## IMPORTANT: Read Architecture First
+## When to use this skill
 
-**Before reviewing any code, you MUST read the appropriate architecture reference:**
+- ✅ Reviewing someone else's open PR (`gh pr view <number>` accessible)
+- ✅ Need to post structured feedback (APPROVE / REQUEST CHANGES / COMMENT)
+- ✅ Want a multi-dimensional review (architecture + security + perf + tests)
+- ❌ Self-review of your own branch before push → use `/review:branch`
+- ❌ Only checking DDD compliance → use `/review:architect`
+- ❌ Addressing comments on your own PR → use `/fix:pr-comment`
 
-### Global Architecture Files
-```
-~/.claude/architecture/
-├── clean-architecture.md    # Core principles for all projects
-├── flutter-mobile.md        # Flutter + Riverpod
-├── react-frontend.md        # React + Vite + TypeScript
-├── go-backend.md            # Go + Gin
-├── laravel-backend.md       # Laravel + PHP
-├── remix-fullstack.md       # Remix fullstack
-└── monorepo.md              # Monorepo structure
-```
-
-### Project-specific (if exists)
-```
-.claude/architecture/        # Project overrides
-```
-
-**Review must verify compliance with architecture patterns defined in these files.**
+## Read Architecture First
 
-## Recommended Agents
-
-| Phase | Agent | Purpose |
-|-------|-------|---------|
-| ANALYZE | `@clean-architect` | Architecture compliance check |
-| REVIEW | `@code-reviewer` | Code quality and best practices |
-| REVIEW | `@security-audit` | Security vulnerabilities scan |
-| REVIEW | `@perf-optimizer` | Performance analysis |
-| REVIEW | `@test-writer` | Test coverage and quality |
+Read `ddd-architecture.md` + stack-specific doc — review must verify compliance.
 
 ## Workflow Overview
 
@@ -618,3 +598,24 @@ PR review is complete when:
 4. Decision made (approve/request/comment)
 5. Review posted to GitHub
 6. Author knows exactly what to do next
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Reviewing own branch before push | `/review:branch` |
+| Only checking DDD architecture | `/review:architect` |
+| Fixing comments on your own PR | `/fix:pr-comment` |
+| Bug surfaced by review | `/fix:hotfix` |
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| ANALYZE | `@clean-architect` | Architecture compliance |
+| REVIEW | `@code-reviewer` | Code quality + best practices |
+| REVIEW | `@security-audit` | Security vulnerabilities |
+| REVIEW | `@perf-optimizer` | Performance analysis |
+| REVIEW | `@test-writer` | Test coverage + quality |

package/assets/skills/review/tdd/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: review-tdd
+description: Test-Driven Development workflow. Use when doing TDD, writing tests first, or when user says "tdd", "test first", "test driven", "red green refactor".
+---
+
+# Test-Driven Development (TDD) Workflow
+
+Red-Green-Refactor cycle: write failing test → write minimal code to pass → refactor while keeping tests green.
+
+## When to use this skill
+
+- ✅ Implementing logic with clear input → output behavior (parsers, validators, business rules, usecases)
+- ✅ Fixing a bug — write the failing test first, then fix (regression guard)
+- ✅ Refactoring critical code where you need a safety net
+- ❌ UI prototyping / visual tweaks → manual is faster
+- ❌ Exploratory spike → use `/research:spike` (throwaway code, no tests needed)
+- ❌ One-line config change → just change it
+
+---
+
+## The TDD Cycle
+
+```
+       ┌──────┐    ┌───────┐    ┌──────────┐
+   ┌──▶│ RED  │───▶│ GREEN │───▶│ REFACTOR │──┐
+   │   └──────┘    └───────┘    └──────────┘  │
+   │   (fail)      (minimal)    (cleanup)     │
+   └──────────────────────────────────────────┘
+              next requirement
+```
+
+## Read Architecture First
+
+Read the stack architecture doc for:
+- Test file location convention (e.g., `_test.go` next to source, `__tests__/` for Jest)
+- Test framework (Go testing, Jest, Pest, Flutter test)
+- Mocking patterns for ports (interfaces)
+- AAA (Arrange-Act-Assert) layout
+
+---
+
+## Phase 1: RED — Write a failing test
+
+**Goal:** describe the behavior you want with a test that fails because the code doesn't exist yet.
+
+### Steps
+1. Pick ONE small requirement (the smallest behavior you can verify)
+2. Write the test name as a sentence describing the behavior
+3. Arrange: set up inputs and mocks
+4. Act: call the method
+5. Assert: verify the expected output / state change / event raised
+6. Run the test — it MUST fail (compile error or assertion fail). If it passes, the test is wrong.
+
+### Test name conventions
+- `should_<expected_behavior>_when_<condition>` (snake_case for Go/Python)
+- `it("returns X when Y", ...)` (Jest / Mocha)
+- `test_<behavior>_<condition>` (PHPUnit)
+
+### AAA pattern
+```
+// Arrange — set up inputs and mocks
+// Act     — call the function under test
+// Assert  — verify result / state / interactions
+```
+
+### Gate
+- [ ] Test fails for the RIGHT reason (compile error or assertion fail, not a typo)
+- [ ] Test name describes behavior, not implementation
+- [ ] Only ONE behavior tested per test
+
+---
+
+## Phase 2: GREEN — Make it pass with minimal code
+
+**Goal:** write the smallest amount of code that makes the test pass. **Resist** the urge to "do it properly" — refactor comes next.
+
+### Rules
+- **Minimal** means: hardcode return values if the test allows it; you'll triangulate with more tests
+- Don't add code not required by a test
+- Don't add error handling unless a test requires it
+- Don't generalize until 3+ tests force you to
+
+### Steps
+1. Run the failing test (confirm RED)
+2. Write just enough code to make it green
+3. Run all tests — all must pass (not just the new one)
+4. If other tests broke, you're not minimal — revert and try smaller
+
+### Gate
+- [ ] New test passes
+- [ ] All previous tests still pass
+- [ ] No untested behavior added
+
+---
+
+## Phase 3: REFACTOR — Clean up while green
+
+**Goal:** improve structure without changing behavior. Tests must stay green throughout.
+
+### What to refactor
+- **Duplication** — extract function / method / class
+- **Long methods** — split when one method does multiple things
+- **Bad names** — rename to reveal intent (most underrated refactor)
+- **Dead branches** — remove code no test exercises
+- **Coupling** — break dependencies that make tests painful
+
+### Rules
+- **Run tests after every change** — green is the safety net
+- **One refactor at a time** — extract method, run tests, rename, run tests, …
+- **No new behavior** — if a refactor needs a new test, you're not refactoring, go back to RED
+
+### When NOT to refactor
+- Tests are flaky — fix the flakiness first
+- You're under time pressure — skip refactor, leave a TODO with link to a follow-up task
+- The code will be deleted soon — don't polish trash
+
+### Gate
+- [ ] All tests still green
+- [ ] No new public API added
+- [ ] Code is easier to read than before
+
+---
+
+## Test patterns per layer (DDD)
+
+| Layer | Test type | Dependencies | Example |
+|-------|-----------|--------------|---------|
+| Value Object | Unit (pure) | None | `Money.add()` |
+| Entity | Unit (pure) | None | `Order.cancel()` raises event |
+| UseCase | Unit | Mock ports | `CreateOrder` calls `OrderStore.save()` |
+| Handler / Controller | Integration | Real router, mock service | `POST /orders` returns 201 |
+| Infrastructure | Integration | Real DB / testcontainers | `OrderRepository.save()` persists |
+| Listener | Unit | Mock infra | `on_order_created` sends email |
+
+### Mock vs real
+- Mock **interfaces** (ports), not concrete classes
+- Use real value objects and entities in tests — they're pure, no need to mock
+- Use real DB in infra tests via testcontainers or in-memory variant
+
+---
+
+## Common Mistakes
+
+| Mistake | Why it's bad | Fix |
+|---------|--------------|-----|
+| Writing tests AFTER the code | You'll test what's written, not what's needed | Always RED first |
+| Testing implementation, not behavior | Refactor breaks tests | Assert on outputs / observable state |
+| One test covers many behaviors | Fail message is unclear | One behavior per test |
+| Mocking value objects | Brittle, no real benefit | Use real ones — they're pure |
+| Skipping the REFACTOR phase | Tech debt accumulates | It's a phase, not optional |
+| Test depends on order | Flaky | Each test sets up its own state |
+
+---
+
+## Final Report
+
+```markdown
+## TDD Cycle Complete: {feature}
+
+### Cycles Done
+| # | RED behavior | GREEN | REFACTOR |
+|---|-------------|-------|----------|
+| 1 | {behavior} | {code added} | {what cleaned} |
+| 2 | ... | ... | ... |
+
+### Test Coverage
+- {N} tests, all passing
+- Coverage: {%} (target: ≥80% for domain layer)
+
+### Files
+- Tests: {paths}
+- Code: {paths}
+```
+
+---
+
+## Hard Rules
+
+- **RED first, always** — never write production code without a failing test driving it
+- **Minimal GREEN** — hardcode if the test allows it; triangulate later
+- **REFACTOR is a phase, not optional**
+- **All tests green at all times** (except briefly during RED)
+- **One behavior per test**, named after the behavior
+
+---
+
+## Related Skills
+
+| When | Use |
+|------|-----|
+| Building a feature from scratch (with TDD inside) | `/feature:new` + this skill |
+| Adding regression test for a bug | `/fix:hotfix` or `/fix:root-cause` → then this skill |
+| Refactoring untested legacy code (add tests first) | `refactor` |
+| Reviewing test quality on a PR | `/review:pr` |
+
+---
+
+## Recommended Agents
+
+| Phase | Agent | Purpose |
+|-------|-------|---------|
+| RED | `@test-writer` | Write failing tests first |
+| GREEN | Stack-specific dev agent | Minimal implementation |
+| REFACTOR | `@refactor` | Clean up patterns |
+| REFACTOR | `@code-reviewer` | Review refactored code |
+| REFACTOR | `@perf-optimizer` | Performance tweaks (only with benchmarks) |

package/bin/cli.js

@@ -9,6 +9,7 @@ import { postinstallCommand } from '../dist/commands/postinstall.js';
 import { enableCommand } from '../dist/commands/enable.js';
 import { disableCommand } from '../dist/commands/disable.js';
 import { statusCommand } from '../dist/commands/status.js';
+import { upgradeCommand } from '../dist/commands/upgrade.js';
 
 const require = createRequire(import.meta.url);
 const pkg = require('../package.json');
@@ -26,7 +27,7 @@ program
   .option('-g, --global', 'Install globally')
   .option('-p, --project', 'Install to current project')
   .option('-a, --all', 'Install both globally and to project')
-  .option('-t, --target <editor>', 'Target editor (claude, cursor, windsurf, antigravity)')
+  .option('-t, --target <editor>', 'Target editor (claude, codex, cursor, windsurf, antigravity)')
   .option('--symlink', 'Force symlinks (default on macOS/Linux)')
   .option('--no-symlink', 'Force copy (default on Windows)')
   .action(installCommand);
@@ -37,6 +38,7 @@ program
   .option('-g, --global', 'Uninstall from ~/.claude/')
   .option('-p, --project', 'Uninstall from current project ./.claude/')
   .option('-a, --all', 'Uninstall from both locations')
+  .option('-t, --target <editor>', 'Target editor (claude, codex, cursor, windsurf, antigravity)')
   .action(uninstallCommand);
 
 program
@@ -44,6 +46,7 @@ program
   .description('List installed agents, commands, and skills')
   .option('-g, --global', 'List global installations')
   .option('-p, --project', 'List project installations')
+  .option('-t, --target <editor>', 'Target editor (claude, codex)')
   .action(listCommand);
 
 program
@@ -72,6 +75,14 @@ program
   .description('Show enabled/disabled status of all items')
   .option('-g, --global', 'Show global status')
   .option('-p, --project', 'Show project status')
+  .option('-t, --target <editor>', 'Target editor (claude, codex)')
   .action(statusCommand);
 
+program
+  .command('upgrade')
+  .description('Upgrade moicle to the latest version from npm')
+  .option('-y, --yes', 'Skip confirmation prompt')
+  .option('--reinstall', 'Automatically re-run "moicle install" after upgrade')
+  .action(upgradeCommand);
+
 program.parse();

package/dist/commands/install.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"install.d.ts","sourceRoot":"","sources":["../../src/commands/install.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,cAAc,EAAmC,MAAM,aAAa,CAAC;AA8QnF,eAAO,MAAM,cAAc,GAAU,SAAS,cAAc,KAAG,OAAO,CAAC,IAAI,CAuG1E,CAAC"}
+{"version":3,"file":"install.d.ts","sourceRoot":"","sources":["../../src/commands/install.ts"],"names":[],"mappings":"AAIA,OAAO,KAAK,EAAE,cAAc,EAAmC,MAAM,aAAa,CAAC;AAyenF,eAAO,MAAM,cAAc,GAAU,SAAS,cAAc,KAAG,OAAO,CAAC,IAAI,CA0H1E,CAAC"}