Add reference implementations for Steps 13-15

[mike-remakerdigital]

Summary

12 new runnable reference files that back the documentation added in PR #1. Previously, Steps 13-15 described the three-layer defense model, testing strategy, and procedure encoding — but the reference/ directory only shipped Layer 3 (SessionStart hook). This PR closes that gap.

New files

Layer 1 — PreToolUse hooks (real-time enforcement):

• reference/hooks/destructive-gate.py — blocks dangerous file, git, and database operations. Fail-closed design.
• reference/hooks/credential-scan.py — blocks hardcoded secrets. Configurable patterns for Azure, AWS, GCP (commented examples). Fail-open design.

Layer 2 — Pre-commit guardrails (commit-time enforcement):

• reference/guardrails/pre-commit — orchestrator bash script that chains all checks
• reference/guardrails/check_test_deletion.py — 100% generic, blocks test file deletion
• reference/guardrails/check_assertion_ratchet.py — rejects commits that decrease assertion counts
• reference/guardrails/generate_assertion_baseline.py — scans tests/, builds JSON baseline for the ratchet

Session scheduler (deferred automation):

• reference/hooks/scheduler.py — cross-platform (Windows msvcrt + Unix fcntl), FIFO prompt queue
• reference/hooks/SCHEDULE.md — example schedule with trigger types

Custom agents (on-demand review):

• reference/agents/code-reviewer.md — confidence-filtered (>80%), severity-rated output format
• reference/agents/security-analyzer.md — OWASP Top 10 table with [CUSTOMIZE] sections

Skills (encoded procedures):

• reference/skills/session-wrap/SKILL.md — 5-phase session wrap-up template

Configuration:

• reference/hooks/settings.local.json — updated from 2 hooks to all 5 (PreToolUse + SessionStart + UserPromptSubmit)

Test plan

• All 12 files present and well-formed
• Python files have correct shebang and docstrings
• No project-specific credentials or FQDNs in reference code
• Agent templates have [CUSTOMIZE] markers for project-specific sections
• settings.local.json registers all 5 hook types

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly expands the reference implementations for the three-layer defense model, testing strategy, and procedure encoding, addressing a previous gap in practical examples for Steps 13-15. It provides a comprehensive set of new hooks, guardrails, agents, and skills, enabling more robust real-time enforcement, commit-time checks, and structured session management within the system.

Highlights

• New Reference Implementations: Introduced 12 new runnable reference files to support the documentation for Steps 13-15, closing a previous gap in practical examples.
• Layer 1 PreToolUse Hooks: Added destructive-gate.py to block dangerous file, git, and database operations, and credential-scan.py to block hardcoded secrets, enhancing real-time enforcement.
• Layer 2 Pre-commit Guardrails: Implemented an orchestrator pre-commit script, check_test_deletion.py to prevent test file deletion, check_assertion_ratchet.py to reject commits decreasing assertion counts, and generate_assertion_baseline.py to build the assertion baseline.
• Session Scheduler: Provided scheduler.py for a cross-platform FIFO prompt queue and SCHEDULE.md as an example schedule with trigger types for deferred automation.
• Custom Agents: Included definitions for code-reviewer.md (a confidence-filtered code reviewer) and security-analyzer.md (an OWASP Top 10 focused security analyzer) for on-demand review.
• Encoded Procedures (Skills): Defined a new skill, session-wrap/SKILL.md, which outlines a 5-phase session wrap-up template.
• Configuration Updates: Updated settings.local.json to register the newly added PreToolUse hooks (credential scanning, destructive gate) and the UserPromptSubmit hook (scheduler).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive set of new guardrails, hooks, and agent definitions for the Claude Code project. Key additions include code-reviewer and security-analyzer agent definitions, pre-commit hooks for assertion count ratcheting and test file deletion prevention, and PreToolUse hooks for credential scanning and destructive command gating. A new scheduler.py hook manages scheduled tasks based on SCHEDULE.md, and a kb-session-wrap skill defines a structured session wrap-up procedure. The settings.local.json file has been updated to integrate these new hooks and ensure consistent python3 usage. Review comments point out inconsistencies in how test files are identified within check_assertion_ratchet.py and check_test_deletion.py, suggesting alignment with generate_assertion_baseline.py's logic. A minor consistency improvement is also suggested for the kb-session-wrap skill to use python3 for executing the assertion check script.

[gemini-code-assist]

The logic for identifying test files in get_staged_test_files should align with how generate_assertion_baseline.py identifies them. Currently, any(p.startswith("test_") for p in parts) is too broad and might include non-test files or miss actual test files that are not directly under a tests/ directory but whose filename starts with test_.

generate_assertion_baseline.py explicitly scans PROJECT_ROOT / "tests" for files whose filename starts with test_ and ends with .py. This function should apply similar filtering to ensure consistency.

This inconsistency can lead to the assertion ratchet being applied to unintended files or failing to track legitimate test files.

Suggested change

	normalized = line.strip().replace("\\", "/")
	if normalized.endswith(".py"):
	parts = normalized.split("/")
	if any(p.startswith("test_") for p in parts):
	files.append(normalized)
	if normalized.startswith("tests/") and normalized.endswith(".py"):
	filename = Path(normalized).name
	if filename.startswith("test_"):
	files.append(normalized)

[gemini-code-assist]

The logic for identifying test files in get_deleted_test_files should align with how generate_assertion_baseline.py identifies them. Currently, any(p.startswith("test_") and p.endswith(".py") for p in parts) is too broad and might include non-test files or miss actual test files.

generate_assertion_baseline.py explicitly scans PROJECT_ROOT / "tests" for files whose filename starts with test_ and ends with .py. This function should apply similar filtering to ensure consistency.

This inconsistency can lead to legitimate test files being deleted without being caught, or non-test files being incorrectly flagged.

Suggested change

	if any(p.startswith("test_") and p.endswith(".py") for p in parts):
	deleted.append(normalized)
	if normalized.startswith("tests/") and normalized.endswith(".py"):
	filename = Path(normalized).name
	if filename.startswith("test_"):
	deleted.append(normalized)

[gemini-code-assist]

The assertion-check.py script is configured to run with python3 in settings.local.json. For consistency, please update the command in this skill to use python3 as well.

Suggested change

	python .claude/hooks/assertion-check.py
	python3 .claude/hooks/assertion-check.py