Claude skills for property security ops live in a folder a leasing manager can edit.

A skill is a folder on the edge device that bundles together everything Claude needs to give one kind of verdict for one kind of event. On a Cyrano unit a skill has four artifacts: an instructions file (the prompt template), a triggers file (the dwell threshold and arming schedule that decides when the skill is even invoked), an output schema (the strict JSON shape Claude has to return), and a dispatch file (who gets paged, what the SMS body looks like, whether to ring the on-call phone). One folder per event class. Loitering is one skill. Tailgating is another. Package theft is another. Force entry is another. They are not different prompts in one big system; they are different skills with different file layouts in /var/lib/cyrano/skills/.

Because property managers edit them. The loitering skill at a Class C property in Atlanta has a 90-second dwell threshold, treats the pool area as armed only after 22:00, and pages the on-call leasing agent. The loitering skill at a 6-building portfolio in Baton Rouge has a 60-second threshold, treats the parking lot as armed 24/7, and pages a dispatched off-duty officer. Those are not configuration toggles in a SaaS dashboard; they are differences in the skill folder, and they should be editable as text files on the device that produces the alerts. Bundling them into one prompt means every change is a deploy and every property is the same. Splitting them into per-event-class skills means a manager who decides 'we treat anyone in the pool after 22:00 as HIGH regardless of dwell' edits one file and the rule is live on the next event.

On a Cyrano unit the path is /var/lib/cyrano/skills/<event_class>/. The folder for the loitering skill contains four files: instructions.md (the prompt sent to Claude alongside the stitched 5-frame burst), triggers.json (dwell threshold in seconds, armed-zones polygon ids, arming schedule by day-of-week and hour, optional cooldown to avoid alert storms), output.schema.json (the strict JSON envelope Claude must return — threat_level, one_line_summary, policy_match), and dispatch.json (the operator routing rules: SMS template, phone-call escalation policy, dashboard chip color). A fifth file, .history/, holds versioned copies of every prior instructions.md so an audit can answer 'which prompt was active when alert e_4193 fired'.

An MCP tool is something Claude can call to get information or take an action: 'fetch the resident roster', 'search the footage index', 'send an SMS to the on-call manager'. A skill is the larger unit that decides when those tools are used and what verdict shape Claude has to produce. Concretely, the loitering skill on a Cyrano unit names two MCP tools in its frontmatter: search_resident_roster (to check whether the figure on the bench at 02:14 is a known resident) and lookup_property_policy (to check whether the bench is in an armed zone after-hours per the property's posted rules). The skill is the unit a manager edits; MCP tools are the calls that skill is allowed to make. We use both, but the per-property differences live at the skill level, not the tool level.

Three steps, all local until the very last one. The on-device detector decides a bounding box is a person inside an armed zone. The dwell timer in /var/lib/cyrano/skills/<event_class>/triggers.json holds the track for the configured threshold (loiter 90s, tailgate 1.2s, package 900s). When the threshold is met, the runtime loads instructions.md and output.schema.json from the same skill folder, stitches a 5-frame burst into one 2x3 image, and emits exactly one Claude messages.create call carrying the prompt, the schema, and the image. The verdict comes back, gets validated against output.schema.json, and dispatch.json decides who gets the SMS and the phone call. If the verdict fails the schema check, the operator sees the local-only event with a 'verdict_pending' flag and the request goes into the outbox queue.

Every dispatched alert leaves four files in /var/lib/cyrano/events/<event_id>/: claude_input.jpg (the literal 2x3 stitched image that went over the wire), claude_prompt.txt (the rendered prompt the skill produced for this specific event), claude_response.json (the parsed JSON verdict Claude returned), and operator_alert.json (the SMS body, the call script, and the dashboard chip color the dispatch.json file produced). Every one of those is openable from the dashboard 'show inputs' affordance for any alert in the past 90 days. That auditability is non-negotiable on a security product. If the model said HIGH and dispatched a guard, the on-call manager has to be able to see what the model saw and what it was asked to decide.

The detection layer never blocks on a remote API. The on-device verdict (zone hit, dwell threshold met, event class matched) is dispatched to the operator immediately with whatever fields the local model can fill, including the local VLM's one-line summary if the local-VLM escalation threshold was satisfied. The 5-frame stitched burst plus the rendered prompt are written to /var/lib/cyrano/outbox/claude/<event_id>.ndjson as an append-only record. When the link returns, the queue drains in order, Claude's verdict is appended to the event record after the fact, and the operator's incident view updates with the higher-confidence verdict. The natural-language footage search index is rebuilt for the lagged events as their verdicts arrive.

Six: loiter (dwell threshold 90s in armed zones), tailgate (1.2s threshold at controlled entry points, two-track-overlap), package_theft (900s threshold near mailroom or doorstep with motion cluster), force_entry (immediate, on detection of pry-tool-shaped object or active manipulation of a lock or gate), after_hours_pool (dwell threshold 30s in pool polygon between 22:00 and 06:00, configurable per property), and pre_action_parking_lot (dwell threshold 240s in unmarked-figure-near-vehicle pattern, fired only when the lot is armed). Each one is a folder under /var/lib/cyrano/skills/. Properties commonly add a seventh and eighth: a leasing-hours-violation skill for after-hours leasing-office traffic, and a fence-line skill for perimeter cuts.

Two ways. The dashboard has a 'skills' tab where the four files for each event class render as an editable form: dwell threshold as a number input, arming schedule as a calendar grid, instructions.md in a text editor with a diff view against the prior version, output.schema.json read-only by default. Saving the form writes the four files atomically into /var/lib/cyrano/skills/<event_class>/, copies the prior versions into .history/, and SIGHUPs the runtime so the next event uses the new files. The second way is direct SSH for portfolio operators who want to manage the skills as a git repo: clone /var/lib/cyrano/skills/, edit, push back, the runtime watches the directory with inotify and reloads. Both paths produce the same audit trail.

On a 25-camera multifamily property the skills emit roughly 250 Claude requests per day across all event classes (the median we see in production), each carrying one stitched 2x3 image and a rendered prompt. That is ~1.31 million image tokens plus ~50 input text tokens per request and ~120 output tokens per response. At Sonnet 4 vision pricing this is roughly $0.04 per property per day or about $1.20 per month. The naive alternative — sending every frame from every camera to Claude with no skill-level dwell gating — would be roughly $97,000 per property per day at the same pricing. The skill folder is the architecture that turns the latter number into the former.

Yes. /var/lib/cyrano/skills/ is a working directory and we recommend operators treat it that way. A regional manager can keep a portfolio_skills repo with a baseline set of folders (loiter, tailgate, package_theft, force_entry, after_hours_pool, pre_action_parking_lot) and per-property overrides as branches. The unit's reload behavior is filesystem-watch based, so a git pull on the device puts the new skill into effect on the next event. The .history/ directory inside each skill folder is the on-device audit log; the git repo is the portfolio-wide change log. Both are useful for different audits.