@globant/coda-windows-x64 1.0.0

package/assets/skills/create-hook/SKILL.md

@@ -0,0 +1,442 @@
+---
+name: create-hook
+description: Explains how to create, configure, and use g-coda lifecycle hooks. Use when the user asks how to create a hook, configure hooks in config.json, write a hook script, or understand hook events and their payloads.
+---
+
+# g-coda Lifecycle Hooks
+
+Hooks are user-defined shell commands or HTTP endpoints that run automatically at specific points in g-coda's lifecycle. They let you audit tool calls, enforce policies, inject context, modify prompts, and automate workflows without changing g-coda's source code.
+
+---
+
+## Configuration location
+
+Hooks live in the `hooks` key of `config.json`. There are two scopes:
+
+| Scope | File |
+|-------|------|
+| **Project** (highest priority) | `.coda/config.json` in the project root |
+| **Global** | `~/.coda/config.json` |
+
+Project hooks are merged on top of global hooks. Both files use the same format.
+
+---
+
+## Config structure
+
+```json
+{
+  "hooks": {
+    "<EventName>": [
+      {
+        "matcher": "<optional pattern>",
+        "hooks": [
+          { "type": "command", "command": "<shell command>" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+- **`<EventName>`** — one of the supported lifecycle events (see below).
+- **`matcher`** — optional filter. Omit (or use `"*"`) to match all. For tool events, matched against the tool name. For `SessionStart`, matched against the session source (`"startup"`, `"resume"`, `"clear"`, `"compact"`). Supports exact strings, pipe-separated lists (`"Bash|Edit"`), and JavaScript regexes.
+- **`hooks`** — array of hook handlers to run when the matcher fires.
+
+---
+
+## Hook handler types
+
+### Command hook
+
+Spawns a shell command via `sh -c`. g-coda writes a JSON payload to the command's **stdin**. The command can write a JSON response to **stdout** to influence the agent.
+
+```json
+{
+  "type": "command",
+  "command": "python3 ~/.coda/hooks/my_hook.py",
+  "timeout": 30,
+  "statusMessage": "Running policy check…"
+}
+```
+
+| Field | Type | Default | Description |
+|-------|------|---------|-------------|
+| `command` | string | required | Shell command to run |
+| `args` | string[] | — | Extra arguments appended to the command |
+| `timeout` | number | 600 | Seconds before the hook is killed |
+| `shell` | `"bash"` \| `"powershell"` | system default | Shell to use |
+| `statusMessage` | string | — | Spinner text shown while the hook runs |
+| `if` | string | — | Conditional expression (tool events only) |
+
+### HTTP hook
+
+POSTs the JSON payload to a URL and reads the JSON response from the response body.
+
+```json
+{
+  "type": "http",
+  "url": "http://localhost:8080/hook",
+  "headers": { "Authorization": "Bearer $MY_TOKEN" },
+  "allowedEnvVars": ["MY_TOKEN"],
+  "timeout": 10
+}
+```
+
+---
+
+## Supported events
+
+> **All events below fire at runtime.** The config schema, the `/hooks` browser,
+> and the g-coda runtime all support every event in the table. A hook you attach
+> to any of them will actually run. Two events have important behavioral notes —
+> see the legend below the table.
+
+| Event | When it fires | Matcher query |
+|-------|--------------|---------------|
+| `PreToolUse` | Before a tool executes | tool name |
+| `PostToolUse` | After a tool succeeds | tool name |
+| `PostToolUseFailure` | After a tool throws an error | tool name |
+| `UserPromptSubmit` | When the user submits a message | — |
+| `SessionStart` | When a session is created | source (`startup`/`resume`/`clear`/`compact`) |
+| `SessionEnd` | When a session ends | — |
+| `Stop` | When the agent loop finishes a turn | — |
+| `PreCompact` | Before context compaction runs | — |
+| `PostCompact` | After context compaction completes | — |
+| `StopFailure` | When the agent loop errors out | — |
+| `SubagentStart` | When a subagent run begins | — |
+| `SubagentStop` | When a subagent run concludes | — |
+| `Notification` | When a user-facing notification is sent | — |
+| `PermissionRequest` | When a permission dialog is surfaced (observe-only) | — |
+| `PermissionDenied` | After a tool call is denied | — |
+| `ConfigChange` | After config is reloaded mid-session (`/reload-hooks`) | — |
+| `CwdChanged` | After a `cd` changes the working directory (best-effort) | — |
+| `FileChanged` | After a `write`/`edit` changes a file | — |
+| `InstructionsLoaded` | When an AGENTS.md file is loaded | — |
+
+Every event is emitted at runtime. Most are mapped from an extension hook in
+`packages/core/src/extensions/hooks-bridge.ts`; the rest are fired by exported
+`emit*Hook()` helpers in the same file, called from the owning runtime point
+(agent run manager, HITL manager, turn orchestrator, prompt builder, the
+`write`/`edit`/`bash` tools, and the CLI reload path).
+
+**Two behavioral notes:**
+
+- **`PermissionRequest` is observe-only.** It fires when the approval dialog is
+  surfaced, but it **cannot block a tool**. To block a tool before it runs, use
+  **`PreToolUse`** with `permissionDecision: "deny"`.
+- **`CwdChanged` is best-effort.** g-coda has no persistent working directory, so
+  it fires by detecting a leading `cd <path>` in a `bash` command. Complex shell
+  constructs (subshells, pipes, `pushd`) are not tracked.
+
+### Event payload notes
+
+The lifecycle events beyond the tool/session set carry event-specific fields on
+their stdin payload (in addition to the base fields):
+
+- `StopFailure` → `error`, `recoverable`
+- `SubagentStart` / `SubagentStop` → `run_id`, `agent_name`, `task`, `model`,
+  and (Stop only) `status`, `summary`, `error`
+- `Notification` → `notification_type`, `message`
+- `PermissionRequest` / `PermissionDenied` → `tool_name`, `tool_input`,
+  `question` (Request), `reason` (Denied)
+- `ConfigChange` → `change_source`
+- `CwdChanged` → `previous_cwd`, `new_cwd`
+- `FileChanged` → `file_path`, `tool_name`
+- `InstructionsLoaded` → `file_path`
+
+---
+
+## Input payload (stdin)
+
+Every hook receives a JSON object on stdin. All events include these base fields:
+
+```json
+{
+  "session_id": "abc123",
+  "transcript_path": "/path/to/transcript.json",
+  "cwd": "/path/to/project",
+  "hook_event_name": "PreToolUse",
+  "permission_mode": "default",
+  "agent_id": "...",
+  "agent_type": "main"
+}
+```
+
+Additional fields by event:
+
+**Tool events** (`PreToolUse`, `PostToolUse`, `PostToolUseFailure`):
+```json
+{
+  "tool_name": "bash",
+  "tool_input": { "command": "ls -la" },
+  "tool_use_id": "toolu_...",
+  "tool_response": "...",   // PostToolUse only
+  "error": "..."            // PostToolUseFailure only
+}
+```
+
+**`UserPromptSubmit`**:
+```json
+{ "prompt": "the user's message text" }
+```
+
+**`SessionStart`**:
+```json
+{ "source": "startup", "model": "claude-sonnet-4-5" }
+```
+
+**`Stop`**:
+```json
+{ "stop_reason": "end_turn" }
+```
+
+---
+
+## Output (stdout)
+
+Return a JSON object from stdout to influence the agent. All fields are optional.
+
+```json
+{
+  "continue": true,
+  "suppressOutput": false,
+  "systemMessage": "Text injected as a system message to the model",
+  "decision": "block",
+  "reason": "Reason shown to the user when blocking",
+  "hookSpecificOutput": {
+    "hookEventName": "PreToolUse",
+    "permissionDecision": "allow",
+    "permissionDecisionReason": "Approved by policy",
+    "updatedInput": { "command": "ls -la --color=never" },
+    "additionalContext": "Extra context appended to tool result",
+    "updatedPrompt": "Rewritten user prompt"
+  }
+}
+```
+
+| Field | Effect |
+|-------|--------|
+| `continue: false` | Stop the agent entirely; show `stopReason` to the user |
+| `systemMessage` | Inject a system message visible to the model |
+| `decision: "block"` | Block the current event (tool call, prompt, etc.) |
+| `decision: "approve"` | Approve without showing the permission dialog |
+| `hookSpecificOutput.permissionDecision` | `"allow"` / `"deny"` / `"ask"` for `PreToolUse` |
+| `hookSpecificOutput.updatedInput` | Replace the tool's input before execution (`PreToolUse`) |
+| `hookSpecificOutput.additionalContext` | Append text to the tool result (`PostToolUse`) |
+| `hookSpecificOutput.updatedPrompt` | Replace the user's prompt (`UserPromptSubmit`) |
+
+Exit code `0` = success. Any non-zero exit code is treated as an error (hook output is still read).
+
+---
+
+## Examples
+
+### Log every tool call to a file
+
+`.coda/config.json`:
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "hooks": [
+          { "type": "command", "command": "jq -r '[.hook_event_name, .tool_name] | @tsv' >> ~/.coda/tool-log.tsv" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+### Block `rm -rf` in Bash
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 -c \"\nimport json, sys\ndata = json.load(sys.stdin)\ncmd = data.get('tool_input', {}).get('command', '')\nif 'rm -rf' in cmd:\n    print(json.dumps({'decision': 'block', 'reason': 'rm -rf is not allowed'}))\n\""
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+### Inject environment variables on session start
+
+```json
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "matcher": "startup",
+        "hooks": [
+          { "type": "command", "command": "bash ~/.coda/hooks/set-env.sh" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+`~/.coda/hooks/set-env.sh`:
+```bash
+#!/usr/bin/env bash
+# Write env vars to the session env file so they are available in every Bash tool call
+SESSION_ENV_FILE="$HOME/.coda/session-env/$SESSION_ID/env.sh"
+mkdir -p "$(dirname "$SESSION_ENV_FILE")"
+echo "export MY_VAR=hello" >> "$SESSION_ENV_FILE"
+```
+
+### Rewrite a user prompt
+
+```json
+{
+  "hooks": {
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 ~/.coda/hooks/rewrite_prompt.py"
+          }
+        ]
+      }
+    ]
+  }
+}
+```
+
+`~/.coda/hooks/rewrite_prompt.py`:
+```python
+import json, sys
+
+data = json.load(sys.stdin)
+prompt = data["prompt"]
+
+# Prepend a context hint to every prompt
+updated = f"[Project: my-app] {prompt}"
+
+print(json.dumps({
+    "hookSpecificOutput": {
+        "hookEventName": "UserPromptSubmit",
+        "updatedPrompt": updated
+    }
+}))
+```
+
+---
+
+## End-to-end walkthroughs
+
+### Example 1 — log every bash command (`PreToolUse`)
+
+**User prompt:** *"Create a hook that logs every bash command I run to a file."*
+
+This works with config alone. Write the script and wire it via the matcher.
+
+`.coda/hooks/bash-audit.py`:
+```python
+#!/usr/bin/env python3
+import json, sys, time
+
+data = json.load(sys.stdin)
+command = data.get("tool_input", {}).get("command", "")
+with open(".coda/hooks-data/bash-audit.log", "a") as log:
+    log.write(f"{time.strftime('%Y-%m-%dT%H:%M:%S')}\t{command}\n")
+```
+
+`.coda/config.json`:
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "bash",
+        "hooks": [
+          { "type": "command", "command": "python3 .coda/hooks/bash-audit.py" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+Then **remind the user to run `/reload-hooks`**. The next bash tool call appends
+a line to `.coda/hooks-data/bash-audit.log`. (This mirrors the existing
+`.coda/hooks/token_cost.py` convention in this repo.)
+
+### Example 2 — react when a subagent finishes (`SubagentStop`)
+
+**User prompt:** *"Create a hook that runs whenever a subagent finishes."*
+
+`SubagentStop` fires at runtime, so this works with config alone. The payload
+includes `run_id`, `agent_name`, `task`, `status`, and (when present) `summary`.
+
+`.coda/hooks/subagent-log.py`:
+```python
+#!/usr/bin/env python3
+import json, sys, time
+
+data = json.load(sys.stdin)
+line = f"{time.strftime('%Y-%m-%dT%H:%M:%S')}\t{data.get('agent_name', '?')}\t{data.get('status', '?')}\n"
+with open(".coda/hooks-data/subagents.log", "a") as log:
+    log.write(line)
+```
+
+`.coda/config.json`:
+```json
+{
+  "hooks": {
+    "SubagentStop": [
+      {
+        "hooks": [
+          { "type": "command", "command": "python3 .coda/hooks/subagent-log.py" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+> **Reminder about the two special-case events.** `PermissionRequest` is
+> observe-only — to *block* a tool, use `PreToolUse` with
+> `permissionDecision: "deny"` instead. `CwdChanged` is best-effort and only
+> detects a leading `cd <path>` in a bash command.
+
+---
+
+## Disabling all hooks
+
+Set `disableAllHooks: true` in `config.json` to skip all hook execution (useful in CI):
+
+```json
+{ "disableAllHooks": true }
+```
+
+---
+
+## Reloading hooks
+
+Run `/reload-hooks` in the chat to reload hook configuration from disk without restarting g-coda.
+
+---
+
+## Instructions for the agent
+
+When the user asks to create a hook:
+
+1. **Identify the event** — ask which lifecycle event they want to hook into if not specified.
+2. **Note the two special-case events** — every event fires, but if the user wants to *block* a tool, use `PreToolUse` with `permissionDecision: "deny"` rather than `PermissionRequest` (which is observe-only); and remember `CwdChanged` is best-effort (`cd`-detection only). See the **Supported events** table.
+3. **Identify the scope** — ask whether the hook should be project-level (`.coda/config.json`) or global (`~/.coda/config.json`). Default to project-level.
+4. **Write the config** — add or update the `hooks` key in the appropriate `config.json`. If the file doesn't exist, create it with only the `hooks` key.
+5. **Write the script** (if needed) — for non-trivial logic, create a separate script file (Python or Bash) and reference it from the `command` field. Place scripts in `.coda/hooks/` (project) or `~/.coda/hooks/` (global).
+6. **Test** — remind the user to run `/reload-hooks` after saving changes.
+7. **Explain the payload** — show the user what JSON fields their script will receive on stdin for the chosen event.

package/assets/skills/create-skill/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: create-skill
+description: Create, modify, and improve skills in coda. Use if users want to create a new skill from scratch, edit an existing skill, decide whether a skill is project-scoped or global, validate skill structure, or understand skill architecture and best practices. e.g create a skill that ...
+---
+
+# TASK
+
+Before creating a skill, understand the intent. In an interactive session, use `ask_user` to clarify; in a headless/batch run (where `ask_user` is unavailable), infer from the prompt and proceed with reasonable defaults. 
+Aim to settle:
+1. What the skill is for, and what problem it solves.
+2. Whether it is **project-specific** (only this repo) or **general/global** (reused across projects). See [Choosing the Skill Location](#choosing-the-skill-location).
+3. Whether `scripts/`, `references/`, or `assets/` are actually needed, or a single SKILL.md is enough.
+
+Default to a **minimal SKILL.md**. Only add bundled resources when the use case clearly demands them.
+
+---
+
+## How Skills Work in Coda
+
+A skill is a Markdown file named `SKILL.md` (or `skill.md`) with YAML frontmatter, optionally accompanied by bundled files. Coda uses progressive disclosure:
+
+- **Level 1 — Metadata** (`name` + `description`): injected into the system prompt's "Available Skills" list so the model knows the skill exists. The description is truncated to a character limit (`skills.descriptionMaxChars`, default 200). A skill with `disable-model-invocation: true` is **omitted** from this list (the user can still invoke it).
+- **Level 2 — SKILL.md body**: loaded when the skill is invoked. Keep it under ~500 lines.
+- **Level 3 — Bundled files**: references/scripts/assets the model reads or runs **only if it chooses to**, using normal tools.
+
+Important: invoking a skill just loads its Markdown body and returns it to the model, which then continues in the normal tool loop. **There is no separate skill runtime** — Coda does not auto-execute bundled scripts and there is no packaging step. Any script a skill ships is just a file on disk that the model may run via a normal tool such as `bash`.
+
+---
+
+## Step 1: Capture Intent
+
+Gather enough to write a well-scoped skill. Don't rush — confirm understanding before writing.
+
+- **Purpose & scope:** the task, the problem solved, expected inputs/outputs, success criteria.
+- **Triggers:** user phrases, file types, and contexts that should activate it; any competing skills. Skills undertrigger by default, so plan a "pushy" description.
+- **Edge cases:** common failure modes, prerequisites/dependencies, and behavior on missing/invalid input.
+
+If the user says "turn this into a skill," extract the workflow, tools, and corrections from the conversation history and confirm the core task.
+
+---
+
+## Step 2: Research
+
+Before writing, check what already exists and confirm feasibility. 
+You may check in the .coda/skills or ~/.coda/skills folders using grep/glob tools.
+
+- Avoid duplication; reuse existing patterns, naming, and shared scripts.
+- Confirm any tools the skill relies on are available to the session.
+
+---
+
+## Choosing the Skill Location
+
+Decide **where** the skill lives before writing files. A project skill overrides a global one with the same `name`.
+
+| Scope | Use when | Write to |
+|-------|----------|----------|
+| **Project** | Only makes sense in this repo — project conventions, internal APIs/tooling, or shared with the team via version control. | `{projectDir}/.coda/skills/` |
+| **Global** | Broadly useful across projects and personal to the user. | `~/.coda/skills/` |
+
+- **Default to project scope** when the request clearly relates to the current codebase (it gets committed and shared with the team).
+- **Choose global scope** for general-purpose helpers reused everywhere.
+- If ambiguous, confirm with the user before creating files.
+- The compat paths `{projectDir}/.agents/skills/` and `~/.agents/skills/` also work; prefer `.coda/skills` unless the user targets `.agents`.
+
+Coda discovers a `SKILL.md` at any depth under these directories. The **recommended** layout is one folder per skill (`<chosen-dir>/<name>/SKILL.md`) so bundled files stay grouped, but a bare `SKILL.md` is also found. No config changes are needed — new skills are picked up on the next session start or after `/skills refresh`.
+
+---
+
+## Step 3: Write the SKILL.md
+
+### Frontmatter
+
+```yaml
+---
+name: skill-identifier
+description: What the skill does AND when to use it. Include trigger contexts and keywords; be explicit and slightly "pushy" to encourage triggering.
+# Optional — defaults shown:
+# disable-model-invocation: false
+# user-invocable: true
+---
+```
+
+Coda only reads the fields below; any other key has no effect.
+
+- **`name`** (required): kebab-case (`^[a-z0-9-]+$`, no leading/trailing or doubled hyphens). Used for the `skills` tool param, the `/skill-name` command, and enable/disable state.
+- **`description`** (required): WHAT + WHEN + triggers. It is injected into the system prompt and **truncated** to a character limit (default 200), so front-load the key triggers.
+- **`disable-model-invocation`** (optional, default `false`): when `true`, the skill is hidden from the "Available Skills" prompt block so the model won't pick it on its own; the user can still invoke it via slash command or explicit tool call.
+- **`user-invocable`** (optional, default `true`): when `false`, the skill is hidden from `/skill-name` registration and Discover Skills listings.
+
+> Do **not** add `execution`/`context`/`timeout`/`compatibility`/`allowed-tools`/`license` — Coda ignores them. Any tools a skill needs must already be available to the session.
+
+**Description examples:**
+
+- ❌ "Helps with PDF tasks"
+- ✅ "Fill PDF forms by extracting field names and populating them with provided data. Use when users mention PDFs, forms, filling documents, or provide .pdf files."
+
+Pattern: *[what it does] + [when to use it] + [specific triggers]*.
+
+### Body
+
+Keep it imperative, structured, and example-driven. A typical skeleton:
+
+```markdown
+# Skill Name
+
+One-paragraph overview of what this accomplishes and why.
+
+## Prerequisites (if any)
+- Tools/dependencies, expected formats.
+
+## Workflow
+### Step 1: ...
+1. Imperative step
+2. Imperative step
+**Why this matters:** brief reasoning.
+
+### Step 2: ...
+**Edge cases:** what to do when input is missing/invalid.
+
+## Output Format (if any)
+Show the exact expected output with a concrete example.
+
+## Examples
+Input → expected output, including one edge case.
+
+## Error Handling
+Common failures and how to recover.
+```
+
+**Style:** imperative voice ("Read the file"), explain the WHY, prefer concrete examples over abstraction, and avoid heavy ALL-CAPS rules. Be instructive, not oppressive.
+
+---
+
+## Step 4: Bundle Resources (Option, consider if it is required)
+
+```
+<name>/
+├── SKILL.md          # Required
+├── scripts/          # Helper scripts the model may run via bash (not auto-run)
+├── references/       # Docs the model reads on demand (add a TOC if >300 lines)
+└── assets/           # Templates, configs, static resources
+```
+
+- **scripts/** — for deterministic, repetitive work better in code than prose (transforms, format conversions, API calls). Coda will not run them automatically; the model invokes them with a normal tool. Give each a docstring, usage example, and error handling.
+- **references/** — for large or occasional reference material; SKILL.md points to them (e.g. "If deploying to AWS, read `references/aws.md`").
+- **assets/** — templates, config files, sample data, UI resources.
+
+**Testing:** there is no built-in eval runner. If a skill needs tests, the user normally describes the test details and expected outcomes in the prompt at invocation time rather than baking them into the skill, so don't add a test harness unless asked.
+
+---
+
+## Step 5: Validate & Activate
+
+There is no validation or packaging command. Check if the skill structure is respected.
+
+1. Starts with `---` and is valid YAML.
+2. `name` and `description` are present and non-empty.
+3. `name` is kebab-case; the file is named exactly `SKILL.md`/`skill.md` (others are ignored).
+4. It lives under the chosen `.coda/skills/` or `~/.coda/skills/`.
+5. If used, `disable-model-invocation` / `user-invocable` are booleans.
+
+---
+
+## Deliverables
+
+When done, give the user:
+
+1. The skill folder path
+2. An example on how to prompt it or call it with a command.
+
+---
+
+## Quality Checklist
+
+- **Progressive disclosure:** SKILL.md under ~500 lines; push detail into references; deterministic work into scripts.
+- **Clear triggering:** description states WHAT + WHEN, slightly pushy.
+- **Actionable & example-driven:** every step executable; concrete input→output pairs; handle edge cases, not just the happy path.
+- **Generalized, not overfit:** patterns over hardcoded values; flexible guidance over rigid MUSTs.
+- **No surprises:** behavior must match the description — no malware, hidden functionality, or data exfiltration.

package/assets/skills/plan/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: plan
+description: analyze the user requirements and create a plan to implement the feature or solve the issue .
+---
+
+### Persona
+Your goal is to gather information and get context to create a detailed plan for accomplishing the user's task, which the user will review and approve before they switch into another mode to implement the solution.
+
+Your task is to plan, design, or strategize before implementation. Perfect for breaking down complex problems, creating technical specifications, designing system architecture, or brainstorming solutions before coding.
+
+### Execution comments
+- Headless mode: It's possible the ask-user tool to be disabled. In this case, a headless execution (also called coda-batch) you will have to explore more deeply the codebase and make reasonable assumptions based on best practices.
+- Interactive mode: Follow the instructions below.
+
+### INSTRUCTIONS
+1. Do some information gathering (using provided tools) to get more context about the task. Use the bash tool grep and find commands to understand the current architecture and implementation. [This step is valid for interactive and headless mode]
+2. You should also ask the user clarifying questions to get a better understanding of the task with the ask_user tool. [This step is valid for interactive mode only]
+3. Write a markdown document with the plan for the feature including UML diagrams and flowcharts to clarify the system design.
+Make sure the diagrams render in VSCode preview.
+
+Output file:
+.coda/plans/plan-{name-of-feature}.md
+
+# Response format
+Provide the user a summary of the plan describing the feature on a high level.

package/lib/keytar/lib/keytar.js

@@ -0,0 +1,43 @@
+var keytar = require('../build/Release/keytar.node')
+
+function checkRequired(val, name) {
+  if (!val || val.length <= 0) {
+    throw new Error(name + ' is required.');
+  }
+}
+
+module.exports = {
+  getPassword: function (service, account) {
+    checkRequired(service, 'Service')
+    checkRequired(account, 'Account')
+
+    return keytar.getPassword(service, account)
+  },
+
+  setPassword: function (service, account, password) {
+    checkRequired(service, 'Service')
+    checkRequired(account, 'Account')
+    checkRequired(password, 'Password')
+
+    return keytar.setPassword(service, account, password)
+  },
+
+  deletePassword: function (service, account) {
+    checkRequired(service, 'Service')
+    checkRequired(account, 'Account')
+
+    return keytar.deletePassword(service, account)
+  },
+
+  findPassword: function (service) {
+    checkRequired(service, 'Service')
+
+    return keytar.findPassword(service)
+  },
+
+  findCredentials: function (service) {
+    checkRequired(service, 'Service')
+
+    return keytar.findCredentials(service)
+  }
+}