Flying Scripts works by matching strings in the source of every script tag against a configurable list of keywords. Anything that matches is delayed until user interaction or a global timeout fires. Configuration lives in the flying_scripts_settings option (the keyword list and the timeout). The admin is a single settings screen with a textarea and a number field, useful for setup but not for listing every keyword with its length and last edit time.

SleekView reads the flying_scripts_settings option as a flat rule set and renders the data as a real table view. Keyword, length, length bucket, last edit and notes become first-class columns with sort, filter and inline action. An engineer can scope the table to overly short keywords likely to match too much, an agency lead can keep a documented audit trail of when the keyword list grew.

Flying Scripts keeps matching keywords and delaying scripts on the front-end exactly as before. SleekView is read-only against the option store, so the delay behavior stays authoritative.

Flying Scripts is intentionally small: a keyword list, a timeout and a buffer interceptor that delays anything matching until the user interacts. The simplicity is the point. The trade-off is that a textarea and a number field cannot answer questions like how many keywords exist, which are overly generic or how often the list has been edited during a release cycle.

SleekView reads the flying_scripts_settings option and renders the keyword list as a sortable, filterable audit table. The plugin keeps delaying scripts exactly as before; SleekView gives the team a shared screen to read configuration health, scoped per role and embeddable on the frontend.