feat(library): add mech_engineer library job

library/jobs/README.md

@@ -4,7 +4,7 @@ DeepWork includes a library of reusable jobs that any project can adopt. These a
 
 ## Enabling Shared Jobs
 
-The fastest way to add shared jobs to your project is with the `/deepwork` skill:
+Requires the DeepWork plugin installed in your AI agent CLI. The fastest way to add shared jobs to your project is with the `/deepwork` skill:
 
 ```
 /deepwork shared_jobs
@@ -16,6 +16,8 @@ This walks you through configuring `DEEPWORK_ADDITIONAL_JOBS_FOLDERS` so the Dee
 
 | Job | Description |
 |-----|-------------|
+| [Engineer](./engineer) | Domain-agnostic engineering execution from product issue through PR merge and product sync, with TDD discipline |
+| [Mech Engineer](./mech_engineer) | Design mechanical assemblies and parts with OTS sourcing, manufacturing method recommendations, BOM generation, and multi-scale production evaluation |
 | [Research](./research) | Multi-workflow research suite — deep investigation, quick summaries, material ingestion, and reproduction planning |
 | [Platform Engineer](./platform_engineer) | Incident response, observability, CI/CD, releases, security, cost management, and infrastructure |
 | [Repo](./repo) | Audit and configure repositories — labels, branch protection, milestones, and boards |
@@ -68,6 +70,18 @@ Each job in this library follows the same structure as the `.deepwork/jobs` subf
 library/jobs/
 ├── .deepreview              # Review rules for library job quality
 ├── README.md
+├── engineer/                # Domain-agnostic engineering execution (TDD, PR lifecycle)
+│   ├── job.yml
+│   ├── AGENTS.md
+│   ├── requirements.md
+│   └── steps/
+├── mech_engineer/           # Mechanical assembly and part design workflows
+│   ├── job.yml
+│   ├── AGENTS.md
+│   ├── hooks/
+│   ├── scripts/
+│   ├── steps/
+│   └── templates/
 ├── platform_engineer/       # Platform engineering workflows
 │   ├── job.yml
 │   ├── AGENTS.md            # Agent context and learnings
@@ -155,7 +169,7 @@ Each step has a markdown file with detailed instructions that guide the AI agent
 
 1. Browse the jobs in this directory
 2. Copy the job folder to your project's `.deepwork/jobs/` directory
-3. Run `/deepwork` to start the job — the MCP server will discover it automatically
+3. Run `/deepwork` to start the job — the skill will prompt you to select the job and workflow, and the MCP server will discover it automatically
 
 ## Using Library Jobs via Nix Dev Shell
 
@@ -257,12 +271,7 @@ git checkout -b improve/repo-job-step-name
 
 2. Make your changes to the library job files
 
-3. Run the portability review to ensure your changes are portable:
-
-```bash
-# From the upstream checkout
-/deepwork:review
-```
+3. Run the portability review to ensure your changes are portable. From inside the upstream checkout, invoke the `/deepwork:review` skill in your AI agent CLI.
 
 The `library_job_portability` review rule checks for hardcoded paths, personal information, platform-specific assumptions, and schema compliance. All library job changes must pass this review before submitting a PR.
 

library/jobs/mech_engineer/.deepreview

@@ -0,0 +1,73 @@
+job_definition_review:
+  description: "Review job.yml and step instructions for correctness, completeness, and coherence as a holistic workflow."
+  match:
+    include:
+      - "job.yml"
+      - "steps/*.md"
+  review:
+    strategy: matches_together
+    instructions: |
+      Review this DeepWork job definition (job.yml) and its step instruction files (steps/*.md)
+      holistically. Check that they form a coherent, well-structured workflow that an AI agent
+      can execute reliably.
+
+      ## Reference Material
+
+      For reference on correct job structure and best practices, read the following files from your plugin:
+      - `job.yml.template` — canonical job.yml structure with all supported fields
+      - `job.yml.example` — a complete working example (competitive research job)
+      - `step_instruction.md.template` — expected structure for step instruction files
+      - `research_report_job_best_practices.md` — design patterns for report-type jobs
+
+      ## What to Check
+
+      ### 1. job.yml Structure
+      - Has required fields: `name`, `version`, `summary`, `workflows`, `steps`
+      - `name` is lowercase with underscores only
+      - `summary` is concise (under 200 characters) and descriptive enough to let a user know what the job does
+      - `version` follows semantic versioning (e.g., "1.0.0")
+      - `common_job_info_provided_to_all_steps_at_runtime` provides useful shared context (problem domain, terminology, conventions, constraints)
+
+      ### 2. Workflow Coherence
+      - Each workflow's steps form a logical sequence toward a clear goal
+      - Step dependencies are declared correctly (no missing or extraneous deps)
+      - No circular dependencies exist
+
+      ### 3. Input/Output Chain
+      - Each step has at least one output
+      - File inputs reference outputs from steps listed in that step's dependencies
+      - `from_step` values match actual step IDs that produce the referenced file
+      - The output chain creates a logical data flow through the workflow
+      - Intermediate outputs that are not meant to be persisted should be in .deepwork/tmp
+      - Final outputs follow project conventions (not hidden in dot-directories, descriptive names, appropriate use of subdirectories)
+
+      ### 4. Step Instructions Match job.yml
+      - Every step defined in job.yml has a corresponding instruction file
+      - Step instruction content aligns with the step's described purpose
+      - Instructions reference the correct input and output filenames from job.yml
+      - Instructions do not duplicate content already in `common_job_info_provided_to_all_steps_at_runtime`
+      - If there is duplicated content amongst the instruction files, it should be moved to `common_job_info_provided_to_all_steps_at_runtime` and removed from the instruction files
+
+      ### 5. Quality Reviews
+      - Steps with complex or final outputs have reviews defined
+      - `run_each` values reference valid output names or `step`
+      - Quality criteria are statements of expected state, not questions
+      - `additional_review_guidance` is used when reviewers need context beyond the step's own output files (e.g., cross-referencing prior step outputs)
+
+      ### 6. Step Instruction Quality
+      - Each instruction file follows the structure and section headings defined in
+        `step_instruction.md.template` for this job type.
+      - The sections clearly communicate: what the step is trying to achieve,
+        what the agent should do, what to produce (including format/examples),
+        and how quality will be evaluated.
+      - Instructions are specific and actionable, not generic placeholders
+      - Output format sections show what good output looks like (examples or templates)
+      - If the step gathers user input, instructions mention using structured questions (e.g., the AskUserQuestion tool)
+      - Instructions explain how to use file inputs from prior steps and how the step's outputs will be consumed by later steps.
+
+      ## Output Format
+
+      - PASS: The job definition and step instructions are coherent and well-structured.
+      - FAIL: List each issue with the specific file, the problem, and a suggested fix.
+    additional_context:
+      unchanged_matching_files: true

library/jobs/mech_engineer/AGENTS.md

@@ -0,0 +1,49 @@
+# Project Context for mech_engineer
+
+## Location
+
+This job lives in `library/jobs/mech_engineer/`.
+It is a library job — available for users to adopt but not auto-installed by the DeepWork runtime.
+
+## File Organization
+
+```
+mech_engineer/
+├── AGENTS.md              # This file (source of truth)
+├── CLAUDE.md -> AGENTS.md # Symlink — Claude Code reads this
+├── job.yml                # Job definition
+└── steps/
+    ├── define_assembly_requirements.md
+    ├── source_ots_components.md
+    ├── design_custom_parts.md
+    ├── generate_bom.md
+    ├── evaluate_manufacturability.md
+    ├── define_part_spec.md
+    ├── select_manufacturing_method.md
+    ├── document_part.md
+    ├── define_ots_requirements.md
+    ├── research_ots_options.md
+    ├── select_ots_part.md
+    ├── load_assembly_bom.md
+    └── run_scale_analysis.md
+```
+
+## Workflows
+
+- **design_assembly**: Full assembly design from requirements through scale evaluation (5 steps)
+- **design_part**: Single custom part spec, manufacturing method selection, and datasheet (3 steps)
+- **source_ots_parts**: OTS component requirements, research, and selection (3 steps)
+- **evaluate_at_scale**: Load an existing BOM and run multi-scale production analysis (2 steps)
+
+## Design Decisions
+
+1. **Manufacturing method table in common_job_info**: All process/scale tradeoff context lives in `job.yml` so steps don't duplicate it
+2. **OTS-first**: `source_ots_components` runs before `design_custom_parts` to minimize unnecessary custom fabrication
+3. **Shared scale tiers**: Prototype / small batch / production definitions are canonical across all workflows
+4. **`.deepwork/tmp/` for tracking files**: Final deliverables are written to `mech_design/{project_name}/` by step instructions; `.deepwork/tmp/` files are workflow tracking artifacts
+5. **`evaluate_at_scale` is standalone**: Allows re-evaluating any existing BOM without re-running the full design workflow
+6. **CAD Toolchain Adaptation table**: A Toolchain Adaptation table in `common_job_info` maps generic concepts (model source file, build command, model registry) to tool-specific equivalents (AnchorSCAD, OpenSCAD, FreeCAD, etc.). Steps MUST reference the target repo's `AGENTS.md` for toolchain details — do NOT hardcode STL/STEP paths. STL is a build artifact, not a source file.
+
+## Project Context
+
+Read the target repo's `AGENTS.md` or `CLAUDE.md` to discover the CAD toolchain, build command, and model registry. Apply the Toolchain Adaptation table from `job.yml` accordingly.

library/jobs/mech_engineer/CLAUDE.md

@@ -0,0 +1 @@
+AGENTS.md