How to Set Up Pre-Commit Hooks in OpenWork: A Complete Guide

OpenWork does not include active pre-commit hooks by default; you'll need to manually create and configure them using Git's sample hooks as a starting point.

The OpenWork repository (different-ai/openwork) ships without any enforced pre-commit checks. While the dev branch contains Git's default sample hook files, none are active. This guide explains what's currently in place and how to add your own pre-commit hooks for linting, testing, or custom validation.

What Pre-Commit Hooks Exist in OpenWork Today

A review of the source code reveals only inactive sample files provided by Git during repository initialization:

• .git/hooks/pre-commit.sample — The standard Git template that must be renamed to pre-commit to become active.
• .git/hooks/pre-applypatch.sample — Contains a reference to a pre-commit hook, but only as a placeholder comment.
• .git/hooks/pre-merge-commit.sample — Includes conditional logic to call pre-commit if it existed, but does not create it.

No .pre-commit-config.yaml, Husky configuration, or custom hook scripts are present anywhere in the codebase. Consequently, developers can commit code without any automated checks running first.

How to Create and Enable a Pre-Commit Hook in OpenWork

Since OpenWork uses pnpm for package management, your pre-commit hook will likely run scripts defined in package.json. Here's how to set one up from scratch.

Step 1: Create the Hook Script

Git hooks live in .git/hooks/ and must be executable shell scripts. Create a pre-commit file that runs your linting or tests:

cat > .git/hooks/pre-commit <<'EOF'
#!/bin/sh

# OpenWork pre-commit hook: run linting before each commit

echo "Running pre-commit checks..."

pnpm lint
if [ $? -ne 0 ]; then
  echo "ERROR: Linting failed – commit aborted"
  exit 1
fi

echo "All checks passed – proceeding with commit"
EOF

Step 2: Make It Executable

Git ignores hook files without execute permissions:

chmod +x .git/hooks/pre-commit

Step 3: Test the Hook Manually

Before committing, verify your hook works by running it directly:

.git/hooks/pre-commit

If your linting fails, the script exits with code 1 and blocks the commit. Fix the errors, then retry.

Alternative: Using the Pre-Commit Framework

For more robust hook management, install the pre-commit framework instead of writing raw shell scripts:

# Install the pre-commit tool

pip install pre-commit

# Create configuration file

cat > .pre-commit-config.yaml <<'EOF'
repos:
  - repo: local
    hooks:
      - id: pnpm-lint
        name: pnpm lint
        entry: pnpm lint
        language: system
        pass_filenames: false
EOF

# Install hooks into Git

pre-commit install

This creates a .pre-commit-config.yaml at the repository root and automatically generates .git/hooks/pre-commit as a wrapper.

Key Differences: Raw Git Hooks vs. Pre-Commit Framework

Approach	Best For	Setup Complexity	Portability
Raw Git hook	Simple, single-script checks	Low (one shell file)	Must manually copy to each clone
Pre-commit framework	Multiple hooks, complex logic, team sharing	Medium (config file + tool)	Config file committed to repo

For OpenWork's current structure, a raw Git hook suffices for individual developers. For team-wide enforcement, add .pre-commit-config.yaml to version control and document the setup in CONTRIBUTING.md.

Persisting Hooks Across Team Members

Git hooks in .git/hooks/ are not tracked by Git. To share hooks with collaborators, store them elsewhere in the repository and copy or symlink them during setup:

# Store hooks in the repo

mkdir -p scripts/git-hooks
cp .git/hooks/pre-commit scripts/git-hooks/

# Add to package.json scripts for easy installation

# "prepare": "cp scripts/git-hooks/pre-commit .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit"

Then teammates run pnpm prepare after cloning to activate the same hooks you use.

Common Pre-Commit Checks for OpenWork Projects

Based on typical monorepo patterns, consider adding these checks to your OpenWork pre-commit hook:

• pnpm lint — Run ESLint across modified files.
• pnpm typecheck — Validate TypeScript compilation.
• pnpm test:changed — Execute only tests affected by your changes.

Chain multiple checks with logical operators, exiting immediately on any failure:

#!/bin/sh
pnpm lint || exit 1
pnpm typecheck || exit 1
pnpm test:changed || exit 1

Summary

• OpenWork's dev branch contains only inactive Git sample hooks — no enforcement exists by default.
• Active hooks require manually creating .git/hooks/pre-commit and marking it executable.
• The repository uses pnpm, so hook scripts typically invoke pnpm lint or similar commands.
• For team-wide consistency, store hook scripts in a tracked directory and automate installation via package.json scripts or the pre-commit framework.

Frequently Asked Questions

Does OpenWork come with pre-commit hooks enabled?

No. The repository includes only Git's default sample files — .git/hooks/pre-commit.sample, .git/hooks/pre-applypatch.sample, and .git/hooks/pre-merge-commit.sample. These must be renamed or replaced to become functional. No .pre-commit-config.yaml or similar configuration exists.

Where should I place custom pre-commit hooks in OpenWork?

Create your hook directly at .git/hooks/pre-commit and run chmod +x to make it executable. For portability, store the script elsewhere in the repository (e.g., scripts/git-hooks/) and copy or symlink it during project setup.

Can I use Husky with OpenWork?

Yes, though it requires installation. Run pnpm add -D husky and add "prepare": "husky install" to your package.json scripts. Then create hooks with npx husky add .husky/pre-commit "pnpm lint". Since Husky manages .git/hooks/ for you, raw Git hooks and Husky should not be mixed on the same repository clone.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}