Cleanup (#6)

* Looks great

* fix gitignore

Author: nhorton

.claude/commands/deepwork_jobs.implement.md

@@ -16,10 +16,12 @@ hooks:
             3. **Specific & Actionable**: Are instructions tailored to each step's purpose, not generic?
             4. **Output Examples**: Does each instruction file show what good output looks like?
             5. **Quality Criteria**: Does each instruction file define quality criteria for its outputs?
-            6. **Registry Updated**: Is `.deepwork/registry.yml` updated with the new job?
-            7. **Sync Complete**: Has `deepwork sync` been run successfully?
-            8. **Commands Available**: Are the slash-commands generated in `.claude/commands/`?
-            9. **Summary Created**: Has `implementation_summary.md` been created?
+            6. **Sync Complete**: Has `deepwork sync` been run successfully?
+            7. **Commands Available**: Are the slash-commands generated in `.claude/commands/`?
+            8. **Summary Created**: Has `implementation_summary.md` been created?
+            9. **Policies Considered**: Have you thought about whether policies would benefit this job?
+               - If relevant policies were identified, did you explain them and offer to run `/deepwork_policy.define`?
+               - Not every job needs policies - only suggest when genuinely helpful.
 
             If ANY criterion is not met, continue working to address it.
             If ALL criteria are satisfied, include `<promise>QUALITY_COMPLETE</promise>` in your response.
@@ -238,6 +240,66 @@ Instruct the user to reload commands in their current session:
 - Run `/reload` command (if available)
 - Or restart the Claude session
 
+### Step 7: Consider Policies 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.
+
+**What are policies?**
+
+Policies are automated guardrails defined in `.deepwork.policy.yml` 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:**
+
+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:**
+
+| Job Type | Potential Policy |
+|----------|------------------|
+| 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:**
+
+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
+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."
+
+If the user agrees, invoke the `/deepwork_policy.define` command to guide them through creating the policy.
+
+**Example dialogue:**
+
+```
+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:
+- **Name**: "Update strategy when competitor analysis changes"
+- **Trigger**: `deepwork/competitive_research-*/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.
+```
+
+**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.
+
 ## Example Implementation
 
 **Given this job.yml:**
@@ -431,6 +493,8 @@ Before marking this step complete, ensure:
 - [ ] Commands generated in platform directory
 - [ ] User informed of next steps (reload commands)
 - [ ] implementation_summary.md created
+- [ ] Considered whether policies would benefit this job (Step 7)
+- [ ] If policies suggested, offered to run `/deepwork_policy.define`
 
 ## Quality Criteria
 
@@ -441,6 +505,7 @@ Before marking this step complete, ensure:
 - Quality criteria defined for each step
 - Sync completed successfully
 - Commands available for use
+- Thoughtfully considered relevant policies for the job domain
 
 
 ## Inputs
@@ -493,10 +558,12 @@ Verify the implementation meets ALL quality criteria before completing:
 3. **Specific & Actionable**: Are instructions tailored to each step's purpose, not generic?
 4. **Output Examples**: Does each instruction file show what good output looks like?
 5. **Quality Criteria**: Does each instruction file define quality criteria for its outputs?
-6. **Registry Updated**: Is `.deepwork/registry.yml` updated with the new job?
-7. **Sync Complete**: Has `deepwork sync` been run successfully?
-8. **Commands Available**: Are the slash-commands generated in `.claude/commands/`?
-9. **Summary Created**: Has `implementation_summary.md` been created?
+6. **Sync Complete**: Has `deepwork sync` been run successfully?
+7. **Commands Available**: Are the slash-commands generated in `.claude/commands/`?
+8. **Summary Created**: Has `implementation_summary.md` been created?
+9. **Policies Considered**: Have you thought about whether policies would benefit this job?
+   - If relevant policies were identified, did you explain them and offer to run `/deepwork_policy.define`?
+   - Not every job needs policies - only suggest when genuinely helpful.
 
 If ANY criterion is not met, continue working to address it.
 If ALL criteria are satisfied, include `<promise>QUALITY_COMPLETE</promise>` in your response.

.deepwork/.gitignore

@@ -0,0 +1,3 @@
+# DeepWork temporary files
+# These files are used for policy evaluation during sessions
+.last_work_tree

.deepwork/config.yml

@@ -0,0 +1,3 @@
+version: 1.0.0
+platforms:
+- claude

.deepwork/jobs/deepwork_jobs/job.yml

@@ -0,0 +1,105 @@
+name: deepwork_jobs
+version: "1.3.0"
+summary: "DeepWork job management commands"
+description: |
+  Core commands for managing DeepWork jobs. These commands help you define new multi-step
+  workflows and refine existing ones.
+
+  The `define` command guides you through an interactive process to create a new job by
+  asking detailed questions about your workflow, understanding each step's inputs and outputs,
+  and generating all necessary files.
+
+  The `refine` command helps you modify existing jobs safely by understanding what you want
+  to change, validating the impact, and ensuring consistency across your workflow.
+
+changelog:
+  - version: "1.0.0"
+    changes: "Initial job creation"
+  - version: "1.1.0"
+    changes: "Added stop hooks for quality validation loops on all steps"
+  - version: "1.2.0"
+    changes: "Updated to support array of stop hooks"
+  - version: "1.3.0"
+    changes: "Added policy awareness to implement step - suggests relevant policies after job implementation"
+
+steps:
+  - id: define
+    name: "Define Job Specification"
+    description: "Create the job.yml specification file by understanding workflow requirements"
+    instructions_file: steps/define.md
+    inputs:
+      - name: job_purpose
+        description: "What complex task or workflow are you trying to accomplish?"
+    outputs:
+      - job.yml
+    dependencies: []
+    stop_hooks:
+      - prompt: |
+          Verify the job.yml output meets ALL quality criteria before completing:
+
+          1. **User Understanding**: Did you fully understand the user's workflow through interactive Q&A?
+          2. **Clear Inputs/Outputs**: Does every step have clearly defined inputs and outputs?
+          3. **Logical Dependencies**: Do step dependencies make sense and avoid circular references?
+          4. **Concise Summary**: Is the summary under 200 characters and descriptive?
+          5. **Rich Description**: Does the description provide enough context for future refinement?
+          6. **Valid Schema**: Does the job.yml follow the required schema (name, version, summary, steps)?
+          7. **File Created**: Has the job.yml file been created in `deepwork/[job_name]/job.yml`?
+
+          If ANY criterion is not met, continue working to address it.
+          If ALL criteria are satisfied, include `<promise>QUALITY_COMPLETE</promise>` in your response.
+
+  - id: implement
+    name: "Implement Job Steps"
+    description: "Generate instruction files for each step based on the job.yml specification"
+    instructions_file: steps/implement.md
+    inputs:
+      - file: job.yml
+        from_step: define
+    outputs:
+      - implementation_summary.md
+    dependencies:
+      - define
+    stop_hooks:
+      - prompt: |
+          Verify the implementation meets ALL quality criteria before completing:
+
+          1. **Directory Structure**: Is `.deepwork/jobs/[job_name]/` created correctly?
+          2. **Complete Instructions**: Are ALL step instruction files complete (not stubs or placeholders)?
+          3. **Specific & Actionable**: Are instructions tailored to each step's purpose, not generic?
+          4. **Output Examples**: Does each instruction file show what good output looks like?
+          5. **Quality Criteria**: Does each instruction file define quality criteria for its outputs?
+          6. **Sync Complete**: Has `deepwork sync` been run successfully?
+          7. **Commands Available**: Are the slash-commands generated in `.claude/commands/`?
+          8. **Summary Created**: Has `implementation_summary.md` been created?
+          9. **Policies Considered**: Have you thought about whether policies would benefit this job?
+             - If relevant policies were identified, did you explain them and offer to run `/deepwork_policy.define`?
+             - Not every job needs policies - only suggest when genuinely helpful.
+
+          If ANY criterion is not met, continue working to address it.
+          If ALL criteria are satisfied, include `<promise>QUALITY_COMPLETE</promise>` in your response.
+
+  - id: refine
+    name: "Refine Existing Job"
+    description: "Modify an existing job definition"
+    instructions_file: steps/refine.md
+    inputs:
+      - name: job_name
+        description: "Name of the job to refine"
+    outputs:
+      - job.yml
+    dependencies: []
+    stop_hooks:
+      - prompt: |
+          Verify the refinement meets ALL quality criteria before completing:
+
+          1. **Job Consistency**: Do the changes maintain overall job consistency?
+          2. **Valid Dependencies**: Are all step dependencies logically valid (no circular refs)?
+          3. **Semantic Versioning**: Was the version bumped appropriately (major/minor/patch)?
+          4. **Changelog Updated**: Is the changelog updated with a description of changes?
+          5. **User Understanding**: Does the user understand the impact of the changes?
+          6. **Breaking Changes**: Were any breaking changes clearly communicated?
+          7. **Files Updated**: Are all affected files (job.yml, step files) updated?
+          8. **Sync Complete**: Has `deepwork sync` been run to regenerate commands?
+
+          If ANY criterion is not met, continue working to address it.
+          If ALL criteria are satisfied, include `<promise>QUALITY_COMPLETE</promise>` in your response.