|
| 1 | +--- |
| 2 | +name: deepwork-jobs |
| 3 | +description: "DeepWork Jobs system - defining, implementing, and syncing multi-step AI workflows. Covers job.yml schema, step instructions, skill generation, hooks, and CLI commands." |
| 4 | +--- |
| 5 | + |
| 6 | +# DeepWork Jobs System |
| 7 | + |
| 8 | +You are an expert on the DeepWork Jobs system - the framework for building |
| 9 | +reusable, multi-step AI workflows that integrate with AI coding assistants. |
| 10 | + |
| 11 | +## Core Concepts |
| 12 | + |
| 13 | +**Jobs** are complex, multi-step tasks defined once and executed many times. |
| 14 | +Each job consists of: |
| 15 | + |
| 16 | +- **job.yml**: The specification file defining the job's structure |
| 17 | +- **steps/**: Markdown files with detailed instructions for each step |
| 18 | +- **hooks/**: Optional validation scripts or prompts |
| 19 | +- **templates/**: Example file formats for outputs |
| 20 | + |
| 21 | +**Skills** are generated from jobs and loaded by AI platforms (Claude Code, |
| 22 | +Gemini CLI). Each step becomes a slash command the user can invoke. |
| 23 | + |
| 24 | +## Job Definition Structure |
| 25 | + |
| 26 | +Jobs live in `.deepwork/jobs/[job_name]/`: |
| 27 | + |
| 28 | +``` |
| 29 | +.deepwork/jobs/ |
| 30 | +└── competitive_research/ |
| 31 | + ├── job.yml |
| 32 | + ├── steps/ |
| 33 | + │ ├── identify_competitors.md |
| 34 | + │ └── research_competitors.md |
| 35 | + ├── hooks/ |
| 36 | + │ └── validate_research.sh |
| 37 | + └── templates/ |
| 38 | + └── competitor_profile.md |
| 39 | +``` |
| 40 | + |
| 41 | +## The job.yml Schema |
| 42 | + |
| 43 | +Required fields: |
| 44 | +- `name`: lowercase with underscores, must start with letter (e.g., `competitive_research`) |
| 45 | +- `version`: semantic versioning X.Y.Z (e.g., `1.0.0`) |
| 46 | +- `summary`: concise description under 200 characters |
| 47 | +- `steps`: array of step definitions |
| 48 | + |
| 49 | +Optional fields: |
| 50 | +- `description`: detailed multi-line explanation of the job |
| 51 | +- `workflows`: named sequences that group steps |
| 52 | +- `changelog`: version history with changes |
| 53 | + |
| 54 | +## Step Definition Fields |
| 55 | + |
| 56 | +Each step in the `steps` array requires: |
| 57 | +- `id`: unique identifier, lowercase with underscores |
| 58 | +- `name`: human-readable name |
| 59 | +- `description`: what this step accomplishes |
| 60 | +- `instructions_file`: path to step markdown (e.g., `steps/identify.md`) |
| 61 | +- `outputs`: array of output files (string or object with `file` and optional `doc_spec`) |
| 62 | + |
| 63 | +Optional step fields: |
| 64 | +- `inputs`: user parameters or file inputs from previous steps |
| 65 | +- `dependencies`: array of step IDs this step requires |
| 66 | +- `exposed`: boolean, if true skill appears in user menus (default: false) |
| 67 | +- `quality_criteria`: array of criteria strings for validation |
| 68 | +- `agent`: agent type for delegation (e.g., `general-purpose`), adds `context: fork` |
| 69 | +- `hooks`: lifecycle hooks for validation (see Hooks section) |
| 70 | +- `stop_hooks`: deprecated, use `hooks.after_agent` instead |
| 71 | + |
| 72 | +## Input Types |
| 73 | + |
| 74 | +**User inputs** - parameters gathered from the user: |
| 75 | +```yaml |
| 76 | +inputs: |
| 77 | + - name: market_segment |
| 78 | + description: "Target market segment for research" |
| 79 | +``` |
| 80 | +
|
| 81 | +**File inputs** - outputs from previous steps: |
| 82 | +```yaml |
| 83 | +inputs: |
| 84 | + - file: competitors_list.md |
| 85 | + from_step: identify_competitors |
| 86 | +``` |
| 87 | +
|
| 88 | +Note: `from_step` must be listed in the step's `dependencies` array. |
| 89 | + |
| 90 | +## Output Types |
| 91 | + |
| 92 | +**Simple output** (string): |
| 93 | +```yaml |
| 94 | +outputs: |
| 95 | + - competitors_list.md |
| 96 | + - research/ |
| 97 | +``` |
| 98 | + |
| 99 | +**Output with doc spec** (object): |
| 100 | +```yaml |
| 101 | +outputs: |
| 102 | + - file: reports/analysis.md |
| 103 | + doc_spec: .deepwork/doc_specs/analysis_report.md |
| 104 | +``` |
| 105 | + |
| 106 | +Doc specs define quality criteria for document outputs and are embedded in |
| 107 | +generated skills for validation. |
| 108 | + |
| 109 | +## Workflows |
| 110 | + |
| 111 | +Workflows group steps into named sequences. Steps not in any workflow are |
| 112 | +"standalone" and can be run independently. |
| 113 | + |
| 114 | +```yaml |
| 115 | +workflows: |
| 116 | + - name: new_job |
| 117 | + summary: "Create a new DeepWork job from scratch" |
| 118 | + steps: |
| 119 | + - define |
| 120 | + - review_job_spec |
| 121 | + - implement |
| 122 | +``` |
| 123 | + |
| 124 | +**Concurrent steps** can run in parallel: |
| 125 | +```yaml |
| 126 | +steps: |
| 127 | + - define |
| 128 | + - [research_competitor_a, research_competitor_b] # run in parallel |
| 129 | + - synthesize |
| 130 | +``` |
| 131 | + |
| 132 | +## Lifecycle Hooks |
| 133 | + |
| 134 | +Hooks trigger at specific points during skill execution. |
| 135 | + |
| 136 | +**Supported events**: |
| 137 | +- `after_agent`: runs after agent finishes (quality validation) |
| 138 | +- `before_tool`: runs before tool use |
| 139 | +- `before_prompt`: runs when user submits prompt |
| 140 | + |
| 141 | +**Hook action types**: |
| 142 | +```yaml |
| 143 | +hooks: |
| 144 | + after_agent: |
| 145 | + - prompt: "Verify all criteria are met" # inline prompt |
| 146 | + - prompt_file: hooks/quality_check.md # prompt from file |
| 147 | + - script: hooks/run_tests.sh # shell script |
| 148 | +``` |
| 149 | + |
| 150 | +Note: Claude Code currently only supports script hooks. Prompt hooks are |
| 151 | +parsed but not executed (documented limitation). |
| 152 | + |
| 153 | +## Skill Generation |
| 154 | + |
| 155 | +Running `deepwork sync` generates skills from job definitions: |
| 156 | + |
| 157 | +1. Parses all `job.yml` files in `.deepwork/jobs/` |
| 158 | +2. For each job, generates a **meta-skill** (entry point) and **step skills** |
| 159 | +3. Writes to platform-specific directories (e.g., `.claude/skills/`) |
| 160 | + |
| 161 | +**Claude Code skill structure**: |
| 162 | +- Meta-skill: `.claude/skills/[job_name]/SKILL.md` |
| 163 | +- Step skill: `.claude/skills/[job_name].[step_id]/SKILL.md` |
| 164 | + |
| 165 | +**Gemini CLI skill structure**: |
| 166 | +- Meta-skill: `.gemini/skills/[job_name]/index.toml` |
| 167 | +- Step skill: `.gemini/skills/[job_name]/[step_id].toml` |
| 168 | + |
| 169 | +## CLI Commands |
| 170 | + |
| 171 | +**Install DeepWork**: |
| 172 | +```bash |
| 173 | +deepwork install --platform claude |
| 174 | +``` |
| 175 | +Creates `.deepwork/` structure, copies standard jobs, runs sync. |
| 176 | + |
| 177 | +**Sync skills**: |
| 178 | +```bash |
| 179 | +deepwork sync |
| 180 | +``` |
| 181 | +Regenerates all skills from job definitions. |
| 182 | + |
| 183 | +**Hook execution** (internal): |
| 184 | +```bash |
| 185 | +deepwork hook check # check for pending rules |
| 186 | +deepwork hook run # execute pending rule actions |
| 187 | +``` |
| 188 | + |
| 189 | +## Standard Jobs |
| 190 | + |
| 191 | +DeepWork ships with standard jobs that are auto-installed: |
| 192 | + |
| 193 | +- `deepwork_jobs`: Create and manage multi-step workflows |
| 194 | + - `define`: Interactive job specification creation |
| 195 | + - `review_job_spec`: Sub-agent validation against doc spec |
| 196 | + - `implement`: Generate step files and sync |
| 197 | + - `learn`: Improve instructions from execution learnings |
| 198 | + |
| 199 | +- `deepwork_rules`: Create file-change trigger rules |
| 200 | + - `define`: Interactive rule creation |
| 201 | + |
| 202 | +Standard jobs live in `src/deepwork/standard_jobs/` and are copied to |
| 203 | +`.deepwork/jobs/` during installation. |
| 204 | + |
| 205 | +## Writing Step Instructions |
| 206 | + |
| 207 | +Step instruction files should include: |
| 208 | + |
| 209 | +1. **Objective**: Clear statement of what this step accomplishes |
| 210 | +2. **Task**: Detailed process with numbered steps |
| 211 | +3. **Inputs section**: What to gather/read before starting |
| 212 | +4. **Output format**: Examples of expected outputs |
| 213 | +5. **Quality criteria**: How to verify the step is complete |
| 214 | + |
| 215 | +Use the phrase "ask structured questions" when gathering user input - |
| 216 | +this triggers proper tooling for interactive prompts. |
| 217 | + |
| 218 | +## Template System |
| 219 | + |
| 220 | +Skills are generated using Jinja2 templates in `src/deepwork/templates/`: |
| 221 | + |
| 222 | +- `claude/skill-job-meta.md.jinja`: Meta-skill template |
| 223 | +- `claude/skill-job-step.md.jinja`: Step skill template |
| 224 | +- `gemini/skill-job-meta.toml.jinja`: Gemini meta-skill |
| 225 | +- `gemini/skill-job-step.toml.jinja`: Gemini step skill |
| 226 | + |
| 227 | +Template variables include job context, step metadata, inputs, outputs, |
| 228 | +hooks, quality criteria, and workflow position. |
| 229 | + |
| 230 | +## Platform Adapters |
| 231 | + |
| 232 | +The `AgentAdapter` class abstracts platform differences: |
| 233 | + |
| 234 | +- `ClaudeAdapter`: Claude Code with markdown skills in `.claude/skills/` |
| 235 | +- `GeminiAdapter`: Gemini CLI with TOML skills in `.gemini/skills/` |
| 236 | + |
| 237 | +Adapters handle: |
| 238 | +- Skill filename patterns |
| 239 | +- Hook event name mapping (e.g., `after_agent` -> `Stop` for Claude) |
| 240 | +- Settings file management |
| 241 | +- Permission syncing |
| 242 | + |
| 243 | +## Parser Dataclasses |
| 244 | + |
| 245 | +The `parser.py` module defines the job structure: |
| 246 | + |
| 247 | +- `JobDefinition`: Top-level job with name, version, steps, workflows |
| 248 | +- `Step`: Individual step with inputs, outputs, hooks, dependencies |
| 249 | +- `StepInput`: User parameter or file input |
| 250 | +- `OutputSpec`: Output file optionally with doc_spec reference |
| 251 | +- `HookAction`: Hook configuration (prompt, prompt_file, or script) |
| 252 | +- `Workflow`: Named step sequence |
| 253 | +- `WorkflowStepEntry`: Sequential or concurrent step group |
| 254 | + |
| 255 | +## Validation Rules |
| 256 | + |
| 257 | +The parser validates: |
| 258 | +- Dependencies reference existing steps |
| 259 | +- No circular dependencies |
| 260 | +- File inputs reference steps in dependencies |
| 261 | +- Workflow steps exist |
| 262 | +- No duplicate workflow names |
| 263 | +- Doc spec files exist (when referenced) |
| 264 | + |
| 265 | +## Common Patterns |
| 266 | + |
| 267 | +**Creating a new job**: |
| 268 | +1. Run `/deepwork_jobs` (or `/deepwork_jobs.define`) |
| 269 | +2. Answer structured questions about your workflow |
| 270 | +3. Review generated job.yml |
| 271 | +4. Run `/deepwork_jobs.implement` to generate step files |
| 272 | +5. Run `deepwork sync` to create skills |
| 273 | + |
| 274 | +**Adding a step to existing job**: |
| 275 | +1. Edit `.deepwork/jobs/[job_name]/job.yml` |
| 276 | +2. Add step definition with required fields |
| 277 | +3. Create instructions file in `steps/` |
| 278 | +4. Update workflow if applicable |
| 279 | +5. Run `deepwork sync` |
| 280 | + |
| 281 | +**Debugging sync issues**: |
| 282 | +- Check job.yml syntax with a YAML validator |
| 283 | +- Verify step IDs match filenames |
| 284 | +- Ensure dependencies form valid DAG |
| 285 | +- Check instructions files exist |
| 286 | + |
| 287 | +--- |
| 288 | + |
| 289 | +## Topics |
| 290 | + |
| 291 | +Detailed documentation on specific subjects within this domain. |
| 292 | + |
| 293 | +$(deepwork topics --expert "deepwork-jobs") |
| 294 | + |
| 295 | +--- |
| 296 | + |
| 297 | +## Learnings |
| 298 | + |
| 299 | +Hard-fought insights from real experiences. |
| 300 | + |
| 301 | +$(deepwork learnings --expert "deepwork-jobs") |
0 commit comments