Add update_job_schema bespoke job

.claude/settings.json

@@ -99,7 +99,6 @@
       "Edit(./.deepwork/**)",
       "Write(./.deepwork/**)",
       "Bash(deepwork:*)",
-      "Bash(./.deepwork/jobs/deepwork_jobs/make_new_job.sh:*)",
       "WebSearch",
       "Skill(deepwork)",
       "mcp__deepwork__get_workflows",

.deepwork/config.yml

@@ -1,4 +1,4 @@
-version: 0.1.0
+version: '1.0'
 platforms:
 - claude
 - gemini

.deepwork/doc_specs/job_spec.md

@@ -12,10 +12,8 @@ quality_criteria:
     description: "Version must follow semantic versioning format X.Y.Z (e.g., `1.0.0`, `2.1.3`)"
   - name: Concise Summary
     description: "Summary must be under 200 characters and clearly describe what the job accomplishes"
-  - name: Rich Description
-    description: "Description must be multi-line and explain: the problem solved, the process, expected outcomes, and target users"
-  - name: Changelog Present
-    description: "Must include a changelog array with at least the initial version entry. Changelog should only include one entry per branch at most"
+  - name: Common Job Info
+    description: "common_job_info_provided_to_all_steps_at_runtime must be present and provide shared context for all steps"
   - name: Complete Steps
     description: "Each step must have: id (lowercase_underscores), name, description, instructions_file, outputs (at least one), and dependencies array"
   - name: Valid Dependencies
@@ -40,19 +38,9 @@ A `job.yml` file defines a complete multi-step workflow that AI agents can execu
 name: job_name                    # lowercase, underscores only
 version: "1.0.0"                  # semantic versioning
 summary: "Brief description"      # max 200 characters
-description: |                    # detailed multi-line explanation
-  [Explain what this workflow does, why it exists,
-  what outputs it produces, and who should use it]
-```
-
-### Changelog
-
-```yaml
-changelog:
-  - version: "1.0.0"
-    changes: "Initial job creation"
-  - version: "1.1.0"
-    changes: "Added quality validation hooks"
+common_job_info_provided_to_all_steps_at_runtime: |
+  [Common context shared across all steps at runtime.
+  Include key terminology, constraints, and shared knowledge.]
 ```
 
 ### Steps Array
@@ -128,21 +116,11 @@ steps:
 name: competitive_research
 version: "1.0.0"
 summary: "Systematic competitive analysis workflow"
-description: |
+common_job_info_provided_to_all_steps_at_runtime: |
   A comprehensive workflow for analyzing competitors in your market segment.
   Helps product teams understand the competitive landscape through systematic
   identification, research, comparison, and positioning recommendations.
 
-  Produces:
-  - Vetted competitor list
-  - Research notes per competitor
-  - Comparison matrix
-  - Strategic positioning report
-
-changelog:
-  - version: "1.0.0"
-    changes: "Initial job creation"
-
 steps:
   - id: identify_competitors
     name: "Identify Competitors"

.deepwork/jobs/test_job_flow/job.yml

@@ -1,7 +1,7 @@
 name: test_job_flow
-version: "1.0.1"
+version: "1.0.2"
 summary: "End-to-end test of the DeepWork job creation workflow with friction analysis"
-description: |
+common_job_info_provided_to_all_steps_at_runtime: |
   A meta-workflow that tests the DeepWork job creation process itself. This job:
 
   1. Creates a new job ("detailed_test_review") via a nested sub-agent workflow,
@@ -14,16 +14,6 @@ description: |
   This is a diagnostic/improvement workflow for the DeepWork framework. The final
   output is a set of actionable recommendations for reducing job creation friction.
 
-  The "detailed_test_review" job created in step 1 has two steps:
-  - Run all tests with coverage reporting, with per-file and per-step quality reviews
-  - Update the README with coverage numbers and an as-of date
-
-changelog:
-  - version: "1.0.1"
-    changes: "Updated create_test_review_job instructions: added explicit `required` field to all output examples to prevent schema validation failures. Added description fields to YAML example outputs."
-  - version: "1.0.0"
-    changes: "Initial job creation"
-
 workflows:
   - name: run
     summary: "Create a test job via sub-agent, review the process, and identify improvements"

.deepwork/jobs/test_job_flow/steps/create_test_review_job.md

@@ -107,17 +107,6 @@ steps:
           "Date Included": "..."
 ```
 
-## Quality Criteria
-
-- The nested workflow ran to completion (all steps finished)
-- The `detailed_test_review` job.yml exists and is valid YAML
-- It defines exactly two steps: `run_tests` and `update_readme`
-- `run_tests` has both `test_files` (files) and `coverage_report` (file) outputs
-- `run_tests` has a for_each file review on `test_files` and a for_each step review for coverage
-- `update_readme` takes `coverage_report` as input from `run_tests`
-- `update_readme` produces a `readme` output
-- When all criteria are met, include `<promise>Quality Criteria Met</promise>` in your response
-
 ## Context
 
 This step is the core exercise of the test_job_flow. By running the full job creation workflow as a nested sub-agent, we can observe the entire process end-to-end and identify any friction points. The transcript from this step will be reviewed in the next step.

.deepwork/jobs/test_job_flow/steps/identify_improvements.md

@@ -76,15 +76,6 @@ A markdown file at `.deepwork/tmp/improvement_recommendations.md`.
 [Suggested sequence for implementing the recommendations, noting dependencies]
 ```
 
-## Quality Criteria
-
-- Every recommendation maps to a specific friction point from the friction report
-- Recommendations point to specific files and code paths (not vague suggestions)
-- Each recommendation includes effort and risk assessment
-- Recommendations are technically feasible given the DeepWork architecture
-- Prioritization is logical (quick wins first, high-impact items ranked higher)
-- When all criteria are met, include `<promise>Quality Criteria Met</promise>` in your response
-
 ## Context
 
 This is the final step of the test_job_flow. Its output is a decision document for the user — they will review these recommendations and decide which ones to implement. The quality of this output determines whether the entire test_job_flow exercise produces actionable value. Be thorough but practical; the user wants recommendations they can act on, not a theoretical analysis.

.deepwork/jobs/test_job_flow/steps/review_creation_process.md

@@ -77,15 +77,6 @@ A markdown file at `.deepwork/tmp/job_creation_friction.md`.
 [Was the process smooth enough for production use? What's the biggest single improvement that could be made?]
 ```
 
-## Quality Criteria
-
-- The friction report references specific events from the sub-agent's transcript (not vague generalities)
-- Each friction point is described concretely enough that a developer could reproduce and fix it
-- The completion status section accurately reflects what happened
-- Both problems AND successes are documented (balanced view)
-- The overall assessment provides a clear priority for improvement
-- When all criteria are met, include `<promise>Quality Criteria Met</promise>` in your response
-
 ## Context
 
 This step bridges observation and action. The friction points documented here will be the input to step 3, where we investigate the actual code to find improvements. The more specific and concrete the friction descriptions, the more targeted the improvements can be.

.deepwork/jobs/update_job_schema/AGENTS.md

@@ -0,0 +1,32 @@
+# Job Management
+
+This folder and its subfolders are managed using `deepwork_jobs` workflows.
+
+## Recommended Workflows
+
+- `deepwork_jobs/new_job` - Full lifecycle: define → implement → test → iterate
+- `deepwork_jobs/learn` - Improve instructions based on execution learnings
+- `deepwork_jobs/repair` - Clean up and migrate from prior DeepWork versions
+
+## Directory Structure
+
+```
+.
+├── AGENTS.md          # This file - project context and guidance
+├── job.yml            # Job specification (created by define step)
+├── steps/             # Step instruction files (created by implement step)
+│   └── *.md           # One file per step
+├── hooks/             # Custom validation scripts and prompts
+│   └── *.md|*.sh      # Hook files referenced in job.yml
+├── scripts/           # Reusable scripts and utilities created during job execution
+│   └── *.sh|*.py      # Helper scripts referenced in step instructions
+└── templates/         # Example file formats and templates
+    └── *.md|*.yml     # Templates referenced in step instructions
+```
+
+## Editing Guidelines
+
+1. **Use workflows** for structural changes (adding steps, modifying job.yml)
+2. **Direct edits** are fine for minor instruction tweaks
+3. **Run `deepwork_jobs/learn`** after executing job steps to capture improvements
+4. **Run `deepwork install`** after any changes to regenerate commands