@hivehub/rulebook 5.4.1 → 5.5.1

package/templates/skills/core/rulebook/SKILL.md

@@ -1,176 +1,176 @@
----
-name: "Rulebook Task Management"
-description: "Spec-driven task management for features and breaking changes with OpenSpec-compatible format"
-version: "1.0.0"
-category: "core"
-author: "Rulebook"
-tags: ["task-management", "openspec", "spec-driven", "workflow"]
-dependencies: []
-conflicts: []
----
-
-# Rulebook Task Management
-
-**CRITICAL**: Use Rulebook's built-in task management system for spec-driven development of new features and breaking changes.
-
-## When to Use
-
-Create tasks for:
-- New features/capabilities
-- Breaking changes
-- Architecture changes
-- Performance/security work
-
-Skip for:
-- Bug fixes (restore intended behavior)
-- Typos, formatting, comments
-- Dependency updates (non-breaking)
-
-## Task Creation is MANDATORY Before Implementation
-
-**ABSOLUTE RULE**: You MUST create a task BEFORE implementing ANY feature.
-
-### MANDATORY Workflow
-
-**NEVER start implementation without creating a task first:**
-
-```bash
-# WRONG: Starting implementation directly
-# ... writing code without task ...
-
-# CORRECT: Create task first
-rulebook task create <task-id>
-# Write proposal.md
-# Write tasks.md
-# Write spec deltas
-rulebook task validate <task-id>
-# NOW you can start implementation
-```
-
-### Task Creation Steps
-
-**When a feature is requested:**
-
-1. **STOP** - Do not start coding
-2. **Create task** - `rulebook task create <task-id>`
-3. **Plan** - Write proposal.md and tasks.md
-4. **Spec** - Write spec deltas
-5. **Validate** - `rulebook task validate <task-id>`
-6. **THEN** - Start implementation
-
-## Task Directory Structure
-
-```
-.rulebook/tasks/<task-id>/
-├── proposal.md         # Why and what changes
-├── tasks.md            # Implementation checklist
-├── design.md           # Technical design (optional)
-└── specs/
-    └── <module>/
-        └── spec.md     # Technical specifications
-```
-
-## Task Commands
-
-```bash
-# Create new task
-rulebook task create <task-id>
-
-# List all tasks
-rulebook task list
-
-# Show task details
-rulebook task show <task-id>
-
-# Validate task structure
-rulebook task validate <task-id>
-
-# Archive completed task
-rulebook task archive <task-id>
-```
-
-## Proposal Format (proposal.md)
-
-```markdown
-# Proposal: <Task Title>
-
-## Why
-<Explain the problem or opportunity>
-
-## What Changes
-<List of changes with ADDED/MODIFIED/REMOVED markers>
-
-## Impact
-- Affected specs: <list spec files>
-- Affected code: <list source files>
-- Breaking change: YES/NO
-- User benefit: <describe benefit>
-```
-
-## Tasks Format (tasks.md)
-
-**CRITICAL**: Only simple checklist items. Technical details go in specs.
-
-```markdown
-## 1. <Phase Name>
-- [ ] 1.1 <Simple task description>
-- [ ] 1.2 <Simple task description>
-
-## 2. <Phase Name>
-- [ ] 2.1 <Simple task description>
-```
-
-## Spec Delta Format (specs/<module>/spec.md)
-
-```markdown
-# <Module> Specification
-
-## ADDED Requirements
-
-### Requirement: <Name>
-<Description>
-
-#### Scenario: <Name>
-Given <context>
-When <action>
-Then <expected result>
-
-## MODIFIED Requirements
-
-### Requirement: <Original Name>
-<Description of modification>
-
-## REMOVED Requirements
-
-### Requirement: <Name to Remove>
-<Reason for removal>
-```
-
-## MCP Integration
-
-If MCP server is enabled, use programmatic task management:
-
-```typescript
-// Create task
-await mcp.rulebook_task_create({ taskId: "my-task" });
-
-// List tasks
-await mcp.rulebook_task_list({});
-
-// Show task
-await mcp.rulebook_task_show({ taskId: "my-task" });
-
-// Validate task
-await mcp.rulebook_task_validate({ taskId: "my-task" });
-
-// Archive task
-await mcp.rulebook_task_archive({ taskId: "my-task" });
-```
-
-## Best Practices
-
-1. **Always create task first** - Never implement without documentation
-2. **Keep tasks.md simple** - Only checklist items, no explanations
-3. **Put details in specs** - Technical requirements go in spec files
-4. **Validate before implementing** - Run `rulebook task validate`
-5. **Archive when done** - Move completed tasks to archive
+---
+name: "Rulebook Task Management"
+description: "Spec-driven task management for features and breaking changes with OpenSpec-compatible format"
+version: "1.0.0"
+category: "core"
+author: "Rulebook"
+tags: ["task-management", "openspec", "spec-driven", "workflow"]
+dependencies: []
+conflicts: []
+---
+
+# Rulebook Task Management
+
+**CRITICAL**: Use Rulebook's built-in task management system for spec-driven development of new features and breaking changes.
+
+## When to Use
+
+Create tasks for:
+- New features/capabilities
+- Breaking changes
+- Architecture changes
+- Performance/security work
+
+Skip for:
+- Bug fixes (restore intended behavior)
+- Typos, formatting, comments
+- Dependency updates (non-breaking)
+
+## Task Creation is MANDATORY Before Implementation
+
+**ABSOLUTE RULE**: You MUST create a task BEFORE implementing ANY feature.
+
+### MANDATORY Workflow
+
+**NEVER start implementation without creating a task first:**
+
+```bash
+# WRONG: Starting implementation directly
+# ... writing code without task ...
+
+# CORRECT: Create task first
+rulebook task create <task-id>
+# Write proposal.md
+# Write tasks.md
+# Write spec deltas
+rulebook task validate <task-id>
+# NOW you can start implementation
+```
+
+### Task Creation Steps
+
+**When a feature is requested:**
+
+1. **STOP** - Do not start coding
+2. **Create task** - `rulebook task create <task-id>`
+3. **Plan** - Write proposal.md and tasks.md
+4. **Spec** - Write spec deltas
+5. **Validate** - `rulebook task validate <task-id>`
+6. **THEN** - Start implementation
+
+## Task Directory Structure
+
+```
+.rulebook/tasks/<task-id>/
+├── proposal.md         # Why and what changes
+├── tasks.md            # Implementation checklist
+├── design.md           # Technical design (optional)
+└── specs/
+    └── <module>/
+        └── spec.md     # Technical specifications
+```
+
+## Task Commands
+
+```bash
+# Create new task
+rulebook task create <task-id>
+
+# List all tasks
+rulebook task list
+
+# Show task details
+rulebook task show <task-id>
+
+# Validate task structure
+rulebook task validate <task-id>
+
+# Archive completed task
+rulebook task archive <task-id>
+```
+
+## Proposal Format (proposal.md)
+
+```markdown
+# Proposal: <Task Title>
+
+## Why
+<Explain the problem or opportunity>
+
+## What Changes
+<List of changes with ADDED/MODIFIED/REMOVED markers>
+
+## Impact
+- Affected specs: <list spec files>
+- Affected code: <list source files>
+- Breaking change: YES/NO
+- User benefit: <describe benefit>
+```
+
+## Tasks Format (tasks.md)
+
+**CRITICAL**: Only simple checklist items. Technical details go in specs.
+
+```markdown
+## 1. <Phase Name>
+- [ ] 1.1 <Simple task description>
+- [ ] 1.2 <Simple task description>
+
+## 2. <Phase Name>
+- [ ] 2.1 <Simple task description>
+```
+
+## Spec Delta Format (specs/<module>/spec.md)
+
+```markdown
+# <Module> Specification
+
+## ADDED Requirements
+
+### Requirement: <Name>
+<Description>
+
+#### Scenario: <Name>
+Given <context>
+When <action>
+Then <expected result>
+
+## MODIFIED Requirements
+
+### Requirement: <Original Name>
+<Description of modification>
+
+## REMOVED Requirements
+
+### Requirement: <Name to Remove>
+<Reason for removal>
+```
+
+## MCP Integration
+
+If MCP server is enabled, use programmatic task management:
+
+```typescript
+// Create task
+await mcp.rulebook_task_create({ taskId: "my-task" });
+
+// List tasks
+await mcp.rulebook_task_list({});
+
+// Show task
+await mcp.rulebook_task_show({ taskId: "my-task" });
+
+// Validate task
+await mcp.rulebook_task_validate({ taskId: "my-task" });
+
+// Archive task
+await mcp.rulebook_task_archive({ taskId: "my-task" });
+```
+
+## Best Practices
+
+1. **Always create task first** - Never implement without documentation
+2. **Keep tasks.md simple** - Only checklist items, no explanations
+3. **Put details in specs** - Technical requirements go in spec files
+4. **Validate before implementing** - Run `rulebook task validate`
+5. **Archive when done** - Move completed tasks to archive

package/templates/skills/core/rulebook-terse/SKILL.md

@@ -1,116 +1,116 @@
----
-name: "Rulebook Terse"
-description: "Output-verbosity compression. Cuts response tokens ~40-70% without losing technical accuracy. Four intensity levels (off/brief/terse/ultra) aligned with Rulebook's agent-tier system. Use when user says 'terse mode', 'be terse', 'less tokens please', or invokes /rulebook-terse. Auto-activates via SessionStart hook with tier-aware default."
-version: "1.0.0"
-category: "core"
-author: "Rulebook"
-tags: ["core", "output", "tokens", "compression"]
-dependencies: []
-conflicts: []
----
-<!-- RULEBOOK_TERSE:START -->
-# Rulebook Terse — Output Compression
-
-Respond tersely. All technical substance stays. Only fluff dies.
-
-## Persistence
-
-ACTIVE EVERY RESPONSE once set. No revert after many turns. No filler drift. Still active if unsure.
-
-Off only via: `/rulebook-terse off` · "normal mode" · "stop terse" · session end.
-
-Default intensity resolves from: `RULEBOOK_TERSE_MODE` env → `.rulebook/rulebook.json` `terse.defaultMode` → active agent tier → `terse`.
-
-## Rules
-
-**Drop**:
-- Articles (`a`, `an`, `the`) — level-dependent, see intensity table
-- Filler (`just`, `really`, `basically`, `actually`, `simply`, `essentially`)
-- Pleasantries (`sure`, `certainly`, `of course`, `happy to`, `great question`, `I'd recommend`)
-- Hedging (`it might be worth`, `you could consider`, `perhaps`, `I think`)
-- Preamble + restating the question
-
-**Keep exact**:
-- Technical terms (library names, API names, protocols, algorithms)
-- Code blocks (fenced and inline) — byte-for-byte pass-through
-- File paths (`/src/foo.ts`, `./config.yaml`, `E:\project\file`)
-- URLs + links
-- Commands (`npm test`, `git commit`)
-- Error messages (quoted)
-- Version numbers + dates
-- Proper nouns
-
-**Pattern**:
-
-```
-[thing] [action] [reason]. [next step].
-```
-
-**Example**:
-
-❌ "Sure! I'd be happy to help. The issue you're experiencing is most likely caused by the authentication middleware not properly validating token expiry. Let me take a look."
-
-✅ "Bug in auth middleware. Token expiry check uses `<` not `<=`. Fix:"
-
-## Intensity
-
-| Level | What changes |
-|-------|-------------|
-| **off** | No compression. Full prose. Full reasoning welcome. Default for Core tier (opus). |
-| **brief** | Drop filler + hedging + pleasantries. Keep articles + full sentences. Default for Standard tier (sonnet). |
-| **terse** | Drop articles. Fragments OK. Short synonyms (`fix` not "implement a solution for", `big` not "extensive"). Default for Research tier (haiku). |
-| **ultra** | Abbreviate (DB/auth/config/req/res/fn/impl). Strip conjunctions. Arrows for causality (`X → Y`). One word when one word suffices. |
-
-### Example — "Why does my React component re-render?"
-
-- **off**: "Your component re-renders because you're creating a new object reference on every render. When you pass an inline object as a prop, React's shallow comparison sees it as a different object each time. Wrap it in `useMemo` to stabilize the reference."
-- **brief**: "Component re-renders because you create a new object reference each render. Inline object prop fails shallow comparison. Wrap it in `useMemo`."
-- **terse**: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
-- **ultra**: "Inline obj prop → new ref → re-render. `useMemo`."
-
-### Example — "Explain database connection pooling."
-
-- **off**: "Connection pooling reuses a set of pre-opened database connections instead of creating a new connection for each request. This avoids the overhead of establishing a new TCP handshake and authenticating every time."
-- **brief**: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake + auth overhead."
-- **terse**: "Pool reuses open DB connections. No new connection per request. Skip handshake overhead."
-- **ultra**: "Pool = reuse DB conn. Skip handshake → fast under load."
-
-## Auto-Clarity (mandatory escape hatch)
-
-Compression is suspended — for the affected turn only — when ANY of the following applies. Full prose is restored. Compression resumes on the next turn.
-
-1. **Security warnings** — CVE-class findings, credential exposure, permission-elevation warnings.
-2. **Destructive-op confirmations** — `rm -rf`, `git reset --hard`, `DROP TABLE`, `rulebook_task_delete`, irreversible file deletion.
-3. **Quality-gate failures** — type-check errors, lint failures, failing tests, coverage below threshold, hook-emitted deny messages from `enforce-no-deferred` / `enforce-no-shortcuts` / `enforce-mcp-for-tasks`.
-4. **Multi-step sequences** where fragment ambiguity risks misread (migration steps, ordered deploys, multi-service restarts).
-5. **User confusion** — explicit "I don't understand", "explain again", or repeat of the same question.
-
-### Example — destructive op
-
-> **Warning**: This will permanently delete all rows in the `users` table and cannot be undone.
->
-> ```sql
-> DROP TABLE users;
-> ```
->
-> Verify a backup exists before proceeding. After confirmation, terse resumes.
-
-## Boundaries
-
-- **Code blocks**: byte-for-byte unchanged. Never compressed, never abbreviated, never reordered.
-- **Commit messages**: handled by the separate `rulebook-terse-commit` skill. Base skill does nothing to commits.
-- **PR reviews**: handled by `rulebook-terse-review`. Base skill does nothing to reviews.
-- **Specs** (`.rulebook/specs/**`, `proposal.md`, `spec.md`): unchanged.
-- **Test assertions + error strings**: verbatim.
-
-## Activation surface
-
-| Surface | Example |
-|---------|---------|
-| Slash command | `/rulebook-terse`, `/rulebook-terse brief\|terse\|ultra\|off` |
-| Natural language (on) | "be terse", "less tokens please", "terse mode", "activate rulebook-terse" |
-| Natural language (off) | "normal mode", "stop terse", "disable terse" |
-| Model inference | Any trigger phrase in this skill's `description` frontmatter |
-| Automatic | SessionStart hook, tier-aware default |
-
-<!-- RULEBOOK_TERSE:END -->
+---
+name: "Rulebook Terse"
+description: "Output-verbosity compression. Cuts response tokens ~40-70% without losing technical accuracy. Four intensity levels (off/brief/terse/ultra) aligned with Rulebook's agent-tier system. Use when user says 'terse mode', 'be terse', 'less tokens please', or invokes /rulebook-terse. Auto-activates via SessionStart hook with tier-aware default."
+version: "1.0.0"
+category: "core"
+author: "Rulebook"
+tags: ["core", "output", "tokens", "compression"]
+dependencies: []
+conflicts: []
+---
+<!-- RULEBOOK_TERSE:START -->
+# Rulebook Terse — Output Compression
+
+Respond tersely. All technical substance stays. Only fluff dies.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE once set. No revert after many turns. No filler drift. Still active if unsure.
+
+Off only via: `/rulebook-terse off` · "normal mode" · "stop terse" · session end.
+
+Default intensity resolves from: `RULEBOOK_TERSE_MODE` env → `.rulebook/rulebook.json` `terse.defaultMode` → active agent tier → `terse`.
+
+## Rules
+
+**Drop**:
+- Articles (`a`, `an`, `the`) — level-dependent, see intensity table
+- Filler (`just`, `really`, `basically`, `actually`, `simply`, `essentially`)
+- Pleasantries (`sure`, `certainly`, `of course`, `happy to`, `great question`, `I'd recommend`)
+- Hedging (`it might be worth`, `you could consider`, `perhaps`, `I think`)
+- Preamble + restating the question
+
+**Keep exact**:
+- Technical terms (library names, API names, protocols, algorithms)
+- Code blocks (fenced and inline) — byte-for-byte pass-through
+- File paths (`/src/foo.ts`, `./config.yaml`, `E:\project\file`)
+- URLs + links
+- Commands (`npm test`, `git commit`)
+- Error messages (quoted)
+- Version numbers + dates
+- Proper nouns
+
+**Pattern**:
+
+```
+[thing] [action] [reason]. [next step].
+```
+
+**Example**:
+
+❌ "Sure! I'd be happy to help. The issue you're experiencing is most likely caused by the authentication middleware not properly validating token expiry. Let me take a look."
+
+✅ "Bug in auth middleware. Token expiry check uses `<` not `<=`. Fix:"
+
+## Intensity
+
+| Level | What changes |
+|-------|-------------|
+| **off** | No compression. Full prose. Full reasoning welcome. Default for Core tier (opus). |
+| **brief** | Drop filler + hedging + pleasantries. Keep articles + full sentences. Default for Standard tier (sonnet). |
+| **terse** | Drop articles. Fragments OK. Short synonyms (`fix` not "implement a solution for", `big` not "extensive"). Default for Research tier (haiku). |
+| **ultra** | Abbreviate (DB/auth/config/req/res/fn/impl). Strip conjunctions. Arrows for causality (`X → Y`). One word when one word suffices. |
+
+### Example — "Why does my React component re-render?"
+
+- **off**: "Your component re-renders because you're creating a new object reference on every render. When you pass an inline object as a prop, React's shallow comparison sees it as a different object each time. Wrap it in `useMemo` to stabilize the reference."
+- **brief**: "Component re-renders because you create a new object reference each render. Inline object prop fails shallow comparison. Wrap it in `useMemo`."
+- **terse**: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
+- **ultra**: "Inline obj prop → new ref → re-render. `useMemo`."
+
+### Example — "Explain database connection pooling."
+
+- **off**: "Connection pooling reuses a set of pre-opened database connections instead of creating a new connection for each request. This avoids the overhead of establishing a new TCP handshake and authenticating every time."
+- **brief**: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake + auth overhead."
+- **terse**: "Pool reuses open DB connections. No new connection per request. Skip handshake overhead."
+- **ultra**: "Pool = reuse DB conn. Skip handshake → fast under load."
+
+## Auto-Clarity (mandatory escape hatch)
+
+Compression is suspended — for the affected turn only — when ANY of the following applies. Full prose is restored. Compression resumes on the next turn.
+
+1. **Security warnings** — CVE-class findings, credential exposure, permission-elevation warnings.
+2. **Destructive-op confirmations** — `rm -rf`, `git reset --hard`, `DROP TABLE`, `rulebook_task_delete`, irreversible file deletion.
+3. **Quality-gate failures** — type-check errors, lint failures, failing tests, coverage below threshold, hook-emitted deny messages from `enforce-no-deferred` / `enforce-no-shortcuts` / `enforce-mcp-for-tasks`.
+4. **Multi-step sequences** where fragment ambiguity risks misread (migration steps, ordered deploys, multi-service restarts).
+5. **User confusion** — explicit "I don't understand", "explain again", or repeat of the same question.
+
+### Example — destructive op
+
+> **Warning**: This will permanently delete all rows in the `users` table and cannot be undone.
+>
+> ```sql
+> DROP TABLE users;
+> ```
+>
+> Verify a backup exists before proceeding. After confirmation, terse resumes.
+
+## Boundaries
+
+- **Code blocks**: byte-for-byte unchanged. Never compressed, never abbreviated, never reordered.
+- **Commit messages**: handled by the separate `rulebook-terse-commit` skill. Base skill does nothing to commits.
+- **PR reviews**: handled by `rulebook-terse-review`. Base skill does nothing to reviews.
+- **Specs** (`.rulebook/specs/**`, `proposal.md`, `spec.md`): unchanged.
+- **Test assertions + error strings**: verbatim.
+
+## Activation surface
+
+| Surface | Example |
+|---------|---------|
+| Slash command | `/rulebook-terse`, `/rulebook-terse brief\|terse\|ultra\|off` |
+| Natural language (on) | "be terse", "less tokens please", "terse mode", "activate rulebook-terse" |
+| Natural language (off) | "normal mode", "stop terse", "disable terse" |
+| Model inference | Any trigger phrase in this skill's `description` frontmatter |
+| Automatic | SessionStart hook, tier-aware default |
+
+<!-- RULEBOOK_TERSE:END -->