Display the Dark Factory pipeline node graphs — spec-review pipelines, factory gates, node types, edge conditions, and handler mappings. Use /factory-spec or /fs to quickly reference the spec graph structure without running a pipeline.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
factory-spec
description
Display the Dark Factory pipeline node graphs — spec-review pipelines, factory gates, node types, edge conditions, and handler mappings. Use /factory-spec or /fs to quickly reference the spec graph structure without running a pipeline.
/factory_spec — Dark Factory Spec Node Graph Reference
Install vs source
Dark Factory runs via the dark-factory binary, not python -m runner from
a raw checkout:
custom goal + delete-first rules; often minimal_feature.dot or custom .dot
Short names for --pipeline: gates, hello, pr_gates, minimal_pr,
minimal_feature, review_slim, review_full.
Execution command (from target repo cwd):
export PATH="$HOME/.local/bin:$PATH"
dark-factory --pipeline pipelines/slim/minimal_pr.dot --goal "..." --backend claude
Purpose
Show the factory pipeline graph structure at a glance — node types, edges,
conditions, and handler mappings — without running a pipeline. Use this when
you need to remember what nodes exist, what the wiring looks like, or which
pipeline to pick for a given goal.
Step 0 (MANDATORY): classify the task — Brownfield vs Greenfield
Before picking a pipeline or writing the spec/goal, decide which kind of change this is.
Getting this wrong is the #1 cause of a factory run that reaches exit/success while
certifying the wrong thing. (Real failure 2026-05-30: a replace-the-backend-override
task was run with a greenfield additive pipeline → the override was never deleted, a parallel
mechanism was bolted on top, net LOC was +2507/−54, and an unwired Pydantic model passed
test_e2e as dead code.)
Greenfield — new behavior from scratch (net-additive)
Use the standard pipelines (hello.dot, minimal_feature.dot, review_*.dot):
plan → implement → test → review → holdout → gates. Net-positive LOC is expected.
The task removes or replaces a code path that already runs in production. A greenfield
pipeline is wrong here. Encode these rules in the spec, the --goal, and the DAG:
DELETE-FIRST ordering (not delete-last). The implement node must remove or replace
the old path as part of the build, and the behavior/test_llm node then proves the new
path works with the old one already gone. Never "add new alongside old → prove → delete
later": the deletion gets orphaned (no node executes it) and the proof is confounded
(the old path's fallback/passthrough can mask a weak new path, so green proves nothing).
Deletion needs an executor node — never a conditional. Do NOT write "(N) only AFTER the
proof, delete X" in a goal: nothing in the DAG runs a post-proof deletion, and resume
pipelines (test-onward) have no implement node at all. Make the deletion part of
implement/fix, or add an explicit node.
Net-LOC ≤ 0 guard. For replace/delete milestones, add a gate/acceptance check that
FAILS if net production LOC > 0 (the new code must displace at least as much as it adds).
See deletion-milestone skill.
Dead-code gate. Add a check that FAILS if a newly-added module/symbol is defined but
unreferenced in runtime (non-test). Otherwise a passing unit test makes test_e2e green
while the code is dead (e.g. a model class only instantiated in its own test).
Replace at the same call site. The new mechanism must be wired into the same call
site the old one used, and the old one removed in the same change — not added at a new
site while the old site still runs.
Prove against the post-deletion tree. The real-LLM / behavior test must execute with the
old path already deleted, so a green verdict cannot be produced by the old fallback.
Quick test: "If this milestone succeeds, should git diff show deletions of production
code?" If yes → brownfield → apply rules 1–6. If the planned diff is all additions for a
replace/delete goal, the pipeline is mis-shaped — STOP and re-architect delete-first.
Spec-Review Pipelines (Primary)
These are the Attractor-style spec-validation pipelines under
benchmarks/attractor-spec-review/pipelines/. The key innovation: an
independent cold reviewer (codex exec --yolo) that numbers every spec
line and returns strict JSON line-by-line findings.
Use when: in-flight PR iteration loop with parameterized test commands (--state slim.test_command="...") and evidence checks, bypassing behavioral holdout scenarios.
Handler type registry
Node type attr
Handler function
Behavior
codergen
_codergen
Render prompt template, dispatch to backend (claude/codex/ao/agy)
tool
_tool
Shell out to command="..." attribute
holdout_eval
_holdout_eval
Run sealed evaluator from $DARK_FACTORY_HOLDOUTS
gate_es
_gate_es
Shell out to claude --print /es
gate_er
_gate_er
Shell out to claude --print /er
gate_code_standards
_gate_code_standards
Shell out to claude --print /code_standards
human_gate
_human_gate
Block on stdin or use ctx.state["<node>.outcome"]
conditional
_conditional
Hexagon decision node; outcome from ctx.state[decision_key]
Shape-based handler fallback
DOT shape
Handler
Mdiamond
start
Msquare
exit
hexagon
conditional
Edge condition syntax
condition="key=value" — matches ctx.state[key] == value
condition="key!=value" — matches ctx.state[key] != value
