@hivehub/rulebook 5.7.0 → 5.8.0

package/templates/commands/rulebook-task-create.md

@@ -1,93 +1,93 @@
----
-name: /rulebook-task-create
-id: rulebook-task-create
-category: Rulebook
-description: Create a new Rulebook task following OpenSpec-compatible format with Context7 MCP validation.
----
-<!-- RULEBOOK:START -->
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- Refer to `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines and format requirements.
-- **CRITICAL**: Context7 MCP is REQUIRED for task creation to ensure correct OpenSpec-compatible format.
-- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
-
-**Steps**
-1. **Check Context7 MCP (MANDATORY)**: Query Context7 for OpenSpec documentation to get the official format:
-   ```
-   @Context7 /fission-ai/openspec task creation format spec structure
-   ```
-   Review official format requirements: spec delta format, requirement structure, scenario formatting, delta headers (ADDED/MODIFIED/REMOVED/RENAMED).
-
-2. **Explore Current State**: 
-   - Run `rulebook task list` to see existing tasks
-   - Review related code or docs (e.g., via `rg`/`ls`) to understand current behavior
-   - Note any gaps that require clarification
-
-3. **Choose Task ID**: Use verb-led kebab-case (e.g., `add-feature`, `update-api`, `refactor-module`). Must be unique.
-
-4. **Create Task Structure**:
-   ```bash
-   rulebook task create <task-id>
-   ```
-   This creates `/.rulebook/tasks/<task-id>/` with:
-   - `proposal.md` - Why and what changes
-   - `tasks.md` - Implementation checklist
-   - `specs/` - Directory for spec deltas
-
-5. **Write Proposal** (`proposal.md`):
-   - **Why**: Minimum 20 characters explaining why this change is needed
-   - **What Changes**: Detailed description of what will change
-   - **Impact**: Affected specs, code, breaking changes, user benefits
-
-6. **Write Tasks Checklist** (`tasks.md`):
-   - Organize by phases (Implementation, Testing, Documentation)
-   - Use checkbox format: `- [ ] Task description`
-   - Include validation steps (tests, coverage checks)
-
-7. **Write Spec Delta** (`specs/<module>/spec.md`):
-   - Use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements` headers
-   - Requirements MUST use `### Requirement: [Name]` with SHALL/MUST keywords
-   - Scenarios MUST use `#### Scenario:` (4 hashtags, NOT 3)
-   - Scenarios MUST use Given/When/Then structure
-   - Example:
-     ```markdown
-     ## ADDED Requirements
-     
-     ### Requirement: Feature Name
-     The system SHALL do something specific and testable.
-     
-     #### Scenario: Scenario Name
-     Given some precondition
-     When an action occurs
-     Then an expected outcome happens
-     ```
-
-8. **Validate Task**:
-   ```bash
-   rulebook task validate <task-id>
-   ```
-   Fix any validation errors before proceeding.
-
-9. **Verify Format**:
-   - Purpose section: ≥20 characters ✅
-   - Requirements: Contain SHALL or MUST ✅
-   - Scenarios: Use `#### Scenario:` (4 hashtags) ✅
-   - Scenarios: Use Given/When/Then structure ✅
-   - Delta headers: Use ADDED/MODIFIED/REMOVED/RENAMED ✅
-
-**Reference**
-- See `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines
-- Use `rulebook task show <task-id>` to view task details
-- Use `rulebook task list` to see all tasks
-- Search existing requirements with `rg -n "Requirement:|Scenario:" .rulebook/tasks` before writing new ones
-- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities
-
-**Common Pitfalls to Avoid**
-- ❌ Using 3 hashtags for scenarios (`### Scenario:`) - MUST use 4 (`#### Scenario:`)
-- ❌ Missing SHALL/MUST keywords in requirements
-- ❌ Using bullet points for scenarios instead of Given/When/Then
-- ❌ Purpose section too short (<20 characters)
-- ❌ Wrong delta headers (use ADDED/MODIFIED/REMOVED/RENAMED, not "New Requirements" or "Changes")
-<!-- RULEBOOK:END -->
-
+---
+name: /rulebook-task-create
+id: rulebook-task-create
+category: Rulebook
+description: Create a new Rulebook task following OpenSpec-compatible format with Context7 MCP validation.
+---
+<!-- RULEBOOK:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines and format requirements.
+- **CRITICAL**: Context7 MCP is REQUIRED for task creation to ensure correct OpenSpec-compatible format.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+
+**Steps**
+1. **Check Context7 MCP (MANDATORY)**: Query Context7 for OpenSpec documentation to get the official format:
+   ```
+   @Context7 /fission-ai/openspec task creation format spec structure
+   ```
+   Review official format requirements: spec delta format, requirement structure, scenario formatting, delta headers (ADDED/MODIFIED/REMOVED/RENAMED).
+
+2. **Explore Current State**: 
+   - Run `rulebook task list` to see existing tasks
+   - Review related code or docs (e.g., via `rg`/`ls`) to understand current behavior
+   - Note any gaps that require clarification
+
+3. **Choose Task ID**: Use verb-led kebab-case (e.g., `add-feature`, `update-api`, `refactor-module`). Must be unique.
+
+4. **Create Task Structure**:
+   ```bash
+   rulebook task create <task-id>
+   ```
+   This creates `/.rulebook/tasks/<task-id>/` with:
+   - `proposal.md` - Why and what changes
+   - `tasks.md` - Implementation checklist
+   - `specs/` - Directory for spec deltas
+
+5. **Write Proposal** (`proposal.md`):
+   - **Why**: Minimum 20 characters explaining why this change is needed
+   - **What Changes**: Detailed description of what will change
+   - **Impact**: Affected specs, code, breaking changes, user benefits
+
+6. **Write Tasks Checklist** (`tasks.md`):
+   - Organize by phases (Implementation, Testing, Documentation)
+   - Use checkbox format: `- [ ] Task description`
+   - Include validation steps (tests, coverage checks)
+
+7. **Write Spec Delta** (`specs/<module>/spec.md`):
+   - Use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements` headers
+   - Requirements MUST use `### Requirement: [Name]` with SHALL/MUST keywords
+   - Scenarios MUST use `#### Scenario:` (4 hashtags, NOT 3)
+   - Scenarios MUST use Given/When/Then structure
+   - Example:
+     ```markdown
+     ## ADDED Requirements
+     
+     ### Requirement: Feature Name
+     The system SHALL do something specific and testable.
+     
+     #### Scenario: Scenario Name
+     Given some precondition
+     When an action occurs
+     Then an expected outcome happens
+     ```
+
+8. **Validate Task**:
+   ```bash
+   rulebook task validate <task-id>
+   ```
+   Fix any validation errors before proceeding.
+
+9. **Verify Format**:
+   - Purpose section: ≥20 characters ✅
+   - Requirements: Contain SHALL or MUST ✅
+   - Scenarios: Use `#### Scenario:` (4 hashtags) ✅
+   - Scenarios: Use Given/When/Then structure ✅
+   - Delta headers: Use ADDED/MODIFIED/REMOVED/RENAMED ✅
+
+**Reference**
+- See `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines
+- Use `rulebook task show <task-id>` to view task details
+- Use `rulebook task list` to see all tasks
+- Search existing requirements with `rg -n "Requirement:|Scenario:" .rulebook/tasks` before writing new ones
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities
+
+**Common Pitfalls to Avoid**
+- ❌ Using 3 hashtags for scenarios (`### Scenario:`) - MUST use 4 (`#### Scenario:`)
+- ❌ Missing SHALL/MUST keywords in requirements
+- ❌ Using bullet points for scenarios instead of Given/When/Then
+- ❌ Purpose section too short (<20 characters)
+- ❌ Wrong delta headers (use ADDED/MODIFIED/REMOVED/RENAMED, not "New Requirements" or "Changes")
+<!-- RULEBOOK:END -->
+

package/templates/commands/rulebook-task-list.md

@@ -1,42 +1,42 @@
----
-name: /rulebook-task-list
-id: rulebook-task-list
-category: Rulebook
-description: List all Rulebook tasks (active and optionally archived).
----
-<!-- RULEBOOK:START -->
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- Refer to `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines.
-
-**Steps**
-1. **List Active Tasks**:
-   ```bash
-   rulebook task list
-   ```
-   Shows all active tasks with their status (pending, in-progress, completed, blocked).
-
-2. **List Including Archived**:
-   ```bash
-   rulebook task list --archived
-   ```
-   Shows both active and archived tasks.
-
-3. **Review Task Status**:
-   - **pending**: Task not started
-   - **in-progress**: Task being worked on
-   - **completed**: Task finished (ready for archive)
-   - **blocked**: Task blocked by dependency
-
-4. **Select Task to Work On**:
-   - Choose task with highest priority
-   - Check task status before starting
-   - Verify task is not blocked
-
-**Reference**
-- Use `rulebook task show <task-id>` to view task details
-- Use `rulebook task validate <task-id>` to check task format
-- See `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines
-<!-- RULEBOOK:END -->
-
+---
+name: /rulebook-task-list
+id: rulebook-task-list
+category: Rulebook
+description: List all Rulebook tasks (active and optionally archived).
+---
+<!-- RULEBOOK:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines.
+
+**Steps**
+1. **List Active Tasks**:
+   ```bash
+   rulebook task list
+   ```
+   Shows all active tasks with their status (pending, in-progress, completed, blocked).
+
+2. **List Including Archived**:
+   ```bash
+   rulebook task list --archived
+   ```
+   Shows both active and archived tasks.
+
+3. **Review Task Status**:
+   - **pending**: Task not started
+   - **in-progress**: Task being worked on
+   - **completed**: Task finished (ready for archive)
+   - **blocked**: Task blocked by dependency
+
+4. **Select Task to Work On**:
+   - Choose task with highest priority
+   - Check task status before starting
+   - Verify task is not blocked
+
+**Reference**
+- Use `rulebook task show <task-id>` to view task details
+- Use `rulebook task validate <task-id>` to check task format
+- See `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines
+<!-- RULEBOOK:END -->
+

package/templates/commands/rulebook-task-show.md

@@ -1,52 +1,52 @@
----
-name: /rulebook-task-show
-id: rulebook-task-show
-category: Rulebook
-description: Show detailed information about a specific Rulebook task.
----
-<!-- RULEBOOK:START -->
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- Refer to `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines.
-
-**Steps**
-1. **Show Task Details**:
-   ```bash
-   rulebook task show <task-id>
-   ```
-   Displays:
-   - Task ID and title
-   - Status (pending, in-progress, completed, blocked)
-   - Created and updated dates
-   - Archive date (if archived)
-   - Proposal summary
-   - Spec files list
-
-2. **Review Proposal**:
-   - Read `proposal.md` to understand why and what changes
-   - Check impact assessment
-   - Verify breaking changes are documented
-
-3. **Review Tasks Checklist**:
-   - Check `tasks.md` for implementation checklist
-   - Identify completed items (`[x]`)
-   - Identify pending items (`[ ]`)
-   - Follow priority order (most critical first)
-
-4. **Review Spec Deltas**:
-   - Check `specs/*/spec.md` files
-   - Verify format compliance (SHALL/MUST, 4 hashtags for scenarios)
-   - Understand requirements and scenarios
-
-5. **Check Task Status**:
-   - Verify task is not blocked
-   - Check if task is ready for implementation
-   - Confirm all prerequisites are met
-
-**Reference**
-- Use `rulebook task list` to see all tasks
-- Use `rulebook task validate <task-id>` to check task format
-- See `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines
-<!-- RULEBOOK:END -->
-
+---
+name: /rulebook-task-show
+id: rulebook-task-show
+category: Rulebook
+description: Show detailed information about a specific Rulebook task.
+---
+<!-- RULEBOOK:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines.
+
+**Steps**
+1. **Show Task Details**:
+   ```bash
+   rulebook task show <task-id>
+   ```
+   Displays:
+   - Task ID and title
+   - Status (pending, in-progress, completed, blocked)
+   - Created and updated dates
+   - Archive date (if archived)
+   - Proposal summary
+   - Spec files list
+
+2. **Review Proposal**:
+   - Read `proposal.md` to understand why and what changes
+   - Check impact assessment
+   - Verify breaking changes are documented
+
+3. **Review Tasks Checklist**:
+   - Check `tasks.md` for implementation checklist
+   - Identify completed items (`[x]`)
+   - Identify pending items (`[ ]`)
+   - Follow priority order (most critical first)
+
+4. **Review Spec Deltas**:
+   - Check `specs/*/spec.md` files
+   - Verify format compliance (SHALL/MUST, 4 hashtags for scenarios)
+   - Understand requirements and scenarios
+
+5. **Check Task Status**:
+   - Verify task is not blocked
+   - Check if task is ready for implementation
+   - Confirm all prerequisites are met
+
+**Reference**
+- Use `rulebook task list` to see all tasks
+- Use `rulebook task validate <task-id>` to check task format
+- See `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines
+<!-- RULEBOOK:END -->
+

package/templates/commands/rulebook-task-validate.md

@@ -1,53 +1,53 @@
----
-name: /rulebook-task-validate
-id: rulebook-task-validate
-category: Rulebook
-description: Validate Rulebook task format against OpenSpec-compatible requirements.
----
-<!-- RULEBOOK:START -->
-**Guardrails**
-- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
-- Keep changes tightly scoped to the requested outcome.
-- Refer to `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines and format requirements.
-
-**Steps**
-1. **Validate Task Format**:
-   ```bash
-   rulebook task validate <task-id>
-   ```
-   Checks:
-   - Purpose section length (≥20 characters)
-   - Requirement keywords (SHALL/MUST)
-   - Scenario format (4 hashtags, not 3)
-   - Given/When/Then structure
-   - Delta headers format (ADDED/MODIFIED/REMOVED/RENAMED)
-
-2. **Review Validation Results**:
-   - **Errors**: Must be fixed before proceeding
-   - **Warnings**: Should be addressed but not blocking
-
-3. **Fix Format Issues**:
-   - **Purpose too short**: Expand "Why" section to ≥20 characters
-   - **Missing SHALL/MUST**: Add SHALL or MUST keyword to requirements
-   - **Wrong scenario format**: Change `### Scenario:` to `#### Scenario:` (4 hashtags)
-   - **Missing Given/When/Then**: Replace bullet points with Given/When/Then structure
-   - **Wrong delta headers**: Use ADDED/MODIFIED/REMOVED/RENAMED, not "New Requirements"
-
-4. **Re-validate After Fixes**:
-   ```bash
-   rulebook task validate <task-id>
-   ```
-   Ensure all errors are resolved.
-
-5. **Common Format Errors**:
-   - ❌ `### Scenario:` (3 hashtags) → ✅ `#### Scenario:` (4 hashtags)
-   - ❌ "The system provides X" → ✅ "The system SHALL provide X"
-   - ❌ `- WHEN user does X THEN Y` → ✅ `Given X\nWhen Y\nThen Z`
-   - ❌ `## New Requirements` → ✅ `## ADDED Requirements`
-
-**Reference**
-- See `/.rulebook/specs/RULEBOOK.md` for complete format requirements
-- Use Context7 MCP to get official OpenSpec format documentation
-- Use `rulebook task show <task-id>` to view task details
-<!-- RULEBOOK:END -->
-
+---
+name: /rulebook-task-validate
+id: rulebook-task-validate
+category: Rulebook
+description: Validate Rulebook task format against OpenSpec-compatible requirements.
+---
+<!-- RULEBOOK:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `/.rulebook/specs/RULEBOOK.md` for complete task management guidelines and format requirements.
+
+**Steps**
+1. **Validate Task Format**:
+   ```bash
+   rulebook task validate <task-id>
+   ```
+   Checks:
+   - Purpose section length (≥20 characters)
+   - Requirement keywords (SHALL/MUST)
+   - Scenario format (4 hashtags, not 3)
+   - Given/When/Then structure
+   - Delta headers format (ADDED/MODIFIED/REMOVED/RENAMED)
+
+2. **Review Validation Results**:
+   - **Errors**: Must be fixed before proceeding
+   - **Warnings**: Should be addressed but not blocking
+
+3. **Fix Format Issues**:
+   - **Purpose too short**: Expand "Why" section to ≥20 characters
+   - **Missing SHALL/MUST**: Add SHALL or MUST keyword to requirements
+   - **Wrong scenario format**: Change `### Scenario:` to `#### Scenario:` (4 hashtags)
+   - **Missing Given/When/Then**: Replace bullet points with Given/When/Then structure
+   - **Wrong delta headers**: Use ADDED/MODIFIED/REMOVED/RENAMED, not "New Requirements"
+
+4. **Re-validate After Fixes**:
+   ```bash
+   rulebook task validate <task-id>
+   ```
+   Ensure all errors are resolved.
+
+5. **Common Format Errors**:
+   - ❌ `### Scenario:` (3 hashtags) → ✅ `#### Scenario:` (4 hashtags)
+   - ❌ "The system provides X" → ✅ "The system SHALL provide X"
+   - ❌ `- WHEN user does X THEN Y` → ✅ `Given X\nWhen Y\nThen Z`
+   - ❌ `## New Requirements` → ✅ `## ADDED Requirements`
+
+**Reference**
+- See `/.rulebook/specs/RULEBOOK.md` for complete format requirements
+- Use Context7 MCP to get official OpenSpec format documentation
+- Use `rulebook task show <task-id>` to view task details
+<!-- RULEBOOK:END -->
+

package/templates/compact-context/_default.md

@@ -1,23 +1,23 @@
-# Post-compaction cheat sheet
-
-This file is re-injected after every conversation compaction. Keep it
-**short (≤50 lines)** and only include directives that must survive
-compaction. Everything else belongs in `CLAUDE.md`, `AGENTS.md`, or
-`.claude/rules/`.
-
-## Critical reminders
-
-- Read `AGENTS.md` and `AGENTS.override.md` before making changes.
-- Never revert or discard uncommitted work — fix forward.
-- Edit files sequentially, not in parallel (see `.claude/rules/sequential-editing.md`).
-- Run diagnostics (`type-check`, `lint`) before running the full test suite.
-- If a fix fails twice, stop and escalate — do not retry a third time.
-- Prefer MCP tools over shell commands when an equivalent MCP tool exists.
-- Save learnings to `.rulebook/learnings/` at the end of significant work.
-
-## Project-specific reminders
-
-(Edit this file to add reminders unique to your project. Examples:
-build command, primary language toolchain, forbidden directories,
-where canonical documentation lives, critical files that must not
-be touched without review.)
+# Post-compaction cheat sheet
+
+This file is re-injected after every conversation compaction. Keep it
+**short (≤50 lines)** and only include directives that must survive
+compaction. Everything else belongs in `CLAUDE.md`, `AGENTS.md`, or
+`.claude/rules/`.
+
+## Critical reminders
+
+- Read `AGENTS.md` and `AGENTS.override.md` before making changes.
+- Never revert or discard uncommitted work — fix forward.
+- Edit files sequentially, not in parallel (see `.claude/rules/sequential-editing.md`).
+- Run diagnostics (`type-check`, `lint`) before running the full test suite.
+- If a fix fails twice, stop and escalate — do not retry a third time.
+- Prefer MCP tools over shell commands when an equivalent MCP tool exists.
+- Save learnings to `.rulebook/learnings/` at the end of significant work.
+
+## Project-specific reminders
+
+(Edit this file to add reminders unique to your project. Examples:
+build command, primary language toolchain, forbidden directories,
+where canonical documentation lives, critical files that must not
+be touched without review.)

package/templates/compact-context/cpp.md

@@ -1,26 +1,26 @@
-# Post-compaction cheat sheet (C/C++ project)
-
-Re-injected after every compaction. Keep ≤50 lines. Edit freely.
-
-## Critical reminders
-
-- Read `AGENTS.md` and `AGENTS.override.md` before changes.
-- `cmake --build <build>` before running tests.
-- Warnings are errors (`-Wall -Wextra -Werror`).
-- Smart pointers only — no raw `new`/`delete` without justification.
-- Edit files sequentially, not in parallel.
-- If a fix fails twice, stop and escalate.
-
-## Build & test quick reference
-
-- **Configure**: `cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`
-- **Build**: `cmake --build build -j`
-- **Test**: `ctest --test-dir build --output-on-failure`
-- **Format**: `clang-format -i <files>`
-- **Sanitize (CI)**: `-fsanitize=address,undefined`
-
-## Forbidden
-
-- No `using namespace std;` in headers.
-- No undefined behavior shortcuts (strict aliasing, signed overflow).
-- No out-of-source build pollution in `build/` committed.
+# Post-compaction cheat sheet (C/C++ project)
+
+Re-injected after every compaction. Keep ≤50 lines. Edit freely.
+
+## Critical reminders
+
+- Read `AGENTS.md` and `AGENTS.override.md` before changes.
+- `cmake --build <build>` before running tests.
+- Warnings are errors (`-Wall -Wextra -Werror`).
+- Smart pointers only — no raw `new`/`delete` without justification.
+- Edit files sequentially, not in parallel.
+- If a fix fails twice, stop and escalate.
+
+## Build & test quick reference
+
+- **Configure**: `cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON`
+- **Build**: `cmake --build build -j`
+- **Test**: `ctest --test-dir build --output-on-failure`
+- **Format**: `clang-format -i <files>`
+- **Sanitize (CI)**: `-fsanitize=address,undefined`
+
+## Forbidden
+
+- No `using namespace std;` in headers.
+- No undefined behavior shortcuts (strict aliasing, signed overflow).
+- No out-of-source build pollution in `build/` committed.

package/templates/compact-context/go.md

@@ -1,26 +1,26 @@
-# Post-compaction cheat sheet (Go project)
-
-Re-injected after every compaction. Keep ≤50 lines. Edit freely.
-
-## Critical reminders
-
-- Read `AGENTS.md` and `AGENTS.override.md` before changes.
-- `go vet ./...` before `go test ./...`.
-- `gofmt -s -w .` on every file you touch.
-- `context.Context` as first parameter for I/O or blocking functions.
-- Edit files sequentially, not in parallel.
-- If a fix fails twice, stop and escalate.
-
-## Build & test quick reference
-
-- **Build**: `go build ./...`
-- **Vet**: `go vet ./...`
-- **Test**: `go test -race ./...`
-- **Format**: `gofmt -s -w .` and `goimports -w .`
-- **Mod tidy**: `go mod tidy` after adding imports
-
-## Forbidden
-
-- No `_ = err` — handle or wrap every error.
-- No vendored `/vendor/` unless project explicitly vendors.
-- No new modules without authorization.
+# Post-compaction cheat sheet (Go project)
+
+Re-injected after every compaction. Keep ≤50 lines. Edit freely.
+
+## Critical reminders
+
+- Read `AGENTS.md` and `AGENTS.override.md` before changes.
+- `go vet ./...` before `go test ./...`.
+- `gofmt -s -w .` on every file you touch.
+- `context.Context` as first parameter for I/O or blocking functions.
+- Edit files sequentially, not in parallel.
+- If a fix fails twice, stop and escalate.
+
+## Build & test quick reference
+
+- **Build**: `go build ./...`
+- **Vet**: `go vet ./...`
+- **Test**: `go test -race ./...`
+- **Format**: `gofmt -s -w .` and `goimports -w .`
+- **Mod tidy**: `go mod tidy` after adding imports
+
+## Forbidden
+
+- No `_ = err` — handle or wrap every error.
+- No vendored `/vendor/` unless project explicitly vendors.
+- No new modules without authorization.