Production Surveillance logo

Production Surveillance

Organization
Amazon-Quick
production-surveillance

Analyze synthetic production surveillance data with deterministic field, well-log, flow-assurance, reservoir, safety, petrophysics, and economics checks. Use when asked to 'generate a morning field report', 'run production surveillance', 'read this LAS file', 'ingest well logs', 'what curves are in SK-14', 'investigate the RED alarm', 'run a full investigation on a well', 'check flow assurance', 'calculate hydrate margin', 'assess reservoir constraints', 'run a safety compliance check', or 'create a production surveillance watch'.

Overview

PublisherAmazon-Quick
RepositoryAmazon-Quick-official-catalog
Skill nameproduction-surveillance
Stars
50
Forks
4
Bundled files
14
LicenseMIT-0
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 14 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by Amazon-Quick on GitHub. Read the source before you install it.

Installation

Install the Production Surveillance AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/Amazon-Quick/Amazon-Quick-official-catalog/tree/main/skills/energy-utilities/production-surveillance
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/Amazon-Quick/Amazon-Quick-official-catalog.git /tmp/Amazon-Quick-official-catalog
mkdir -p .claude/skills
cp -r /tmp/Amazon-Quick-official-catalog/skills/energy-utilities/production-surveillance .claude/skills/production-surveillance
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Production Surveillance in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Production Surveillance on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Production Surveillance is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Overview

Production Surveillance provides six operationally read-only analysis workflows for a synthetic deepwater-gas field. The Morning Field Report can add a self-contained Highcharts dashboard, and the Anomaly Investigation fans out three isolated domain checks in parallel before applying the safety veto. After either workflow, the skill can offer once to create an opt-in recurring surveillance watch. It produces evidence-bound analysis and proposed external handoffs, never field commands or claims of execution.

Workflow

<Definition - Synthetic fixture> All bundled data under references/ and evals/files/ is synthetic. references/tiger-data-sample-response.json contains the 27-well field snapshot, references/formation-tops.json contains two synthetic formation summaries, references/petrophysics-summary.json contains pre-computed results derived from synthetic well-log sidecars, and evals/files/ contains synthetic LAS 2.0 logs for SK-14 and SK-22. None represents a real field, customer, or operator. </Definition - Synthetic fixture>

<Definition - Signed scenario margin> The hydrate signed scenario margin is current temperature minus inhibited equilibrium temperature. A positive value means the synthetic temperature is above the inhibited hydrate curve. It is not a field-certified operating margin. </Definition - Signed scenario margin>

<Definition - Safety veto> A BLOCK from the Safety Compliance Check overrides every other finding. An UNKNOWN safety result also withholds the proposed handoff until the evidence gap is resolved. The agent must not offer APPROVE while either condition remains. </Definition - Safety veto>

<Definition - Domain result> Each isolated Anomaly Investigation task returns one status from PASS, CAUTION, BLOCK, or UNKNOWN. A failed, malformed, unavailable, or timed-out task is UNKNOWN for that domain, never PASS. The parent agent retains the failure reason in the recommendation card. </Definition - Domain result>

<Definition - Human decision> APPROVE records approval for an external handoff only. MODIFY changes assumptions or proposed parameters and requires the affected calculations and safety screen to run again. REJECT records the rejection reason and holds the current state. None executes a field command. </Definition - Human decision>

<Definition - Partial report> A report labeled PARTIAL contains only completed calculations, names every failed or missing input, and makes no conclusion that depends on unavailable evidence. </Definition - Partial report>

<Definition - Production Surveillance watch> An opt-in recurring local Quick scheduled task that runs the bundled well_deviations and alarms operations. A RED alarm invokes Anomaly Investigation and stops at the human decision boundary. The watch never auto-approves or executes an operational action. </Definition - Production Surveillance watch>

<Workflow - Well Log Ingestion description="Read a confined LAS 2.0 unwrapped well log, resolve curve aliases, normalize supported units, run the existing petrophysics sequence, and report evidence limits." tools=[file_read, run_python] triggers=["read this LAS file", "ingest well logs", "what curves are in SK-14", "parse a LAS 2.0 well log"]

  1. [Agent] Read README.md ## Pre-requisites, references/analysis-basis.md, and references/script-interface.md. Verify run_python is available. Identify the requested path as bundled synthetic data under evals/files/ or user-supplied data, and ensure it resolves within WORKSPACE_DIR. Validate: The Python tool and references are available, the source label is explicit, and the path contains no parent traversal and stays within WORKSPACE_DIR. If fails: Stop, return UNKNOWN, and name the missing tool, reference, or confinement error. Never copy data outside the workspace to bypass confinement.

  2. [Agent] Run scripts/run_las_reader.py operation read_metadata with the documented path argument. Validate: The response has status: success, version: 2.0, wrap: NO, a finite null value, a non-empty well section, and a curve inventory. If fails: Preserve the documented error code. Wrapped LAS, LAS 3.0, a missing ASCII section, or malformed metadata returns UNKNOWN and must not continue to petrophysics.

  3. [Agent] Pass the returned curve mnemonics to operation resolve_aliases. Identify GR, NPHI, RHOB, and RT; also retain depth and every unresolved mnemonic in the inventory. Validate: The response has status: success; every input mnemonic appears once; the mapping source is recorded; required curves for each requested calculation are known. If fails: Return alias status UNKNOWN. Continue only calculations whose required canonical curves are unambiguous.

  4. [Agent] Run operation read_curves with the same path and optional source-unit depth_min and depth_max. For bundled SK-14 and SK-22 reservoir calculations, use the intervals in references/analysis-basis.md. Remove any row containing null in a curve required by the next calculation, and report the removed-row count. Validate: Raw and canonical arrays have equal sample counts, JSON null represents the LAS null value, canonical units are FT for depth, GAPI for GR, V/V for NPHI, G/CC for RHOB, and OHMM for RT when those source curves exist. If fails: Preserve the error code and return curve data UNKNOWN. Never substitute, interpolate, or model a malformed or missing value.

  5. [Agent] Using only aligned non-null canonical arrays and the constants in references/analysis-basis.md, call scripts/run_petrophysics.py in this order: density_porosity from RHOB; shale_volume from GR; effective_porosity from density porosity and shale volume; archie_water_saturation from RT and effective porosity; then net_pay from depth, effective porosity, water saturation, and shale volume. Validate: Every response has status: success, arrays remain aligned, the input and output units match references/script-interface.md, and no model arithmetic replaces a failed operation. If fails: Mark the failed operation and all dependent operations UNKNOWN, retain independent successful outputs, and label the result PARTIAL.

  6. [Agent] Report the source label, LAS version and wrap, well metadata, original curve inventory, canonical mapping, units, source and retained row counts, depth interval, each successful petrophysics result, constants and cutoffs, null-row handling, and evidence gaps. State the professional-review disclaimer from Rule 11. Validate: Bundled SK-14 or SK-22 is labeled synthetic, user-supplied data is not mislabeled synthetic, every number traces to script output or references/analysis-basis.md, and no field action or certified interpretation is claimed. If fails: Remove unsupported claims and rebuild the report only from successful script results and committed references.

</Workflow - Well Log Ingestion>

<Workflow - Morning Field Report description="Build a synthetic morning production report and optional self-contained dashboard with field status, anomalies, petrophysics context, economics, safety screening, and a human handoff decision." tools=[file_read, run_python, run_python_with_write, open_in_session_tab, get_current_time, agent_management, memory_management, list_scheduled_agents, create_scheduled_agent, recall_memories, save_to_memory] triggers=["generate a morning field report", "run production surveillance", "summarize the synthetic field", "review today's production anomalies"]

  1. [Agent] Read README.md ## Pre-requisites. Verify run_python is available. Check whether the optional html_design, highcharts, agent_management, and memory_management built-ins are enabled. If the user supplied LAS, require LAS 2.0 unwrapped text within WORKSPACE_DIR; if the user supplied DLIS, require external conversion to validated JSON. Validate: The required Python tool is available, LAS input is supported and confined or DLIS input is validated JSON, and optional built-in availability is recorded. If fails: Stop for a missing required tool or unsupported well-log input. Continue without an unavailable optional capability, state the reduced scope, and keep the Markdown report available.

  2. [Agent] Read references/analysis-basis.md and references/script-interface.md. Record the run time with get_current_time. Run scripts/run_tiger_fixture.py against references/tiger-data-sample-response.json using the documented {"operation": ..., "arguments": {...}} envelope for field_summary, well_deviations with threshold_pct: 10, and alarms with severity: all. Validate: Each result is valid JSON with status: success; the field summary contains 27 wells and the deviation and alarm outputs retain fixture timestamps. If fails: Retry only a malformed invocation once. Then label the report PARTIAL, name each failed operation, and omit dependent conclusions.

  3. [Agent] Read references/formation-tops.json. When bundled or user-supplied LAS 2.0 unwrapped input is available, run <Workflow - Well Log Ingestion> through its calculation and reporting steps and use only successful outputs for petrophysics context. Otherwise read references/petrophysics-summary.json as the fallback. Confirm any fallback covers only SK-14 and SK-22 and identify its pre-computed calculation sequence and cutoffs. Validate: The selected source is labeled bundled synthetic or user-supplied, LAS output has status: success for every retained calculation, or the fallback JSON is valid and contains SK-14 and SK-22 without implying coverage of all 27 wells. If fails: Mark petrophysics context UNKNOWN, name the failed LAS operation or missing fallback, and continue the independent field and economics sections as a partial report.

  4. [Agent] Run scripts/run_economics.py for daily_revenue with gas_rate_mmscfd: 1004, gas_price_per_mmbtu: 3.5, btu_per_scf: 1050, condensate_bpd: 68000, and condensate_price_per_bbl: 72.5. Run deferred_production twice with the same price and heating value: once with constrained_wells holding SK-14 at current_rate_mmscfd: 22 and potential_rate_mmscfd: 38, and once with shut_in_wells holding SK-14 at potential_rate_mmscfd: 38. Argument names are in references/script-interface.md. Validate: The script returns $58,800/day current deferral and $139,650/day full-well exposure, with all assumptions repeated in JSON. If fails: Mark economics UNKNOWN; do not calculate replacements or label any value as avoided savings.

  5. [Agent] If the report proposes the external handoff in references/analysis-basis.md, run scripts/run_tiger_fixture.py operation safety_compliance for SK-14 with that proposed action and action class chemical. Validate: The result includes verdict, blocking, precedent_basis: active_alarm_set, and execution_status: not_executed. If fails: Treat safety as UNKNOWN, withhold the handoff, and do not offer APPROVE.

  6. [Agent] Produce a Markdown report containing: synthetic-data disclosure; analysis and fixture timestamps; field summary; active alarms; deviations; SK-14 and SK-22 petrophysics status; explicit economics assumptions; separate current-deferral and full-exposure values; safety result; evidence gaps; exact script operations used; and the professional-review disclaimer. Validate: Every numeric claim traces to a successful result or committed reference, failed sections are labeled UNKNOWN or PARTIAL, and no operational action is described as executed. If fails: Remove unsupported claims and rebuild only from retained evidence.

  7. [Decide] Are both html_design and highcharts enabled? Validate: Availability is determined from step 1.

    • Yes: Continue to the dashboard location step.
    • No: Present the complete Markdown report, state which built-in is unavailable, skip the dashboard location and build steps, and continue to the human decision step. If fails: Preserve the Markdown report as the fallback, skip the dashboard location and build steps, and continue to the human decision step.
  8. [Ask user] Ask where to save the optional HTML dashboard. Accept a user-confirmed location or the current session workspace. Validate: A writable destination is explicitly confirmed before any file is created. If fails: Keep the Markdown report in chat, skip the dashboard build step, and continue to the human decision step.

  9. [Agent] Load the built-in highcharts and html_design skills. Build one self-contained HTML file using the vendored Highcharts from those skills, with no CDN or external dependency. Include a field-production column chart; an SK-14 rate, pressure, and temperature trend with the 14.22 degC inhibited hydrate curve as a separately labeled line; an active-alarm table; and separate cards for $58,800/day current deferral and $139,650/day full-well exposure. Generate the HTML only from successful prior results, write it to the confirmed location with run_python_with_write, and open it with open_in_session_tab. Validate: The file opens, contains all four requested views, uses only vendored Highcharts, labels the fixture synthetic, and keeps both economics figures in separate cards with their $3.50/MMBtu and 1,050 BTU/scf basis. If fails: State that dashboard rendering failed and present the complete Markdown report as the fallback. Do not replace Highcharts with a CDN.

  10. [Ask user] If safety is not BLOCK or UNKNOWN, present the proposed handoff with execution_status: not_executed and ask for exactly one decision: APPROVE, MODIFY, or REJECT. If safety is BLOCK or UNKNOWN, present the withheld handoff and request MODIFY or REJECT instead. Validate: A blocked or unknown case offers no APPROVE path; otherwise the response matches one human decision. If fails: Re-state the safety result and decision boundary, then ask again without taking action.

  11. [Decide] On APPROVE, record approval for external handoff only. On MODIFY, collect changed assumptions, rerun affected calculations, rebuild the report and dashboard if requested, and reapply safety. On REJECT, record the reason and hold current state. Then run <Workflow - Scheduled Surveillance Offer> unless this report was launched by the watch. Validate: The final record retains execution_status: not_executed; a modified case was recalculated and rescreened; the scheduling check was invoked once for an owner-initiated run. If fails: Reset the status to not executed, keep the report in chat, and state which decision, save, or scheduling step failed.

</Workflow - Morning Field Report>

<Workflow - Anomaly Investigation description="Investigate a synthetic well anomaly by dispatching flow assurance, reservoir constraints, and safety compliance in parallel, then synthesize one safety-gated recommendation card." tools=[file_read, run_python, get_current_time, start_task, create_task_group, get_task_group_result, inspect_task, agent_management, memory_management, list_scheduled_agents, create_scheduled_agent, recall_memories, save_to_memory] triggers=["SK-14 pressure is spiking and rate is dropping, run a full investigation", "investigate the RED alarm", "run a full investigation on a well", "review the production anomaly end to end"]

  1. [Agent] Read README.md ## Pre-requisites, references/analysis-basis.md, and references/script-interface.md. Verify run_python, create_task_group, start_task, and get_task_group_result are available. Record the analysis time with get_current_time. Validate: Required tools and both references are available, and the script contract is loaded before any command is assembled. If fails: Stop, name the unavailable tool or reference, and do not simulate parallel results.

  2. [Agent] Read current alarm evidence first by running run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"alarms","arguments":{"severity":"RED"}}. If the request names a well, rerun with well_id added. If no well is named and exactly one RED well is returned, select it; if multiple RED wells are returned, ask the user which well to investigate. Validate: Alarm output has status: success, every selected alarm is current fixture evidence, and exactly one well_id is selected. If fails: Return anomaly status UNKNOWN, preserve the script error, and request a well identifier or valid alarm evidence.

  3. [Agent] Assemble isolated-task inputs for the selected well: complete active-alarm JSON; any user-supplied proposed action or rate; and aqueous MEG weight percent only when explicitly supplied or committed for that well in references/analysis-basis.md. For SK-14, use the committed proposed external handoff and 21.5 wt% basis. For another well without a supported proposal, use "hold current state and request qualified review" with action class other. Validate: Every value has a successful tool, user, or committed-reference source; volumetric MEG rate was not converted to weight percent. If fails: Set the unsupported input to null and require the affected task to return UNKNOWN rather than inventing it.

  4. [Agent] Create one task group. Render <Template - Flow Assurance Investigation Task>, <Template - Reservoir Investigation Task>, and <Template - Safety Investigation Task> with the step 3 inputs. Call start_task once per rendered objective using the same group identifier and distinct names. Start all three tasks before calling get_task_group_result so they run in parallel as isolated contexts. Validate: Three task identifiers exist in one group, each objective contains the selected well ID, complete alarm JSON, the execution recipe, exact request objects, required JSON output shape, and execution_status: not_executed. If fails: Do not substitute parent-agent analysis for a missing task. Create an UNKNOWN domain result with the launch failure and continue as PARTIAL only if at least one independent task launched.

  5. [Agent] Collect the group with at most eight get_task_group_result calls, waiting between calls while any task is non-terminal. After the eighth call, or when a task reports completed with an empty summary, call inspect_task once for that task and take its final JSON output as the result. If every task in the group failed with a 503 or service_overloaded error, create one replacement group with the same objectives and repeat this step once; no further retries. Parse each returned JSON object against <Definition - Domain result>. Convert an error, timeout, still-running task after the bound, missing result, malformed JSON, or unsupported conclusion into an UNKNOWN result for that domain and retain the reason. Validate: No group receives more than eight result calls; inspect_task is called at most once per task; at most one retry group exists; exactly one normalized result exists for flow assurance, reservoir constraints, and safety compliance; no failed, timed-out, or still-running task is labeled PASS. If fails: Mark every unvalidated domain UNKNOWN, label the investigation PARTIAL, and withhold APPROVE.

  6. [Agent] For SK-14, run the two exact deferred_production commands from references/script-interface.md: one with constrained_wells containing current rate 22 and potential rate 38, and one with shut_in_wells containing potential rate 38, both at $3.50/MMBtu and 1,050 BTU/scf. For another well, use only successful source values for the same argument names; otherwise mark economics UNKNOWN. Validate: SK-14 returns $58,800/day current deferral and $139,650/day full-well exposure as separate scenarios with assumptions repeated. If fails: Mark economics UNKNOWN and do not calculate a replacement.

  7. [Agent] Apply <Definition - Safety veto>, then synthesize exactly one <Template - Anomaly Recommendation Card>. State the root cause only when supported by retained evidence, include calculation basis and all three domain statuses, show $58,800/day current deferral separately from $139,650/day full-well exposure, name the proposed external handoff, and set execution_status: not_executed. Include every UNKNOWN reason. Validate: One card is produced; safety BLOCK or UNKNOWN withholds the handoff and removes APPROVE; no task output is presented as an executed action. If fails: Replace unsupported synthesis with root_cause: UNKNOWN, retain the component evidence, and withhold APPROVE.

  8. [Ask user] For an evidence-complete card without a safety veto, ask for exactly one decision: APPROVE, MODIFY, or REJECT. Under BLOCK or safety UNKNOWN, ask for MODIFY or REJECT only and state what must change before APPROVE can return. Validate: The available decisions match the safety state and no response is treated as execution authority. If fails: Re-present the one card with the safety result and allowed decisions.

  9. [Decide] On APPROVE, record approval for the external handoff only. On MODIFY, collect revised inputs and rerun steps 3 through 8, including affected isolated tasks and the safety veto. On REJECT, record the reason and hold current state. Then run <Workflow - Scheduled Surveillance Offer> unless this investigation was launched by the watch. Validate: The decision record remains execution_status: not_executed; modifications received fresh domain and safety results; the scheduling check was invoked once for an owner-initiated run. If fails: Invalidate the decision, hold current state, and return to the human decision step.

</Workflow - Anomaly Investigation>

<Workflow - Flow Assurance Check description="Calculate a synthetic MEG-inhibited hydrate equilibrium and signed scenario margin, then safety-screen a proposed external handoff." tools=[file_read, run_python, get_current_time] triggers=["check flow assurance", "calculate hydrate margin", "assess hydrate risk", "review a low-temperature gas well"]

  1. [Agent] Read README.md ## Pre-requisites, references/analysis-basis.md, and references/script-interface.md. Verify run_python is available. Validate: The required Python tool is available and the hydrate basis and limitations were read. If fails: Stop for a missing required tool or report the missing reference before calculating.

  2. [Ask user] Obtain well_id, pressure_psi, current_temp_degc, and aqueous-phase meg_weight_pct. Accept current_meg_rate_m3hr only as a separate reported observation. Validate: Required values are numeric and finite; pressure is positive; MEG is in [0, 100); the weight percent is not inferred from volumetric rate. If fails: Return UNKNOWN, identify each invalid or missing field, and request corrected inputs.

  3. [Agent] Run scripts/run_petrophysics.py operation hydrate_equilibrium with the validated pressure, temperature, and aqueous MEG weight percent. Preserve returned method, assumptions, inhibited equilibrium, signed scenario margin, and risk band. Validate: Output is JSON with status: success and all requested fields; SK-14 canonical inputs produce 14.22 degC, +1.48 degC, and HIGH within rounding tolerance. If fails: Preserve the error code and message, return UNKNOWN, and do not recompute with model arithmetic.

  4. [Decide] For requests beyond equilibrium, margin, and script-owned risk band, check whether an implemented model is available. Unsupported examples include hydrate nucleation time, plug timing, wax, slugging, cooldown time, safe operating envelopes, and the effect of a volumetric rate change on MEG weight percent. Validate: Every unsupported assessment is UNKNOWN and names the missing model or evidence. If fails: Remove the unsupported conclusion and replace it with the evidence gap.

  5. [Agent] If proposing an external handoff, run scripts/run_tiger_fixture.py operation safety_compliance for the same well and proposed action. Do not change a field setting. Validate: Safety returns a non-error result with blocking and execution_status: not_executed. If fails: Set safety to UNKNOWN, withhold the handoff, and request qualified review.

  6. [Agent] Return a result containing inputs, synthetic evidence status, inhibited equilibrium, signed scenario margin, risk band, interpretation, assumptions, unsupported assessments, proposed external handoff if allowed, safety result, and the professional-review disclaimer. Validate: The result never claims a proposed volumetric rate produces a calculated post-change margin or a safe field response. If fails: Remove the conversion or safety claim and retain only the script output.

  7. [Ask user] Enforce <Definition - Safety veto>. When not blocked or unknown, ask for APPROVE, MODIFY, or REJECT; approval records an external handoff only. Validate: BLOCK and UNKNOWN offer no APPROVE path; every branch retains execution_status: not_executed. If fails: Re-present the safety status and decision choices without executing anything.

  8. [Decide] On APPROVE, record the external handoff. On MODIFY, collect revised inputs and rerun steps 2 through 7. On REJECT, record the reason and hold current state. Validate: Modified values were recalculated and rescreened, and no field command, work order, alarm acknowledgement, notification, or dispatch occurred. If fails: Mark the decision record invalid and return to step 7.

</Workflow - Flow Assurance Check>

<Workflow - Reservoir Constraints description="Screen synthetic drawdown, sand, water, and pressure-rate signatures to distinguish reservoir decline from downstream restriction." tools=[file_read, run_python, get_current_time] triggers=["assess reservoir constraints", "check drawdown and sand risk", "is the decline reservoir driven", "evaluate a proposed rate change"]

  1. [Agent] Read README.md ## Pre-requisites, the reservoir section of references/analysis-basis.md, and references/script-interface.md. Verify run_python is available. Validate: The required Python tool is available and the synthetic threshold basis was read. If fails: Stop for a missing required tool or return UNKNOWN for a missing basis reference.

  2. [Ask user] Obtain well_id and optional proposed_rate_mmscfd. Use a seven-day history unless the user supplies another integer from 1 to 3,650. Validate: The well identifier is non-empty; supplied rates are finite and non-negative; history days are within bounds. If fails: Return UNKNOWN with the invalid fields and request corrections.

  3. [Agent] Run scripts/run_tiger_fixture.py operation completion_data, well_readings for 60 minutes, and well_history for the selected window. Validate: Required reservoir pressure, gas gravity, temperature, perforation depths, tubing pressure, gas rate, water cut, and sand rate exist; history has at least two rows. If fails: Return UNKNOWN for drawdown or trend components that lack evidence and continue only independent checks as PARTIAL.

  4. [Agent] Run scripts/run_tiger_fixture.py operation reservoir_constraints with the well and optional proposed rate. Preserve fbhp_basis, threshold basis, water-trend basis, binding constraint, and decline diagnosis. Validate: Output is successful; utilisation values are finite; SK-14 identifies rising pressure with falling rate as DOWNSTREAM_RESTRICTION. If fails: Preserve the error, return UNKNOWN, and do not invent a bottomhole pressure or diagnosis.

  5. [Agent] If the result supports a proposed external handoff, run safety_compliance for the proposed action before presenting it. Validate: The safety result is available and any BLOCK overrides reservoir PASS or CAUTION. If fails: Set safety to UNKNOWN, withhold the handoff, and request qualified review.

  6. [Agent] Report current and proposed verdicts separately, the estimated-static-column basis, drawdown utilisation, sand and water utilisation, trend diagnosis, binding constraint, evidence limits, and professional-review disclaimer. Validate: No estimated value is described as measured; no multi-day sand or water trend is claimed; a proposed increase blocked by sand or drawdown is not recommended. If fails: Correct the basis labels and reconcile the recommendation to the strictest constraint.

  7. [Ask user] Enforce <Definition - Safety veto>. For a non-blocked, evidence-complete handoff, ask for APPROVE, MODIFY, or REJECT with execution_status: not_executed. Validate: No blocked or unknown case offers APPROVE, and the human response maps to one branch. If fails: Re-present the binding constraint, safety status, and allowed choices.

  8. [Decide] On APPROVE, record an external handoff only. On MODIFY, collect the revised rate or action and rerun steps 2 through 7. On REJECT, record the reason and hold current state. Validate: Any modified rate was fully recalculated and safety-screened, and no operational action occurred. If fails: Invalidate the decision and return to step 7.

</Workflow - Reservoir Constraints>

<Workflow - Safety Compliance Check description="Apply the mandatory synthetic safety gate to a proposed production action and exercise veto authority before human review." tools=[file_read, run_python, get_current_time] triggers=["run a safety compliance check", "run the safety gate", "can this action proceed", "check a production recommendation"]

  1. [Agent] Read README.md ## Pre-requisites, the safety section of references/analysis-basis.md, and references/script-interface.md. Verify run_python is available. Validate: The required Python tool is available and the synthetic safety thresholds and evidence limits were read. If fails: Stop for a missing required tool or return safety UNKNOWN for a missing basis reference.

  2. [Ask user] Obtain well_id, free-text proposed_action, and optional action_class from chemical, choke, thermal, mechanical, or other. Validate: The well and proposed action are non-empty; any supplied action class is in the allowed set. If fails: Return UNKNOWN and request corrected inputs without inferring a safe classification.

  3. [Agent] Run scripts/run_tiger_fixture.py operation completion_data, well_readings for 60 minutes, well_history for seven days, and alarms filtered to the well. Validate: Barrier pressures, reservoir fluid context, at least two history rows, and the current alarm set are available. If fails: Treat missing barrier evidence as UNKNOWN or CAUTION, never PASS, and name each unavailable check.

  4. [Agent] Run scripts/run_tiger_fixture.py operation safety_compliance with the proposed action and optional action class. Preserve MAASP and HIPPS utilisation, pressure-trend basis, sour-service review note, CO2 and water review note, permit posture, and active-alarm precedent basis. Validate: Output includes verdict, blocking, precedent_basis: active_alarm_set, threshold_basis: synthetic_fixture, and execution_status: not_executed. If fails: Return UNKNOWN, withhold the proposal, and do not reconstruct a verdict manually.

  5. [Decide] Apply strict precedence: any barrier check over 100 percent is BLOCK; otherwise any 80 to 100 percent check is CAUTION; otherwise the script result is PASS. Missing required safety evidence cannot produce PASS. Validate: Overall verdict is at least as severe as every component, and any BLOCK sets blocking: true. If fails: Replace the verdict with the strictest component and set the blocking flag consistently.

  6. [Agent] Produce a safety card with all checks, synthetic threshold basis, active-alarm-only precedent statement, missing evidence, permit-review posture, veto result, execution_status: not_executed, and the professional-review disclaimer. Validate: The card claims no incident history, commissioned envelope, permit approval, regulatory determination, or operational execution. If fails: Remove unsupported compliance claims and retain only the synthetic screening evidence.

  7. [Ask user] If the verdict is BLOCK or UNKNOWN, state that the safety veto withholds the handoff and request a safer revision or missing evidence. If PASS or CAUTION, ask for APPROVE, MODIFY, or REJECT and show every caution verbatim. Validate: APPROVE is unavailable under a veto; CAUTION is never hidden; no response is treated as execution authority. If fails: Re-present the veto or cautions and ask again.

  8. [Decide] On APPROVE, record approval for external handoff only. On MODIFY, collect the revision and rerun steps 2 through 7. On REJECT, record the reason and hold current state. Validate: The final record remains not executed and every modification received a fresh safety result. If fails: Mark the decision invalid and return to step 7.

</Workflow - Safety Compliance Check>

<Workflow - Scheduled Surveillance Offer description="Offer once to create a recurring read-only production-surveillance watch after an owner-initiated report or investigation." tools=[agent_management, memory_management, list_scheduled_agents, create_scheduled_agent, recall_memories, save_to_memory] triggers=["Called after Morning Field Report", "Called after Anomaly Investigation"]

  1. [Agent] If this run came from the Production Surveillance watch, stop this workflow. Otherwise call list_scheduled_agents and look for a recurring task that runs production-surveillance well_deviations and alarms. Then call recall_memories with the query "Production Surveillance watch scheduling decision". Validate: Both durable signals are checked before deciding, unless this is already a scheduled run. If fails: State that scheduling status could not be verified and do not create or offer a duplicate watch.

  2. [Decide] If a matching watch exists, or memory records acceptance or decline, skip the offer. If neither exists, continue to the offer. Validate: The offer occurs only when no watch and no recorded decision exist. If fails: Skip the offer rather than risk asking twice.

  3. [Ask user] Offer once: "Want me to run a recurring read-only production surveillance scan? It fires only while your machine is on and Quick is running. If yes, tell me the local time you want it to run." Validate: The user clearly accepts with a local schedule time or declines. If fails: Wait for a clear answer and create nothing.

  4. [Agent] If declined, call save_to_memory with a plain record that the user declined the Production Surveillance watch on the current date. If accepted, call create_scheduled_agent with the user-confirmed recurring local time, no condition, and a read-only tool policy. Its prompt must run well_deviations with threshold 10 and alarms with severity all; on any RED alarm, run <Workflow - Anomaly Investigation> for the affected well and stop at the human decision; never auto-approve, acknowledge an alarm, create a work order, notify a crew, dispatch, or execute a field action. After successful creation, call save_to_memory with the accepted decision and schedule time. Validate: A decline is recorded, or one schedule is created without a condition and acceptance is recorded. The scheduled prompt preserves execution_status: not_executed and the safety veto. If fails: Report that setup failed, record the accepted-but-not-created outcome so it is not re-asked automatically, and leave on-demand surveillance available.

  5. [Agent] For acceptance, confirm the schedule, how to change or cancel it in Settings > Scheduled tasks, and repeat that it fires only while the machine is on and Quick is running. Validate: Confirmation states the local time, read-only scope, human decision stop, local-runtime caveat, and cancellation path. If fails: Re-state those five facts without changing the task.

</Workflow - Scheduled Surveillance Offer>

<Template - Flow Assurance Investigation Task>

text
You are an isolated flow-assurance investigator. You have no conversation history. Use only the synthetic files and successful command output.

WELL_ID: [WELL_ID]
ACTIVE_ALARMS_JSON: [ACTIVE_ALARMS_JSON]
AQUEOUS_MEG_WEIGHT_PCT: [AQUEOUS_MEG_WEIGHT_PCT_OR_NULL]
PROPOSED_EXTERNAL_HANDOFF: [PROPOSED_EXTERNAL_HANDOFF]

Execution rules: read references/script-interface.md and the named script with file_read. In run_python, import the named script by its file stem (for example import run_flow_assurance as script), which the sandbox exposes on the import path, and call script.run(request) with the request object shown below. Never read or assign __file__, __dict__, or any dunder attribute; the sandbox blocks them. Never compile or exec the source yourself. Never spawn a subprocess, mutate os.environ, modify sys.path, or import one script from another. Make at most two run_python attempts per request; after two sandbox failures return the UNKNOWN shape with the exact error text.
Execute these exact requests after substituting only bracketed values with valid JSON values:
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"well_readings","arguments":{"well_ids":["[WELL_ID]"],"minutes":60}}
run_petrophysics.run({"operation":"hydrate_equilibrium","arguments":{"pressure_psi":[CURRENT_PRESSURE_PSI],"current_temp_degc":[CURRENT_TEMP_DEGC],"meg_weight_pct":[AQUEOUS_MEG_WEIGHT_PCT]}})

Take pressure and temperature only from the successful well_readings output. Run hydrate_equilibrium only when aqueous MEG weight percent is non-null and evidence-bound. Never derive weight percent from volumetric injection rate. Unsupported wax, slugging, cooldown, plug-timing, or post-change margin claims are UNKNOWN. Return only this JSON shape:
{"domain":"flow_assurance","well_id":"[WELL_ID]","status":"PASS|CAUTION|BLOCK|UNKNOWN","findings":["..."],"calculation_basis":["operation and inputs"],"evidence_gaps":["..."],"proposed_external_handoff":"string or null","blocking":false,"execution_status":"not_executed"}

A script error, sandbox failure after two attempts, missing input, malformed output, or unsupported assessment makes the affected result UNKNOWN, never PASS.

</Template - Flow Assurance Investigation Task>

<Template - Reservoir Investigation Task>

text
You are an isolated reservoir-constraints investigator. You have no conversation history. Use only the synthetic files and successful command output.

WELL_ID: [WELL_ID]
ACTIVE_ALARMS_JSON: [ACTIVE_ALARMS_JSON]
PROPOSED_RATE_MMSCFD: [PROPOSED_RATE_MMSCFD_OR_NULL]
PROPOSED_EXTERNAL_HANDOFF: [PROPOSED_EXTERNAL_HANDOFF]

Execution rules: read references/script-interface.md and the named script with file_read. In run_python, import the named script by its file stem (for example import run_flow_assurance as script), which the sandbox exposes on the import path, and call script.run(request) with the request object shown below. Never read or assign __file__, __dict__, or any dunder attribute; the sandbox blocks them. Never compile or exec the source yourself. Never spawn a subprocess, mutate os.environ, modify sys.path, or import one script from another. Make at most two run_python attempts per request; after two sandbox failures return the UNKNOWN shape with the exact error text.
Execute these exact requests after substituting only bracketed values with valid JSON values:
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"completion_data","arguments":{"well_id":"[WELL_ID]"}}
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"well_readings","arguments":{"well_ids":["[WELL_ID]"],"minutes":60}}
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"well_history","arguments":{"well_id":"[WELL_ID]","days":7}}
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"reservoir_constraints","arguments":{"well_id":"[WELL_ID]"}}
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"reservoir_constraints","arguments":{"well_id":"[WELL_ID]","proposed_rate_mmscfd":[PROPOSED_RATE_MMSCFD]}}

Execute the first reservoir_constraints request when the proposed rate is null; otherwise execute the second after substituting the supported numeric rate. Preserve `fbhp_basis`, drawdown, sand and water utilization, trend basis, binding constraint, and decline diagnosis. Never call estimated bottomhole pressure measured. Return only this JSON shape:
{"domain":"reservoir_constraints","well_id":"[WELL_ID]","status":"PASS|CAUTION|BLOCK|UNKNOWN","findings":["..."],"calculation_basis":["operation and inputs"],"evidence_gaps":["..."],"proposed_external_handoff":"string or null","blocking":false,"execution_status":"not_executed"}

A script error, sandbox failure after two attempts, timeout, missing input, malformed output, or unsupported assessment makes the affected result UNKNOWN, never PASS.

</Template - Reservoir Investigation Task>

<Template - Safety Investigation Task>

text
You are an isolated safety-compliance investigator with veto authority. You have no conversation history. Use only the synthetic files and successful command output.

WELL_ID: [WELL_ID]
ACTIVE_ALARMS_JSON: [ACTIVE_ALARMS_JSON]
PROPOSED_EXTERNAL_HANDOFF: [PROPOSED_EXTERNAL_HANDOFF]
ACTION_CLASS: [ACTION_CLASS]

Execution rules: read references/script-interface.md and the named script with file_read. In run_python, import the named script by its file stem (for example import run_flow_assurance as script), which the sandbox exposes on the import path, and call script.run(request) with the request object shown below. Never read or assign __file__, __dict__, or any dunder attribute; the sandbox blocks them. Never compile or exec the source yourself. Never spawn a subprocess, mutate os.environ, modify sys.path, or import one script from another. Make at most two run_python attempts per request; after two sandbox failures return the UNKNOWN shape with the exact error text.
Execute these exact requests after substituting only bracketed values with valid JSON strings:
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"completion_data","arguments":{"well_id":"[WELL_ID]"}}
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"well_readings","arguments":{"well_ids":["[WELL_ID]"],"minutes":60}}
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"well_history","arguments":{"well_id":"[WELL_ID]","days":7}}
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"alarms","arguments":{"severity":"all","well_id":"[WELL_ID]"}}
run_tiger_fixture.run({"fixture":"references/tiger-data-sample-response.json","operation":"safety_compliance","arguments":{"well_id":"[WELL_ID]","proposed_action":"[PROPOSED_EXTERNAL_HANDOFF]","action_class":"[ACTION_CLASS]"}}

Preserve every component check, threshold basis, current pressure trend, active-alarm-only precedent, permit posture, blocking flag, and execution status. Missing required barrier evidence cannot produce PASS. Return only this JSON shape:
{"domain":"safety_compliance","well_id":"[WELL_ID]","status":"PASS|CAUTION|BLOCK|UNKNOWN","findings":["..."],"calculation_basis":["operation and inputs"],"evidence_gaps":["..."],"proposed_external_handoff":"string or null","blocking":false,"execution_status":"not_executed"}

A script error, sandbox failure after two attempts, timeout, missing input, malformed output, or unsupported assessment makes the affected result UNKNOWN, never PASS. Set blocking true for BLOCK.

</Template - Safety Investigation Task>

<Template - Anomaly Recommendation Card>

markdown
# Anomaly Investigation Recommendation

- Well: {{well_id}}
- Active alarm evidence: {{active_alarm_summary}}
- Root cause: {{supported_root_cause_or_UNKNOWN}}
- Calculation basis: {{commands_inputs_methods_and_thresholds}}
- Flow assurance: {{status_and_findings}}
- Reservoir constraints: {{status_and_findings}}
- Safety compliance: {{status_findings_and_veto}}
- Current deferral: {{current_deferral_with_rate_price_and_heating_value_or_UNKNOWN}}
- Full-well exposure scenario: {{full_well_exposure_with_rate_price_and_heating_value_or_UNKNOWN}}
- Proposed external handoff: {{handoff_or_WITHHELD}}
- Evidence gaps: {{all_UNKNOWN_reasons_or_none}}
- execution_status: not_executed
- Decision required: {{APPROVE_MODIFY_REJECT_or_MODIFY_REJECT_under_veto}}

</Template - Anomaly Recommendation Card>

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Production Surveillance AI skill do?

Analyze synthetic production surveillance data with deterministic field, well-log, flow-assurance, reservoir, safety, petrophysics, and economics checks. Use when asked to 'generate a morning field report', 'run production surveillance', 'read this LAS file', 'ingest well logs', 'what curves are in SK-14', 'investigate the RED alarm', 'run a full investigation on a well', 'check flow assurance', 'calculate hydrate margin', 'assess reservoir constraints', 'run a safety compliance check', or 'create a production surveillance watch'.

Why use Production Surveillance on TypingMind?

Because you install it once and use it with any model. Production Surveillance is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Production Surveillance in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/Amazon-Quick/Amazon-Quick-official-catalog/tree/main/skills/energy-utilities/production-surveillance. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Production Surveillance?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Production Surveillance?

As many as you like. As long as a model supports skills, you can use Production Surveillance with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Production Surveillance AI skill free?

Yes. It is published on GitHub by Amazon-Quick under the MIT-0 license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇