From 7368f0890686aabce8c07f4697cccaf8d0038217 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 30 Jan 2026 19:20:27 +0000 Subject: [PATCH 1/5] feat: Add multiple workflow support to deepwork_jobs Update the define step and templates to support jobs with multiple workflows. This allows a single job to define different execution paths through the same set of steps (e.g., full_analysis vs. quick_summary). Changes: - Add Step 2.5 in define.md to ask about workflow organization - Update job.yml.template with workflows section - Add multi-workflow example to job.yml.example - Add Valid Workflows quality criterion to job_spec.md - Update example dialog to show workflow discovery https://claude.ai/code/session_01Mr1h2fVSKeVP84FDWXx4UM --- .../deepwork_jobs/doc_specs/job_spec.md | 48 +++++++++ .../deepwork_jobs/steps/define.md | 99 ++++++++++++++++++- .../deepwork_jobs/templates/job.yml.example | 29 ++++++ .../deepwork_jobs/templates/job.yml.template | 17 ++++ 4 files changed, 188 insertions(+), 5 deletions(-) diff --git a/src/deepwork/standard_jobs/deepwork_jobs/doc_specs/job_spec.md b/src/deepwork/standard_jobs/deepwork_jobs/doc_specs/job_spec.md index 50ce2edd..0e3d55b7 100644 --- a/src/deepwork/standard_jobs/deepwork_jobs/doc_specs/job_spec.md +++ b/src/deepwork/standard_jobs/deepwork_jobs/doc_specs/job_spec.md @@ -24,6 +24,8 @@ quality_criteria: description: "File inputs with `from_step` must reference a step that is in the dependencies array" - name: Output Paths description: "Outputs must be valid filenames or paths within the main repo directory structure, never in dot-directories like `.deepwork/`. Use specific, descriptive paths that lend themselves to glob patterns (e.g., `competitive_research/acme_corp/swot.md` or `operations/reports/2026-01/spending_analysis.md`). Parameterized paths like `[competitor_name]/` are encouraged for per-entity outputs. Avoid generic names (`output.md`, `analysis.md`) and transient-sounding paths (`temp/`, `draft.md`). Supporting materials for a final output should go in a peer `_dataroom` folder (e.g., `spending_analysis_dataroom/`)." + - name: Valid Workflows + description: "If a `workflows` section is present, each workflow must have a unique name (lowercase_underscores), a summary, and a steps array. All step IDs referenced in workflows must exist in the steps section. Multiple workflows can share steps and define different execution paths through the same step set." - name: Concise Instructions description: "The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI." --- @@ -55,6 +57,36 @@ changelog: changes: "Added quality validation hooks" ``` +### Workflows (Optional) + +Jobs can define multiple workflows that use different combinations of the same steps: + +```yaml +workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - report + + - name: refresh + summary: "Update existing research" + steps: + - research + - analyze + - report +``` + +If the `workflows` section is omitted, all steps form a single implicit workflow. + ### Steps Array ```yaml @@ -127,6 +159,7 @@ steps: 3. **Unique step IDs**: No two steps can have the same id 4. **Valid file paths**: Output paths must not contain invalid characters and should be in the main repo (not dot-directories) 5. **Instructions files exist**: Each `instructions_file` path should have a corresponding file created +6. **Valid workflow references**: If workflows are defined, all step IDs in workflow steps arrays must exist in the steps section ## Example: Complete Job Specification @@ -145,6 +178,21 @@ description: | - Comparison matrix - Strategic positioning report +# Multiple workflows using the same steps +workflows: + - name: full_analysis + summary: "Complete competitive analysis with all steps" + steps: + - identify_competitors + - research_competitors + - positioning_report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify_competitors + - positioning_report + changelog: - version: "1.0.0" changes: "Initial job creation" diff --git a/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md b/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md index 72a6ff88..f984df3a 100644 --- a/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md +++ b/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md @@ -192,12 +192,73 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 3: Validate the Workflow +### Step 2.5: Organize Steps into Workflows -After gathering information about all steps: +A job can contain **multiple workflows** that use the same set of steps in different sequences or combinations. After defining individual steps, determine if the job should have multiple workflows. -1. **Review the flow** - - Summarize the complete workflow +**Ask structured questions to understand workflow organization:** + +1. **Are there different ways to use these steps?** + - Can some steps be run independently as standalone skills? + - Are there different entry points or use cases? + - Are there shorter variations that skip some steps? + +2. **What are the distinct use cases?** + - What's the full workflow from start to finish? + - Are there "quick" variations that skip optional steps? + - Are there standalone utilities (like "learn" or "validate")? + +**When to use multiple workflows:** + +- **Different entry points**: A "quick_analysis" workflow might skip the deep research step +- **Standalone skills**: A "learn" step that can be run independently after any job execution +- **Different audiences**: A "detailed_report" workflow for executives vs. "quick_summary" for team standups +- **Optional phases**: Some workflows might include review/validation, others might skip it + +**Workflow definition format:** + +```yaml +workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - analyze + - report +``` + +**Single workflow jobs:** + +If the job has only one workflow (the most common case), you can either: +1. Define it explicitly in the `workflows` section +2. Omit the `workflows` section entirely (all steps form the implicit workflow) + +**Exposed steps:** + +Steps marked with `exposed: true` can be invoked directly without running their dependencies. These are useful for standalone utilities like "learn" that can run anytime. + +```yaml +steps: + - id: learn + name: "Learn from Execution" + exposed: true # Can be run directly via /job_name.learn + ... +``` + +### Step 3: Validate the Workflow(s) + +After gathering information about all steps and workflows: + +1. **Review the flow(s)** + - Summarize each complete workflow - Show how outputs from one step feed into the next - Ask if anything is missing @@ -205,12 +266,14 @@ After gathering information about all steps: - Are there any steps where the input isn't clearly defined? - Are there any outputs that aren't used by later steps? - Are there circular dependencies? + - Do all workflows reference valid step IDs? 3. **Confirm details** - Job name (lowercase, underscores, descriptive) - Job summary (one clear sentence, max 200 chars) - Job description (detailed multi-line explanation) - Version number (start with 1.0.0) + - Workflow names and their step sequences (if multiple workflows) ### Step 4: Define Quality Validation (Stop Hooks) @@ -350,7 +413,22 @@ Claude: Great. Now for the "Research each one" step: [After gathering all information:] -Claude: Let me summarize the workflow I've designed based on our conversation: +Claude: Now let's think about how these steps should be organized into workflows. Are there different ways you might want to use these steps? + +For example: +- A full analysis that goes through all steps? +- A quick version that skips some steps? +- Any steps that should be available to run independently? + +User: Yes, I'd like a full workflow for complete analysis, but also a quick workflow that just identifies competitors and goes straight to a summary. Also, I sometimes want to just refresh the research on existing competitors without re-identifying them. + +Claude: Great! So we have three workflows: + +1. **full_analysis** - Complete workflow: identify → research → comparative_analysis → positioning_recommendations +2. **quick_summary** - Fast workflow: identify → positioning_recommendations (skip deep research) +3. **refresh_research** - Update existing: research → comparative_analysis → positioning_recommendations + +Let me summarize the complete job I've designed: **Job: competitive_research** Summary: Systematic competitive analysis workflow for product positioning @@ -366,6 +444,17 @@ The workflow produces: Designed for product teams conducting quarterly competitive analysis. +**Workflows:** + +1. **full_analysis** - Complete analysis with all steps + - identify_competitors → research_competitors → comparative_analysis → positioning_recommendations + +2. **quick_summary** - Rapid analysis skipping deep research + - identify_competitors → positioning_recommendations + +3. **refresh_research** - Update research on existing competitors + - research_competitors → comparative_analysis → positioning_recommendations + **Steps:** Step 1: identify_competitors diff --git a/src/deepwork/standard_jobs/deepwork_jobs/templates/job.yml.example b/src/deepwork/standard_jobs/deepwork_jobs/templates/job.yml.example index 7cc6e3bb..61784053 100644 --- a/src/deepwork/standard_jobs/deepwork_jobs/templates/job.yml.example +++ b/src/deepwork/standard_jobs/deepwork_jobs/templates/job.yml.example @@ -1,6 +1,7 @@ # Example: Competitive Research Job # # This is a complete example of a job.yml file for reference. +# It demonstrates multiple workflows using the same set of steps. name: competitive_research version: "1.0.0" @@ -10,6 +11,34 @@ description: | Helps product teams understand the competitive landscape through systematic identification, research, comparison, and positioning recommendations. + This job provides three workflows: + - full_analysis: Complete end-to-end competitive analysis + - quick_summary: Rapid analysis skipping deep research + - refresh_research: Update research on existing competitors + +# Multiple workflows allow different paths through the same steps +workflows: + - name: full_analysis + summary: "Complete competitive analysis with all steps" + steps: + - identify_competitors + - research_competitors + - comparative_analysis + - positioning_recommendations + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify_competitors + - positioning_recommendations + + - name: refresh_research + summary: "Update research on existing competitors" + steps: + - research_competitors + - comparative_analysis + - positioning_recommendations + changelog: - version: "1.0.0" changes: "Initial job creation" diff --git a/src/deepwork/standard_jobs/deepwork_jobs/templates/job.yml.template b/src/deepwork/standard_jobs/deepwork_jobs/templates/job.yml.template index 9aaf45d1..aa3f760e 100644 --- a/src/deepwork/standard_jobs/deepwork_jobs/templates/job.yml.template +++ b/src/deepwork/standard_jobs/deepwork_jobs/templates/job.yml.template @@ -16,6 +16,23 @@ description: | - Who the intended users are - Any important context about the workflow] +# Optional: Define multiple workflows using different combinations of steps +# If omitted, all steps form a single implicit workflow +workflows: + - name: [workflow_name] + summary: "[Brief description of this workflow variant]" + steps: + - [step_id_1] + - [step_id_2] + - [step_id_3] + + # Additional workflow example (optional - include only if multiple workflows needed) + # - name: [another_workflow] + # summary: "[Description of this alternative workflow]" + # steps: + # - [step_id_1] + # - [step_id_3] # Can skip steps or use different combinations + changelog: - version: "1.0.0" changes: "Initial job creation" From 9e27a693d912075947b8da8e238efe4e5a14c043 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 30 Jan 2026 19:21:52 +0000 Subject: [PATCH 2/5] docs: Add changelog entry for multi-workflow define guidance https://claude.ai/code/session_01Mr1h2fVSKeVP84FDWXx4UM --- CHANGELOG.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9fbcd172..e2bac75a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -14,6 +14,10 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 - Step skills now display workflow context (e.g., "Step 2/3 in new_job workflow") - Standalone skills are clearly marked as "can be run anytime" - Backward compatible: jobs without `workflows` section use dependency-based detection +- Enhanced `deepwork_jobs.define` with guidance for creating jobs with multiple workflows + - New Step 2.5 asks structured questions about workflow organization + - Updated example dialog demonstrates multi-workflow discovery conversation + - Templates and doc_specs updated with `workflows` section examples and validation criteria ### Changed - Skill templates now show workflow-aware progress (e.g., "new_job step 2/3 complete") From e7fa65ba48f5cd94612972a718e0a34f4f763d0d Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 30 Jan 2026 19:22:59 +0000 Subject: [PATCH 3/5] chore: Sync deployed skills with multi-workflow guidance changes https://claude.ai/code/session_01Mr1h2fVSKeVP84FDWXx4UM --- .claude/skills/deepwork_jobs.define/SKILL.md | 148 +++++++++++++++++- .../deepwork_jobs.review_job_spec/SKILL.md | 49 +++++- .deepwork/doc_specs/job_spec.md | 48 ++++++ .../jobs/deepwork_jobs/doc_specs/job_spec.md | 48 ++++++ .deepwork/jobs/deepwork_jobs/steps/define.md | 99 +++++++++++- .../deepwork_jobs/templates/job.yml.example | 29 ++++ .../deepwork_jobs/templates/job.yml.template | 17 ++ .gemini/skills/deepwork_jobs/define.toml | 102 +++++++++++- .../skills/deepwork_jobs/review_job_spec.toml | 3 +- 9 files changed, 524 insertions(+), 19 deletions(-) diff --git a/.claude/skills/deepwork_jobs.define/SKILL.md b/.claude/skills/deepwork_jobs.define/SKILL.md index c4419033..124ef7f7 100644 --- a/.claude/skills/deepwork_jobs.define/SKILL.md +++ b/.claude/skills/deepwork_jobs.define/SKILL.md @@ -212,12 +212,73 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 3: Validate the Workflow +### Step 2.5: Organize Steps into Workflows -After gathering information about all steps: +A job can contain **multiple workflows** that use the same set of steps in different sequences or combinations. After defining individual steps, determine if the job should have multiple workflows. -1. **Review the flow** - - Summarize the complete workflow +**Ask structured questions to understand workflow organization:** + +1. **Are there different ways to use these steps?** + - Can some steps be run independently as standalone skills? + - Are there different entry points or use cases? + - Are there shorter variations that skip some steps? + +2. **What are the distinct use cases?** + - What's the full workflow from start to finish? + - Are there "quick" variations that skip optional steps? + - Are there standalone utilities (like "learn" or "validate")? + +**When to use multiple workflows:** + +- **Different entry points**: A "quick_analysis" workflow might skip the deep research step +- **Standalone skills**: A "learn" step that can be run independently after any job execution +- **Different audiences**: A "detailed_report" workflow for executives vs. "quick_summary" for team standups +- **Optional phases**: Some workflows might include review/validation, others might skip it + +**Workflow definition format:** + +```yaml +workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - analyze + - report +``` + +**Single workflow jobs:** + +If the job has only one workflow (the most common case), you can either: +1. Define it explicitly in the `workflows` section +2. Omit the `workflows` section entirely (all steps form the implicit workflow) + +**Exposed steps:** + +Steps marked with `exposed: true` can be invoked directly without running their dependencies. These are useful for standalone utilities like "learn" that can run anytime. + +```yaml +steps: + - id: learn + name: "Learn from Execution" + exposed: true # Can be run directly via /job_name.learn + ... +``` + +### Step 3: Validate the Workflow(s) + +After gathering information about all steps and workflows: + +1. **Review the flow(s)** + - Summarize each complete workflow - Show how outputs from one step feed into the next - Ask if anything is missing @@ -225,12 +286,14 @@ After gathering information about all steps: - Are there any steps where the input isn't clearly defined? - Are there any outputs that aren't used by later steps? - Are there circular dependencies? + - Do all workflows reference valid step IDs? 3. **Confirm details** - Job name (lowercase, underscores, descriptive) - Job summary (one clear sentence, max 200 chars) - Job description (detailed multi-line explanation) - Version number (start with 1.0.0) + - Workflow names and their step sequences (if multiple workflows) ### Step 4: Define Quality Validation (Stop Hooks) @@ -370,7 +433,22 @@ Claude: Great. Now for the "Research each one" step: [After gathering all information:] -Claude: Let me summarize the workflow I've designed based on our conversation: +Claude: Now let's think about how these steps should be organized into workflows. Are there different ways you might want to use these steps? + +For example: +- A full analysis that goes through all steps? +- A quick version that skips some steps? +- Any steps that should be available to run independently? + +User: Yes, I'd like a full workflow for complete analysis, but also a quick workflow that just identifies competitors and goes straight to a summary. Also, I sometimes want to just refresh the research on existing competitors without re-identifying them. + +Claude: Great! So we have three workflows: + +1. **full_analysis** - Complete workflow: identify → research → comparative_analysis → positioning_recommendations +2. **quick_summary** - Fast workflow: identify → positioning_recommendations (skip deep research) +3. **refresh_research** - Update existing: research → comparative_analysis → positioning_recommendations + +Let me summarize the complete job I've designed: **Job: competitive_research** Summary: Systematic competitive analysis workflow for product positioning @@ -386,6 +464,17 @@ The workflow produces: Designed for product teams conducting quarterly competitive analysis. +**Workflows:** + +1. **full_analysis** - Complete analysis with all steps + - identify_competitors → research_competitors → comparative_analysis → positioning_recommendations + +2. **quick_summary** - Rapid analysis skipping deep research + - identify_competitors → positioning_recommendations + +3. **refresh_research** - Update research on existing competitors + - research_competitors → comparative_analysis → positioning_recommendations + **Steps:** Step 1: identify_competitors @@ -510,7 +599,8 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` 7. **Valid Dependencies**: Dependencies must reference existing step IDs with no circular references 8. **Input Consistency**: File inputs with `from_step` must reference a step that is in the dependencies array 9. **Output Paths**: Outputs must be valid filenames or paths within the main repo directory structure, never in dot-directories like `.deepwork/`. Use specific, descriptive paths that lend themselves to glob patterns (e.g., `competitive_research/acme_corp/swot.md` or `operations/reports/2026-01/spending_analysis.md`). Parameterized paths like `[competitor_name]/` are encouraged for per-entity outputs. Avoid generic names (`output.md`, `analysis.md`) and transient-sounding paths (`temp/`, `draft.md`). Supporting materials for a final output should go in a peer `_dataroom` folder (e.g., `spending_analysis_dataroom/`). - 10. **Concise Instructions**: The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI. + 10. **Valid Workflows**: If a `workflows` section is present, each workflow must have a unique name (lowercase_underscores), a summary, and a steps array. All step IDs referenced in workflows must exist in the steps section. Multiple workflows can share steps and define different execution paths through the same step set. + 11. **Concise Instructions**: The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI.
Example Document Structure @@ -543,6 +633,36 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` changes: "Added quality validation hooks" ``` + ### Workflows (Optional) + + Jobs can define multiple workflows that use different combinations of the same steps: + + ```yaml + workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - report + + - name: refresh + summary: "Update existing research" + steps: + - research + - analyze + - report + ``` + + If the `workflows` section is omitted, all steps form a single implicit workflow. + ### Steps Array ```yaml @@ -615,6 +735,7 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` 3. **Unique step IDs**: No two steps can have the same id 4. **Valid file paths**: Output paths must not contain invalid characters and should be in the main repo (not dot-directories) 5. **Instructions files exist**: Each `instructions_file` path should have a corresponding file created + 6. **Valid workflow references**: If workflows are defined, all step IDs in workflow steps arrays must exist in the steps section ## Example: Complete Job Specification @@ -633,6 +754,21 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` - Comparison matrix - Strategic positioning report + # Multiple workflows using the same steps + workflows: + - name: full_analysis + summary: "Complete competitive analysis with all steps" + steps: + - identify_competitors + - research_competitors + - positioning_report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify_competitors + - positioning_report + changelog: - version: "1.0.0" changes: "Initial job creation" diff --git a/.claude/skills/deepwork_jobs.review_job_spec/SKILL.md b/.claude/skills/deepwork_jobs.review_job_spec/SKILL.md index 5369f686..e91a0607 100644 --- a/.claude/skills/deepwork_jobs.review_job_spec/SKILL.md +++ b/.claude/skills/deepwork_jobs.review_job_spec/SKILL.md @@ -277,7 +277,8 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` 7. **Valid Dependencies**: Dependencies must reference existing step IDs with no circular references 8. **Input Consistency**: File inputs with `from_step` must reference a step that is in the dependencies array 9. **Output Paths**: Outputs must be valid filenames or paths within the main repo directory structure, never in dot-directories like `.deepwork/`. Use specific, descriptive paths that lend themselves to glob patterns (e.g., `competitive_research/acme_corp/swot.md` or `operations/reports/2026-01/spending_analysis.md`). Parameterized paths like `[competitor_name]/` are encouraged for per-entity outputs. Avoid generic names (`output.md`, `analysis.md`) and transient-sounding paths (`temp/`, `draft.md`). Supporting materials for a final output should go in a peer `_dataroom` folder (e.g., `spending_analysis_dataroom/`). - 10. **Concise Instructions**: The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI. + 10. **Valid Workflows**: If a `workflows` section is present, each workflow must have a unique name (lowercase_underscores), a summary, and a steps array. All step IDs referenced in workflows must exist in the steps section. Multiple workflows can share steps and define different execution paths through the same step set. + 11. **Concise Instructions**: The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI.
Example Document Structure @@ -310,6 +311,36 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` changes: "Added quality validation hooks" ``` + ### Workflows (Optional) + + Jobs can define multiple workflows that use different combinations of the same steps: + + ```yaml + workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - report + + - name: refresh + summary: "Update existing research" + steps: + - research + - analyze + - report + ``` + + If the `workflows` section is omitted, all steps form a single implicit workflow. + ### Steps Array ```yaml @@ -382,6 +413,7 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` 3. **Unique step IDs**: No two steps can have the same id 4. **Valid file paths**: Output paths must not contain invalid characters and should be in the main repo (not dot-directories) 5. **Instructions files exist**: Each `instructions_file` path should have a corresponding file created + 6. **Valid workflow references**: If workflows are defined, all step IDs in workflow steps arrays must exist in the steps section ## Example: Complete Job Specification @@ -400,6 +432,21 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` - Comparison matrix - Strategic positioning report + # Multiple workflows using the same steps + workflows: + - name: full_analysis + summary: "Complete competitive analysis with all steps" + steps: + - identify_competitors + - research_competitors + - positioning_report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify_competitors + - positioning_report + changelog: - version: "1.0.0" changes: "Initial job creation" diff --git a/.deepwork/doc_specs/job_spec.md b/.deepwork/doc_specs/job_spec.md index 50ce2edd..0e3d55b7 100644 --- a/.deepwork/doc_specs/job_spec.md +++ b/.deepwork/doc_specs/job_spec.md @@ -24,6 +24,8 @@ quality_criteria: description: "File inputs with `from_step` must reference a step that is in the dependencies array" - name: Output Paths description: "Outputs must be valid filenames or paths within the main repo directory structure, never in dot-directories like `.deepwork/`. Use specific, descriptive paths that lend themselves to glob patterns (e.g., `competitive_research/acme_corp/swot.md` or `operations/reports/2026-01/spending_analysis.md`). Parameterized paths like `[competitor_name]/` are encouraged for per-entity outputs. Avoid generic names (`output.md`, `analysis.md`) and transient-sounding paths (`temp/`, `draft.md`). Supporting materials for a final output should go in a peer `_dataroom` folder (e.g., `spending_analysis_dataroom/`)." + - name: Valid Workflows + description: "If a `workflows` section is present, each workflow must have a unique name (lowercase_underscores), a summary, and a steps array. All step IDs referenced in workflows must exist in the steps section. Multiple workflows can share steps and define different execution paths through the same step set." - name: Concise Instructions description: "The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI." --- @@ -55,6 +57,36 @@ changelog: changes: "Added quality validation hooks" ``` +### Workflows (Optional) + +Jobs can define multiple workflows that use different combinations of the same steps: + +```yaml +workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - report + + - name: refresh + summary: "Update existing research" + steps: + - research + - analyze + - report +``` + +If the `workflows` section is omitted, all steps form a single implicit workflow. + ### Steps Array ```yaml @@ -127,6 +159,7 @@ steps: 3. **Unique step IDs**: No two steps can have the same id 4. **Valid file paths**: Output paths must not contain invalid characters and should be in the main repo (not dot-directories) 5. **Instructions files exist**: Each `instructions_file` path should have a corresponding file created +6. **Valid workflow references**: If workflows are defined, all step IDs in workflow steps arrays must exist in the steps section ## Example: Complete Job Specification @@ -145,6 +178,21 @@ description: | - Comparison matrix - Strategic positioning report +# Multiple workflows using the same steps +workflows: + - name: full_analysis + summary: "Complete competitive analysis with all steps" + steps: + - identify_competitors + - research_competitors + - positioning_report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify_competitors + - positioning_report + changelog: - version: "1.0.0" changes: "Initial job creation" diff --git a/.deepwork/jobs/deepwork_jobs/doc_specs/job_spec.md b/.deepwork/jobs/deepwork_jobs/doc_specs/job_spec.md index 50ce2edd..0e3d55b7 100644 --- a/.deepwork/jobs/deepwork_jobs/doc_specs/job_spec.md +++ b/.deepwork/jobs/deepwork_jobs/doc_specs/job_spec.md @@ -24,6 +24,8 @@ quality_criteria: description: "File inputs with `from_step` must reference a step that is in the dependencies array" - name: Output Paths description: "Outputs must be valid filenames or paths within the main repo directory structure, never in dot-directories like `.deepwork/`. Use specific, descriptive paths that lend themselves to glob patterns (e.g., `competitive_research/acme_corp/swot.md` or `operations/reports/2026-01/spending_analysis.md`). Parameterized paths like `[competitor_name]/` are encouraged for per-entity outputs. Avoid generic names (`output.md`, `analysis.md`) and transient-sounding paths (`temp/`, `draft.md`). Supporting materials for a final output should go in a peer `_dataroom` folder (e.g., `spending_analysis_dataroom/`)." + - name: Valid Workflows + description: "If a `workflows` section is present, each workflow must have a unique name (lowercase_underscores), a summary, and a steps array. All step IDs referenced in workflows must exist in the steps section. Multiple workflows can share steps and define different execution paths through the same step set." - name: Concise Instructions description: "The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI." --- @@ -55,6 +57,36 @@ changelog: changes: "Added quality validation hooks" ``` +### Workflows (Optional) + +Jobs can define multiple workflows that use different combinations of the same steps: + +```yaml +workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - report + + - name: refresh + summary: "Update existing research" + steps: + - research + - analyze + - report +``` + +If the `workflows` section is omitted, all steps form a single implicit workflow. + ### Steps Array ```yaml @@ -127,6 +159,7 @@ steps: 3. **Unique step IDs**: No two steps can have the same id 4. **Valid file paths**: Output paths must not contain invalid characters and should be in the main repo (not dot-directories) 5. **Instructions files exist**: Each `instructions_file` path should have a corresponding file created +6. **Valid workflow references**: If workflows are defined, all step IDs in workflow steps arrays must exist in the steps section ## Example: Complete Job Specification @@ -145,6 +178,21 @@ description: | - Comparison matrix - Strategic positioning report +# Multiple workflows using the same steps +workflows: + - name: full_analysis + summary: "Complete competitive analysis with all steps" + steps: + - identify_competitors + - research_competitors + - positioning_report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify_competitors + - positioning_report + changelog: - version: "1.0.0" changes: "Initial job creation" diff --git a/.deepwork/jobs/deepwork_jobs/steps/define.md b/.deepwork/jobs/deepwork_jobs/steps/define.md index 72a6ff88..f984df3a 100644 --- a/.deepwork/jobs/deepwork_jobs/steps/define.md +++ b/.deepwork/jobs/deepwork_jobs/steps/define.md @@ -192,12 +192,73 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 3: Validate the Workflow +### Step 2.5: Organize Steps into Workflows -After gathering information about all steps: +A job can contain **multiple workflows** that use the same set of steps in different sequences or combinations. After defining individual steps, determine if the job should have multiple workflows. -1. **Review the flow** - - Summarize the complete workflow +**Ask structured questions to understand workflow organization:** + +1. **Are there different ways to use these steps?** + - Can some steps be run independently as standalone skills? + - Are there different entry points or use cases? + - Are there shorter variations that skip some steps? + +2. **What are the distinct use cases?** + - What's the full workflow from start to finish? + - Are there "quick" variations that skip optional steps? + - Are there standalone utilities (like "learn" or "validate")? + +**When to use multiple workflows:** + +- **Different entry points**: A "quick_analysis" workflow might skip the deep research step +- **Standalone skills**: A "learn" step that can be run independently after any job execution +- **Different audiences**: A "detailed_report" workflow for executives vs. "quick_summary" for team standups +- **Optional phases**: Some workflows might include review/validation, others might skip it + +**Workflow definition format:** + +```yaml +workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - analyze + - report +``` + +**Single workflow jobs:** + +If the job has only one workflow (the most common case), you can either: +1. Define it explicitly in the `workflows` section +2. Omit the `workflows` section entirely (all steps form the implicit workflow) + +**Exposed steps:** + +Steps marked with `exposed: true` can be invoked directly without running their dependencies. These are useful for standalone utilities like "learn" that can run anytime. + +```yaml +steps: + - id: learn + name: "Learn from Execution" + exposed: true # Can be run directly via /job_name.learn + ... +``` + +### Step 3: Validate the Workflow(s) + +After gathering information about all steps and workflows: + +1. **Review the flow(s)** + - Summarize each complete workflow - Show how outputs from one step feed into the next - Ask if anything is missing @@ -205,12 +266,14 @@ After gathering information about all steps: - Are there any steps where the input isn't clearly defined? - Are there any outputs that aren't used by later steps? - Are there circular dependencies? + - Do all workflows reference valid step IDs? 3. **Confirm details** - Job name (lowercase, underscores, descriptive) - Job summary (one clear sentence, max 200 chars) - Job description (detailed multi-line explanation) - Version number (start with 1.0.0) + - Workflow names and their step sequences (if multiple workflows) ### Step 4: Define Quality Validation (Stop Hooks) @@ -350,7 +413,22 @@ Claude: Great. Now for the "Research each one" step: [After gathering all information:] -Claude: Let me summarize the workflow I've designed based on our conversation: +Claude: Now let's think about how these steps should be organized into workflows. Are there different ways you might want to use these steps? + +For example: +- A full analysis that goes through all steps? +- A quick version that skips some steps? +- Any steps that should be available to run independently? + +User: Yes, I'd like a full workflow for complete analysis, but also a quick workflow that just identifies competitors and goes straight to a summary. Also, I sometimes want to just refresh the research on existing competitors without re-identifying them. + +Claude: Great! So we have three workflows: + +1. **full_analysis** - Complete workflow: identify → research → comparative_analysis → positioning_recommendations +2. **quick_summary** - Fast workflow: identify → positioning_recommendations (skip deep research) +3. **refresh_research** - Update existing: research → comparative_analysis → positioning_recommendations + +Let me summarize the complete job I've designed: **Job: competitive_research** Summary: Systematic competitive analysis workflow for product positioning @@ -366,6 +444,17 @@ The workflow produces: Designed for product teams conducting quarterly competitive analysis. +**Workflows:** + +1. **full_analysis** - Complete analysis with all steps + - identify_competitors → research_competitors → comparative_analysis → positioning_recommendations + +2. **quick_summary** - Rapid analysis skipping deep research + - identify_competitors → positioning_recommendations + +3. **refresh_research** - Update research on existing competitors + - research_competitors → comparative_analysis → positioning_recommendations + **Steps:** Step 1: identify_competitors diff --git a/.deepwork/jobs/deepwork_jobs/templates/job.yml.example b/.deepwork/jobs/deepwork_jobs/templates/job.yml.example index 7cc6e3bb..61784053 100644 --- a/.deepwork/jobs/deepwork_jobs/templates/job.yml.example +++ b/.deepwork/jobs/deepwork_jobs/templates/job.yml.example @@ -1,6 +1,7 @@ # Example: Competitive Research Job # # This is a complete example of a job.yml file for reference. +# It demonstrates multiple workflows using the same set of steps. name: competitive_research version: "1.0.0" @@ -10,6 +11,34 @@ description: | Helps product teams understand the competitive landscape through systematic identification, research, comparison, and positioning recommendations. + This job provides three workflows: + - full_analysis: Complete end-to-end competitive analysis + - quick_summary: Rapid analysis skipping deep research + - refresh_research: Update research on existing competitors + +# Multiple workflows allow different paths through the same steps +workflows: + - name: full_analysis + summary: "Complete competitive analysis with all steps" + steps: + - identify_competitors + - research_competitors + - comparative_analysis + - positioning_recommendations + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify_competitors + - positioning_recommendations + + - name: refresh_research + summary: "Update research on existing competitors" + steps: + - research_competitors + - comparative_analysis + - positioning_recommendations + changelog: - version: "1.0.0" changes: "Initial job creation" diff --git a/.deepwork/jobs/deepwork_jobs/templates/job.yml.template b/.deepwork/jobs/deepwork_jobs/templates/job.yml.template index 9aaf45d1..aa3f760e 100644 --- a/.deepwork/jobs/deepwork_jobs/templates/job.yml.template +++ b/.deepwork/jobs/deepwork_jobs/templates/job.yml.template @@ -16,6 +16,23 @@ description: | - Who the intended users are - Any important context about the workflow] +# Optional: Define multiple workflows using different combinations of steps +# If omitted, all steps form a single implicit workflow +workflows: + - name: [workflow_name] + summary: "[Brief description of this workflow variant]" + steps: + - [step_id_1] + - [step_id_2] + - [step_id_3] + + # Additional workflow example (optional - include only if multiple workflows needed) + # - name: [another_workflow] + # summary: "[Description of this alternative workflow]" + # steps: + # - [step_id_1] + # - [step_id_3] # Can skip steps or use different combinations + changelog: - version: "1.0.0" changes: "Initial job creation" diff --git a/.gemini/skills/deepwork_jobs/define.toml b/.gemini/skills/deepwork_jobs/define.toml index 804d650f..ba4ed44d 100644 --- a/.gemini/skills/deepwork_jobs/define.toml +++ b/.gemini/skills/deepwork_jobs/define.toml @@ -212,12 +212,73 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 3: Validate the Workflow +### Step 2.5: Organize Steps into Workflows -After gathering information about all steps: +A job can contain **multiple workflows** that use the same set of steps in different sequences or combinations. After defining individual steps, determine if the job should have multiple workflows. -1. **Review the flow** - - Summarize the complete workflow +**Ask structured questions to understand workflow organization:** + +1. **Are there different ways to use these steps?** + - Can some steps be run independently as standalone skills? + - Are there different entry points or use cases? + - Are there shorter variations that skip some steps? + +2. **What are the distinct use cases?** + - What's the full workflow from start to finish? + - Are there "quick" variations that skip optional steps? + - Are there standalone utilities (like "learn" or "validate")? + +**When to use multiple workflows:** + +- **Different entry points**: A "quick_analysis" workflow might skip the deep research step +- **Standalone skills**: A "learn" step that can be run independently after any job execution +- **Different audiences**: A "detailed_report" workflow for executives vs. "quick_summary" for team standups +- **Optional phases**: Some workflows might include review/validation, others might skip it + +**Workflow definition format:** + +```yaml +workflows: + - name: full_analysis + summary: "Complete analysis with all steps" + steps: + - identify + - research + - analyze + - report + + - name: quick_summary + summary: "Rapid analysis skipping deep research" + steps: + - identify + - analyze + - report +``` + +**Single workflow jobs:** + +If the job has only one workflow (the most common case), you can either: +1. Define it explicitly in the `workflows` section +2. Omit the `workflows` section entirely (all steps form the implicit workflow) + +**Exposed steps:** + +Steps marked with `exposed: true` can be invoked directly without running their dependencies. These are useful for standalone utilities like "learn" that can run anytime. + +```yaml +steps: + - id: learn + name: "Learn from Execution" + exposed: true # Can be run directly via /job_name.learn + ... +``` + +### Step 3: Validate the Workflow(s) + +After gathering information about all steps and workflows: + +1. **Review the flow(s)** + - Summarize each complete workflow - Show how outputs from one step feed into the next - Ask if anything is missing @@ -225,12 +286,14 @@ After gathering information about all steps: - Are there any steps where the input isn't clearly defined? - Are there any outputs that aren't used by later steps? - Are there circular dependencies? + - Do all workflows reference valid step IDs? 3. **Confirm details** - Job name (lowercase, underscores, descriptive) - Job summary (one clear sentence, max 200 chars) - Job description (detailed multi-line explanation) - Version number (start with 1.0.0) + - Workflow names and their step sequences (if multiple workflows) ### Step 4: Define Quality Validation (Stop Hooks) @@ -370,7 +433,22 @@ Claude: Great. Now for the "Research each one" step: [After gathering all information:] -Claude: Let me summarize the workflow I've designed based on our conversation: +Claude: Now let's think about how these steps should be organized into workflows. Are there different ways you might want to use these steps? + +For example: +- A full analysis that goes through all steps? +- A quick version that skips some steps? +- Any steps that should be available to run independently? + +User: Yes, I'd like a full workflow for complete analysis, but also a quick workflow that just identifies competitors and goes straight to a summary. Also, I sometimes want to just refresh the research on existing competitors without re-identifying them. + +Claude: Great! So we have three workflows: + +1. **full_analysis** - Complete workflow: identify → research → comparative_analysis → positioning_recommendations +2. **quick_summary** - Fast workflow: identify → positioning_recommendations (skip deep research) +3. **refresh_research** - Update existing: research → comparative_analysis → positioning_recommendations + +Let me summarize the complete job I've designed: **Job: competitive_research** Summary: Systematic competitive analysis workflow for product positioning @@ -386,6 +464,17 @@ The workflow produces: Designed for product teams conducting quarterly competitive analysis. +**Workflows:** + +1. **full_analysis** - Complete analysis with all steps + - identify_competitors → research_competitors → comparative_analysis → positioning_recommendations + +2. **quick_summary** - Rapid analysis skipping deep research + - identify_competitors → positioning_recommendations + +3. **refresh_research** - Update research on existing competitors + - research_competitors → comparative_analysis → positioning_recommendations + **Steps:** Step 1: identify_competitors @@ -510,7 +599,8 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` 7. **Valid Dependencies**: Dependencies must reference existing step IDs with no circular references 8. **Input Consistency**: File inputs with `from_step` must reference a step that is in the dependencies array 9. **Output Paths**: Outputs must be valid filenames or paths within the main repo directory structure, never in dot-directories like `.deepwork/`. Use specific, descriptive paths that lend themselves to glob patterns (e.g., `competitive_research/acme_corp/swot.md` or `operations/reports/2026-01/spending_analysis.md`). Parameterized paths like `[competitor_name]/` are encouraged for per-entity outputs. Avoid generic names (`output.md`, `analysis.md`) and transient-sounding paths (`temp/`, `draft.md`). Supporting materials for a final output should go in a peer `_dataroom` folder (e.g., `spending_analysis_dataroom/`). - 10. **Concise Instructions**: The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI. + 10. **Valid Workflows**: If a `workflows` section is present, each workflow must have a unique name (lowercase_underscores), a summary, and a steps array. All step IDs referenced in workflows must exist in the steps section. Multiple workflows can share steps and define different execution paths through the same step set. + 11. **Concise Instructions**: The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI. ## On Completion diff --git a/.gemini/skills/deepwork_jobs/review_job_spec.toml b/.gemini/skills/deepwork_jobs/review_job_spec.toml index 265eb151..178c287c 100644 --- a/.gemini/skills/deepwork_jobs/review_job_spec.toml +++ b/.gemini/skills/deepwork_jobs/review_job_spec.toml @@ -277,7 +277,8 @@ Use branch format: `deepwork/deepwork_jobs-[instance]-YYYYMMDD` 7. **Valid Dependencies**: Dependencies must reference existing step IDs with no circular references 8. **Input Consistency**: File inputs with `from_step` must reference a step that is in the dependencies array 9. **Output Paths**: Outputs must be valid filenames or paths within the main repo directory structure, never in dot-directories like `.deepwork/`. Use specific, descriptive paths that lend themselves to glob patterns (e.g., `competitive_research/acme_corp/swot.md` or `operations/reports/2026-01/spending_analysis.md`). Parameterized paths like `[competitor_name]/` are encouraged for per-entity outputs. Avoid generic names (`output.md`, `analysis.md`) and transient-sounding paths (`temp/`, `draft.md`). Supporting materials for a final output should go in a peer `_dataroom` folder (e.g., `spending_analysis_dataroom/`). - 10. **Concise Instructions**: The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI. + 10. **Valid Workflows**: If a `workflows` section is present, each workflow must have a unique name (lowercase_underscores), a summary, and a steps array. All step IDs referenced in workflows must exist in the steps section. Multiple workflows can share steps and define different execution paths through the same step set. + 11. **Concise Instructions**: The content of the file, particularly the description, must not have excessively redundant information. It should be concise and to the point given that extra tokens will confuse the AI. ## Quality Validation (Manual) From b3d9a204fbde941661e9a0056c9397936769b4df Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 30 Jan 2026 19:35:14 +0000 Subject: [PATCH 4/5] refactor: Simplify multi-workflow guidance in define step Focus on the key use case: workflows are for when different parts need to happen at different points in time (human review gates, setup/teardown patterns, phased execution). Remove verbose questions about workflow organization and simplify the example dialog to show a single-workflow job (the common case). https://claude.ai/code/session_01Mr1h2fVSKeVP84FDWXx4UM --- .claude/skills/deepwork_jobs.define/SKILL.md | 148 +++++------------- .deepwork/jobs/deepwork_jobs/steps/define.md | 148 +++++------------- .gemini/skills/deepwork_jobs/define.toml | 148 +++++------------- .../deepwork_jobs/steps/define.md | 148 +++++------------- 4 files changed, 172 insertions(+), 420 deletions(-) diff --git a/.claude/skills/deepwork_jobs.define/SKILL.md b/.claude/skills/deepwork_jobs.define/SKILL.md index 124ef7f7..950bd910 100644 --- a/.claude/skills/deepwork_jobs.define/SKILL.md +++ b/.claude/skills/deepwork_jobs.define/SKILL.md @@ -212,73 +212,47 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 2.5: Organize Steps into Workflows +### Step 2.5: Consider Multiple Workflows -A job can contain **multiple workflows** that use the same set of steps in different sequences or combinations. After defining individual steps, determine if the job should have multiple workflows. +A job can define **multiple workflows** when different parts of the work need to happen at different points in time. Most jobs have a single workflow, but consider multiple workflows when: -**Ask structured questions to understand workflow organization:** +- **Human review/approval gates**: Some steps produce output that needs human review before proceeding. Split into separate workflows so users can run the second part after review. +- **Setup/teardown patterns**: Provisioning resources and later destroying them are distinct operations. +- **Phased execution**: Steps that naturally happen days or weeks apart. -1. **Are there different ways to use these steps?** - - Can some steps be run independently as standalone skills? - - Are there different entry points or use cases? - - Are there shorter variations that skip some steps? +**Examples:** -2. **What are the distinct use cases?** - - What's the full workflow from start to finish? - - Are there "quick" variations that skip optional steps? - - Are there standalone utilities (like "learn" or "validate")? +| Job | Workflows | Reason | +|-----|-----------|--------| +| Twitter Ad Campaign | `analyze_and_propose` → `setup_approved_ads` | Human reviews proposed ads before setup | +| Customer Environment | `provision` → `teardown` | Distinct operations at different times | +| Quarterly Report | `gather_data` → `finalize_report` | Data gathering happens throughout quarter | -**When to use multiple workflows:** - -- **Different entry points**: A "quick_analysis" workflow might skip the deep research step -- **Standalone skills**: A "learn" step that can be run independently after any job execution -- **Different audiences**: A "detailed_report" workflow for executives vs. "quick_summary" for team standups -- **Optional phases**: Some workflows might include review/validation, others might skip it - -**Workflow definition format:** +**Format:** ```yaml workflows: - - name: full_analysis - summary: "Complete analysis with all steps" + - name: analyze_and_propose + summary: "Analyze trends and propose ad content" steps: - - identify - - research - - analyze - - report + - analyze_trends + - generate_proposals + - build_report - - name: quick_summary - summary: "Rapid analysis skipping deep research" + - name: setup_approved_ads + summary: "Create approved ads on platform" steps: - - identify - - analyze - - report + - setup_ads ``` -**Single workflow jobs:** - -If the job has only one workflow (the most common case), you can either: -1. Define it explicitly in the `workflows` section -2. Omit the `workflows` section entirely (all steps form the implicit workflow) - -**Exposed steps:** - -Steps marked with `exposed: true` can be invoked directly without running their dependencies. These are useful for standalone utilities like "learn" that can run anytime. +If the job has only one workflow (most common), you can omit the `workflows` section entirely. -```yaml -steps: - - id: learn - name: "Learn from Execution" - exposed: true # Can be run directly via /job_name.learn - ... -``` - -### Step 3: Validate the Workflow(s) +### Step 3: Validate the Workflow -After gathering information about all steps and workflows: +After gathering information about all steps: -1. **Review the flow(s)** - - Summarize each complete workflow +1. **Review the flow** + - Summarize the complete workflow - Show how outputs from one step feed into the next - Ask if anything is missing @@ -286,14 +260,12 @@ After gathering information about all steps and workflows: - Are there any steps where the input isn't clearly defined? - Are there any outputs that aren't used by later steps? - Are there circular dependencies? - - Do all workflows reference valid step IDs? 3. **Confirm details** - Job name (lowercase, underscores, descriptive) - Job summary (one clear sentence, max 200 chars) - Job description (detailed multi-line explanation) - Version number (start with 1.0.0) - - Workflow names and their step sequences (if multiple workflows) ### Step 4: Define Quality Validation (Stop Hooks) @@ -433,70 +405,36 @@ Claude: Great. Now for the "Research each one" step: [After gathering all information:] -Claude: Now let's think about how these steps should be organized into workflows. Are there different ways you might want to use these steps? - -For example: -- A full analysis that goes through all steps? -- A quick version that skips some steps? -- Any steps that should be available to run independently? - -User: Yes, I'd like a full workflow for complete analysis, but also a quick workflow that just identifies competitors and goes straight to a summary. Also, I sometimes want to just refresh the research on existing competitors without re-identifying them. - -Claude: Great! So we have three workflows: - -1. **full_analysis** - Complete workflow: identify → research → comparative_analysis → positioning_recommendations -2. **quick_summary** - Fast workflow: identify → positioning_recommendations (skip deep research) -3. **refresh_research** - Update existing: research → comparative_analysis → positioning_recommendations - -Let me summarize the complete job I've designed: +Claude: Let me summarize the workflow I've designed: **Job: competitive_research** Summary: Systematic competitive analysis workflow for product positioning Description: -A comprehensive workflow for analyzing competitors in your market segment. This job helps product teams understand the competitive landscape by systematically identifying competitors, researching their offerings, creating comparison matrices, and developing strategic positioning recommendations. - -The workflow produces: -- A vetted list of key competitors -- Detailed research notes on each competitor -- A comparison matrix highlighting key differentiators -- Strategic positioning recommendations - -Designed for product teams conducting quarterly competitive analysis. - -**Workflows:** - -1. **full_analysis** - Complete analysis with all steps - - identify_competitors → research_competitors → comparative_analysis → positioning_recommendations - -2. **quick_summary** - Rapid analysis skipping deep research - - identify_competitors → positioning_recommendations - -3. **refresh_research** - Update research on existing competitors - - research_competitors → comparative_analysis → positioning_recommendations +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. **Steps:** -Step 1: identify_competitors -- Input: market_segment (user), product_category (user) -- Output: competitors_list.md (5-7 competitors with descriptions) +1. **identify_competitors** + - Input: market_segment (user), product_category (user) + - Output: competitive_research/competitors_list.md -Step 2: research_competitors -- Input: competitors_list.md (from step 1) -- Output: research_notes.md (detailed findings for each competitor) -- Depends on: identify_competitors +2. **research_competitors** + - Input: competitors_list.md (from step 1) + - Output: competitive_research/research_notes.md + - Depends on: identify_competitors -Step 3: comparative_analysis -- Input: research_notes.md (from step 2) -- Output: comparison_matrix.md (side-by-side analysis) -- Depends on: research_competitors +3. **comparative_analysis** + - Input: research_notes.md (from step 2) + - Output: competitive_research/comparison_matrix.md + - Depends on: research_competitors -Step 4: positioning_recommendations -- Input: comparison_matrix.md (from step 3) -- Output: positioning_report.md (strategic recommendations) -- Depends on: comparative_analysis +4. **positioning_recommendations** + - Input: comparison_matrix.md (from step 3) + - Output: competitive_research/positioning_report.md + - Depends on: comparative_analysis -Does this accurately capture your workflow? Any changes needed? +Does this accurately capture your workflow? User: Yes, that's perfect! diff --git a/.deepwork/jobs/deepwork_jobs/steps/define.md b/.deepwork/jobs/deepwork_jobs/steps/define.md index f984df3a..ba49491b 100644 --- a/.deepwork/jobs/deepwork_jobs/steps/define.md +++ b/.deepwork/jobs/deepwork_jobs/steps/define.md @@ -192,73 +192,47 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 2.5: Organize Steps into Workflows +### Step 2.5: Consider Multiple Workflows -A job can contain **multiple workflows** that use the same set of steps in different sequences or combinations. After defining individual steps, determine if the job should have multiple workflows. +A job can define **multiple workflows** when different parts of the work need to happen at different points in time. Most jobs have a single workflow, but consider multiple workflows when: -**Ask structured questions to understand workflow organization:** +- **Human review/approval gates**: Some steps produce output that needs human review before proceeding. Split into separate workflows so users can run the second part after review. +- **Setup/teardown patterns**: Provisioning resources and later destroying them are distinct operations. +- **Phased execution**: Steps that naturally happen days or weeks apart. -1. **Are there different ways to use these steps?** - - Can some steps be run independently as standalone skills? - - Are there different entry points or use cases? - - Are there shorter variations that skip some steps? +**Examples:** -2. **What are the distinct use cases?** - - What's the full workflow from start to finish? - - Are there "quick" variations that skip optional steps? - - Are there standalone utilities (like "learn" or "validate")? +| Job | Workflows | Reason | +|-----|-----------|--------| +| Twitter Ad Campaign | `analyze_and_propose` → `setup_approved_ads` | Human reviews proposed ads before setup | +| Customer Environment | `provision` → `teardown` | Distinct operations at different times | +| Quarterly Report | `gather_data` → `finalize_report` | Data gathering happens throughout quarter | -**When to use multiple workflows:** - -- **Different entry points**: A "quick_analysis" workflow might skip the deep research step -- **Standalone skills**: A "learn" step that can be run independently after any job execution -- **Different audiences**: A "detailed_report" workflow for executives vs. "quick_summary" for team standups -- **Optional phases**: Some workflows might include review/validation, others might skip it - -**Workflow definition format:** +**Format:** ```yaml workflows: - - name: full_analysis - summary: "Complete analysis with all steps" + - name: analyze_and_propose + summary: "Analyze trends and propose ad content" steps: - - identify - - research - - analyze - - report + - analyze_trends + - generate_proposals + - build_report - - name: quick_summary - summary: "Rapid analysis skipping deep research" + - name: setup_approved_ads + summary: "Create approved ads on platform" steps: - - identify - - analyze - - report + - setup_ads ``` -**Single workflow jobs:** - -If the job has only one workflow (the most common case), you can either: -1. Define it explicitly in the `workflows` section -2. Omit the `workflows` section entirely (all steps form the implicit workflow) - -**Exposed steps:** - -Steps marked with `exposed: true` can be invoked directly without running their dependencies. These are useful for standalone utilities like "learn" that can run anytime. +If the job has only one workflow (most common), you can omit the `workflows` section entirely. -```yaml -steps: - - id: learn - name: "Learn from Execution" - exposed: true # Can be run directly via /job_name.learn - ... -``` - -### Step 3: Validate the Workflow(s) +### Step 3: Validate the Workflow -After gathering information about all steps and workflows: +After gathering information about all steps: -1. **Review the flow(s)** - - Summarize each complete workflow +1. **Review the flow** + - Summarize the complete workflow - Show how outputs from one step feed into the next - Ask if anything is missing @@ -266,14 +240,12 @@ After gathering information about all steps and workflows: - Are there any steps where the input isn't clearly defined? - Are there any outputs that aren't used by later steps? - Are there circular dependencies? - - Do all workflows reference valid step IDs? 3. **Confirm details** - Job name (lowercase, underscores, descriptive) - Job summary (one clear sentence, max 200 chars) - Job description (detailed multi-line explanation) - Version number (start with 1.0.0) - - Workflow names and their step sequences (if multiple workflows) ### Step 4: Define Quality Validation (Stop Hooks) @@ -413,70 +385,36 @@ Claude: Great. Now for the "Research each one" step: [After gathering all information:] -Claude: Now let's think about how these steps should be organized into workflows. Are there different ways you might want to use these steps? - -For example: -- A full analysis that goes through all steps? -- A quick version that skips some steps? -- Any steps that should be available to run independently? - -User: Yes, I'd like a full workflow for complete analysis, but also a quick workflow that just identifies competitors and goes straight to a summary. Also, I sometimes want to just refresh the research on existing competitors without re-identifying them. - -Claude: Great! So we have three workflows: - -1. **full_analysis** - Complete workflow: identify → research → comparative_analysis → positioning_recommendations -2. **quick_summary** - Fast workflow: identify → positioning_recommendations (skip deep research) -3. **refresh_research** - Update existing: research → comparative_analysis → positioning_recommendations - -Let me summarize the complete job I've designed: +Claude: Let me summarize the workflow I've designed: **Job: competitive_research** Summary: Systematic competitive analysis workflow for product positioning Description: -A comprehensive workflow for analyzing competitors in your market segment. This job helps product teams understand the competitive landscape by systematically identifying competitors, researching their offerings, creating comparison matrices, and developing strategic positioning recommendations. - -The workflow produces: -- A vetted list of key competitors -- Detailed research notes on each competitor -- A comparison matrix highlighting key differentiators -- Strategic positioning recommendations - -Designed for product teams conducting quarterly competitive analysis. - -**Workflows:** - -1. **full_analysis** - Complete analysis with all steps - - identify_competitors → research_competitors → comparative_analysis → positioning_recommendations - -2. **quick_summary** - Rapid analysis skipping deep research - - identify_competitors → positioning_recommendations - -3. **refresh_research** - Update research on existing competitors - - research_competitors → comparative_analysis → positioning_recommendations +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. **Steps:** -Step 1: identify_competitors -- Input: market_segment (user), product_category (user) -- Output: competitors_list.md (5-7 competitors with descriptions) +1. **identify_competitors** + - Input: market_segment (user), product_category (user) + - Output: competitive_research/competitors_list.md -Step 2: research_competitors -- Input: competitors_list.md (from step 1) -- Output: research_notes.md (detailed findings for each competitor) -- Depends on: identify_competitors +2. **research_competitors** + - Input: competitors_list.md (from step 1) + - Output: competitive_research/research_notes.md + - Depends on: identify_competitors -Step 3: comparative_analysis -- Input: research_notes.md (from step 2) -- Output: comparison_matrix.md (side-by-side analysis) -- Depends on: research_competitors +3. **comparative_analysis** + - Input: research_notes.md (from step 2) + - Output: competitive_research/comparison_matrix.md + - Depends on: research_competitors -Step 4: positioning_recommendations -- Input: comparison_matrix.md (from step 3) -- Output: positioning_report.md (strategic recommendations) -- Depends on: comparative_analysis +4. **positioning_recommendations** + - Input: comparison_matrix.md (from step 3) + - Output: competitive_research/positioning_report.md + - Depends on: comparative_analysis -Does this accurately capture your workflow? Any changes needed? +Does this accurately capture your workflow? User: Yes, that's perfect! diff --git a/.gemini/skills/deepwork_jobs/define.toml b/.gemini/skills/deepwork_jobs/define.toml index ba4ed44d..2c7631fc 100644 --- a/.gemini/skills/deepwork_jobs/define.toml +++ b/.gemini/skills/deepwork_jobs/define.toml @@ -212,73 +212,47 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 2.5: Organize Steps into Workflows +### Step 2.5: Consider Multiple Workflows -A job can contain **multiple workflows** that use the same set of steps in different sequences or combinations. After defining individual steps, determine if the job should have multiple workflows. +A job can define **multiple workflows** when different parts of the work need to happen at different points in time. Most jobs have a single workflow, but consider multiple workflows when: -**Ask structured questions to understand workflow organization:** +- **Human review/approval gates**: Some steps produce output that needs human review before proceeding. Split into separate workflows so users can run the second part after review. +- **Setup/teardown patterns**: Provisioning resources and later destroying them are distinct operations. +- **Phased execution**: Steps that naturally happen days or weeks apart. -1. **Are there different ways to use these steps?** - - Can some steps be run independently as standalone skills? - - Are there different entry points or use cases? - - Are there shorter variations that skip some steps? +**Examples:** -2. **What are the distinct use cases?** - - What's the full workflow from start to finish? - - Are there "quick" variations that skip optional steps? - - Are there standalone utilities (like "learn" or "validate")? +| Job | Workflows | Reason | +|-----|-----------|--------| +| Twitter Ad Campaign | `analyze_and_propose` → `setup_approved_ads` | Human reviews proposed ads before setup | +| Customer Environment | `provision` → `teardown` | Distinct operations at different times | +| Quarterly Report | `gather_data` → `finalize_report` | Data gathering happens throughout quarter | -**When to use multiple workflows:** - -- **Different entry points**: A "quick_analysis" workflow might skip the deep research step -- **Standalone skills**: A "learn" step that can be run independently after any job execution -- **Different audiences**: A "detailed_report" workflow for executives vs. "quick_summary" for team standups -- **Optional phases**: Some workflows might include review/validation, others might skip it - -**Workflow definition format:** +**Format:** ```yaml workflows: - - name: full_analysis - summary: "Complete analysis with all steps" + - name: analyze_and_propose + summary: "Analyze trends and propose ad content" steps: - - identify - - research - - analyze - - report + - analyze_trends + - generate_proposals + - build_report - - name: quick_summary - summary: "Rapid analysis skipping deep research" + - name: setup_approved_ads + summary: "Create approved ads on platform" steps: - - identify - - analyze - - report + - setup_ads ``` -**Single workflow jobs:** - -If the job has only one workflow (the most common case), you can either: -1. Define it explicitly in the `workflows` section -2. Omit the `workflows` section entirely (all steps form the implicit workflow) - -**Exposed steps:** - -Steps marked with `exposed: true` can be invoked directly without running their dependencies. These are useful for standalone utilities like "learn" that can run anytime. +If the job has only one workflow (most common), you can omit the `workflows` section entirely. -```yaml -steps: - - id: learn - name: "Learn from Execution" - exposed: true # Can be run directly via /job_name.learn - ... -``` - -### Step 3: Validate the Workflow(s) +### Step 3: Validate the Workflow -After gathering information about all steps and workflows: +After gathering information about all steps: -1. **Review the flow(s)** - - Summarize each complete workflow +1. **Review the flow** + - Summarize the complete workflow - Show how outputs from one step feed into the next - Ask if anything is missing @@ -286,14 +260,12 @@ After gathering information about all steps and workflows: - Are there any steps where the input isn't clearly defined? - Are there any outputs that aren't used by later steps? - Are there circular dependencies? - - Do all workflows reference valid step IDs? 3. **Confirm details** - Job name (lowercase, underscores, descriptive) - Job summary (one clear sentence, max 200 chars) - Job description (detailed multi-line explanation) - Version number (start with 1.0.0) - - Workflow names and their step sequences (if multiple workflows) ### Step 4: Define Quality Validation (Stop Hooks) @@ -433,70 +405,36 @@ Claude: Great. Now for the "Research each one" step: [After gathering all information:] -Claude: Now let's think about how these steps should be organized into workflows. Are there different ways you might want to use these steps? - -For example: -- A full analysis that goes through all steps? -- A quick version that skips some steps? -- Any steps that should be available to run independently? - -User: Yes, I'd like a full workflow for complete analysis, but also a quick workflow that just identifies competitors and goes straight to a summary. Also, I sometimes want to just refresh the research on existing competitors without re-identifying them. - -Claude: Great! So we have three workflows: - -1. **full_analysis** - Complete workflow: identify → research → comparative_analysis → positioning_recommendations -2. **quick_summary** - Fast workflow: identify → positioning_recommendations (skip deep research) -3. **refresh_research** - Update existing: research → comparative_analysis → positioning_recommendations - -Let me summarize the complete job I've designed: +Claude: Let me summarize the workflow I've designed: **Job: competitive_research** Summary: Systematic competitive analysis workflow for product positioning Description: -A comprehensive workflow for analyzing competitors in your market segment. This job helps product teams understand the competitive landscape by systematically identifying competitors, researching their offerings, creating comparison matrices, and developing strategic positioning recommendations. - -The workflow produces: -- A vetted list of key competitors -- Detailed research notes on each competitor -- A comparison matrix highlighting key differentiators -- Strategic positioning recommendations - -Designed for product teams conducting quarterly competitive analysis. - -**Workflows:** - -1. **full_analysis** - Complete analysis with all steps - - identify_competitors → research_competitors → comparative_analysis → positioning_recommendations - -2. **quick_summary** - Rapid analysis skipping deep research - - identify_competitors → positioning_recommendations - -3. **refresh_research** - Update research on existing competitors - - research_competitors → comparative_analysis → positioning_recommendations +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. **Steps:** -Step 1: identify_competitors -- Input: market_segment (user), product_category (user) -- Output: competitors_list.md (5-7 competitors with descriptions) +1. **identify_competitors** + - Input: market_segment (user), product_category (user) + - Output: competitive_research/competitors_list.md -Step 2: research_competitors -- Input: competitors_list.md (from step 1) -- Output: research_notes.md (detailed findings for each competitor) -- Depends on: identify_competitors +2. **research_competitors** + - Input: competitors_list.md (from step 1) + - Output: competitive_research/research_notes.md + - Depends on: identify_competitors -Step 3: comparative_analysis -- Input: research_notes.md (from step 2) -- Output: comparison_matrix.md (side-by-side analysis) -- Depends on: research_competitors +3. **comparative_analysis** + - Input: research_notes.md (from step 2) + - Output: competitive_research/comparison_matrix.md + - Depends on: research_competitors -Step 4: positioning_recommendations -- Input: comparison_matrix.md (from step 3) -- Output: positioning_report.md (strategic recommendations) -- Depends on: comparative_analysis +4. **positioning_recommendations** + - Input: comparison_matrix.md (from step 3) + - Output: competitive_research/positioning_report.md + - Depends on: comparative_analysis -Does this accurately capture your workflow? Any changes needed? +Does this accurately capture your workflow? User: Yes, that's perfect! diff --git a/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md b/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md index f984df3a..ba49491b 100644 --- a/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md +++ b/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md @@ -192,73 +192,47 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 2.5: Organize Steps into Workflows +### Step 2.5: Consider Multiple Workflows -A job can contain **multiple workflows** that use the same set of steps in different sequences or combinations. After defining individual steps, determine if the job should have multiple workflows. +A job can define **multiple workflows** when different parts of the work need to happen at different points in time. Most jobs have a single workflow, but consider multiple workflows when: -**Ask structured questions to understand workflow organization:** +- **Human review/approval gates**: Some steps produce output that needs human review before proceeding. Split into separate workflows so users can run the second part after review. +- **Setup/teardown patterns**: Provisioning resources and later destroying them are distinct operations. +- **Phased execution**: Steps that naturally happen days or weeks apart. -1. **Are there different ways to use these steps?** - - Can some steps be run independently as standalone skills? - - Are there different entry points or use cases? - - Are there shorter variations that skip some steps? +**Examples:** -2. **What are the distinct use cases?** - - What's the full workflow from start to finish? - - Are there "quick" variations that skip optional steps? - - Are there standalone utilities (like "learn" or "validate")? +| Job | Workflows | Reason | +|-----|-----------|--------| +| Twitter Ad Campaign | `analyze_and_propose` → `setup_approved_ads` | Human reviews proposed ads before setup | +| Customer Environment | `provision` → `teardown` | Distinct operations at different times | +| Quarterly Report | `gather_data` → `finalize_report` | Data gathering happens throughout quarter | -**When to use multiple workflows:** - -- **Different entry points**: A "quick_analysis" workflow might skip the deep research step -- **Standalone skills**: A "learn" step that can be run independently after any job execution -- **Different audiences**: A "detailed_report" workflow for executives vs. "quick_summary" for team standups -- **Optional phases**: Some workflows might include review/validation, others might skip it - -**Workflow definition format:** +**Format:** ```yaml workflows: - - name: full_analysis - summary: "Complete analysis with all steps" + - name: analyze_and_propose + summary: "Analyze trends and propose ad content" steps: - - identify - - research - - analyze - - report + - analyze_trends + - generate_proposals + - build_report - - name: quick_summary - summary: "Rapid analysis skipping deep research" + - name: setup_approved_ads + summary: "Create approved ads on platform" steps: - - identify - - analyze - - report + - setup_ads ``` -**Single workflow jobs:** - -If the job has only one workflow (the most common case), you can either: -1. Define it explicitly in the `workflows` section -2. Omit the `workflows` section entirely (all steps form the implicit workflow) - -**Exposed steps:** - -Steps marked with `exposed: true` can be invoked directly without running their dependencies. These are useful for standalone utilities like "learn" that can run anytime. +If the job has only one workflow (most common), you can omit the `workflows` section entirely. -```yaml -steps: - - id: learn - name: "Learn from Execution" - exposed: true # Can be run directly via /job_name.learn - ... -``` - -### Step 3: Validate the Workflow(s) +### Step 3: Validate the Workflow -After gathering information about all steps and workflows: +After gathering information about all steps: -1. **Review the flow(s)** - - Summarize each complete workflow +1. **Review the flow** + - Summarize the complete workflow - Show how outputs from one step feed into the next - Ask if anything is missing @@ -266,14 +240,12 @@ After gathering information about all steps and workflows: - Are there any steps where the input isn't clearly defined? - Are there any outputs that aren't used by later steps? - Are there circular dependencies? - - Do all workflows reference valid step IDs? 3. **Confirm details** - Job name (lowercase, underscores, descriptive) - Job summary (one clear sentence, max 200 chars) - Job description (detailed multi-line explanation) - Version number (start with 1.0.0) - - Workflow names and their step sequences (if multiple workflows) ### Step 4: Define Quality Validation (Stop Hooks) @@ -413,70 +385,36 @@ Claude: Great. Now for the "Research each one" step: [After gathering all information:] -Claude: Now let's think about how these steps should be organized into workflows. Are there different ways you might want to use these steps? - -For example: -- A full analysis that goes through all steps? -- A quick version that skips some steps? -- Any steps that should be available to run independently? - -User: Yes, I'd like a full workflow for complete analysis, but also a quick workflow that just identifies competitors and goes straight to a summary. Also, I sometimes want to just refresh the research on existing competitors without re-identifying them. - -Claude: Great! So we have three workflows: - -1. **full_analysis** - Complete workflow: identify → research → comparative_analysis → positioning_recommendations -2. **quick_summary** - Fast workflow: identify → positioning_recommendations (skip deep research) -3. **refresh_research** - Update existing: research → comparative_analysis → positioning_recommendations - -Let me summarize the complete job I've designed: +Claude: Let me summarize the workflow I've designed: **Job: competitive_research** Summary: Systematic competitive analysis workflow for product positioning Description: -A comprehensive workflow for analyzing competitors in your market segment. This job helps product teams understand the competitive landscape by systematically identifying competitors, researching their offerings, creating comparison matrices, and developing strategic positioning recommendations. - -The workflow produces: -- A vetted list of key competitors -- Detailed research notes on each competitor -- A comparison matrix highlighting key differentiators -- Strategic positioning recommendations - -Designed for product teams conducting quarterly competitive analysis. - -**Workflows:** - -1. **full_analysis** - Complete analysis with all steps - - identify_competitors → research_competitors → comparative_analysis → positioning_recommendations - -2. **quick_summary** - Rapid analysis skipping deep research - - identify_competitors → positioning_recommendations - -3. **refresh_research** - Update research on existing competitors - - research_competitors → comparative_analysis → positioning_recommendations +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. **Steps:** -Step 1: identify_competitors -- Input: market_segment (user), product_category (user) -- Output: competitors_list.md (5-7 competitors with descriptions) +1. **identify_competitors** + - Input: market_segment (user), product_category (user) + - Output: competitive_research/competitors_list.md -Step 2: research_competitors -- Input: competitors_list.md (from step 1) -- Output: research_notes.md (detailed findings for each competitor) -- Depends on: identify_competitors +2. **research_competitors** + - Input: competitors_list.md (from step 1) + - Output: competitive_research/research_notes.md + - Depends on: identify_competitors -Step 3: comparative_analysis -- Input: research_notes.md (from step 2) -- Output: comparison_matrix.md (side-by-side analysis) -- Depends on: research_competitors +3. **comparative_analysis** + - Input: research_notes.md (from step 2) + - Output: competitive_research/comparison_matrix.md + - Depends on: research_competitors -Step 4: positioning_recommendations -- Input: comparison_matrix.md (from step 3) -- Output: positioning_report.md (strategic recommendations) -- Depends on: comparative_analysis +4. **positioning_recommendations** + - Input: comparison_matrix.md (from step 3) + - Output: competitive_research/positioning_report.md + - Depends on: comparative_analysis -Does this accurately capture your workflow? Any changes needed? +Does this accurately capture your workflow? User: Yes, that's perfect! From 87b309a7bd59d98e462eb40c2508a314ca0a6e0f Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 30 Jan 2026 19:43:12 +0000 Subject: [PATCH 5/5] refactor: Move multi-workflow guidance into Capability Considerations Demote from separate "Step 2.5" to a brief note alongside Browser Automation in the existing Capability Considerations section. https://claude.ai/code/session_01Mr1h2fVSKeVP84FDWXx4UM --- .claude/skills/deepwork_jobs.define/SKILL.md | 35 +------------------ .deepwork/jobs/deepwork_jobs/steps/define.md | 35 +------------------ .gemini/skills/deepwork_jobs/define.toml | 35 +------------------ .../deepwork_jobs/steps/define.md | 35 +------------------ 4 files changed, 4 insertions(+), 136 deletions(-) diff --git a/.claude/skills/deepwork_jobs.define/SKILL.md b/.claude/skills/deepwork_jobs.define/SKILL.md index 950bd910..7adc5778 100644 --- a/.claude/skills/deepwork_jobs.define/SKILL.md +++ b/.claude/skills/deepwork_jobs.define/SKILL.md @@ -212,40 +212,7 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 2.5: Consider Multiple Workflows - -A job can define **multiple workflows** when different parts of the work need to happen at different points in time. Most jobs have a single workflow, but consider multiple workflows when: - -- **Human review/approval gates**: Some steps produce output that needs human review before proceeding. Split into separate workflows so users can run the second part after review. -- **Setup/teardown patterns**: Provisioning resources and later destroying them are distinct operations. -- **Phased execution**: Steps that naturally happen days or weeks apart. - -**Examples:** - -| Job | Workflows | Reason | -|-----|-----------|--------| -| Twitter Ad Campaign | `analyze_and_propose` → `setup_approved_ads` | Human reviews proposed ads before setup | -| Customer Environment | `provision` → `teardown` | Distinct operations at different times | -| Quarterly Report | `gather_data` → `finalize_report` | Data gathering happens throughout quarter | - -**Format:** - -```yaml -workflows: - - name: analyze_and_propose - summary: "Analyze trends and propose ad content" - steps: - - analyze_trends - - generate_proposals - - build_report - - - name: setup_approved_ads - summary: "Create approved ads on platform" - steps: - - setup_ads -``` - -If the job has only one workflow (most common), you can omit the `workflows` section entirely. +**Multiple Workflows**: Most jobs have a single workflow, but consider defining multiple workflows when different parts need to happen at different points in time—for example, an analysis workflow that produces a report for human review, then a separate execution workflow to act on approved items. Other examples: `provision` + `teardown` for environment management, or `gather_data` + `finalize_report` for phased work. If the job needs multiple workflows, define them in a `workflows` section in job.yml. ### Step 3: Validate the Workflow diff --git a/.deepwork/jobs/deepwork_jobs/steps/define.md b/.deepwork/jobs/deepwork_jobs/steps/define.md index ba49491b..11f7b41f 100644 --- a/.deepwork/jobs/deepwork_jobs/steps/define.md +++ b/.deepwork/jobs/deepwork_jobs/steps/define.md @@ -192,40 +192,7 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 2.5: Consider Multiple Workflows - -A job can define **multiple workflows** when different parts of the work need to happen at different points in time. Most jobs have a single workflow, but consider multiple workflows when: - -- **Human review/approval gates**: Some steps produce output that needs human review before proceeding. Split into separate workflows so users can run the second part after review. -- **Setup/teardown patterns**: Provisioning resources and later destroying them are distinct operations. -- **Phased execution**: Steps that naturally happen days or weeks apart. - -**Examples:** - -| Job | Workflows | Reason | -|-----|-----------|--------| -| Twitter Ad Campaign | `analyze_and_propose` → `setup_approved_ads` | Human reviews proposed ads before setup | -| Customer Environment | `provision` → `teardown` | Distinct operations at different times | -| Quarterly Report | `gather_data` → `finalize_report` | Data gathering happens throughout quarter | - -**Format:** - -```yaml -workflows: - - name: analyze_and_propose - summary: "Analyze trends and propose ad content" - steps: - - analyze_trends - - generate_proposals - - build_report - - - name: setup_approved_ads - summary: "Create approved ads on platform" - steps: - - setup_ads -``` - -If the job has only one workflow (most common), you can omit the `workflows` section entirely. +**Multiple Workflows**: Most jobs have a single workflow, but consider defining multiple workflows when different parts need to happen at different points in time—for example, an analysis workflow that produces a report for human review, then a separate execution workflow to act on approved items. Other examples: `provision` + `teardown` for environment management, or `gather_data` + `finalize_report` for phased work. If the job needs multiple workflows, define them in a `workflows` section in job.yml. ### Step 3: Validate the Workflow diff --git a/.gemini/skills/deepwork_jobs/define.toml b/.gemini/skills/deepwork_jobs/define.toml index 2c7631fc..28458dcb 100644 --- a/.gemini/skills/deepwork_jobs/define.toml +++ b/.gemini/skills/deepwork_jobs/define.toml @@ -212,40 +212,7 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 2.5: Consider Multiple Workflows - -A job can define **multiple workflows** when different parts of the work need to happen at different points in time. Most jobs have a single workflow, but consider multiple workflows when: - -- **Human review/approval gates**: Some steps produce output that needs human review before proceeding. Split into separate workflows so users can run the second part after review. -- **Setup/teardown patterns**: Provisioning resources and later destroying them are distinct operations. -- **Phased execution**: Steps that naturally happen days or weeks apart. - -**Examples:** - -| Job | Workflows | Reason | -|-----|-----------|--------| -| Twitter Ad Campaign | `analyze_and_propose` → `setup_approved_ads` | Human reviews proposed ads before setup | -| Customer Environment | `provision` → `teardown` | Distinct operations at different times | -| Quarterly Report | `gather_data` → `finalize_report` | Data gathering happens throughout quarter | - -**Format:** - -```yaml -workflows: - - name: analyze_and_propose - summary: "Analyze trends and propose ad content" - steps: - - analyze_trends - - generate_proposals - - build_report - - - name: setup_approved_ads - summary: "Create approved ads on platform" - steps: - - setup_ads -``` - -If the job has only one workflow (most common), you can omit the `workflows` section entirely. +**Multiple Workflows**: Most jobs have a single workflow, but consider defining multiple workflows when different parts need to happen at different points in time—for example, an analysis workflow that produces a report for human review, then a separate execution workflow to act on approved items. Other examples: `provision` + `teardown` for environment management, or `gather_data` + `finalize_report` for phased work. If the job needs multiple workflows, define them in a `workflows` section in job.yml. ### Step 3: Validate the Workflow diff --git a/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md b/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md index ba49491b..11f7b41f 100644 --- a/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md +++ b/src/deepwork/standard_jobs/deepwork_jobs/steps/define.md @@ -192,40 +192,7 @@ When defining steps, identify any that require specialized tools: **Browser Automation**: If any step involves web scraping, form filling, interactive browsing, UI testing, or research requiring website visits, ask the user what browser tools they have available. For Claude Code users, **Claude in Chrome** (Anthropic's browser extension) has been tested with DeepWork and is recommended for new users. Don't assume a default—confirm the tool before designing browser-dependent steps. -### Step 2.5: Consider Multiple Workflows - -A job can define **multiple workflows** when different parts of the work need to happen at different points in time. Most jobs have a single workflow, but consider multiple workflows when: - -- **Human review/approval gates**: Some steps produce output that needs human review before proceeding. Split into separate workflows so users can run the second part after review. -- **Setup/teardown patterns**: Provisioning resources and later destroying them are distinct operations. -- **Phased execution**: Steps that naturally happen days or weeks apart. - -**Examples:** - -| Job | Workflows | Reason | -|-----|-----------|--------| -| Twitter Ad Campaign | `analyze_and_propose` → `setup_approved_ads` | Human reviews proposed ads before setup | -| Customer Environment | `provision` → `teardown` | Distinct operations at different times | -| Quarterly Report | `gather_data` → `finalize_report` | Data gathering happens throughout quarter | - -**Format:** - -```yaml -workflows: - - name: analyze_and_propose - summary: "Analyze trends and propose ad content" - steps: - - analyze_trends - - generate_proposals - - build_report - - - name: setup_approved_ads - summary: "Create approved ads on platform" - steps: - - setup_ads -``` - -If the job has only one workflow (most common), you can omit the `workflows` section entirely. +**Multiple Workflows**: Most jobs have a single workflow, but consider defining multiple workflows when different parts need to happen at different points in time—for example, an analysis workflow that produces a report for human review, then a separate execution workflow to act on approved items. Other examples: `provision` + `teardown` for environment management, or `gather_data` + `finalize_report` for phased work. If the job needs multiple workflows, define them in a `workflows` section in job.yml. ### Step 3: Validate the Workflow