lov-finder-action

Finder context menu action

Create a macOS Finder file quick action or directory background menu extension.

Triggers

Activate when

• "Create a macOS Finder file quick action or directory background menu extension."
• “Create a Finder context menu action.”

Do not activate when

• Only querying the description of this Skill, or requesting tasks unrelated to the above results; does not execute actual business operations.
• When the user only wants a preview or review, do not enter the modify, commit, or publish branch.

Execution boundary

A natural language request is sufficient to trigger; no legacy slash path, parameter interpolation, or specified assistant is needed. Clearly parse the project, target files, options, and output location in the current request; use the file, search, CLI, and browser capabilities actually provided by the current host. Project dependency versions and external APIs are verified at execution time; do not assume the examples are current configuration. Package scripts resolve from the Skill root, business files resolve from the target project root. First read the current state, protect existing uncommitted content and the staging area of other tasks. Analysis and preview requests remain read-only; modification, commit, push, deployment, and publishing each execute according to the explicit scope of the current request. Do not bypass protections, automatically send messages, force-kill user processes, or steal the foreground. On failure, preserve diagnosable raw errors.

Workflow

1. Choose an Automator Quick Action or Finder Sync Extension depending on whether selected files are needed; parse the action name, file types, actual processing logic, and target directory.

2. Quick Action uses scripts and a workflow plist received as parameters, tool paths resolve from the actual installation, handling Chinese, spaces, multiple selections, and same-name output; reference references/automator-template.xml and verify current system fields.

3. Finder Extension uses the actual Xcode toolchain, an independent bundle ID, necessary sandbox permissions, and a precisely monitored directory, with the menu action specifying a clear target; verify capabilities against current Apple documentation, and do not require temporary exception permissions for the entire disk.

4. When a cross-process helper is needed, use verifiable structured messages and a fixed set of operations; do not read arbitrary shell commands from the clipboard, and do not use the helper to bypass system permissions.

5. After generating build configuration and code, check the plist, compilation, and extension registration; report local ad-hoc signing and distributable signing separately, and do not call the former a formal release.

6. Do not force killall Finder, open Automator, or switch applications to the foreground; accurately explain the steps required for the user to enable the extension. Actual menu triggering is marked verified only after observation is completed.

7. Preserve existing workflows and applications, and clearly specify the installation location and rollback path; do not overwrite same-name menu actions.

Composition

Before execution, read capability combinations, and hand off adjacent capabilities according to explicit artifacts.

Runtime context (shared)

Before running, read this package's skill.yaml and Profile contract. The priority is the current request, project context, this Skill records, shared preferences, brand/user Profile, and secure defaults. Read only declared fields; a host without a dedicated runtime may use scripts/profile_store.py to read the shared Profile. For missing configuration, ask only one question that affects the result. Values the user explicitly requests to save long-term are atomically written through that script, and the actual path is reported; do not save inferences, credentials, or materials from other tasks.

General feedback loop

When the user provides modification feedback during a Skill-driven task, before continuing with the current artifact you must execute:

1. First determine whether the feedback is task-specific(This time only) or reusable(reusable across tasks).
2. task-specific Only modify the current task, not the Skill.
3. reusable First determine the scope: for domain rules, update the corresponding canonical Skill first; for rules that apply to all Skills, update the shared specification first.
4. After completing the rule update, versioning, lint, and distribution verification, then apply the changes to the current task.
5. reusable Modifications will invalidate previous "confirm," "continue," and "send it" instructions; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, without automatically proceeding to publishing, submission, or other external writes.