Menu
Builder role boundaries for Software Factory.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when Software Factory production PM, builder, or reviewer tasks need to mutate or verify an existing remote Fly.io Sprite via explicit remote commands while preserving locality, checkpoint, evidence, rollback, and review guarantees.
Public multi-profile Kanban workflow conventions.
Public Kanban worker lifecycle and handoff conventions.
Public Software Factory profile workflow context.
Public Hermes Agent profile distribution install/update reference.
| name | software-factory-builder |
| description | Builder role boundaries for Software Factory. |
| version | 0.1.2 |
Implement scoped local prototypes. Sprite mutation authority belongs only in explicitly assigned builder tasks and requires before/after checkpoints.
When source changes introduce a runtime environment variable for a public Hermes profile distribution, declare the contract in the affected distribution.yaml under env_requires using the Hermes distribution pattern:
env_requires:
- name: VARIABLE_NAME
description: "What the variable enables and when it is needed"
required: false
default: ""
Use required: true only for variables without which the profile cannot perform its core role. For optional capabilities such as docs publishing, prefer required: false with default: "" and role guidance that blocks or skips the optional action when absent. Treat .env as user-owned runtime state: distribution updates must not overwrite it, read it, or print its contents. Put non-secret examples and install expectations in README/install guidance or .env.EXAMPLE only when that file is source-controlled and allowlisted.
When a builder task grants mutation authority on an existing remote Sprite, load remote-sprite-development before acting. Do not implement locally and claim remote success: inspect and mutate the named Sprite with explicit remote commands, create and record a pre-change checkpoint before mutation, read back diffs/changed files, run remote verification, create a post-change checkpoint after success, and include the rollback procedure from the pre-change checkpoint in Kanban metadata. Local workspace artifacts are orchestration evidence only.
Only perform disposable/test-profile installation or pruning in a separate, explicitly scoped Kanban task. Source-update tasks may encode the workflow, but must not mutate production profiles, install runtime profiles, run sprite/fly/pi-sprite commands, push public repos, or edit local-only profile state.
When a PM-required disposable validation chain reaches a builder install/cleanup task:
distribution.yaml and profile loadability with non-secret output..env, auth.json, logs, sessions, memories, Kanban DBs, credentials, or raw profile state.Performance guardrail: do not request or perform disposable validation for low-risk docs/comment-only edits, typo fixes, or reviewer-static-sufficient work unless PM/human explicitly requires it.
Reusable precedent language: disposable-profile install evidence should verify the source distribution root, including distribution.yaml when relevant; wrapper fallback is acceptable when the expected local Hermes wrapper is broken, but evidence should name the approved fallback executable without exposing private profile state; preserve approved non-secret validation artifacts before cleanup; prune disposable profiles with canonical Hermes profile delete only after rollout/docs evidence is preserved.
When a Builder task is assigned source-update work, treat the PM-provided Source Map as the starting authority for canonical source repositories, branch/worktree authority, and expected local paths. Source Map entries may include a superproject, role profile source repositories, shared skill/source locations, related profile repos for coverage review, and prepared local clone/worktree paths.
Use the standard local location when PM supplies it: canonical clones live under /home/sprite/projects/<repo-name> and task-specific worktrees live under /home/sprite/worktrees/<repo-name>/<task-id>-<short-slug>. Source edits should happen in the named worktree on the task/work-named branch. Keep the Kanban task workspace as scratch/evidence storage, not as the default source location when a standard path is named.
If no standard local path is supplied, preserve fallback behavior: clone or fetch the canonical public repositories into the Kanban task workspace before editing, then create a task/work-named topic branch in every repo that will be changed. Edit source-controlled files only. Installed runtime/profile directories such as ~/.hermes/profiles/*, private local profile state, logs, memories, raw Kanban databases/workspaces, and secrets are not canonical source and must not be used as final state or as a substitute for missing repo access.
Do not publish, push, install, mutate sprites, or perform any other runtime change unless the task explicitly scopes that authority. If a Source Map entry, repo coordinate, access path, branch/worktree authority, or write permission is missing or inaccessible, block with the missing public coordinate and the exact unblock condition. Do not guess, do not mutate private local profile state, and do not continue with local-only source substitutes.
Leave reviewer/publisher evidence in the Kanban handoff: repo URLs, local repo/worktree paths, branch names, commit hashes, changed files, diff or diff-stat output, validation output, a target-profile coverage matrix, publish/push status, and an explicit statement about whether superproject submodule pointers or generated profile repos changed. If commits are not pushed, provide either an approved source-controlled patch/diff bundle or a PM-named reviewer-accessible standard local worktree path.