원클릭으로 Manus에서 모든 스킬 실행

hook-author

스타2

포크0

업데이트2026년 6월 27일 09:58

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

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

mahmoud-emad-dev

mahmoud-emad-dev/aspis

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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.

이 저장소의 다른 Skills

같은 저장소

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.

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).