diff --git a/.cursor/commands/commit.md b/.cursor/commands/commit.md
new file mode 100644
index 0000000..1f91e24
--- /dev/null
+++ b/.cursor/commands/commit.md
@@ -0,0 +1,57 @@
+# Commit changes following project rules
+
+When creating or suggesting git commits, follow these rules. Full details in `agent.md`.
+
+## Message format
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+<footer>
+```
+
+- **Type** (required): `feat` | `fix` | `refactor` | `test` | `docs` | `chore` | `style`
+- **Scope** (optional): `app` | `frontend` | `backend` | `tauri` | `crates` | `docs` | `scripts` | `config`
+- **Subject** (required): imperative, lowercase start, ≤50 chars, no trailing period
+- **Body** (optional): wrap at 72 chars; explain what and why
+- **Footer** (optional): breaking changes, issue refs
+
+## Principles
+
+1. Single purpose per commit
+2. Split unrelated changes into separate commits
+3. Each commit should be independently meaningful
+4. Prefer small, logical units
+
+## Pre-commit (required)
+
+**TypeScript/JavaScript**: Run `pnpm run format`; run `pnpm run lint`; stage any changed files; then commit.
+
+**Rust**: Run `cargo fmt --all -- --check` (fix with `cargo fmt --all` if needed); run `cargo clippy --all-targets --all-features -- -D warnings` and fix all warnings; then commit.
+
+## Post-commit (required)
+
+After committing: write a summary to an MD file. The file must include:
+
+1. **Title** (e.g. branch name or commit subject)
+2. **Work content**: what was done — goals, changes, and outcomes in prose (PR-style). If tests were added or updated, mention that (e.g. "Tests were added for …" or "Test coverage includes …").
+
+**Do not commit this MD file** (add to `.gitignore` or leave unstaged).
+
+## Examples
+
+```
+feat(frontend): add code execution panel
+
+- Implement React component for JavaScript code execution
+- Support real-time code execution results
+```
+
+```
+refactor(tauri): move file operations to Rust backend
+
+- Remove JavaScript-based file operations
+- Add Tauri command for file read/write
+```
diff --git a/.cursor/commands/copilot-review.md b/.cursor/commands/copilot-review.md
new file mode 100644
index 0000000..00bf7bc
--- /dev/null
+++ b/.cursor/commands/copilot-review.md
@@ -0,0 +1,51 @@
+# Apply GitHub Copilot review feedback
+
+Review Copilot feedback on a branch/PR and apply the suggested changes.
+
+## Input
+
+- **Branch/PR link** (optional): User may provide the link (e.g. `https://github.com/owner/repo/pull/123`). If not provided, use GitHub CLI to find the PR for the **current branch**:
+  ```bash
+  gh pr view --json number,url  # from repo root; fails if no PR for current branch
+  # or
+  gh pr list --head $(git branch --show-current) --state open --json number,url
+  ```
+  - If exactly one PR exists for the current branch, use that PR. If none or multiple, ask the user for the PR link (or pasted review text).
+- **Review text**: User may paste Copilot review text directly; use that as the source of feedback.
+
+## Steps
+
+1. **Get the review**:
+   - If the user pasted a PR link: open or fetch that PR and find the GitHub Copilot review (summary and/or file comments).
+   - If the user did **not** provide a link: run `gh pr view` from the repo root (or `gh pr list --head $(git branch --show-current) --state open`). If one PR is found for the current branch, use that PR; otherwise say "No PR for the current branch" or "Multiple PRs found" and ask for the PR link.
+   - If the user pasted the review text directly: use that as the source of feedback.
+   - With the PR: use `gh pr view <number>` or the web URL to check the PR conversation for Copilot review.
+
+2. **Read the feedback**:
+   - Summarize what Copilot suggested (e.g. style, security, logic, tests).
+   - Identify which files and lines each comment refers to.
+
+3. **Apply the changes**:
+   - Edit the codebase to address each suggestion where it makes sense.
+   - Prefer accepting suggestions that improve correctness, security, or maintainability; skip or adapt ones that conflict with project rules or intent.
+   - Run format/lint after edits (`pnpm run format`, `pnpm run lint` for TS/JS; `cargo fmt`, `cargo clippy` for Rust).
+
+4. **Reply to the user**:
+   - List what was changed and what was skipped (and why, if relevant).
+   - Ask for the PR link (or pasted review text) only when no PR was found for the current branch via `gh pr view` / `gh pr list`, or when the user needs to specify a different PR.
+
+5. **Update PR content** (after applying Copilot review):
+   - Add to `branch-summary.md` (or the PR description source) a short section describing what Copilot suggested and what was applied (e.g. "Copilot review: applied AGENTS.MD casing, frontmatter name/model, Redux export alignment").
+   - If the branch is already pushed and a PR exists, suggest or run `gh pr edit --body-file branch-summary.md` so the PR description reflects the Copilot review work. Do not commit `branch-summary.md`; it is used only for the PR body.
+
+6. **Resolve review threads** (after applying feedback):
+   - For each Copilot comment thread that was addressed, mark the conversation as **resolved** on GitHub so the PR does not show unresolved threads.
+   - **Web**: PR → "Files changed" → open each comment → "Resolve conversation".
+   - **CLI**: `gh` has no built-in resolve command; use GraphQL: `gh api graphql -f query='mutation { resolveReviewThread(input: { threadId: "PRRT_xxx" }) { thread { isResolved } } }'` with the thread ID from the PR (e.g. from `pull-requests/pr-N/comments.json` or the review comment payload). Run once per unresolved thread.
+
+## Notes
+
+- **PR source**: If the user did not provide a link, first run `gh pr view` (or `gh pr list --head $(git branch --show-current)`) to see if the current branch has a PR; use it when exactly one is found. Ask for the PR link or pasted review text only when no PR is found or the user must specify a different PR.
+- Do not commit automatically; let the user review the diff and run `/commit` if they want to commit.
+- After applying Copilot review, always update the PR content (branch-summary.md) and optionally refresh the PR body with `gh pr edit --body-file branch-summary.md`.
+- After applying feedback, resolve the addressed review threads on GitHub (web "Resolve conversation" or `gh api graphql` with `resolveReviewThread` and the thread ID).
diff --git a/.cursor/commands/init-pr.md b/.cursor/commands/init-pr.md
new file mode 100644
index 0000000..90e75b3
--- /dev/null
+++ b/.cursor/commands/init-pr.md
@@ -0,0 +1,37 @@
+# PR 전 gh 계정·SSH 설정 (이 레포 전용)
+
+이 레포(ohah/executeJS)에서는 **ohah** GitHub 계정으로 push·PR을 사용한다.
+
+## 해야 할 것
+
+- **SSH remote**: push가 ohah SSH 키를 쓰도록 origin을 `github.com-private` 로 맞춘다. (한 번만 하면 됨.)
+  ```bash
+  git remote set-url origin git@github.com-private:ohah/executeJS.git
+  ```
+  `~/.ssh/config` 에 `Host github.com-private` 가 ohah용 키를 쓰도록 설정되어 있어야 한다.
+- **gh**: `gh auth switch` 로 ohah 계정을 쓰면 된다.
+
+## 수동으로 할 때
+
+이 레포에서 PR 만들기·푸시 전에:
+
+```bash
+gh auth switch --hostname github.com --user ohah
+```
+
+작업 끝난 뒤 다른 레포로 갈 때, 원래 쓰던 계정으로 돌리려면:
+
+```bash
+gh auth switch --hostname github.com --user <원래_계정명>
+```
+
+## /pr 커맨드 동작
+
+`/pr` 실행 시 에이전트가 자동으로:
+
+1. origin이 `git@github.com-private:ohah/executeJS.git` 인지 확인하고, 아니면 **한 번 설정**한 뒤
+2. 현재 gh 로그인 계정을 확인하고,
+3. ohah가 아니면 **일시적으로 ohah로 전환**한 뒤 push·PR 생성/수정을 하고,
+4. **다시 원래 계정으로 전환**한다.
+
+그래서 `/pr` 한 번 실행해도 전역 gh 설정은 원래대로 유지된다.
diff --git a/.cursor/commands/pr.md b/.cursor/commands/pr.md
new file mode 100644
index 0000000..6eedb78
--- /dev/null
+++ b/.cursor/commands/pr.md
@@ -0,0 +1,104 @@
+# Create or Update a Pull Request
+
+Create or update a PR for the current branch. Follow the steps below.
+
+## What the agent should do
+
+1. **Check current branch and PR status**: `git branch --show-current`, `gh pr list --head <current-branch> --state all`
+2. **Determine base**: If the user specifies a base branch (e.g. "base is main", "base feat/xyz"), use that as the merge target.
+   - **If current branch equals base** → Create a new branch from the current one and open a PR with that new branch as head (see "When base and current branch are the same").
+   - Otherwise use the specified base.
+3. **Prepare body**: If `branch-summary.md` exists and fills the required sections (Purpose, Description, How to test, etc., or Title + Work content), use it as the PR body. If sections are missing, fill them before use.
+4. **Create or update PR**:
+   - No open PR → `gh pr create --head <current-branch> --base <base> --title "<title>" --body-file branch-summary.md`
+   - Open PR exists → Update body (and base via PATCH if base was specified and PR is open).
+5. **Push**: If there are unpushed commits, run `git push origin <current-branch>`.
+6. **Labels**: After creating or updating the PR, check `gh label list` and add labels that match the PR (e.g. feat, fix, docs).
+
+## Base branch (apply when user specifies it)
+
+- If the user **specifies a base branch** (e.g. "base is main", "base feat/menu-board"), **always** use that branch as the merge target (base).
+- **On create**: Pass `--base <user-specified-branch>` to `gh pr create`.
+- **On update**: If the PR is **open**, update the base via REST PATCH. If the PR is **closed**, base cannot be changed (update body only).
+  ```bash
+  gh api repos/ohah/executeJS/pulls/<PR-number> -X PATCH -f body=@branch-summary.md -f base="<user-specified-branch>"
+  ```
+  (If 422 on base change, treat as closed PR and PATCH body only.)
+
+## When base and current branch are the same
+
+- If the user set base=XXX and **the current branch is also XXX**, self-merge is not allowed. **Create a new branch** from the current one and use that as the PR head.
+- Steps:
+  1. From the current branch (XXX), create a new branch: `git checkout -b feat/xxx-description` (name it by the work).
+  2. If there are uncommitted changes, stage and commit (and push) on the new branch.
+  3. `gh pr create --head <new-branch> --base XXX --title "..." --body-file branch-summary.md --assignee @me`
+  4. Push the new branch: `git push -u origin <new-branch>`
+
+## gh account and SSH remote for this repo (ohah only)
+
+This repo (ohah/executeJS) uses the **ohah** GitHub account for push and PR.
+
+- **SSH remote**: So that `git push` authenticates as ohah, origin must use the SSH host `github.com-private` (see `~/.ssh/config`). Before any push, ensure origin is set to:
+  ```bash
+  git remote set-url origin git@github.com-private:ohah/executeJS.git
+  ```
+  (If it is already that URL, skip.)
+- **gh auth switch**: Before any push or `gh pr create` / `gh api .../pulls/...` PATCH: get current user with `gh api user -q .login`. If the result is not `ohah`, run `gh auth switch --hostname github.com --user ohah` and **remember the previous login** (e.g. `PREV_GH_USER=<that value>`).
+- **After** all push and gh PR operations are done: if you switched to ohah, restore the previous account with `gh auth switch --hostname github.com --user <PREV_GH_USER>` so the global gh account is unchanged.
+
+## Order of operations
+
+1. **Read user input**: If a base branch is specified, set base accordingly (see above).
+2. **SSH remote**: Ensure origin is `git@github.com-private:ohah/executeJS.git` so push uses ohah's SSH key; if not, run `git remote set-url origin git@github.com-private:ohah/executeJS.git`.
+3. **gh account**: Get current user: `gh api user -q .login`. If not `ohah`, run `gh auth switch --hostname github.com --user ohah` and store the previous login so you can switch back later.
+4. **Create or update PR with GitHub CLI**:
+   - If the branch is already pushed → use `--head <branch-name>` when creating.
+   - If base is specified → always pass `--base <base>` on create, or include base in PATCH on update (when PR is open).
+
+   ```bash
+   gh pr create --head $(git branch --show-current) --base <base> --title "<title>" --body-file branch-summary.md
+   ```
+
+   - If a PR already exists → Update body. If base was specified and PR is open, PATCH body and base.
+
+   ```bash
+   # body only:
+   gh api repos/ohah/executeJS/pulls/<PR-number> -X PATCH -f body=@branch-summary.md
+   # body + base:
+   gh api repos/ohah/executeJS/pulls/<PR-number> -X PATCH -f body=@branch-summary.md -f base="<base>"
+   ```
+
+5. **Push**: After create/update, if there are unpushed commits, push so the PR has the latest commits.
+
+   ```bash
+   git push origin $(git branch --show-current)
+   ```
+
+6. **If `gh` is not available**: Install [GitHub CLI](https://cli.github.com/) or open the PR in the browser (repo → Compare & pull request for the branch) and paste the contents of `branch-summary.md` as the description.
+
+7. **Labels**: On create use `--label <name>` (multiple allowed). On update use `gh pr edit <PR-number> --add-label <name>`. Choose labels from `gh label list` that fit the PR (e.g. feat, fix, docs, config).
+
+8. **Restore gh account**: If you switched to ohah in step 3, run `gh auth switch --hostname github.com --user <previous-login>` to restore the original gh account.
+
+## PR title rules
+
+- **If the user provides a title**: Use it as-is.
+- **If the user provides an issue ref** (e.g. `/pr fixes #123`): Use a prefix like `[#123]` and a short subject.
+- **If neither**: Use a short, imperative subject in English (e.g. from the first line of branch-summary or the main change). Prefer lowercase start and no trailing period.
+
+## PR body format
+
+Use `branch-summary.md` as the PR body. It should include at least:
+
+- **Title** (or Purpose): What this PR is for.
+- **Work content** (or Description): What was changed and why, in prose. If tests were added or updated, say so (e.g. "Tests were added for …" or "Test coverage includes …").
+
+If the repo has `.github/PULL_REQUEST_TEMPLATE.md`, align `branch-summary.md` with its sections (Purpose, Description, How to test, Additional info, Screenshots, etc.) when writing or updating it.
+
+## Notes
+
+- **Language**: Use **English** for PR title and body (per project rules).
+- **Base**: If the user specifies a base branch, always use it for create/update (and create a new head branch when base and current branch are the same).
+- **Body**: Keep `branch-summary.md` up to date and use it only for the PR description; do not commit it unless the project says otherwise.
+- **Push**: After updating the PR body, push any unpushed commits so the PR reflects the latest code.
+- **Labels**: Use `gh label list` and attach labels that match the PR type (feat, fix, docs, etc.).
diff --git a/.cursor/commands/review-apply.md b/.cursor/commands/review-apply.md
new file mode 100644
index 0000000..1fb170c
--- /dev/null
+++ b/.cursor/commands/review-apply.md
@@ -0,0 +1,67 @@
+# Apply PR review suggestions locally (review-apply)
+
+Fetch **review comments that contain suggestion blocks** from the PR for the current branch and apply those suggestions to the local files. This replicates GitHub's "Commit suggestion" locally.
+
+## When to use
+
+- Run this command from Cursor (e.g. command palette → "review-apply" or `/review-apply`).
+
+## Order of operations
+
+1. **Find the PR for the current branch**
+   - If there is no PR, say "There is no PR for the current branch" and stop.
+
+   ```bash
+   gh pr view --json number,headRefOid
+   ```
+
+   - If that fails: `gh pr list --head $(git branch --show-current)` to confirm.
+
+2. **Fetch review comments**
+
+   ```bash
+   gh api repos/ohah/executeJS/pulls/<PR-number>/comments
+   ```
+
+   - Use `path`, `line`, `start_line`, and `body`.
+
+3. **Keep only comments that have a suggestion block**
+   - Include only comments whose `body` contains ` ```suggestion `.
+   - Use a regex like `/```suggestion\s*([\s\S]*?)```/` to extract the **suggested code** from the block.
+   - For each such comment, record: `path`, `line`, `start_line` (or treat as single-line if missing), and `suggestedCode` (extracted text; preserve line endings).
+
+4. **When in doubt, ask the user**
+   - **Do not apply** automatically; instead briefly describe the situation and ask: "Apply all? / Only some? / Skip?"
+   - Do this when:
+     - There are **two or more** suggestions for the **same file and same line** (or overlapping line range).
+     - The **current content** at that line (or range) has changed a lot since the review, so pasting the suggestion might conflict or look wrong.
+     - The **file** in `path` does not exist locally (e.g. moved or deleted).
+     - The suggestion spans **multiple lines** but `start_line` is missing or the range is unclear.
+   - Once the user says "apply all", "apply only this one", or "skip", proceed accordingly.
+
+5. **Apply suggestions to local files**
+   - For each chosen suggestion:
+     - Open the file at `path`.
+     - **Single line**: Replace the line at `line` with the suggested line(s). If the suggestion has multiple lines, replace from that line downward by the number of lines in the suggestion.
+     - **Multiple lines** (when `start_line` and `line` exist): Replace the range `start_line` … `line` with the suggested code. If the suggested line count differs from the range length, replace using the suggested line count.
+   - Preserve **indentation** as in the suggestion. If the suggestion has no trailing newline, only replace the intended line(s).
+
+6. **Summarize what was applied**
+   - List in short form which files and lines (or ranges) were updated.
+   - Suggest: "Review the changes and use the `commit` command to commit when ready."
+
+7. **Optionally update the PR body**
+   - If at least one suggestion was applied, you may update the PR description.
+   - Add a line under **Description** or **Additional info** in `branch-summary.md`: "Review suggestions applied: (short summary)."
+   - Then PATCH the PR body:
+     ```bash
+     gh api repos/ohah/executeJS/pulls/<PR-number> -X PATCH -f body=@branch-summary.md
+     ```
+   - Use the PR number from step 1. Whether to commit `branch-summary.md` is up to the author.
+
+## Notes
+
+- Run from the repo root with `gh` authenticated.
+- Only **inline review comments** (on "Files changed") are used; general timeline comments are ignored.
+- Only text inside ` ```suggestion ` … ` ``` ` is applied; other text in the comment is not.
+- If the code has changed and line numbers or content no longer match, or if multiple suggestions target the same spot, **ask the user** before applying.
diff --git a/.cursor/commands/review.md b/.cursor/commands/review.md
new file mode 100644
index 0000000..ac2ebf8
--- /dev/null
+++ b/.cursor/commands/review.md
@@ -0,0 +1,98 @@
+# Review a Pull Request (AI review and post summary + inline suggestions)
+
+Fetch the PR for the current branch, have the AI review the code and description, then post **both** a **summary review (body)** and **line-level suggestions (inline comments)** to the PR.
+
+- **Summary review**: Write a review body in English covering: whether the PR purpose and description match the changes, what's done well, improvement suggestions (bugs, edge cases, performance, tests), and testing notes.
+- **Line-level suggestions**: For concrete code changes, add inline comments on the right file/line with a short explanation and, when applicable, a ` ```suggestion ``` ` block so the author can apply it on GitHub.
+
+## gh account for this repo (ohah only)
+
+This repo (ohah/executeJS) uses the **ohah** GitHub account for posting reviews.
+
+- **Before** submitting the review (`gh api .../reviews` or `gh pr comment`): get current user with `gh api user -q .login`. If the result is not `ohah`, run `gh auth switch --hostname github.com --user ohah` and **remember the previous login** (e.g. `PREV_GH_USER=<that value>`).
+- **After** submitting the review: if you switched to ohah, restore the previous account with `gh auth switch --hostname github.com --user <PREV_GH_USER>` so the global gh account is unchanged.
+
+## Order of operations
+
+1. **Branch and gh account (this repo / ohah only)**
+   - Run from the repo root. The review targets the **current branch**'s PR.
+   - Get current gh user: `gh api user -q .login`. If not `ohah`, run `gh auth switch --hostname github.com --user ohah` and store the previous login so you can restore later.
+
+2. **Find the PR for the current branch**
+   - If there is no PR, say "There is no PR for the current branch" and stop.
+
+   ```bash
+   gh pr view --json number,title,body,url,additions,deletions,changedFiles
+   ```
+
+   - If that fails (no PR): `gh pr list --head $(git branch --show-current)` to confirm.
+
+3. **Gather PR details and diff**
+   - PR meta and body: `gh pr view`
+   - Changed files: `gh pr diff --name-only`
+   - Full diff: `gh pr diff`
+   - Use this to build context for the review.
+
+4. **Write the AI review (summary + line suggestions)**
+   - **Summary body** (in English):
+     - **Purpose and description**: Do the PR purpose and description match the changes?
+     - **What's done well**: Structure, naming, conventions, consistency.
+     - **Improvement suggestions**: Potential bugs, edge cases, performance, tests, and other recommendations.
+   - **Line-level suggestions**: For each place that needs a change, prepare an inline comment with:
+     - **path**: Repo-root-relative path (e.g. `apps/executeJS/src/widgets/code-editor/code-editor.tsx`)
+     - **line**: Line number in the **new (right) side** of the diff.
+     - **side**: `"RIGHT"`
+     - **body**: Short explanation; if the change is a concrete code edit, include a ` ```suggestion ``` ` block so GitHub shows "Commit suggestion".
+
+5. **Submit the review (summary + inlines together when there are inlines)**
+   - **5-a. When there is at least one inline suggestion**
+     Submit **one** review that includes both the **body** and the **comments** array.
+     - **body**: The summary written in step 4 (what's done well, improvement summary, testing notes).
+     - **comments**: One entry per suggestion, e.g.:
+       - **path**: Repo-root-relative path
+       - **line**: Line number on the **new (right)** side. Verify against the actual file.
+       - **side**: `"RIGHT"`
+       - **body**: Short description + (if applicable) ` ```suggestion ` … ` ``` ` block.
+     - Example payload file (`review-payload.json`):
+       ````json
+       {
+         "commit_id": "<headRefOid>",
+         "event": "COMMENT",
+         "body": "## AI review\n\n### What's done well\n- ...\n\n### Improvement suggestions\n- ...\n\n### Testing\n- ...",
+         "comments": [
+           {
+             "path": "apps/executeJS/src/widgets/code-editor/code-editor.tsx",
+             "line": 42,
+             "side": "RIGHT",
+             "body": "Consider adding error handling for code execution.\n\n```suggestion\n  try {\n    const result = await executeCode(code);\n  } catch (error) {\n    console.error(error);\n  }\n```"
+           }
+         ]
+       }
+       ````
+     - Commands:
+       ```bash
+       gh pr view --json headRefOid -q .headRefOid   # use as commit_id
+       gh api repos/ohah/executeJS/pulls/$(gh pr view --json number -q .number)/reviews --input review-payload.json
+       ```
+     - You can delete `review-payload.json` after submitting.
+
+   - **5-b. When there are no inline suggestions**
+     Post only the summary as a single comment:
+
+     ```bash
+     gh pr comment $(gh pr view --json number -q .number) --body-file review-comment.md
+     ```
+
+     (Write the summary from step 4 into `review-comment.md` first. You can delete it after posting.)
+
+   - **Rule**: If there are line-level suggestions, use 5-a (one review with body + comments). If not, use 5-b (comment only).
+
+6. **Restore gh account (this repo / ohah only)**: If you switched to ohah in step 1, run `gh auth switch --hostname github.com --user <PREV_GH_USER>` to restore the original gh account.
+
+## Notes
+
+- Run from the repo root with `gh` authenticated. This repo (ohah/executeJS): use ohah for posting reviews; switch gh before submit and restore after (see "gh account for this repo" and step 1, step 6).
+- If the current branch has no PR, do not post a review; only output the message above.
+- **Inline comments**: `line` must be the line number on the **new (right)** side of the diff; `side` is `"RIGHT"`. Wrong line numbers can cause 422; confirm against the actual file.
+- **Suggestion blocks**: In the comment body, put the suggested code between ` ```suggestion ` and ` ``` ` so GitHub shows "Commit suggestion".
+- Keep the review within GitHub's comment length limits; use bullets and short paragraphs.
