New to Claude Skills? Learn how to install them →

Ppinchtab on GitHub

PinchTab Development

Free

Streamline your contributions to the PinchTab project.

by pinchtab10k stars on pinchtab/pinchtab
2 views
Updated Aug 3, 2026
Get this skill

Free · Opens the source repo

What PinchTab Development does

PinchTab is a specialized browser control server designed for AI agents, implemented as a small Go binary with an HTTP API. This skill facilitates development and contribution to the PinchTab project, providing a structured environment for adding features, fixing bugs, running tests, and preparing pull requests. Developers working on this project will find that the skill automates many routine tasks, allowing them to focus on code quality and functionality.

The development commands are executed through a simple interface using ./dev, which encapsulates various commands for building, testing, and running the application. For example, commands like ./dev build and ./dev run allow for quick application builds and execution, while ./dev check ensures code quality through linting and type checks. The skill also supports comprehensive testing with commands for unit tests and end-to-end tests, ensuring that new features or bug fixes meet the project's quality standards before integration.

This skill is particularly useful for developers who are actively contributing to the PinchTab codebase. It provides a clear workflow for creating branches, making changes, and running thorough checks before pushing code. The defined process encourages best practices such as conventional commits and thorough documentation of changes, which are essential for maintaining a clean and understandable project history.

Overall, the PinchTab Development skill is an essential tool for anyone looking to contribute effectively to the PinchTab project, streamlining the development process and enhancing collaboration among contributors.

When to use it

Use this skill when you are working on the PinchTab source code, whether adding features or fixing bugs.

When not to use it

This skill may not be suitable for projects outside of the PinchTab ecosystem or for developers not involved in its development.

What you can build with it

Adding a New Feature

When you want to implement a new feature in PinchTab, use the skill to create a branch, make changes, and run all necessary checks before submitting a pull request.

Fixing a Bug

If you encounter a bug in PinchTab, the skill guides you through the process of isolating the issue, applying a fix, and ensuring that all tests pass before merging your changes.

Running Tests

Utilize the skill to run unit and end-to-end tests, ensuring that your contributions do not introduce regressions or new issues.

How to install PinchTab Development

View source

1. Install with the skills CLI

npx skills add pinchtab/pinchtab/pinchtab-dev --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by pinchtab

PinchTab Development

PinchTab is a browser control server for AI agents — Small Go binary with HTTP API.

Project Location

cd ~/dev/pinchtab

Dev Commands

All development commands run via ./dev:

CommandDescription
./dev buildBuild the application
./dev devBuild & run
./dev dashboardHot-reload dashboard development (Vite + Go)
./dev runRun the application
./dev checkAll checks (Go + Dashboard + Plugin)
./dev check goGo checks only
./dev check dashboardDashboard checks only
./dev test unitGo unit tests
./dev test dashboardDashboard unit tests
./dev e2e basicBasic suite (api + cli + infra)
./dev e2e extendedExtended suite (all extended)
./dev e2e smokeSmoke suite
./dev e2e smoke-dockerHost Docker smoke checks only
./dev e2e test "<name>"Run a single E2E test by start_test name
./dev allcheck + test + e2e (pre-push gate)
./dev binariesBuild the full release binary matrix into dist/
./dev doctorSetup dev environment

Architecture

cmd/pinchtab/     CLI entry point
internal/
  bridge/         Chrome CDP communication
  handlers/       HTTP API handlers
  server/         HTTP server
  dashboard/      Embedded React dashboard
  config/         Configuration
  assets/         Embedded assets (stealth.js)
dashboard/        React dashboard source (Vite + TypeScript)
tests/e2e/        E2E test suites

Workflow: New Feature or Bug Fix

  1. Create branch from main:

    git checkout main && git pull
    git checkout -b feat/my-feature  # or fix/my-bug
    
  2. Make changes — follow code patterns in existing files

  3. Run checks locally:

    ./dev all          # check + test + e2e (one-shot pre-push gate)
    # …or individually:
    ./dev check        # Lint + format + typecheck
    ./dev test unit    # Go unit tests
    ./dev e2e basic    # E2E tests (Docker required)
    
  4. Commit with conventional commits:

    • feat: new feature
    • fix: bug fix
    • refactor: code change without behavior change
    • test: adding tests
    • docs: documentation
    • chore: maintenance
  5. Push and create PR

Definition of Done (PR Checklist)

Required — Code Quality

  • Error handling explicit — all errors wrapped with %w, no silent failures
  • No regressions — verify stealth, token efficiency, session persistence
  • SOLID principles — functions do one thing, testable
  • No redundant comments — explain why, not what

Required — Testing

  • New/changed functionality has tests
  • Docker E2E tests pass locally: ./dev e2e basic (or ./dev all for the full chain)
  • If npm wrapper touched: npm pack and npm install work

Required — Documentation

  • README.md updated if user-facing changes
  • /docs/ updated if API/architecture changed

Required — Review

  • PR description explains what + why
  • Commits are atomic with good messages

Key Files

FilePurpose
internal/assets/stealth.jsBot detection evasion (light/medium/full levels)
internal/bridge/bridge.goChrome CDP bridge
internal/handlers/*.goHTTP API endpoints
dashboard/src/React dashboard source
tests/e2e/scenarios-api/API E2E tests
tests/e2e/scenarios-cli/CLI E2E tests

Testing

Unit Tests

./dev test unit              # All Go tests
go test ./internal/handlers  # Specific package

E2E Tests (requires Docker)

./dev e2e basic                 # Basic suite (api + cli + infra)
./dev e2e api                   # API basic tests
./dev e2e cli                   # CLI basic tests
./dev e2e infra                 # Infra basic tests
./dev e2e api-extended          # API extended tests (multi-instance)
./dev e2e cli-extended          # CLI extended tests
./dev e2e infra-extended        # Infra extended tests (multi-instance)
./dev e2e extended              # Full extended suite (all extended tests)
./dev e2e smoke-docker          # Host Docker smoke checks only

# Run specific test file(s) with filter (second argument)
./dev e2e api clipboard                # Run only clipboard-basic.sh
./dev e2e api-extended "clipboard|console"  # Run clipboard and console tests
./dev e2e cli browser                  # Run browser-basic.sh in CLI suite

# Run a single test by its start_test name (fastest debug loop)
./dev e2e test "humanClick: click input by ref"
./dev e2e test "scroll (down)"
./dev e2e test "low-level mouse"

The scenario filter is a substring matched against scenario filenames. Requires Docker daemon running.

Single-test mode (dev e2e test "<name>")

Use this when iterating on one specific E2E failure. The runner:

  1. Greps tests/e2e/scenarios/**/*.sh for start_test "...<name substring>...".
  2. Auto-picks the suite (api/cli/infra/plugin) and -extended variant from the matching scenario file's path.
  3. Builds fresh images (compose ... up --build) and runs only the matching start_test...end_test block — the scenario preamble (helper sourcing, FIXTURES_URL, etc.) is preserved, every other test in the file is skipped.

Notes:

  • The substring is literal (fgrep), so colons/parens/quotes in test names work without escaping.
  • If multiple tests match, the runner uses the first and prints the others — pass a longer/more-specific substring to disambiguate.
  • Logs stream to the terminal by default (unlike full suites which hide logs); helpful for debugging.
  • Implemented by scripts/dev-e2e.sh + E2E_TEST_FILTER plumbing through scripts/e2e.sh and tests/e2e/run.sh.

Dashboard Tests

./dev test dashboard  # Vitest
cd dashboard && npm test

Dashboard Development

Setup

Start hot-reload development:

./dev dashboard

This runs:

  • Backend on :9867
  • Vite dev server on :5173 with hot-reload
  • Dashboard at http://localhost:5173/dashboard/

Development Workflow (Use PinchTab to Develop PinchTab)

Do not assume changes worked. Use pinchtab itself to verify changes visually:

  1. Start dev mode:

    ./dev dashboard
    
  2. Make changes to files in dashboard/src/

  3. Verify with pinchtab — use the pinchtab skill to inspect the dashboard:

    # Navigate to the page under development
    curl -X POST http://localhost:9867/navigate \
      -d '{"url":"http://localhost:5173/dashboard/settings"}'
    
    # Take a screenshot to verify the change
    curl -X POST http://localhost:9867/screenshot \
      -d '{"path":"/tmp/dashboard-check.png"}'
    
    # Or get a snapshot to inspect elements
    curl -s http://localhost:9867/snapshot | jq .
    
  4. Provide evidence — when reporting changes, include:

    • Link to the page: http://localhost:5173/dashboard/{page}
    • Screenshot of the result
    • Relevant snapshot data if inspecting specific elements

Example: Verifying a Settings Page Change

# Navigate to settings
curl -X POST http://localhost:9867/navigate \
  -d '{"url":"http://localhost:5173/dashboard/settings"}'

# Screenshot the result
curl -X POST http://localhost:9867/screenshot \
  -d '{"path":"./dashboard-settings.png","fullPage":true}'

# Find specific element
curl -X POST http://localhost:9867/find \
  -d '{"selector":"[data-testid=stealth-level]"}'

Key Dashboard Pages

PageURLPurpose
Home/dashboard/Instance overview
Settings/dashboard/settingsConfiguration
Profiles/dashboard/profilesBrowser profiles
Tabs/dashboard/tabsActive tabs

Dashboard Tech Stack

  • React 19 + TypeScript
  • Vite (build/dev)
  • Tailwind CSS
  • Zustand (state)
  • Vitest (tests)

Stealth Module

The stealth module (internal/assets/stealth.js) has three levels:

LevelFeaturesTrade-offs
lightwebdriver, CDP markers, plugins, hardwareNone — safe
medium+ userAgentData, chrome.runtime.connect, csi/loadTimesMay affect error monitoring
full+ WebGL/canvas noise, WebRTC relayMay break WebRTC, canvas apps

Configure in ~/.pinchtab/config.json:

{
  "instanceDefaults": {
    "stealthLevel": "medium"
  }
}

Common Tasks

Add new API endpoint

  1. Create handler in internal/handlers/
  2. Register route in internal/server/routes.go
  3. Add tests in same package
  4. Add E2E test in tests/e2e/scenarios-api/

Modify stealth behavior

  1. Edit internal/assets/stealth.js
  2. Run ./dev build (embeds via go:embed)
  3. Test with ./dev e2e api-fast (includes stealth tests)

Update dashboard

  1. Run ./dev dashboard for hot-reload
  2. Edit files in dashboard/src/
  3. Run ./dev check dashboard before commit

Frequently asked questions about PinchTab Development

Similar skills