Prevent mixing hook types in job schema validation

Updates the job schema to enforce that each hook event (after_agent,
before_tool, before_prompt) can only contain hooks of a single type -
either all scripts, all prompts, or all prompt_files. Mixing types
like having both a script and a prompt in the same event is now rejected.

This prevents confusing configurations where script output would be
followed by a prompt evaluation, which doesn't work as expected.

Adds tests to verify:
- Mixed script/prompt hooks are rejected
- Mixed script/prompt_file hooks are rejected
- Multiple scripts in same event are allowed
- Multiple prompts in same event are allowed

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: nhorton

.claude/commands/deepwork_rules.md

@@ -0,0 +1,59 @@
+---
+description: Rules enforcement for AI agent sessions
+---
+
+# deepwork_rules
+
+You are executing the **deepwork_rules** job. Rules enforcement for AI agent sessions
+
+Manages rules that automatically trigger when certain files change during an AI agent session.
+Rules help ensure that code changes follow team guidelines, documentation is updated,
+and architectural decisions are respected.
+
+Rules are stored as individual markdown files with YAML frontmatter in the `.deepwork/rules/`
+directory. Each rule file specifies:
+- Detection mode: trigger/safety, set (bidirectional), or pair (directional)
+- Patterns: Glob patterns for matching files, with optional variable capture
+- Instructions: Markdown content describing what the agent should do
+
+Example use cases:
+- Update installation docs when configuration files change
+- Require security review when authentication code is modified
+- Ensure API documentation stays in sync with API code
+- Enforce source/test file pairing
+
+
+## Available Steps
+
+This job has 1 step(s):
+
+### define
+**Define Rule**: Create a new rule file in .deepwork/rules/
+- Command: `uw.deepwork_rules.define`
+
+## Instructions
+
+This is a **multi-step workflow**. Determine the starting point and run through the steps in sequence.
+
+1. **Analyze user intent** from the text that follows `/deepwork_rules`
+
+2. **Identify the starting step** based on intent:
+   - define: Create a new rule file in .deepwork/rules/
+
+3. **Run the workflow** starting from the identified step:
+   - Invoke the starting step using the Skill tool
+   - When that step completes, **automatically continue** to the next step in the workflow
+   - Continue until the workflow is complete or the user intervenes
+
+4. **If intent is ambiguous**, ask the user which step to start from:
+   - Present the available steps as numbered options
+   - Use AskUserQuestion to let them choose
+
+**Critical**:
+- You MUST invoke each step using the Skill tool. Do not copy/paste step instructions.
+- After each step completes, check if there's a next step and invoke it automatically.
+- The workflow continues until all dependent steps are complete.
+
+## Context Files
+
+- Job definition: `.deepwork/jobs/deepwork_rules/job.yml`

.claude/commands/update.md

@@ -7,7 +7,7 @@ description: Update standard jobs in src/ and sync to installed locations
 You are executing the **update** job. Update standard jobs in src/ and sync to installed locations
 
 A workflow for maintaining standard jobs bundled with DeepWork. Standard jobs
-(like `deepwork_jobs` and `deepwork_policy`) are source-controlled in
+(like `deepwork_jobs` and `deepwork_rules`) are source-controlled in
 `src/deepwork/standard_jobs/` and must be edited there—never in `.deepwork/jobs/`
 or `.claude/commands/` directly.
 

.claude/commands/uw.add_platform.verify.md

@@ -13,7 +13,7 @@ hooks:
             2. Does running `deepwork install --platform <platform>` complete without errors?
             3. Are expected command files created in the platform's command directory?
             4. Does command file content match the templates and job definitions?
-            5. Are established DeepWork jobs (deepwork_jobs, deepwork_policy) installed correctly?
+            5. Are established DeepWork jobs (deepwork_jobs, deepwork_rules) installed correctly?
             6. Can the platform be used alongside existing platforms without conflicts?
 
             ## Instructions
@@ -117,7 +117,7 @@ Ensure the implementation step is complete:
    - `deepwork_jobs.define.md` exists (or equivalent for the platform)
    - `deepwork_jobs.implement.md` exists
    - `deepwork_jobs.refine.md` exists
-   - `deepwork_policy.define.md` exists
+   - `deepwork_rules.define.md` exists
    - All expected step commands exist
 
 4. **Validate command file content**
@@ -147,7 +147,7 @@ Ensure the implementation step is complete:
 - `deepwork install --platform <platform_name>` completes without errors
 - All expected command files are created:
   - deepwork_jobs.define, implement, refine
-  - deepwork_policy.define
+  - deepwork_rules.define
   - Any other standard job commands
 - Command file content is correct:
   - Matches platform's expected format
@@ -214,7 +214,7 @@ This step uses an iterative quality validation loop. After completing your work,
 2. Does running `deepwork install --platform <platform>` complete without errors?
 3. Are expected command files created in the platform's command directory?
 4. Does command file content match the templates and job definitions?
-5. Are established DeepWork jobs (deepwork_jobs, deepwork_policy) installed correctly?
+5. Are established DeepWork jobs (deepwork_jobs, deepwork_rules) installed correctly?
 6. Can the platform be used alongside existing platforms without conflicts?
 
 

.claude/commands/uw.commit.format.md

@@ -5,14 +5,6 @@ hooks:
     - hooks:
         - type: command
           command: ".deepwork/jobs/commit/hooks/run_ruff.sh"
-        - type: prompt
-          prompt: |
-            Evaluate the ruff format and lint check output above.
-
-            **If ruff reported issues (exit code non-zero)**: Start your response with "**AGENT: TAKE ACTION** -" followed by what needs to be fixed.
-
-            **If ruff reported no issues (exit code 0)**: Confirm the agent included `<promise>✓ Quality Criteria Met</promise>`. Allow completion.
-
 ---
 
 # commit.format
@@ -128,11 +120,20 @@ No file output is required. Success is determined by ruff passing all checks.
 - `uv run ruff check src/ tests/` passes (exit code 0)
 - Any fixes made don't break functionality (tests should still pass)
 - If issues couldn't be fixed in 5 attempts, clear explanation provided
-- When all checks pass, include `<promise>✓ Quality Criteria Met</promise>` in your response
+
+## Hook Behavior
+
+After you complete this step, a hook will automatically run ruff format and lint checks and show you the results.
+
+**Interpreting the hook output:**
+- **Both checks passed (exit code 0)**: The step is complete. Proceed to the next step.
+- **Checks failed (exit code non-zero)**: You must fix the issues. Use `uv run ruff format src/ tests/` for formatting and `uv run ruff check --fix src/ tests/` for auto-fixable lint issues. For remaining issues, fix manually. The hook will re-run after each attempt.
+
+**Important**: The hook runs automatically - you don't need to run the checks yourself after fixing. Just focus on making fixes, and the hook will verify them.
 
 ## Context
 
-This is the second step in the commit workflow, after tests pass. Code must be properly formatted and lint-free before committing. The format step uses a script hook that automatically runs ruff checks, so focus on analyzing results and making fixes efficiently.
+This is the second step in the commit workflow, after tests pass. Code must be properly formatted and lint-free before committing.
 
 
 

.claude/commands/uw.commit.test.md

@@ -5,14 +5,6 @@ hooks:
     - hooks:
         - type: command
           command: ".deepwork/jobs/commit/hooks/run_tests.sh"
-        - type: prompt
-          prompt: |
-            Evaluate the pytest output above.
-
-            **If any tests failed**: Start your response with "**AGENT: TAKE ACTION** -" followed by which tests failed and why.
-
-            **If ALL tests passed**: Confirm the agent included `<promise>✓ Quality Criteria Met</promise>`. Allow completion.
-
 ---
 
 # commit.test
@@ -100,11 +92,20 @@ No file output is required. Success is determined by all tests passing.
 - All tests pass (`uv run pytest tests/ -v` exits with code 0)
 - Any fixes made are minimal and don't break other functionality
 - If tests couldn't be fixed in 5 attempts, clear explanation provided
-- When all tests pass, include `<promise>✓ Quality Criteria Met</promise>` in your response
+
+## Hook Behavior
+
+After you complete this step, a hook will automatically run `uv run pytest tests/ -v` and show you the results.
+
+**Interpreting the hook output:**
+- **All tests passed (exit code 0)**: The step is complete. Proceed to the next step.
+- **Tests failed (exit code non-zero)**: You must fix the failing tests. Analyze the output, make fixes, and try again. The hook will re-run after each attempt.
+
+**Important**: The hook runs automatically - you don't need to run pytest yourself after the initial run. Just focus on making fixes when tests fail, and the hook will verify your fixes.
 
 ## Context
 
-This is the first step in the commit workflow. Tests must pass before code formatting is checked, ensuring that any changes being committed are functionally correct. The test step uses a script hook that automatically runs pytest, so focus on analyzing results and making fixes.
+This is the first step in the commit workflow. Tests must pass before code formatting is checked, ensuring that any changes being committed are functionally correct.
 
 
 

.claude/commands/uw.deepwork_jobs.implement.md

@@ -17,7 +17,7 @@ hooks:
             6. **Ask Structured Questions**: Do step instructions that gather user input explicitly use the phrase "ask structured questions"?
             7. **Sync Complete**: Has `deepwork sync` been run successfully?
             8. **Commands Available**: Are the slash-commands generated in `.claude/commands/`?
-            9. **Policies Considered**: Has the agent thought about whether policies would benefit this job? If relevant policies were identified, did they explain them and offer to run `/deepwork_policy.define`? Not every job needs policies - only suggest when genuinely helpful.
+            9. **Rules Considered**: Has the agent thought about whether rules would benefit this job? If relevant rules were identified, did they explain them and offer to run `/deepwork_rules.define`? Not every job needs rules - only suggest when genuinely helpful.
 
             ## Instructions
 
@@ -192,48 +192,48 @@ This will:
 
 After running `deepwork sync`, look at the "To use the new commands" section in the output. **Relay these exact reload instructions to the user** so they know how to pick up the new commands. Don't just reference the sync output - tell them directly what they need to do (e.g., "Type 'exit' then run 'claude --resume'" for Claude Code, or "Run '/memory refresh'" for Gemini CLI).
 
-### Step 7: Consider Policies for the New Job
+### Step 7: Consider Rules for the New Job
 
-After implementing the job, consider whether there are **policies** that would help enforce quality or consistency when working with this job's domain.
+After implementing the job, consider whether there are **rules** that would help enforce quality or consistency when working with this job's domain.
 
-**What are policies?**
+**What are rules?**
 
-Policies are automated guardrails defined in `.deepwork.policy.yml` that trigger when certain files change during an AI session. They help ensure:
+Rules are automated guardrails stored as markdown files in `.deepwork/rules/` that trigger when certain files change during an AI session. They help ensure:
 - Documentation stays in sync with code
 - Team guidelines are followed
 - Architectural decisions are respected
 - Quality standards are maintained
 
-**When to suggest policies:**
+**When to suggest rules:**
 
 Think about the job you just implemented and ask:
 - Does this job produce outputs that other files depend on?
 - Are there documentation files that should be updated when this job's outputs change?
 - Are there quality checks or reviews that should happen when certain files in this domain change?
 - Could changes to the job's output files impact other parts of the project?
 
-**Examples of policies that might make sense:**
+**Examples of rules that might make sense:**
 
-| Job Type | Potential Policy |
-|----------|------------------|
+| Job Type | Potential Rule |
+|----------|----------------|
 | API Design | "Update API docs when endpoint definitions change" |
 | Database Schema | "Review migrations when schema files change" |
 | Competitive Research | "Update strategy docs when competitor analysis changes" |
 | Feature Development | "Update changelog when feature files change" |
 | Configuration Management | "Update install guide when config files change" |
 
-**How to offer policy creation:**
+**How to offer rule creation:**
 
-If you identify one or more policies that would benefit the user, explain:
-1. **What the policy would do** - What triggers it and what action it prompts
+If you identify one or more rules that would benefit the user, explain:
+1. **What the rule would do** - What triggers it and what action it prompts
 2. **Why it would help** - How it prevents common mistakes or keeps things in sync
 3. **What files it would watch** - The trigger patterns
 
 Then ask the user:
 
-> "Would you like me to create this policy for you? I can run `/deepwork_policy.define` to set it up."
+> "Would you like me to create this rule for you? I can run `/deepwork_rules.define` to set it up."
 
-If the user agrees, invoke the `/deepwork_policy.define` command to guide them through creating the policy.
+If the user agrees, invoke the `/deepwork_rules.define` command to guide them through creating the rule.
 
 **Example dialogue:**
 
@@ -242,15 +242,15 @@ Based on the competitive_research job you just created, I noticed that when
 competitor analysis files change, it would be helpful to remind you to update
 your strategy documentation.
 
-I'd suggest a policy like:
+I'd suggest a rule like:
 - **Name**: "Update strategy when competitor analysis changes"
 - **Trigger**: `**/positioning_report.md`
 - **Action**: Prompt to review and update `docs/strategy.md`
 
-Would you like me to create this policy? I can run `/deepwork_policy.define` to set it up.
+Would you like me to create this rule? I can run `/deepwork_rules.define` to set it up.
 ```
 
-**Note:** Not every job needs policies. Only suggest them when they would genuinely help maintain consistency or quality. Don't force policies where they don't make sense.
+**Note:** Not every job needs rules. Only suggest them when they would genuinely help maintain consistency or quality. Don't force rules where they don't make sense.
 
 ## Example Implementation
 
@@ -284,8 +284,8 @@ Before marking this step complete, ensure:
 - [ ] `deepwork sync` executed successfully
 - [ ] Commands generated in platform directory
 - [ ] User informed to follow reload instructions from `deepwork sync`
-- [ ] Considered whether policies would benefit this job (Step 7)
-- [ ] If policies suggested, offered to run `/deepwork_policy.define`
+- [ ] Considered whether rules would benefit this job (Step 7)
+- [ ] If rules suggested, offered to run `/deepwork_rules.define`
 
 ## Quality Criteria
 
@@ -297,7 +297,7 @@ Before marking this step complete, ensure:
 - Steps with user inputs explicitly use "ask structured questions" phrasing
 - Sync completed successfully
 - Commands available for use
-- Thoughtfully considered relevant policies for the job domain
+- Thoughtfully considered relevant rules for the job domain
 
 
 ## Inputs
@@ -346,7 +346,7 @@ This step uses an iterative quality validation loop. After completing your work,
 6. **Ask Structured Questions**: Do step instructions that gather user input explicitly use the phrase "ask structured questions"?
 7. **Sync Complete**: Has `deepwork sync` been run successfully?
 8. **Commands Available**: Are the slash-commands generated in `.claude/commands/`?
-9. **Policies Considered**: Has the agent thought about whether policies would benefit this job? If relevant policies were identified, did they explain them and offer to run `/deepwork_policy.define`? Not every job needs policies - only suggest when genuinely helpful.
+9. **Rules Considered**: Has the agent thought about whether rules would benefit this job? If relevant rules were identified, did they explain them and offer to run `/deepwork_rules.define`? Not every job needs rules - only suggest when genuinely helpful.
 
 
 ### Completion Promise