What this prompt does
This prompt builds a Python file watcher daemon that monitors [watch_directories] for [event_types] and triggers automated actions, sized for [file_volume] events per hour on [target_os]. It covers the whole reliability story: recursive watching with debouncing, an event-handler registry running in a thread pool, true daemon mode with signal handling and a systemd unit, a resumable processing pipeline, health monitoring, a management CLI, and rotating logs. Calling out editor temp files and atomic writes up front is what keeps the watcher from firing on phantom events.
The variables tune filtering and resilience. [watcher_library] and [filter_patterns] set what is watched, while [debounce_interval] batches rapid successive changes to the same file. [handler_mapping] and [thread_count] route file types to handlers that run without blocking the watcher, [daemon_method] and [pid_file_path] enable proper daemonization, and [state_storage] makes the [pipeline_steps] pipeline resumable after a crash. [metrics_endpoint] and [alert_threshold] provide unattended health visibility.
When to use it
- Picking up and processing files the moment they land in a directory.
- Filtering noisy filesystem events down to real changes with
[filter_patterns]and debouncing. - Routing different file types to different handlers via
[handler_mapping]. - Running as a real systemd daemon with signal handling rather than a fragile script.
- Building a resumable pipeline whose state survives crashes via
[state_storage]. - Exposing health metrics and alerting when a backlog exceeds
[alert_threshold].
Example output
You get a daemon implementation with code: a core watcher on [watcher_library] with recursive monitoring, [filter_patterns] include/exclude globs, and [debounce_interval] debouncing that handles editor temp files and atomic writes; a handler registry mapping file types per [handler_mapping], executing in a [thread_count]-worker pool; daemon mode via [daemon_method] with a PID file at [pid_file_path], SIGHUP reload, and a systemd unit; a resumable pipeline running [pipeline_steps] with state in [state_storage]; health monitoring exposed at [metrics_endpoint] alerting past [alert_threshold]; a management CLI; and rotating logs.
Pro tips
- Debounce with the
[debounce_interval]window; editors and atomic save-then-rename patterns fire multiple events per logical change. - Set
[filter_patterns]to exclude temp and lock files explicitly, or the daemon will chase.swpand~phantom files. - Run handlers in a
[thread_count]pool so a slow handler cannot block the watcher from seeing new events. - Persist pipeline state to
[state_storage]so an interrupted run resumes instead of reprocessing or dropping files. - Daemonize properly with
[daemon_method]and a PID lockfile so you do not accidentally run two watchers over the same[watch_directories]. - Alert when the backlog passes
[alert_threshold]; a silently growing queue is how unattended automation fails invisibly. - Use the management CLI to add or remove watch paths at runtime and replay events from a timestamp, so you can recover without restarting the daemon.
