How shimanto008/midjourney-automation-tool works
1. Repository shape
This is a very small, single-purpose desktop automation repo. The visible runtime is essentially one Python application, mid_journey_automation.py, plus a packaged Windows executable, mid_journey_automation.exe. There are no separate services, libraries, or submodules in the tree.
2. Deployment model
The app is designed to run locally on Windows as a standalone tool. The .exe suggests the Python program has been bundled for distribution so end users do not need Python installed. Architecturally, this is a monolithic client-side utility, not a networked system.
3. Primary user workflow
The user supplies a DOCX file containing MidJourney prompts, configures automation settings in the app UI, starts the process, then switches focus to the MidJourney window. The tool then takes over input automation until the prompt set is exhausted or the user stops it.
4. Input ingestion boundary
The main external input is the DOCX prompt document. The README also mentions automatic CSV export, so the document likely passes through a conversion/parsing step before being consumed by the automation pipeline. In diagram terms, the DOCX file is the inbound data source feeding the app.
5. Prompt processing pipeline
Prompts are likely normalized into an internal queue or list, then grouped according to batch settings. The batch mode described in the README implies the app can send prompts in chunks with pauses between chunks, which is an important scheduling boundary in the architecture.
6. Automation engine
The core behavior is keyboard/mouse automation against the MidJourney UI. The app does not talk to MidJourney through an API; it interacts with the active desktop window by typing prompts and clicking into the text input. This makes the MidJourney application itself the main external runtime dependency.
7. Control and pacing subsystem
The tool exposes runtime controls such as typing speed, delay tuning, pause/resume, and batch size. These settings affect how the automation engine emits keystrokes and when it pauses. This subsystem is the primary difference between “prompt list processing” and “actual automation execution.”
8. Safety and interruption path
The README describes an emergency stop by moving the mouse to the top-left corner, which strongly suggests a global fail-safe built into the automation layer. That means the app has an interrupt path that can preempt the typing/clicking loop outside the normal UI controls.
9. Progress and state tracking
Progress tracking is called out as a feature, so the app probably maintains internal state about current prompt index, batch position, and running/paused status. That state is surfaced back to the UI so the user can see how far the automation has progressed.
10. Important architectural boundary
The most important boundary is between the local automation app and the external MidJourney window. Everything inside the repo is about preparing prompts, pacing them, and controlling execution; the actual image-generation work happens entirely outside the repo in MidJourney.
11. What to draw in an architecture diagram
A good diagram would show: user selects DOCX -> app parses/converts prompts -> internal queue/batching/controller -> keyboard/mouse automation -> MidJourney desktop window. Side paths should show settings input into the controller, progress state back to the UI, and a fail-safe/stop path interrupting the automation loop.
Main entry points: mid_journey_automation.py Automation App · mid_journey_automation.exe Windows EXE
Components 12
Local Tool
Standalone Windows automation app and its internal control flow.
- Windows EXE · Bundled standalone executable for Windows distribution.
mid_journey_automation.exe - Automation App · Main application entrypoint that coordinates prompt processing and desktop automation.
mid_journey_automation.py - Controls UI · User-facing configuration for speed, delay, batch size, and run state.
- Prompt Parser · Reads the DOCX input and converts prompts into internal records.
- Prompt Queue · Normalized prompt list ready for ordered execution.
- Batch Scheduler · Groups prompts into batches and inserts pauses between chunks.
- Automation Engine · Types prompts and clicks into the active MidJourney window.
- Progress State · Tracks current prompt, batch position, and running or paused status.
- Fail-safe Stop · Emergency interruption that can preempt the automation loop.
External
Inputs and runtime dependencies outside the repository.
- User · Starts the workflow, configures automation, and can pause or stop execution.
- DOCX Prompts · Source document containing MidJourney prompts.
- MidJourney App · External MidJourney window that receives automated typing and clicks.
Connections 14
- User → Controls UI: configures · User sets speed, delay, batching, and run controls.
- User → DOCX Prompts: supplies · User provides the prompt document.
- DOCX Prompts → Prompt Parser: ingested by · DOCX content is parsed into prompts.
- Automation App → Prompt Parser: runs · Application coordinates document ingestion.
- Prompt Parser → Prompt Queue: normalizes · Parsed prompts are assembled into an internal queue.
- Prompt Queue → Batch Scheduler: feeds · Queue entries are scheduled in batches.
- Controls UI → Batch Scheduler: tunes · User settings affect pacing and batch size.
- Batch Scheduler → Automation Engine: dispatches · Batched prompts are handed to the automation layer.
- Automation Engine → MidJourney App: controls · Keystrokes and clicks are sent to the active desktop app.
- Automation Engine → Progress State: updates · Execution state advances as prompts are sent.
- Progress State → Controls UI: renders · Progress and running state are shown back in the UI.
- Fail-safe Stop → Automation Engine: interrupts · Emergency stop can abort the automation loop.
- User → Fail-safe Stop: triggers · User can stop or pause the run, including emergency interruption.
- Windows EXE → Automation App: bundles · Standalone executable distributes the Python application.