Run any Skill in Manus with one click

hook-author

Stars2

Forks0

UpdatedJune 27, 2026 at 09:58

Author a new git or runtime hook with a parity test to prove it behaves identically across both runtime surfaces (OpenCode/Claude).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

mahmoud-emad-dev

mahmoud-emad-dev/aspis

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	hook-author
description	Author a new git or runtime hook with a parity test to prove it behaves identically across both runtime surfaces (OpenCode/Claude).

hook-author

Purpose

Author a new hook that works correctly on both the git surface AND the runtime tool surface from a single shared implementation. The parity test proves the hook catches the same violations, produces the same messages, and respects the same enforcement mode regardless of which surface triggered it.

When to use

Adding a new hook (git or runtime).
Modifying an existing hook's logic.
Changing a hook's enforcement mode (warn <-> block).

Procedure

Define the hook's purpose and which violations it detects.
Author the hook logic ONCE as a Python module under .aspis/scripts/hooks/ — this is the shared core. Per R-006, never copy logic between surfaces.
Create the git-surface entry point (shell script in .git/hooks/) that imports the shared module.
Create the runtime-surface entry point (OpenCode plugin / Claude PreToolUse hook) that imports the SAME shared module. No second copy.
Write a parity test: run identical scenarios (clean commit, violation commit) through BOTH surfaces; assert identical exit codes, error messages, violation counts, and enforcement behavior.
Set the enforcement mode: warn for pre-commit (auto-fixes, non-blocking), block for runtime tools (hard wall). Read the mode from config, not from the hook body.
Register the hook in hooks.yaml so the system knows it exists.

Outputs

A new hook module in .aspis/scripts/hooks/.
Both surface entry points (git + runtime).
Parity test results proving identical behavior across surfaces.
Updated hooks.yaml registration.

Anti-patterns

Copy-pasting hook logic between surfaces instead of sharing a module (R-006 violation — the rule is "two surfaces, one shared core").
Testing only one surface and assuming the other works.
Authoring a hook without a parity test — untrustworthy by construction.
Hard-coding enforcement mode in the hook body instead of reading config.
Blocking but ignoring the ASPIS_ENFORCEMENT env var override.

More from this repository

same repository

commit-splitting

mahmoud-emad-dev/aspis

Keep commits atomic — split a mixed change set into scoped, reviewable commits.

2026-07-012

project-onboarding

mahmoud-emad-dev/aspis

The one-time procedure to take an exported project to live — understand it, confirm the name/goal/stack with the user, run the deterministic `aspis bootstrap`, enrich the judgment files (AGENTS.md, ARCHITECTURE, context), verify, and let the package self-clean. Followed by the bootstrap agent.

2026-06-292

architecture-memory

mahmoud-emad-dev/aspis

Keep per-subsystem architectural intent current through the planning loop — read before designing, record an impact report on change, confirm with the user, apply a dated update, and verify the build against approved intent.

2026-06-292

dependency-audit

mahmoud-emad-dev/aspis

Audit a plan's task dependency graph for structural integrity — circular dependencies, missing prerequisites, orphan tasks, and dependency classification (hard/soft/warning). Produces a pass/warn/fail audit report per dependency so planners catch graph errors before build starts.

2026-06-272

clean-tree-precondition

mahmoud-emad-dev/aspis

Every editing agent should start on a clean working tree so parallel work never collides.

2026-06-272

commit-readiness

mahmoud-emad-dev/aspis

Verify hooks ran, no secrets, protected paths untouched, and commit message valid before committing. Owned by the reviewer.

2026-06-272

hook-author

Purpose

When to use

Adding a new hook (git or runtime).

Modifying an existing hook's logic.

Changing a hook's enforcement mode (warn <-> block).

Procedure

Define the hook's purpose and which violations it detects.

Author the hook logic ONCE as a Python module under .aspis/scripts/hooks/ — this is the shared core. Per R-006, never copy logic between surfaces.

Create the git-surface entry point (shell script in .git/hooks/) that imports the shared module.

Create the runtime-surface entry point (OpenCode plugin / Claude PreToolUse hook) that imports the SAME shared module. No second copy.

Write a parity test: run identical scenarios (clean commit, violation commit) through BOTH surfaces; assert identical exit codes, error messages, violation counts, and enforcement behavior.

Set the enforcement mode: warn for pre-commit (auto-fixes, non-blocking), block for runtime tools (hard wall). Read the mode from config, not from the hook body.

Outputs

A new hook module in .aspis/scripts/hooks/.

Both surface entry points (git + runtime).

Parity test results proving identical behavior across surfaces.

Updated hooks.yaml registration.

Anti-patterns

Copy-pasting hook logic between surfaces instead of sharing a module (R-006 violation — the rule is "two surfaces, one shared core").

Testing only one surface and assuming the other works.

Authoring a hook without a parity test — untrustworthy by construction.

Hard-coding enforcement mode in the hook body instead of reading config.

Blocking but ignoring the ASPIS_ENFORCEMENT env var override.