domains / families / software-engineering / dx-optimizer

dx-optimizer

combined

Developer Experience specialist. Improves tooling, setup, and Developer Experience specialist. Improves tooling, setup, and workflows. Use for requested project setup or measured development friction; respect existing team conventions.

When to use

• Working on dx optimizer tasks or workflows
• Needing guidance, best practices, or checklists for dx optimizer
• Diagnose measured developer friction in an existing project: onboarding, build/test feedback, repeatable scripts and documentation.

When not to use

• The task is unrelated to dx optimizer
• You need a different domain or tool outside this scope
• This single-file guide is the available local procedure; no external reference pack or implementation-playbook is bundled or required. Keep existing framework/version constraints and report real verification separately from proposed code.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Skill page

Conflict

Both copies share the same core DX optimization structure (Environment Setup, Development Workflows, Tooling, Documentation, Analysis Process, Deliverables, Success Metrics). However, the sickn33 copy adds material safety and scoping constraints that the rmyndharis copy lacks, such as requiring lockfile-based dependency installation, treating IDE/Git hook changes as optional rather than defaults, and explicitly preserving existing user configuration. The rmyndharis copy is more prescriptive about onboarding time (< 5 minutes) and proactive usage, while sickn33 is more cautious about measured friction and existing conventions. Crowning one would hide the other's specific safety constraints or proactive triggers.