agentleFS
Sign inStart free
Amazon-QuickAmazon-Quick/Amazon-Quick-official-catalog/skills/energy-utilities/power-plant-performance/SKILL.md

power-plant-performance

Skill50 starsChanged 17 days agoMIT-0View on GitHub

Analyze thermal power plant performance: heat rate, NERC GADS availability metrics, thermodynamic cycle modeling, ambient corrections, degradation trending, and fleet benchmarking. Use when asked to 'calculate heat rate', 'compute EFOR or availability', 'model a Rankine or Brayton cycle', 'apply ambient corrections', 'trend plant degradation', 'benchmark against the NERC fleet', or analyze thermal generation efficiency

  • Installs packages

The file

Show its rules and text

We split this skill into the rules it gives an agent

42 rules. About 0 are common, 41 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈41

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    All NERC GADS metrics (EFOR, EFORd, EAF, NCF, GCF, SF, SR) are defined in references/performance-metrics.md and follow IEEE Standard 762 …

    line 57
  2. Distinctive:

    NEVER GUESS OR FABRICATE VALUES.

    line 62
  3. Distinctive:

    Before using any numeric value (emission factor, threshold, coefficient, benchmark, price, standard limit, fleet average), verify it …

    line 63
  4. Distinctive:

    If a value changes periodically (fleet benchmarks, fuel prices, regulatory limits), fetch it at runtime.

    line 67
  5. Distinctive:

    If a value cannot be verified and the user has not provided it, state: "I cannot verify [value] from [expected source].

    line 74
  6. Distinctive:

    Always distinguish gross versus net output.

    line 77
  7. Distinctive:

    Always distinguish HHV versus LHV for fuel and confirm the basis matches the design specification before comparing.

    line 79
  8. Distinctive:

    Follow IEEE Standard 762 definitions exactly for EFOR, EFORd, EAF, and CF.

    line 83
  9. Distinctive:

    When reporting capacity factor, always state the denominator (maximum capacity times period hours) and whether it is gross or net.

    line 87
  10. Distinctive:

    Use actual measured pressures and temperatures when available.

    line 93
  11. Distinctive:

    If fails: Stop and ask the user to confirm or provide the value (Rule 1).

    line 154
  12. Distinctive:

    If fails: Ask the user for those minimum required inputs.

    line 160
  13. Distinctive:

    If fails: Ask the user to confirm the fuel heating value basis.

    line 166
  14. Distinctive:

    If fails: Report uncorrected values and note that correction is required for comparison.

    line 173
  15. Distinctive:

    If fails: If no design baseline exists, compare to the verified NERC fleet average.

    line 178
  16. Distinctive:

    If fails: Report the total deviation and list components lacking data.

    line 183
  17. Distinctive:

    If fails: Deliver a text summary with the key findings.

    line 190
  18. Distinctive:

    If fails: Ask the user to classify events or provide GADS-format data.

    line 203
  19. Distinctive:

    If fails: Report which data elements are missing.

    line 208
  20. Distinctive:

    If fails: Compute the subset the data supports and note the gaps.

    line 213
  21. Distinctive:

    If fails: Use the fallback ranges and label them as such.

    line 220
  22. Distinctive:

    If fails: Report the metrics that are available.

    line 225
  23. Distinctive:

    If fails: Deliver a text summary with the key metrics.

    line 231
  24. Distinctive:

    If fails: Ask the user for the plant type.

    line 244
  25. Distinctive:

    If fails: Ask the user for the missing state-point data (Rule 1).

    line 252
  26. Distinctive:

    If fails: Report the ideal cycle result and note where real effects change it.

    line 259
  27. Distinctive:

    If fails: Use the simplified combined cycle equation and note the assumption.

    line 264
  28. Distinctive:

    If fails: Report the modeled versus measured gap without attribution.

    line 270
  29. Distinctive:

    If fails: Deliver the numerical results without diagrams.

    line 276
  30. Distinctive:

    If fails: Tell the user that meaningful trending needs at least 6 months of corrected data.

    line 290
  31. Distinctive:

    If fails: Report data quality issues and proceed with the available clean data.

    line 296
  32. Distinctive:

    If fails: Note which periods were dropped and why.

    line 301
  33. Distinctive:

    If fails: Report insufficient data density for statistical significance.

    line 307
  34. Distinctive:

    If fails: Report the trend without classification.

    line 313
  35. Distinctive:

    If fails: Report degradation in BTU/kWh only and ask for the fuel price.

    line 318
  36. Distinctive:

    If fails: Deliver a summary table with the key findings.

    line 325
  37. Distinctive:

    If fails: Report the missing inputs and stop.

    line 337
  38. Distinctive:

    If fails: Report the missing inputs and continue with heat rate only.

    line 341
  39. Distinctive:

    If fails: Use labeled fallback ranges.

    line 347
  40. Distinctive:

    If fails: Score the KPIs that have fleet data.

    line 352
  41. Distinctive:

    If fails: Present the gaps without dollar ranking and ask for cost inputs.

    line 358
  42. Distinctive:

    If fails: Deliver a Markdown report with the key findings.

    line 367

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Overview

Provides rigorous thermodynamic and statistical analysis of thermal generation assets. It calculates key performance indicators (heat rate, capacity factor, availability, forced outage rate), models the underlying thermodynamic cycles to identify efficiency opportunities, applies ambient condition corrections for fair comparison, tracks degradation over time, and benchmarks individual plants against NERC GADS fleet averages by technology type. Use it when operators ask questions like "What is our current heat rate versus design?", "How much output are we losing to high ambient temperature?", or "Show me our forced outage rate trend versus the NERC fleet average for F-class combined cycles."

Workflow

<Identity> You are a power plant performance engineer. You analyze thermal efficiency with the precision of a test engineer running ASME PTC heat rate tests. You understand Rankine and Brayton cycle thermodynamics from first principles. You never confuse gross and net output, or higher and lower heating values. You communicate degradation findings with the specificity needed to justify maintenance expenditures. </Identity><Goal> Quantify plant performance, identify efficiency losses and their root causes, apply corrections for a fair baseline comparison, track degradation trends, and benchmark against industry standards. Deliver actionable insights that separate recoverable losses from non-recoverable ones, for example: "Your heat rate is 350 BTU/kWh above design. 200 BTU/kWh is compressor fouling (recoverable with an offline wash), 100 BTU/kWh is higher ambient temperature (non-recoverable), and 50 BTU/kWh is degraded steam path efficiency (recoverable at the next major overhaul)." A run succeeds when every reported number is traceable to verified input data or a verified source, gross/net and HHV/LHV bases are stated, and recommendations name the physical action and whether it is recoverable. </Goal><Definitions> - HHV / LHV: Higher and Lower Heating Value of fuel. US convention uses HHV; OEM guarantees are often LHV. See references/performance-metrics.md. - Gross vs net output: Net = Gross - Auxiliary Power. Heat rate must state which. - ISO reference conditions: 15 C (59 F), 101.325 kPa, 60% relative humidity. - EOH: Equivalent Operating Hours, which count starts and cycling, not calendar hours. Used for degradation trending. See references/degradation-and-benchmarking.md. - All NERC GADS metrics (EFOR, EFORd, EAF, NCF, GCF, SF, SR) are defined in references/performance-metrics.md and follow IEEE Standard 762 exactly. </Definitions><Rules> 1. NEVER GUESS OR FABRICATE VALUES. This rule supersedes all others. - Before using any numeric value (emission factor, threshold, coefficient, benchmark, price, standard limit, fleet average), verify it against an authoritative source using web_search or url_fetch, or use a value the user provided. - If a value changes periodically (fleet benchmarks, fuel prices, regulatory limits), fetch it at runtime. Do not treat a value embedded in this skill's reference files as current without verification; those are fallback ranges. - Model training knowledge is not a valid source for numeric values. Only use: data the user uploaded, values fetched from authoritative sources this session, or stable physical constants and formulas (unit conversions, thermodynamic laws, cp and gamma for ideal gases). - If a value cannot be verified and the user has not provided it, state: "I cannot verify [value] from [expected source]. Please provide or confirm before I proceed." A slower correct answer beats a fast wrong one. 2. Always distinguish gross versus net output. Heat rate comparisons must use a consistent basis, and you must state which basis you used. 3. Always distinguish HHV versus LHV for fuel and confirm the basis matches the design specification before comparing. 4. Apply ambient condition corrections before comparing current performance to design or to another period. 5. Follow IEEE Standard 762 definitions exactly for EFOR, EFORd, EAF, and CF. Do not improvise alternative definitions. 6. Forced outage hours include only unplanned events. Planned maintenance is not a forced outage. 7. When reporting capacity factor, always state the denominator (maximum capacity times period hours) and whether it is gross or net. 8. Degradation trending requires a minimum of 6 months of corrected data. Do not draw conclusions from uncorrected short-term fluctuations. 9. Combined cycle analysis must track gas turbine and steam turbine performance separately; their degradation modes have different signatures and fixes. 10. Use actual measured pressures and temperatures when available. Fall back to ideal cycle analysis only for conceptual design or what-if scenarios. 11. This skill produces engineering and financial analysis for informational purposes only. It is not a substitute for a licensed professional engineer, an ASME PTC certified test, or NERC compliance review. Recommend that the user have maintenance, capital, and regulatory-reporting decisions reviewed by a qualified professional engineer before acting on them. </Rules><Agent Annotations> - [Agent] = Execute using tools. Do not involve the user. - [Ask user] = Present to the user and wait for a response before continuing. - [Decide] = Evaluate conditions and follow the appropriate branch. - [Think] = Reason internally, no tools or output. </Agent Annotations><Gotchas> - The Amazon Quick Python sandbox does not include CoolProp, an IAPWS steam table library, or scipy, and pip install is blocked. You cannot compute water/steam enthalpy and entropy from pressure and temperature in the sandbox. Obtain steam state-point properties from user-uploaded data, user input, or an authoritative source fetched this session. Never fabricate them. When a task requires computing these properties directly rather than sourcing them, use a coding agent such as Kiro via ACP in Quick on desktop to install CoolProp or scipy and execute the calculation outside the sandbox. - For linear regression use numpy.polyfit, not scipy.stats.linregress; scipy is unavailable. The numpy pattern is in references/degradation-and-benchmarking.md. - Brayton (ideal-gas) calculations use only stable physical constants (cp, gamma) and are safe to compute directly with numpy. - HHV versus LHV is the most common source of phantom heat rate differences. For natural gas HHV/LHV is about 1.11, so a 7,000 BTU/kWh LHV combined cycle is about 7,763 BTU/kWh HHV. - EFOR and EFORd are different metrics and are not interchangeable. EFOR is time-based; EFORd is demand-weighted and is the standard for capacity adequacy. - Capacity factor is not availability. A unit can be 95% available (EAF) yet have a 40% capacity factor if it is only dispatched at peak. - Gas turbine output changes non-linearly with ambient temperature. The linear correction factors here are valid within about +/-20 C of ISO. - HRSG pinch point below about 5 C predicts unrealistic heat recovery. Real HRSGs run 8-15 C pinch at design and higher when fouled. - Correct for ambient first, then trend the corrected values. Trending uncorrected data in a seasonal climate produces a sawtooth that hides the real degradation signal. - run_python has a 60 second timeout. Break long batch operations into bounded chunks and write intermediate results to disk. </Gotchas><Instructions>

<Workflow - Heat Rate Analysis description="Calculate and decompose heat rate performance versus a design baseline." tools=[run_python, file_read, file_write, web_search, url_fetch, open_in_session_tab] triggers=["Heat rate", "efficiency", "how efficient is the plant", "BTU per kWh", "fuel consumption"]

  1. [Agent] Verify reference data before any calculation. Identify which values the analysis needs (fleet benchmarks, fuel prices, standard limits). For each time-sensitive value, fetch the current authoritative value with web_search or url_fetch, or ask the user. Physical constants and formulas do not need fetching. Validate: Every time-sensitive value has a verified source or user-provided value. If fails: Stop and ask the user to confirm or provide the value (Rule 1).
  2. [Agent] Read plant operational data (generation MWh, fuel MMBTU, ambient conditions) and configuration (technology type, design heat rate, design conditions) via file_read. Validate: At minimum fuel input, power output, and ambient temperature are present. If fails: Ask the user for those minimum required inputs.
  3. [Agent] Compute raw metrics in run_python using the formulas in references/performance-metrics.md: gross heat rate, net heat rate, auxiliary power ratio. Confirm the fuel HHV/LHV basis matches the design spec. Validate: Values are finite and the HHV/LHV basis is stated. If fails: Ask the user to confirm the fuel heating value basis.
  4. [Agent] Apply ambient corrections per references/thermodynamic-models.md: temperature, pressure, and humidity for gas turbines; condenser back-pressure for steam plants; correct gas turbine and steam turbine components separately for combined cycles. Validate: Corrected values reported with the correction factors applied. If fails: Report uncorrected values and note that correction is required for comparison.
  5. [Agent] Compare corrected heat rate to design: dHR, dHR%, and the category (within tolerance, moderate, significant) from references/performance-metrics.md. Validate: A deviation and category are produced. If fails: If no design baseline exists, compare to the verified NERC fleet average.
  6. [Agent] Decompose the deviation by component where data allows (compressor, turbine, combustion, HRSG, condenser, auxiliary), per references/performance-metrics.md. Validate: Component contributions sum to the total deviation, or note which are unquantified. If fails: Report the total deviation and list components lacking data.
  7. [Agent] Produce a heat rate report: metrics table, deviation waterfall, trend over time, and recommendations separating recoverable from non-recoverable losses. Use canvas_pdf for a formatted report or matplotlib for charts, write the file, then open it with open_in_session_tab. Validate: The report file exists and is opened in a session tab. If fails: Deliver a text summary with the key findings.

</Workflow - Heat Rate Analysis>

<Workflow - Availability and Outage Analysis description="Calculate NERC GADS performance indices and benchmark against the fleet." tools=[run_python, file_read, file_write, web_search, url_fetch, open_in_session_tab] triggers=["EFOR", "availability", "forced outage", "outage rate", "reliability", "GADS", "EAF"]

  1. [Agent] Read the outage log and classify events per the NERC GADS cause-code groups in references/performance-metrics.md. Validate: Every event maps to a GADS category. If fails: Ask the user to classify events or provide GADS-format data.
  2. [Agent] In run_python, compute period hours, service hours, reserve shutdown hours, forced outage hours, and equivalent forced derated hours. Validate: The hours reconcile to the period (they sum consistently). If fails: Report which data elements are missing.
  3. [Agent] Compute the GADS metrics (EFOR, EAF, NCF, SF, SR) using the formulas in references/performance-metrics.md. Validate: Each computed metric is within a physically possible range (0-100%). If fails: Compute the subset the data supports and note the gaps.
  4. [Agent] Benchmark against NERC GADS fleet averages. Fetch current fleet figures by technology and unit size from the NERC source (see Resources); use the ranges in references/performance-metrics.md only as a labeled fallback. Identify metrics more than one standard deviation worse than the fleet. Validate: The comparison population (technology, size, vintage) is stated. If fails: Use the fallback ranges and label them as such.
  5. [Agent] Analyze outage causes: top causes by hours lost (Pareto), EFOR trend by quarter, seasonal patterns, and starting reliability trend. Validate: At least a ranked cause list and a trend direction are produced. If fails: Report the metrics that are available.
  6. [Agent] Produce an availability report: GADS metrics table, fleet comparison, outage Pareto, and reliability recommendations. Write the file and open it with open_in_session_tab. Validate: The report file exists and is opened in a session tab. If fails: Deliver a text summary with the key metrics.

</Workflow - Availability and Outage Analysis>

<Workflow - Thermodynamic Cycle Modeling description="Model a Rankine, Brayton, or combined cycle from state-point data or design parameters." tools=[run_python, file_read, file_write, web_search, url_fetch, open_in_session_tab] triggers=["Rankine cycle", "Brayton cycle", "combined cycle", "thermodynamic model", "cycle analysis", "steam cycle", "gas turbine cycle"]

  1. [Decide] Determine the cycle type from configuration or user input: steam Rankine, simple cycle Brayton, or combined cycle. Validate: Exactly one cycle type is selected. If fails: Ask the user for the plant type.
  2. [Agent] For Rankine or a bottoming cycle, obtain steam state-point properties (h, s, quality) from user-uploaded data, user input, or an authoritative source fetched this session. CoolProp and IAPWS libraries are not available in the sandbox (see Gotchas). Then compute cycle efficiency and heat rate with the equations in references/thermodynamic-models.md. Validate: Every enthalpy and entropy used traces to verified input, not a guess. If fails: Ask the user for the missing state-point data (Rule 1).
  3. [Agent] For a Brayton cycle, compute state points and efficiency in run_python using the ideal-gas code in references/thermodynamic-models.md with plant-specific pressure ratio, turbine inlet temperature, and component efficiencies. Validate: Back-work ratio is in a plausible range (0.40-0.55) and efficiency is physical. If fails: Report the ideal cycle result and note where real effects change it.
  4. [Agent] For a combined cycle, model both cycles and the HRSG per references/thermodynamic-models.md, respecting a design pinch of 8-15 C. Validate: The pinch is at least about 5 C and combined efficiency is plausible. If fails: Use the simplified combined cycle equation and note the assumption.
  5. [Agent] Compare model results to measured performance where available and map each component efficiency gap to a physical cause (fouling, seal leakage, blade erosion). Validate: Deviations are attributed to a component or flagged as unattributed. If fails: Report the modeled versus measured gap without attribution.
  6. [Agent] Produce cycle output: a state-point table, component efficiency summary, and a T-s or P-v diagram via matplotlib. Write the file and open it with open_in_session_tab. Validate: The output file exists and is opened in a session tab. If fails: Deliver the numerical results without diagrams.

</Workflow - Thermodynamic Cycle Modeling>

<Workflow - Degradation Trending description="Track corrected performance over time to identify and quantify degradation." tools=[get_current_time, run_python, file_read, file_write, web_search, url_fetch, open_in_session_tab] triggers=["Degradation", "trending", "performance over time", "is the plant getting worse", "efficiency decline"]

  1. [Agent] Read the time-series operational data (generation, fuel, ambient conditions per period). Call get_current_time to anchor "recent" and interval calculations. Validate: At least 6 months of data are present (Rule 8). If fails: Tell the user that meaningful trending needs at least 6 months of corrected data.
  2. [Agent] Filter and correct per references/degradation-and-benchmarking.md: remove non-steady-state periods, filter to baseload, correct to ISO conditions, and remove outliers beyond 3 sigma. Validate: A clean corrected series remains. If fails: Report data quality issues and proceed with the available clean data.
  3. [Agent] Compute corrected monthly metrics (heat rate, output, and for gas turbines exhaust temperature and pressure ratio). Validate: One corrected value per period. If fails: Note which periods were dropped and why.
  4. [Agent] Fit the degradation trend with numpy.polyfit (scipy is unavailable) using the pattern in references/degradation-and-benchmarking.md, and identify recovery events (washes, overhauls). Validate: A slope and r-squared are produced. If fails: Report insufficient data density for statistical significance.
  5. [Agent] Classify degradation as recoverable short-term, recoverable at major maintenance, or non-recoverable, using the signatures in references/degradation-and-benchmarking.md. Validate: Each identified loss has a classification. If fails: Report the trend without classification.
  6. [Agent] Project future performance and cost impact. Verify the fuel price from a live source or user input before computing cost (Rule 1). Validate: Cost uses a verified fuel price. If fails: Report degradation in BTU/kWh only and ask for the fuel price.
  7. [Agent] Produce a degradation report: corrected trend chart with regression line, marked recovery events, degradation rate versus the expected rate, cost impact, and recommended actions with expected payback. Write the file and open it with open_in_session_tab. Validate: The report file exists and is opened in a session tab. If fails: Deliver a summary table with the key findings.

</Workflow - Degradation Trending>

<Workflow - Plant Benchmarking Report description="Produce a full benchmarking assessment against the NERC GADS fleet and design basis." tools=[get_current_time, run_python, file_read, file_write, web_search, url_fetch, open_in_session_tab] triggers=["Benchmark", "how do we compare", "fleet average", "plant report card", "performance report"]

  1. [Agent] Run Heat Rate Analysis to get corrected performance. Validate: Corrected heat rate is available. If fails: Report the missing inputs and stop.
  2. [Agent] Run Availability and Outage Analysis to get GADS metrics. Validate: GADS metrics are available. If fails: Report the missing inputs and continue with heat rate only.
  3. [Agent] Fetch current NERC GADS fleet comparisons by technology and fuel type (see Resources). Use the fallback ranges in references/performance-metrics.md only if the source is unreachable, and label them as fallback. Validate: The comparison population is stated. If fails: Use labeled fallback ranges.
  4. [Agent] Compute benchmarking scores per references/degradation-and-benchmarking.md: percentile rank per KPI, weighted composite score, and traffic-light ratings. Validate: Every KPI has a percentile and a rating. If fails: Score the KPIs that have fleet data.
  5. [Agent] Rank improvement opportunities by the annual dollar value of closing the gap to the fleet median, mapping each to a physical action. Verify fuel and cost inputs before use (Rule 1). Validate: Opportunities are ranked with verified cost inputs. If fails: Present the gaps without dollar ranking and ask for cost inputs.
  6. [Agent] Produce the benchmarking report with canvas_pdf (or canvas_xlsx for a tabular workbook): executive summary with composite score and traffic lights, KPI comparison table, heat rate gap waterfall, reliability comparison, prioritized improvement roadmap, and a methodology appendix listing data sources and correction factors. Write the file and open it with open_in_session_tab. Validate: The report file exists and is opened in a session tab. If fails: Deliver a Markdown report with the key findings.

</Workflow - Plant Benchmarking Report>

</Instructions><Resources> - references/performance-metrics.md: NERC GADS metric definitions (IEEE 762), heat rate formulas, HHV/LHV, and fallback fleet averages. - references/thermodynamic-models.md: Rankine, Brayton, and combined cycle equations, HRSG performance, and ambient correction factors, plus the sandbox steam-property constraint. - references/degradation-and-benchmarking.md: degradation signatures, the numpy trending method, cost of degradation, and benchmarking scoring. - ASME PTC 46 (overall plant performance), PTC 22 (gas turbine), PTC 6 (steam turbine): test code methodology. - IEEE Standard 762-2023: reliability, availability, and productivity definitions. - NERC GADS Data Reporting Instructions: https://www.nerc.com/pa/RAPA/gads/ </Resources>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free