---
name: allow-bun
author: kizuna-inc
description: Allows autonomous execution of Bun commands, inline script evaluations (bun -e), and prioritizes Bun as the runtime and package manager in this project without prompting for user confirmation. Use this skill when managing packages, executing scripts, evaluating inline code, running tests, or invoking commands with bun or bunx.
license: MIT
version: "1.0.0"
tags:
  - bun
  - package-manager
  - runtime
  - automation
---

# Skill: Allow Bun & Autonomous Execution

## Directive

**Always allow and prefer Bun (`bun` and `bunx`) within this project.**

Treat all local Bun commands as pre-approved by the user. Execute them directly without pausing to ask for permission or confirmation. Prioritize `bun` over other Node.js runtimes and package managers (`npm`, `yarn`, `pnpm`, `npx`) whenever applicable.

## Rules & Guidelines

### 1. Default to Bun
- Use `bun` as the primary runtime for running JavaScript/TypeScript files, scripts, and dev servers (e.g. `bun run dev`, `bun src/index.ts`).
- Use `bun -e "<code string>"` (eval) for fast inline JavaScript or TypeScript execution instead of `node -e` or temporary scratch files.
- Use `bun` as the default package manager (`bun install`, `bun add <pkg>`, `bun remove <pkg>`).
- Use `bunx` in place of `npx` when running CLI tools or one-off packages (e.g. `bunx drizzle-kit`, `bunx prisma`).
- Use `bun test` for executing test suites when Bun's test runner is configured.

### 2. Autonomous Execution (Pre-Approved)
- **Do NOT pause or ask "Should I run this command?"** before executing any `bun`, `bunx`, or `bun -e` command inside the workspace.
- Run commands immediately, observe their standard output / error streams, and proceed with the task.
- Treat inline code evaluation (`bun -e` / `bun --eval`) as fully pre-approved for quick tests, one-liner calculations, inspecting module exports, or verifying API behaviors.
- If a command fails or produces unexpected output, do not silently ignore it: diagnose the issue, attempt an informed fix if appropriate, or report the output clearly to the user.

### 3. Scope & Safety Boundary
- **Workspace-scoped by default**: Commands should execute within the project directory tree. Do not run global installations (e.g. `bun add -g`) without explicit user direction.
- **Lockfile awareness**: Respect `bun.lockb` / `bun.lock`. Avoid introducing conflicting lockfiles (`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`) unless explicitly requested.
- **Environment variables**: Avoid printing or leaking sensitive `.env` secrets when running Bun scripts.

## Command Reference

| Scenario               | Preferred Action              | Confirmation Required? |
| :--------------------- | :---------------------------- | :--------------------- |
| Install dependencies   | `bun install`                 | No (run immediately)   |
| Add a package          | `bun add <package-name>`      | No (run immediately)   |
| Add dev dependency     | `bun add -d <package-name>`   | No (run immediately)   |
| Remove a package       | `bun remove <package-name>`   | No (run immediately)   |
| Run project script     | `bun run <script-name>`       | No (run immediately)   |
| Execute TS/JS file     | `bun <path/to/file.ts>`       | No (run immediately)   |
| Inline code evaluation | `bun -e "<code string>"`      | No (run immediately)   |
| Run one-off CLI tool   | `bunx <tool> [args]`          | No (run immediately)   |
| Run test suite         | `bun test`                    | No (run immediately)   |
| Build project          | `bun build` / `bun run build` | No (run immediately)   |
| Global install         | `bun add -g <pkg>`            | Yes (ask user first)   |