simon-factory-lights-out
Health Pass
- License — License: MIT
- Description — Repository has a description
- Active repo — Last push 0 days ago
- Community trust — 21 GitHub stars
Code Fail
- rm -rf — Recursive force deletion command in setup.sh
- rm -rf — Recursive force deletion command in src/hooks/install.sh
- process.env — Environment variable access in src/hooks/openclaw/sflo-pipeline/handler.ts
Permissions Pass
- Permissions — No dangerous permissions requested
This tool provides a gated pipeline protocol for building software using AI agents. It orchestrates multiple specialized agents through a five-stage quality assurance process, ensuring specific artifacts are produced at each step before the software is shipped.
Security Assessment
The overall risk is High. The installation process relies on cloning a repository and executing a `setup.sh` script, which is inherently risky. The automated scan confirms severe issues: there are recursive force deletion commands (`rm -rf`) present in both the main `setup.sh` and a secondary installation hook. Running these scripts could aggressively delete critical files if path variables are mishandled or malicious. Additionally, the tool accesses environment variables, meaning it could potentially expose sensitive local data or API keys to its language model components. There is a significant risk of arbitrary shell execution.
Quality Assessment
The project has a strong foundation for an early-stage open-source tool. It is actively maintained (last updated today), uses a standard permissive MIT license, and has a clear, detailed description. However, community trust and adoption are currently minimal, indicated by a low star count of 21.
Verdict
Not recommended due to dangerous recursive deletion commands found in its automated setup scripts, which pose an unacceptable risk to the host system without a careful manual code review prior to execution.
SFLO — Simon Factory Lights Out: a gated pipeline protocol for building software with AI agents
SFLO — Simon Factory Lights Out
A gated pipeline protocol for building software with AI agents. Five gates — each producing a required artifact. No artifact, no progress. No skipping.
flowchart LR
G1["Gate 1<br/>DISCOVER<br/><br/>PM Agent<br/>SCOPE.md"] --> DEV_QA
subgraph DEV_QA ["Inner Loop — max 10 rounds"]
G2["Gate 2<br/>BUILD<br/><br/>Dev Agent<br/>BUILD-STATUS.md"] --> G3["Gate 3<br/>TEST<br/><br/>QA Agent<br/>QA-REPORT.md"]
G3 -- "below threshold" --> G2
end
DEV_QA -- "meets threshold" --> G4["Gate 4<br/>VERIFY<br/><br/>PM Agent<br/>PM-VERIFY.md"]
G4 -- "not A" --> DEV_QA
G4 -- "A" --> G5["Gate 5<br/>SHIP<br/><br/>SFLO Agent<br/>SHIP-DECISION.md"]
Install
If you want to use v1 (no code) - get it from here
Latest version install
Tell your AI agent:
Install SFLO from https://github.com/simonasrazm/simon-factory-lights-out
The agent will clone the repo, run setup.sh, install the pipeline hook, and configure bindings. After a gateway restart (OpenClaw) or new session (Claude Code), SFLO is ready.
Usage
Say "SFLO: [describe what to build]" to start the pipeline. Examples:
- "SFLO: build a job board website with search and filters"
- "SFLO: create a CLI tool that scans code for vulnerabilities"
The pipeline runs automatically — Scout picks the right agents, gates enforce quality, hooks keep it moving until done or escalated.
Agents
Gates define what to produce. Agents define how. Each agent is a directory with a SOUL.md (methodology) and a BRIEF.md (one-paragraph description for Scout matching). See docs/agent-spec.md for the spec.
How Scout picks agents
On user prompt, Scout scans agents/ directory and reads each BRIEF.md to understand what the agent specializes in. It then matches agents to pipeline roles based on the user's prompt. Scout is an LLM agent.
flowchart TD
P["User prompt:<br/>'Build a weather dashboard'"] --> S["Scout reads prompt"]
S --> SCAN["Scans agent directories"]
SCAN --> B1["agents/pm/BRIEF.md<br/>'Generic PM for any project'"]
SCAN --> B2["agents/pm-website/BRIEF.md<br/>'PM specialized for web apps.<br/>Web-specific acceptance criteria.'"]
SCAN --> B3["agents/pm-mobile/BRIEF.md<br/>'PM for mobile apps. Platform-specific<br/>criteria for iOS and Android.'"]
B1 --> MATCH{"Match prompt<br/>to role"}
B2 --> MATCH
B3 --> MATCH
MATCH -- "web app → pm-website" --> A["PM: agents/pm-website"]
MATCH -- "no match → generic" --> G["PM: agents/pm"]
Example: When the prompt says "build a weather dashboard," Scout reads all BRIEF.md files, sees that pm-website specializes in web apps, and assigns it as PM. If no better agent matches, Scout falls back to the generic agent (agents/pm).
Adding your own agents
Create a directory with two files:
agents/
my-pm-agent/
BRIEF.md ← one paragraph, tells Scout when to use this agent
SOUL.md ← full methodology, read by the agent at runtime
Scout will discover your agent automatically on the next pipeline run — no configuration needed.
Configuration
SFLO is config-driven via pipeline.yaml. The default pipeline is bundled with SFLO, but you can override it by placing your own pipeline.yaml in your project root.
# project-root/pipeline.yaml
threshold: A- # Raise the quality bar
guardian:
enabled: true # Enable safety limits
max_spawns: 30 # Max agent spawns before escalating
gates:
1:
artifact: SCOPE.md
role: pm
gate_doc: sflo/gates/discovery.md
# Add custom gates by inserting float keys, e.g. 1.5 for an architecture gate
See sflo/pipeline.yaml for the full default configuration with all options documented.
Contributing
See CONTRIBUTING.md.
License
Reviews (0)
Sign in to leave a review.
Leave a reviewNo results found