Interview the user to design a project-level Hookify V2 or Pi hook rule set for a repository. Use this whenever the user wants help defining `.pi/hookify.*.local.yaml` rules, choosing `on / when / do / respond`, designing repo-wide guardrails, approvals, command or file safety checks, prompt transforms, rollout policy, or asks things like "design my hook rules", "what hooks should I enable", "repo guardrails", "制定项目级 hook 规则", or "帮我设计项目级 guardrails", even if they do not mention Hookify by name.
Help the user turn vague guardrail ideas into a concrete project-level hook policy.
This skill is interview-first. Do not jump straight into writing rule files unless the user explicitly asks for implementation. Your main job is to:
By the end of the interview, produce a project-level hook plan that answers:
Before asking questions, quickly inspect the repository for signals that reduce guesswork:
.pi/hookify*.yaml.pi/settings.json.claude/, , , , or similar automation folders.agents/.github/.husky/package.json, pyproject.toml, Cargo.toml, go.mod, DockerfileREADME.md, docs/, workflow files, test scriptsreferences/event-playbook.md from this skill when you need a quick mapping from repo concern to Pi hook surface.references/output-template.md before presenting the final interview result so your structure stays consistent.When this skill is used inside pi-hookify, bias your recommendations toward the current Hookify V2 design:
.pi/on / when / do / respond DSLinput, tool_call, tool_result, before_agent_start, context, and user_bashIf the user wants implementation after the interview, draft rules that match the current V2 schema rather than proposing legacy Hookify formats.
Keep the interview tight. Ask only what the repo cannot answer.
Prefer AskUserQuestion when you need structured tradeoffs, especially for:
input, tool_call, tool_result, before_agent_start, context, user_bash, session_before_*, before_provider_request, or observe-only audit hooks?Always present your interview result using this structure:
Project Hook Policy BriefHook Coverage MatrixCandidate Rule SetRollout PlanOpen Questions / RisksUse the template in references/output-template.md.
For each high-signal hook, specify:
Be concrete. The matrix should be close enough that another agent can implement it without redoing the interview.
When proposing rules:
If the user asks for actual Hookify V2 rules, map the matrix into YAML rule files under .pi/, using the current on / when / do / respond rule shape.
Use these defaults unless the user gives a better repo-specific answer:
before_agent_start and context sparingly; reserve them for policy framing and context cleanuptool_call for the majority of concrete enforcementtool_result when the team wants annotation, sanitization, or structured post-processinguser_bash only when the team cares about direct ! shell behavior from the operatorAfter the interview is accepted:
.pi/Do not silently implement while requirements are still fuzzy.
You are done when: