Problem
Data Machine Code currently carries several Homeboy-specific seams directly in core because they were useful pragmatically:
DataMachineCode\\Homeboy availability detection.
- Homeboy guidance injected into generated
AGENTS.md.
datamachine-code/run-pr-homeboy-review and PrHomeboyReviewRunner.
- Homeboy CI artifact compatibility helpers such as
datamachine/get-github-homeboy-ci-results.
- Homeboy-specific parsing/summarization for GitHub Actions artifacts.
These are useful integrations, but they are not core DMC architecture. DMC core should own workspaces/worktrees, GitHub primitives, artifact egress, ability/tool registration, and command execution policy. Homeboy behavior should be an optional integration layer.
Proposed Direction
Create a dedicated Homeboy integration plugin/package, e.g. data-machine-code-homeboy, that owns:
- Homeboy CLI availability detection.
- Homeboy
AGENTS.md prompt contribution.
- Homeboy review abilities/tools.
- Homeboy CI artifact parsing and compatibility wrappers.
- Future bridges between Homeboy workflows and Sandbox Runtime where appropriate.
DMC core should expose generic extension points for these integrations rather than hardcoding Homeboy concepts.
Migration Shape
- Inventory current Homeboy-specific symbols, abilities, tools, and prompt sections in DMC.
- Add/confirm generic extension points for AGENTS.md sections, abilities/tools, and artifact parsers.
- Move Homeboy-specific registration into the dedicated integration package.
- Keep compatibility aliases or wrappers during transition so existing agents/tools do not break abruptly.
- Document the split: DMC core is the workspace/GitHub/control-plane substrate; Homeboy is an optional CI/operator integration.
Why Now
Sandbox Runtime is becoming its own portable execution substrate. DMC will likely grow additional integrations (sandbox-runtime, Studio, wp-gym, etc.). Keeping Homeboy-specific code in DMC core sets the wrong precedent; extracting it makes future integrations cleaner.
Acceptance Criteria
- Homeboy-specific abilities/tools/prompt text can be disabled or absent without changing DMC core behavior.
- DMC core no longer needs a Homeboy-specific helper class for prompt/ability registration.
- Existing Homeboy workflows have a documented compatibility path.
- Tests cover the generic extension points and the Homeboy integration registration path.
Problem
Data Machine Code currently carries several Homeboy-specific seams directly in core because they were useful pragmatically:
DataMachineCode\\Homeboyavailability detection.AGENTS.md.datamachine-code/run-pr-homeboy-reviewandPrHomeboyReviewRunner.datamachine/get-github-homeboy-ci-results.These are useful integrations, but they are not core DMC architecture. DMC core should own workspaces/worktrees, GitHub primitives, artifact egress, ability/tool registration, and command execution policy. Homeboy behavior should be an optional integration layer.
Proposed Direction
Create a dedicated Homeboy integration plugin/package, e.g.
data-machine-code-homeboy, that owns:AGENTS.mdprompt contribution.DMC core should expose generic extension points for these integrations rather than hardcoding Homeboy concepts.
Migration Shape
Why Now
Sandbox Runtime is becoming its own portable execution substrate. DMC will likely grow additional integrations (
sandbox-runtime, Studio, wp-gym, etc.). Keeping Homeboy-specific code in DMC core sets the wrong precedent; extracting it makes future integrations cleaner.Acceptance Criteria