deepwork 0.2.0__py3-none-any.whl → 0.3.1__py3-none-any.whl

deepwork/standard_jobs/deepwork_jobs/steps/define.md

@@ -6,13 +6,15 @@ Create a `job.yml` specification file that defines the structure of a new DeepWo
 
 ## Task
 
-Guide the user through defining a job specification by asking clarifying questions. **Do not attempt to create the specification without first fully understanding the user's needs.**
+Guide the user through defining a job specification by asking structured questions. **Do not attempt to create the specification without first fully understanding the user's needs.**
+
+**Important**: Use the AskUserQuestion tool to ask structured questions when gathering information from the user. This provides a better user experience with clear options and guided choices.
 
 The output of this step is **only** the `job.yml` file - a complete specification of the workflow. The actual step instruction files will be created in the next step (`implement`).
 
 ### Step 1: Understand the Job Purpose
 
-Start by asking questions to understand what the user wants to accomplish:
+Start by asking structured questions to understand what the user wants to accomplish:
 
 1. **What is the overall goal of this workflow?**
    - What complex task are they trying to accomplish?
@@ -31,7 +33,7 @@ Start by asking questions to understand what the user wants to accomplish:
 
 ### Step 2: Define Each Step
 
-For each major phase they mentioned, ask detailed questions:
+For each major phase they mentioned, ask structured questions to gather details:
 
 1. **Step Purpose**
    - What exactly does this step accomplish?
@@ -92,7 +94,7 @@ After gathering information about all steps:
 
 For each step, consider whether it would benefit from **quality validation loops**. Stop hooks allow the AI agent to iteratively refine its work until quality criteria are met.
 
-**Ask the user about quality validation:**
+**Ask structured questions about quality validation:**
 - "Are there specific quality criteria that must be met for this step?"
 - "Would you like the agent to validate its work before completing?"
 - "What would make you send the work back for revision?"
@@ -281,11 +283,11 @@ Run `/deepwork_jobs.implement` to generate the instruction files for each step b
 ## Important Guidelines
 
 1. **Focus on specification only** - Don't create instruction files yet
-2. **Ask clarifying questions** - Never skip the discovery phase
+2. **Ask structured questions** - Never skip the discovery phase; use the AskUserQuestion tool
 3. **Rich context in description** - This helps with future refinement
 4. **Validate understanding** - Summarize and confirm before creating
 5. **Use examples** - Help users understand what good specifications look like
-6. **Understand file organization** - Always ask where outputs should be saved and if subdirectories are needed
+6. **Understand file organization** - Always ask structured questions about where outputs should be saved and if subdirectories are needed
 
 ## Validation Rules
 
@@ -319,6 +321,7 @@ After creating the file:
 
 ## Quality Criteria
 
+- Asked structured questions to fully understand user requirements
 - User fully understands what job they're creating
 - All steps have clear inputs and outputs
 - Dependencies make logical sense

deepwork/standard_jobs/deepwork_jobs/steps/implement.md

@@ -69,6 +69,7 @@ For each step in the job.yml, create a comprehensive instruction file at `.deepw
 4. **Explain the "why"** - Help the user understand the step's role in the workflow
 5. **Quality over quantity** - Detailed, actionable instructions are better than vague ones
 6. **Align with stop hooks** - If the step has `stop_hooks` defined, ensure the quality criteria in the instruction file match the validation criteria in the hooks
+7. **Ask structured questions** - When a step has user inputs, the instructions MUST explicitly tell the agent to "ask structured questions" using the AskUserQuestion tool to gather that information. Never use generic phrasing like "ask the user" - always use "ask structured questions"
 
 ### Handling Stop Hooks
 
@@ -112,9 +113,9 @@ See `.deepwork/jobs/deepwork_jobs/steps/supplemental_file_references.md` for det
 
 Verify that `job.yml` is in the correct location at `.deepwork/jobs/[job_name]/job.yml`. The define step should have created it there. If for some reason it's not there, you may need to create or move it.
 
-### Step 5: Sync Commands
+### Step 5: Sync Skills
 
-Run `deepwork sync` to generate the slash-commands for this job:
+Run `deepwork sync` to generate the skills for this job:
 
 ```bash
 deepwork sync
@@ -122,26 +123,26 @@ deepwork sync
 
 This will:
 - Parse the job definition
-- Generate slash-commands for each step
-- Make the commands available in `.claude/commands/` (or appropriate platform directory)
+- Generate skills for each step
+- Make the skills available in `.claude/skills/` (or appropriate platform directory)
 
 ### Step 6: Relay Reload Instructions
 
-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).
+After running `deepwork sync`, look at the "To use the new skills" section in the output. **Relay these exact reload instructions to the user** so they know how to pick up the new skills. 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?
@@ -149,28 +150,28 @@ Think about the job you just implemented and ask:
 - 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:**
 
@@ -179,15 +180,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
 
@@ -219,10 +220,10 @@ Before marking this step complete, ensure:
 - [ ] All step instruction files created
 - [ ] Each instruction file is complete and actionable
 - [ ] `deepwork sync` executed successfully
-- [ ] Commands generated in platform directory
+- [ ] Skills 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
 
@@ -231,6 +232,7 @@ Before marking this step complete, ensure:
 - Instructions are specific and actionable
 - Output examples are provided in each instruction file
 - Quality criteria defined for each step
+- 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
+- Skills available for use
+- Thoughtfully considered relevant rules for the job domain

deepwork/standard_jobs/deepwork_jobs/steps/learn.md

@@ -171,7 +171,7 @@ If instruction files were modified:
    deepwork sync
    ```
 
-2. **If commands were regenerated**, look at the "To use the new commands" section in the `deepwork sync` output and **relay these exact reload instructions to the user** (e.g., "Type 'exit' then run 'claude --resume'" for Claude Code)
+2. **If skills were regenerated**, look at the "To use the new skills" section in the `deepwork sync` output and **relay these exact reload instructions to the user** (e.g., "Type 'exit' then run 'claude --resume'" for Claude Code)
 
 ## File Reference Patterns
 
@@ -261,7 +261,7 @@ I found the following job executions:
 
 **Summary**
 
-Updated job instructions and created AGENTS.md with bespoke learnings. To get the updated commands, type 'exit' then run 'claude --resume'.
+Updated job instructions and created AGENTS.md with bespoke learnings. To get the updated skills, type 'exit' then run 'claude --resume'.
 ```
 
 ## Handling Edge Cases

deepwork/standard_jobs/deepwork_rules/hooks/capture_prompt_work_tree.sh

@@ -0,0 +1,30 @@
+#!/bin/bash
+# capture_prompt_work_tree.sh - Captures the git work tree state at prompt submission
+#
+# This script creates a snapshot of ALL tracked files at the time the prompt
+# is submitted. This baseline is used for rules with compare_to: prompt and
+# created: mode to detect truly NEW files (not modifications to existing ones).
+#
+# The baseline contains ALL tracked files (not just changed files) so that
+# the rules_check hook can determine which files are genuinely new vs which
+# files existed before and were just modified.
+
+set -e
+
+# Ensure .deepwork directory exists
+mkdir -p .deepwork
+
+# Save ALL tracked files (not just changed files)
+# This is critical for created: mode rules to distinguish between:
+# - Newly created files (not in baseline) -> should trigger created: rules
+# - Modified existing files (in baseline) -> should NOT trigger created: rules
+git ls-files > .deepwork/.last_work_tree 2>/dev/null || true
+
+# Also include untracked files that exist at prompt time
+# These are files the user may have created before submitting the prompt
+git ls-files --others --exclude-standard >> .deepwork/.last_work_tree 2>/dev/null || true
+
+# Sort and deduplicate
+if [ -f .deepwork/.last_work_tree ]; then
+    sort -u .deepwork/.last_work_tree -o .deepwork/.last_work_tree
+fi

deepwork/standard_jobs/deepwork_rules/hooks/global_hooks.yml

@@ -0,0 +1,8 @@
+# DeepWork Rules Hooks Configuration
+# Maps lifecycle events to hook scripts or Python modules
+
+UserPromptSubmit:
+  - user_prompt_submit.sh
+
+Stop:
+  - module: deepwork.hooks.rules_check

deepwork/standard_jobs/deepwork_rules/job.yml

@@ -0,0 +1,47 @@
+name: deepwork_rules
+version: "0.3.0"
+summary: "Rules enforcement for AI agent sessions"
+description: |
+  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.
+
+  IMPORTANT: Rules are evaluated at the "Stop" hook, which fires when an agent finishes its turn.
+  This includes when sub-agents complete their work. Rules are NOT evaluated immediately after
+  each file edit - they batch up and run once at the end of the agent's response cycle.
+  - Command action rules: Execute their command (e.g., `uv sync`) when the agent stops
+  - Prompt action rules: Display instructions to the agent, blocking until addressed
+
+  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
+  - Action type: prompt (default) to show instructions, or command to run a shell command
+  - 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
+  - Auto-run `uv sync` when pyproject.toml changes (command action)
+
+changelog:
+  - version: "0.1.0"
+    changes: "Initial version"
+  - version: "0.2.0"
+    changes: "Standardized on 'ask structured questions' phrasing for user input"
+  - version: "0.3.0"
+    changes: "Migrated to v2 format - individual markdown files in .deepwork/rules/"
+
+steps:
+  - id: define
+    name: "Define Rule"
+    description: "Create a new rule file in .deepwork/rules/"
+    instructions_file: steps/define.md
+    inputs:
+      - name: rule_purpose
+        description: "What guideline or constraint should this rule enforce?"
+    outputs:
+      - .deepwork/rules/{rule-name}.md
+    dependencies: []

deepwork/standard_jobs/deepwork_rules/rules/.gitkeep

@@ -0,0 +1,13 @@
+# This directory contains example rule templates.
+# Copy and customize these files to create your own rules.
+#
+# Rule files use YAML frontmatter in markdown format:
+#
+# ---
+# name: Rule Name
+# trigger: "pattern/**/*"
+# safety: "optional/pattern"
+# ---
+# Instructions in markdown here.
+#
+# See doc/rules_syntax.md for full documentation.

deepwork/standard_jobs/deepwork_rules/rules/api-documentation-sync.md.example

@@ -0,0 +1,10 @@
+---
+name: API Documentation Sync
+trigger: src/api/**/*
+safety: docs/api/**/*.md
+---
+API code has changed. Please verify that API documentation is up to date:
+
+- New or changed endpoints
+- Modified request/response schemas
+- Updated authentication requirements

deepwork/standard_jobs/deepwork_rules/rules/readme-documentation.md.example

@@ -0,0 +1,10 @@
+---
+name: README Documentation
+trigger: src/**/*
+safety: README.md
+---
+Source code has been modified. Please review README.md for accuracy:
+
+1. Verify the project overview reflects current functionality
+2. Check that usage examples are still correct
+3. Ensure installation/setup instructions remain valid

deepwork/standard_jobs/deepwork_rules/rules/security-review.md.example

@@ -0,0 +1,11 @@
+---
+name: Security Review for Auth Changes
+trigger:
+  - src/auth/**/*
+  - src/security/**/*
+---
+Authentication or security code has been changed. Please:
+
+1. Review for hardcoded credentials or secrets
+2. Check input validation on user inputs
+3. Verify access control logic is correct

deepwork/standard_jobs/deepwork_rules/rules/skill-md-validation.md

@@ -0,0 +1,46 @@
+---
+name: SKILL.md Validation
+trigger: "**/SKILL.md"
+compare_to: base
+---
+A SKILL.md file has been created or modified. Please validate that it follows the required format:
+
+## Required Structure
+
+The file MUST have valid YAML frontmatter at the start, enclosed between `---` markers:
+
+```markdown
+---
+name: my-skill-name
+description: A description of what this skill does
+---
+
+# Rest of the skill documentation...
+```
+
+## Validation Checklist
+
+1. **YAML Frontmatter**: Verify the file starts with `---` followed by valid YAML and ends with `---`
+
+2. **`name` field** (required):
+   - Must be present in the frontmatter
+   - Must contain only lowercase letters, numbers, and hyphens (`a-z`, `0-9`, `-`)
+   - Must be 64 characters or fewer
+   - Example valid names: `my-skill`, `code-review-2`, `lint`
+   - Example invalid names: `My Skill` (uppercase/spaces), `skill_name` (underscores), `SKILL` (uppercase)
+
+3. **`description` field** (required):
+   - Must be present in the frontmatter
+   - Must be 1024 characters or fewer
+   - Should clearly describe what the skill does
+
+## What to Check
+
+For the modified file: {trigger_files}
+
+1. Parse the YAML frontmatter and verify it is valid YAML
+2. Check that `name` exists and matches the pattern `^[a-z0-9-]+$` with max length 64
+3. Check that `description` exists and is at most 1024 characters
+4. Report any validation errors to the user
+
+If the file does not pass validation, help the user fix the issues.

deepwork/standard_jobs/deepwork_rules/rules/source-test-pairing.md.example

@@ -0,0 +1,13 @@
+---
+name: Source/Test Pairing
+set:
+  - src/{path}.py
+  - tests/{path}_test.py
+---
+Source and test files should change together.
+
+When modifying source code, ensure corresponding tests are updated.
+When adding tests, ensure they test actual source code.
+
+Modified source: {trigger_files}
+Expected tests: {expected_files}

deepwork/standard_jobs/deepwork_rules/steps/define.md

@@ -0,0 +1,249 @@
+# Define Rule
+
+## Objective
+
+Create a new rule file in the `.deepwork/rules/` directory to enforce team guidelines, documentation requirements, or other constraints when specific files change.
+
+## Task
+
+Guide the user through defining a new rule by asking structured questions. **Do not create the rule without first understanding what they want to enforce.**
+
+**Important**: Use the AskUserQuestion tool to ask structured questions when gathering information from the user. This provides a better user experience with clear options and guided choices.
+
+### Step 1: Understand the Rule Purpose
+
+Start by asking structured questions to understand what the user wants to enforce:
+
+1. **What guideline or constraint should this rule enforce?**
+   - What situation triggers the need for action?
+   - What files or directories, when changed, should trigger this rule?
+   - Examples: "When config files change", "When API code changes", "When database schema changes"
+
+2. **What action should be taken?**
+   - What should the agent do when the rule triggers?
+   - Update documentation? Perform a security review? Update tests?
+   - Is there a specific file or process that needs attention?
+
+3. **Are there any "safety" conditions?**
+   - Are there files that, if also changed, mean the rule doesn't need to fire?
+   - For example: If config changes AND install_guide.md changes, assume docs are already updated
+   - This prevents redundant prompts when the user has already done the right thing
+
+### Step 2: Choose the Detection Mode
+
+Help the user select the appropriate detection mode:
+
+**Trigger/Safety Mode** (most common):
+- Fires when trigger patterns match AND no safety patterns match
+- Use for: "When X changes, check Y" rules
+- Example: When config changes, verify install docs
+
+**Set Mode** (bidirectional correspondence):
+- Fires when files that should change together don't all change
+- Use for: Source/test pairing, model/migration sync
+- Example: `src/foo.py` and `tests/foo_test.py` should change together
+
+**Pair Mode** (directional correspondence):
+- Fires when a trigger file changes but expected files don't
+- Changes to expected files alone do NOT trigger
+- Use for: API code requires documentation updates (but docs can update independently)
+
+### Step 3: Define the Patterns
+
+Help the user define glob patterns for files.
+
+**Common patterns:**
+- `src/**/*.py` - All Python files in src directory (recursive)
+- `app/config/**/*` - All files in app/config directory
+- `*.md` - All markdown files in root
+- `src/api/**/*` - All files in the API directory
+- `migrations/**/*.sql` - All SQL migrations
+
+**Variable patterns (for set/pair modes):**
+- `src/{path}.py` - Captures path variable (e.g., `foo/bar` from `src/foo/bar.py`)
+- `tests/{path}_test.py` - Uses same path variable in corresponding file
+- `{name}` matches single segment, `{path}` matches multiple segments
+
+**Pattern syntax:**
+- `*` - Matches any characters within a single path segment
+- `**` - Matches any characters across multiple path segments (recursive)
+- `?` - Matches a single character
+
+### Step 4: Choose the Comparison Mode (Optional)
+
+The `compare_to` field controls what baseline is used when detecting "changed files":
+
+**Options:**
+- `base` (default) - Compares to the base of the current branch (merge-base with main/master). Best for feature branches.
+- `default_tip` - Compares to the current tip of the default branch. Useful for seeing difference from production.
+- `prompt` - Compares to the state at the start of each prompt. For rules about very recent changes.
+
+Most rules should use the default (`base`) and don't need to specify `compare_to`.
+
+### Step 5: Write the Instructions
+
+Create clear, actionable instructions for what the agent should do when the rule fires.
+
+**Good instructions include:**
+- What to check or review
+- What files might need updating
+- Specific actions to take
+- Quality criteria for completion
+
+**Template variables available in instructions:**
+- `{trigger_files}` - Files that triggered the rule
+- `{expected_files}` - Expected corresponding files (for set/pair modes)
+
+### Step 6: Create the Rule File
+
+Create a new file in `.deepwork/rules/` with a kebab-case filename:
+
+**File Location**: `.deepwork/rules/{rule-name}.md`
+
+**Format for Trigger/Safety Mode:**
+```markdown
+---
+name: Friendly Name for the Rule
+trigger: "glob/pattern/**/*"  # or array: ["pattern1", "pattern2"]
+safety: "optional/pattern"    # optional, or array
+compare_to: base              # optional: "base" (default), "default_tip", or "prompt"
+---
+Instructions for the agent when this rule fires.
+
+Multi-line markdown content is supported.
+```
+
+**Format for Set Mode (bidirectional):**
+```markdown
+---
+name: Source/Test Pairing
+set:
+  - src/{path}.py
+  - tests/{path}_test.py
+---
+Source and test files should change together.
+
+Modified: {trigger_files}
+Expected: {expected_files}
+```
+
+**Format for Pair Mode (directional):**
+```markdown
+---
+name: API Documentation
+pair:
+  trigger: api/{path}.py
+  expects: docs/api/{path}.md
+---
+API code requires documentation updates.
+
+Changed API: {trigger_files}
+Update docs: {expected_files}
+```
+
+### Step 7: Verify the Rule
+
+After creating the rule:
+
+1. **Check the YAML frontmatter** - Ensure valid YAML formatting
+2. **Test trigger patterns** - Verify patterns match intended files
+3. **Review instructions** - Ensure they're clear and actionable
+4. **Check for conflicts** - Ensure the rule doesn't conflict with existing ones
+
+## Example Rules
+
+### Update Documentation on Config Changes
+`.deepwork/rules/config-docs.md`:
+```markdown
+---
+name: Update Install Guide on Config Changes
+trigger: app/config/**/*
+safety: docs/install_guide.md
+---
+Configuration files have been modified. Please review docs/install_guide.md
+and update it if any installation instructions need to change based on the
+new configuration.
+```
+
+### Security Review for Auth Code
+`.deepwork/rules/security-review.md`:
+```markdown
+---
+name: Security Review for Authentication Changes
+trigger:
+  - src/auth/**/*
+  - src/security/**/*
+safety:
+  - SECURITY.md
+  - docs/security_audit.md
+---
+Authentication or security code has been changed. Please:
+
+1. Review for hardcoded credentials or secrets
+2. Check input validation on user inputs
+3. Verify access control logic is correct
+4. Update security documentation if needed
+```
+
+### Source/Test Pairing
+`.deepwork/rules/source-test-pairing.md`:
+```markdown
+---
+name: Source/Test Pairing
+set:
+  - src/{path}.py
+  - tests/{path}_test.py
+---
+Source and test files should change together.
+
+When modifying source code, ensure corresponding tests are updated.
+When adding tests, ensure they test actual source code.
+
+Modified: {trigger_files}
+Expected: {expected_files}
+```
+
+### API Documentation Sync
+`.deepwork/rules/api-docs.md`:
+```markdown
+---
+name: API Documentation Update
+pair:
+  trigger: src/api/{path}.py
+  expects: docs/api/{path}.md
+---
+API code has changed. Please verify that API documentation in docs/api/
+is up to date with the code changes. Pay special attention to:
+
+- New or changed endpoints
+- Modified request/response schemas
+- Updated authentication requirements
+
+Changed API: {trigger_files}
+Update: {expected_files}
+```
+
+## Output Format
+
+### .deepwork/rules/{rule-name}.md
+Create a new file with the rule definition using YAML frontmatter and markdown body.
+
+## Quality Criteria
+
+- Asked structured questions to understand user requirements
+- Rule name is clear and descriptive (used in promise tags)
+- Correct detection mode selected for the use case
+- Patterns accurately match the intended files
+- Safety patterns prevent unnecessary triggering (if applicable)
+- Instructions are actionable and specific
+- YAML frontmatter is valid
+
+## Context
+
+Rules are evaluated automatically when the agent finishes a task. The system:
+1. Determines which files have changed based on each rule's `compare_to` setting
+2. Evaluates rules based on their detection mode (trigger/safety, set, or pair)
+3. Skips rules where the correspondence is satisfied (for set/pair) or safety matched
+4. Prompts you with instructions for any triggered rules
+
+You can mark a rule as addressed by including `<promise>Rule Name</promise>` in your response (replace Rule Name with the actual rule name from the `name` field). This tells the system you've already handled that rule's requirements.