Skill Tracer
Skills › Scientific Agent Skills › simpy

simpy

skill · 314 lines · MIT · skills/simpy/SKILL.md

The facts

Its description

Builds, inspects, tests, and analyzes bounded process-based discrete-event simulations with SimPy. Use for event scheduling, resource queues, interrupts, monitoring, independent replications, warm-up, and reproducible output analysis.

The description the agent reads to decide when to use it.

From its settingsline 3

Tools it may use, or may not

allowed-tools: Read Write Edit Bash Glob

Tools it may use while it runs without asking you first.

From its settingsline 6

Runs scripts

bin/activate, scripts/resource_monitor.py, python skills/simpy/scripts/bounded_queue_scenario.py, python skills/simpy/scripts/replication_runner.py, python skills/simpy/scripts/event_trace_summary.py (first 5 of 9 lines)

Scripts the text names. Found by matching words, so treat them as pointers.

Found by matching wordsline 41 line 228 line 248 line 249 line 250

Files it mentions

references/sources.md, references/simulation-methodology.md, references/events.md, references/monitoring.md, references/process-interaction.md, references/resources.md (first 5 of 16 lines)

Files the text names, such as ones to read or write. Found by matching words, so treat them as pointers.

Found by matching wordsline 48 line 78 line 148 line 174 line 208

Stops for a person

1 line stops to ask a person

Lines that stop and wait for a person before going on. Found by matching words, so treat them as pointers.

Found by matching wordsline 63

Licence

MIT, from the skill file

The terms its author shares it under, which let it be shown here.

From its settingsline 4 licence text

Other settings

compatibility: Upstream SimPy 4.1.2 supports Python 3.8+; bundled CLIs require Python 3.10+, uv, and SimPy 4.1.2. They use only SimPy and the standard library, operate on local bounded inputs, and make no network calls. metadata: version: "1.6" last-reviewed: "2026-10-01" skill-author: K-Dense Inc.

More settings at the top of the file, shown as written.

From its settingsline 5 line 7
Other files in this skill (15) Close

The text

Open on GitHub

Most marks come from matching words in the file, so treat them as pointers.

1---
2name: simpy
3description: Builds, inspects, tests, and analyzes bounded process-based discrete-event simulations with SimPy. Use for event scheduling, resource queues, interrupts, monitoring, independent replications, warm-up, and reproducible output analysis.
4license: MIT
5compatibility: Upstream SimPy 4.1.2 supports Python 3.8+; bundled CLIs require Python 3.10+, uv, and SimPy 4.1.2. They use only SimPy and the standard library, operate on local bounded inputs, and make no network calls.
6allowed-tools: Read Write Edit Bash Glob
7metadata:
8 version: "1.6"
9 last-reviewed: "2026-10-01"
10 skill-author: K-Dense Inc.
11---
13# SimPy
15## Scope
17Use this skill for process-based discrete-event models where active entities yield
18events and contend for resources: queues, production systems, logistics, networks,
19service operations, inventory, and other event-driven systems.
21SimPy supplies an event scheduler and modeling primitives. It does **not** choose a
22scientifically valid conceptual model, input distribution, warm-up, run length,
23replication count, estimand, or causal interpretation. Treat those as simulation-study
24methodology, not SimPy API behavior.

Scope

Use this skill for process-based discrete-event models where active entities yield events and contend for resources: queues, production systems, logistics, networks, service operations, inventory, and other event-driven systems.

SimPy supplies an event scheduler and modeling primitives. It does not choose a scientifically valid conceptual model, input distribution, warm-up, run length, replication count, estimand, or causal interpretation. Treat those as simulation-study methodology, not SimPy API behavior.

Raw lines 15 to 25
26## Current release and installation
28Reviewed **2026-10-01** against current official documentation and the released source:
30- Latest stable: **SimPy 4.1.2**, released on PyPI 2026-05-24; source tag
31 `4.1.2` points to commit `f4381649`.
32- Package metadata requires Python **>=3.8** and classifies CPython 3.8-3.14
33 plus PyPy. SimPy has no runtime dependencies.
34- 4.1.2 adds Python 3.13/3.14 support and modern-interpreter test fixes.
35- Upstream and this skill are MIT-licensed.
37Create a reproducible environment:
39```bash
40uv venv --python 3.13
41source .venv/bin/activate
42uv pip install "simpy==4.1.2"
43python -c "import importlib.metadata; print(importlib.metadata.version('simpy'))"
44```
46Do not silently substitute the `latest` documentation build: it may describe an
47unreleased development revision. Use the versioned 4.1.2 links in

Current release and installation

Reviewed 2026-10-01 against current official documentation and the released source:

  • Latest stable: SimPy 4.1.2, released on PyPI 2026-05-24; source tag 4.1.2 points to commit f4381649.
  • Package metadata requires Python >=3.8 and classifies CPython 3.8-3.14 plus PyPy. SimPy has no runtime dependencies.
  • 4.1.2 adds Python 3.13/3.14 support and modern-interpreter test fixes.
  • Upstream and this skill are MIT-licensed.

Create a reproducible environment:

uv venv --python 3.13
source .venv/bin/activate
uv pip install "simpy==4.1.2"
python -c "import importlib.metadata; print(importlib.metadata.version('simpy'))"

Do not silently substitute the latest documentation build: it may describe an unreleased development revision. Use the versioned 4.1.2 links in references/sources.md.

Raw lines 26 to 49
Runs code bin/activate :41
Reads a file references/sources.md :48
50## Model workflow
521. **Define purpose and estimands.** State the decision/question, system boundary,
53 entities, resources, state, outputs, time units, and terminating event or
54 steady-state target.
552. **Write a conceptual model first.** Record assumptions, distributions,
56 routing, priorities, initial conditions, and omitted mechanisms.
573. **Implement generators.** A SimPy process is an event-yielding Python generator.
58 Register the generator object with `env.process(...)`.
594. **Bound execution.** Give every production run explicit time, entity, event, and
60 replication caps. Never call `env.run()` on a model containing an endless process.
61 A time horizon alone cannot stop an endless `yield env.timeout(0)` loop: events
62 keep running at the same simulation time. Add an event-count or no-time-progress
63 guard, and wait on state-change events instead of zero-delay busy polling.
645. **Separate random streams.** Use local RNG instances for logically distinct
65 stochastic sources; retain a seed manifest.
666. **Instrument deliberately.** Observe state after the transition of interest,
67 close time-weighted intervals at the horizon, and test that monitoring does not
68 alter event order.
697. **Verify and validate.** Test deterministic edge cases, conservation identities,
70 traces, queue discipline, and analytical benchmarks; compare against system or
71 expert evidence for the stated purpose.
728. **Run independent replications.** Make intervals from replication-level
73 estimates, not correlated entities within one run.
749. **Report limitations.** Include initialization, unfinished entities, run length,
75 seeds/streams, precision, sensitivity, and validation evidence. Never convert
76 simulation association into a causal claim.
78Read `references/simulation-methodology.md` before making inferential claims.

Model workflow

  1. Define purpose and estimands. State the decision/question, system boundary, entities, resources, state, outputs, time units, and terminating event or steady-state target.
  2. Write a conceptual model first. Record assumptions, distributions, routing, priorities, initial conditions, and omitted mechanisms.
  3. Implement generators. A SimPy process is an event-yielding Python generator. Register the generator object with env.process(...).
  4. Bound execution. Give every production run explicit time, entity, event, and replication caps. Never call env.run() on a model containing an endless process. A time horizon alone cannot stop an endless yield env.timeout(0) loop: events keep running at the same simulation time. Add an event-count or no-time-progress guard, and wait on state-change events instead of zero-delay busy polling.
  5. Separate random streams. Use local RNG instances for logically distinct stochastic sources; retain a seed manifest.
  6. Instrument deliberately. Observe state after the transition of interest, close time-weighted intervals at the horizon, and test that monitoring does not alter event order.
  7. Verify and validate. Test deterministic edge cases, conservation identities, traces, queue discipline, and analytical benchmarks; compare against system or expert evidence for the stated purpose.
  8. Run independent replications. Make intervals from replication-level estimates, not correlated entities within one run.
  9. Report limitations. Include initialization, unfinished entities, run length, seeds/streams, precision, sensitivity, and validation evidence. Never convert simulation association into a causal claim.

Read references/simulation-methodology.md before making inferential claims.

Raw lines 50 to 79
Involves a person and wait :63
80## Minimal bounded model
82```python
83import random
84import simpy
86HORIZON = 480.0
87arrival_rng = random.Random(101)
88service_rng = random.Random(202)
89env = simpy.Environment()
90server = simpy.Resource(env, capacity=2)
91completed = []
93def customer(arrival):
94 with server.request() as request:
95 yield request
96 wait = env.now - arrival
97 yield env.timeout(service_rng.expovariate(1 / 6.0))
98 completed.append((env.now, wait))
100def arrivals():
101 for _ in range(10_000): # Entity cap.
102 delay = arrival_rng.expovariate(1 / 4.0)
103 if env.now + delay >= HORIZON:
104 return
105 yield env.timeout(delay)
106 env.process(customer(env.now))
108env.process(arrivals())
109env.run(until=HORIZON)
110```
112The numeric horizon is half-open: normal events scheduled exactly at `480.0` are
113not processed. Report unfinished entities rather than silently treating them as
114completed observations.

Minimal bounded model

import random
import simpy

HORIZON = 480.0
arrival_rng = random.Random(101)
service_rng = random.Random(202)
env = simpy.Environment()
server = simpy.Resource(env, capacity=2)
completed = []

def customer(arrival):
    with server.request() as request:
        yield request
        wait = env.now - arrival
        yield env.timeout(service_rng.expovariate(1 / 6.0))
    completed.append((env.now, wait))

def arrivals():
    for _ in range(10_000):  # Entity cap.
        delay = arrival_rng.expovariate(1 / 4.0)
        if env.now + delay >= HORIZON:
            return
        yield env.timeout(delay)
        env.process(customer(env.now))

env.process(arrivals())
env.run(until=HORIZON)

The numeric horizon is half-open: normal events scheduled exactly at 480.0 are not processed. Report unfinished entities rather than silently treating them as completed observations.

Raw lines 80 to 115
116## Core semantics

Core semantics

Raw lines 116 to 117
118### Environment and deterministic ordering
120`Environment` is single-threaded. The queue is ordered by simulation time, event
121priority, then a strictly increasing event ID. Same-time, same-priority events are
122therefore processed FIFO in scheduling order. Model processes may represent
123concurrency, but callbacks execute sequentially and deterministically.
125This orders the events currently queued. A callback can insert an urgent event at
126the current time, so a valid processing trace need not have globally increasing
127priority or event IDs within a timestamp.
129- `env.now`: unitless simulation clock; choose and document one unit.
130- `env.peek()`: next event time or infinity.
131- `env.step()`: process one event; raises `EmptySchedule` when empty.
132- `env.active_process`: currently executing process, otherwise `None`.
133- `env.run()`: drain the queue; unsafe with recurring or endless processes.
135`env.run(until=number)` and `env.run(until=event)` are not interchangeable at
136boundaries:
138- A numeric value schedules an urgent stop event and excludes ordinary events at
139 that exact time.
140- An Event criterion returns that event's value when its stop callback fires.
141 Other same-time ordering depends on priority and scheduling order.
142- In 4.1.2, `Environment.step()` preserves callbacks remaining after
143 `StopSimulation` by rescheduling the target. Consequently, after
144 `env.run(until=target)`, `target.processed` can remain `False` until one more
145 `step()`/`run()` even though its value was returned. Do not use `processed` as the
146 sole post-run completion test.

Environment and deterministic ordering

Environment is single-threaded. The queue is ordered by simulation time, event priority, then a strictly increasing event ID. Same-time, same-priority events are therefore processed FIFO in scheduling order. Model processes may represent concurrency, but callbacks execute sequentially and deterministically.

This orders the events currently queued. A callback can insert an urgent event at the current time, so a valid processing trace need not have globally increasing priority or event IDs within a timestamp.

  • env.now: unitless simulation clock; choose and document one unit.
  • env.peek(): next event time or infinity.
  • env.step(): process one event; raises EmptySchedule when empty.
  • env.active_process: currently executing process, otherwise None.
  • env.run(): drain the queue; unsafe with recurring or endless processes.

env.run(until=number) and env.run(until=event) are not interchangeable at boundaries:

  • A numeric value schedules an urgent stop event and excludes ordinary events at that exact time.
  • An Event criterion returns that event's value when its stop callback fires. Other same-time ordering depends on priority and scheduling order.
  • In 4.1.2, Environment.step() preserves callbacks remaining after StopSimulation by rescheduling the target. Consequently, after env.run(until=target), target.processed can remain False until one more step()/run() even though its value was returned. Do not use processed as the sole post-run completion test.

See references/events.md and references/monitoring.md.

Raw lines 118 to 149
Reads a file references/events.md :148
Reads a file references/monitoring.md :148
150### Event, Timeout, Process, and Condition
152- An `Event` moves once through not-triggered -> triggered/scheduled -> processed.
153 `succeed(value)` or `fail(exception)` triggers it once.
154- A `Timeout` triggers when created, is scheduled for `now + delay`, and cannot be
155 manually succeeded again.
156- `env.process(generator)` creates a `Process`; the generator resumes with the
157 yielded event value. Returning from the generator succeeds the Process with that
158 return value. Uncaught exceptions fail it.
159- `AnyOf` / `a | b` and `AllOf` / `a & b` yield a `ConditionValue`: an ordered,
160 dict-like mapping from **event objects** to their values. Test membership using
161 the original event objects; do not assume a scalar result.
162- `AnyOf` does not cancel losing events. Explicitly cancel pending resource
163 requests when abandoning them; ordinary timeouts remain scheduled.

Event, Timeout, Process, and Condition

  • An Event moves once through not-triggered -> triggered/scheduled -> processed. succeed(value) or fail(exception) triggers it once.
  • A Timeout triggers when created, is scheduled for now + delay, and cannot be manually succeeded again.
  • env.process(generator) creates a Process; the generator resumes with the yielded event value. Returning from the generator succeeds the Process with that return value. Uncaught exceptions fail it.
  • AnyOf / a | b and AllOf / a & b yield a ConditionValue: an ordered, dict-like mapping from event objects to their values. Test membership using the original event objects; do not assume a scalar result.
  • AnyOf does not cancel losing events. Explicitly cancel pending resource requests when abandoning them; ordinary timeouts remain scheduled.
Raw lines 150 to 164
165### Interrupts
167`process.interrupt(cause)` schedules an urgent interruption that throws
168`simpy.Interrupt` into the target generator. Catch it around the yielded work that
169may be interrupted, inspect `interrupt.cause`, update remaining work, then either
170resume, re-yield the original event, or terminate.
172Interrupting a process removes its resume callback from its current target; it does
173not cancel that target event. A process cannot interrupt itself or a terminated

Interrupts

process.interrupt(cause) schedules an urgent interruption that throws simpy.Interrupt into the target generator. Catch it around the yielded work that may be interrupted, inspect interrupt.cause, update remaining work, then either resume, re-yield the original event, or terminate.

Interrupting a process removes its resume callback from its current target; it does not cancel that target event. A process cannot interrupt itself or a terminated process. See references/process-interaction.md.

Raw lines 165 to 175
176## Shared resources
178| Type | Semantics |
179|---|---|
180| `Resource` | FIFO semaphore-like usage slots |
181| `PriorityResource` | Queued requests sorted by lower numeric priority first |
182| `PreemptiveResource` | Priority queue plus optional preemption of a current user |
183| `Container` | Homogeneous numeric level; `put`/`get` wait for capacity/material |
184| `Store` | FIFO Python objects |
185| `FilterStore` | First available item satisfying the request's predicate |
186| `PriorityStore` | Comparable items returned in priority order |
188Use a request context manager:
190```python
191def job(env, resource):
192 with resource.request() as request:
193 yield request
194 yield env.timeout(3)
195```
197On exit it releases an acquired request or cancels a still-pending one, including
198during exception unwinding. For a manually retained pending `put`/`get`/request,
199call `cancel()` if an interrupt or timeout makes the process abandon it.
201`PreemptiveResource.request(priority=..., preempt=True)` uses lower numbers as
202higher priority. The preempted process receives an `Interrupt` whose cause is a
203`Preempted` object: `cause.by` is the preempting Process,
204`cause.usage_since` is when use began, and `cause.resource` is the resource.
205Queued priority takes precedence over the `preempt` flag; mixing preempting and
206non-preempting requests needs explicit tests.
208Read `references/resources.md` for blocked operations, queue rules, and examples.

Shared resources

TypeSemantics
ResourceFIFO semaphore-like usage slots
PriorityResourceQueued requests sorted by lower numeric priority first
PreemptiveResourcePriority queue plus optional preemption of a current user
ContainerHomogeneous numeric level; put/get wait for capacity/material
StoreFIFO Python objects
FilterStoreFirst available item satisfying the request's predicate
PriorityStoreComparable items returned in priority order

Use a request context manager:

def job(env, resource):
    with resource.request() as request:
        yield request
        yield env.timeout(3)

On exit it releases an acquired request or cancels a still-pending one, including during exception unwinding. For a manually retained pending put/get/request, call cancel() if an interrupt or timeout makes the process abandon it.

PreemptiveResource.request(priority=..., preempt=True) uses lower numbers as higher priority. The preempted process receives an Interrupt whose cause is a Preempted object: cause.by is the preempting Process, cause.usage_since is when use began, and cause.resource is the resource. Queued priority takes precedence over the preempt flag; mixing preempting and non-preempting requests needs explicit tests.

Read references/resources.md for blocked operations, queue rules, and examples.

Raw lines 176 to 209
Reads a file references/resources.md :208
210## Monitoring and stepping
212Prefer explicit domain observations at state transitions. For generic resource
213monitoring, wrappers or subclasses can inspect `count`, `queue`, `level`, `items`,
214`put_queue`, and `get_queue`. For event tracing, `schedule()` and `step()` are the
215central hooks.
217Queue measurements are timing-sensitive:
219- A request method's pre-state, post-call state, grant callback, and release
220 callback can all differ at the same simulation timestamp.
221- Sample averages weight event observations, not time. Compute area under the
222 post-transition state path and divide by elapsed time.
223- Add initial and final samples; close the last interval at the analysis horizon.
224- `env._queue`, resource `_env`, and monkey-patching are implementation details.
225 Pin SimPy, isolate the instrumentation, and regression-test after upgrades.
226- Tracing every event changes runtime and memory use; cap trace records.

Monitoring and stepping

Prefer explicit domain observations at state transitions. For generic resource monitoring, wrappers or subclasses can inspect count, queue, level, items, put_queue, and get_queue. For event tracing, schedule() and step() are the central hooks.

Queue measurements are timing-sensitive:

  • A request method's pre-state, post-call state, grant callback, and release callback can all differ at the same simulation timestamp.
  • Sample averages weight event observations, not time. Compute area under the post-transition state path and divide by elapsed time.
  • Add initial and final samples; close the last interval at the analysis horizon.
  • env._queue, resource _env, and monkey-patching are implementation details. Pin SimPy, isolate the instrumentation, and regression-test after upgrades.
  • Tracing every event changes runtime and memory use; cap trace records.

Use scripts/resource_monitor.py and references/monitoring.md.

Raw lines 210 to 229
Reads a file scripts/resource_monitor.py :228
Reads a file references/monitoring.md :228
230## Real-time execution
232`simpy.rt.RealtimeEnvironment(initial_time=0, factor=1.0, strict=True)` maps one
233simulation unit to `factor` wall-clock seconds. In strict mode, `step()`/`run()`
234raises `RuntimeError` when computation falls behind. `strict=False` tolerates lag;
235it does not restore timing accuracy. Develop logic with `Environment`, then run
236separate timing tests with generous platform-aware tolerances. See

Real-time execution

simpy.rt.RealtimeEnvironment(initial_time=0, factor=1.0, strict=True) maps one simulation unit to factor wall-clock seconds. In strict mode, step()/run() raises RuntimeError when computation falls behind. strict=False tolerates lag; it does not restore timing accuracy. Develop logic with Environment, then run separate timing tests with generous platform-aware tolerances. See references/real-time.md.

Raw lines 230 to 238
Reads a file references/real-time.md :237
239## Bundled safe CLIs
241All CLIs use a fixed built-in queue model or summarize local artifacts. They reject
242unknown JSON keys, URLs, symlinks, non-finite numbers, oversized inputs, and
243unbounded time/events/entities/replications. They never evaluate config text,
244execute user Python, import plugins, or call a network service.
246```bash
247# Inspect all options.
248python skills/simpy/scripts/bounded_queue_scenario.py --help
249python skills/simpy/scripts/replication_runner.py --help
250python skills/simpy/scripts/event_trace_summary.py --help
251python skills/simpy/scripts/validate_simulation_config.py --help
253# Deterministic built-in scenario.
254python skills/simpy/scripts/bounded_queue_scenario.py
256# Independent replications with replication-level Student-t intervals.
257python skills/simpy/scripts/replication_runner.py
259# Validate only; no simulation runs.
260python skills/simpy/scripts/validate_simulation_config.py config.json
261```
263The replication runner refuses one-replication intervals. Its intervals quantify
264Monte Carlo uncertainty under the configured model; they neither validate the model
265nor identify causal effects. See `references/cli-guide.md`.
267Schema 1.2 reports explicit metric windows: throughput counts all departures during
268`[warm_up, horizon)`, loss uses arrivals/rejections in that same window, and customer
269means use post-warm-up arrivals completed before the horizon. These customer means
270remain vulnerable to completion censoring. The scripts require the pinned SimPy
271version because tracing depends on its scheduler internals.

Bundled safe CLIs

All CLIs use a fixed built-in queue model or summarize local artifacts. They reject unknown JSON keys, URLs, symlinks, non-finite numbers, oversized inputs, and unbounded time/events/entities/replications. They never evaluate config text, execute user Python, import plugins, or call a network service.

# Inspect all options.
python skills/simpy/scripts/bounded_queue_scenario.py --help
python skills/simpy/scripts/replication_runner.py --help
python skills/simpy/scripts/event_trace_summary.py --help
python skills/simpy/scripts/validate_simulation_config.py --help

# Deterministic built-in scenario.
python skills/simpy/scripts/bounded_queue_scenario.py

# Independent replications with replication-level Student-t intervals.
python skills/simpy/scripts/replication_runner.py

# Validate only; no simulation runs.
python skills/simpy/scripts/validate_simulation_config.py config.json

The replication runner refuses one-replication intervals. Its intervals quantify Monte Carlo uncertainty under the configured model; they neither validate the model nor identify causal effects. See references/cli-guide.md.

Schema 1.2 reports explicit metric windows: throughput counts all departures during [warm_up, horizon), loss uses arrivals/rejections in that same window, and customer means use post-warm-up arrivals completed before the horizon. These customer means remain vulnerable to completion censoring. The scripts require the pinned SimPy version because tracing depends on its scheduler internals.

Raw lines 239 to 272
Runs code python skills/simpy/scripts/bounded_queue_scenario.py :248
Runs code python skills/simpy/scripts/replication_runner.py :249
Runs code python skills/simpy/scripts/event_trace_summary.py :250
Runs code python skills/simpy/scripts/validate_simulation_config.py :251
Reads a file references/cli-guide.md :265
273## Testing
275Use deterministic unit tests for ordering, boundary times, conditions, interrupts,
276all resource disciplines, conservation, event/entity limits, seed reproducibility,
277and monitor non-interference. Add stochastic tests only as broad distributional
278checks with fixed seeds; avoid brittle exact sample estimates.
280Run the skill's suite in the exact pinned environment without bytecode artifacts:
282```bash
283PYTHONDONTWRITEBYTECODE=1 uv run --isolated --no-project \
284 --python 3.13 --with "simpy==4.1.2" --with pytest \
285 python -m pytest tests/simpy -q
286```

Testing

Use deterministic unit tests for ordering, boundary times, conditions, interrupts, all resource disciplines, conservation, event/entity limits, seed reproducibility, and monitor non-interference. Add stochastic tests only as broad distributional checks with fixed seeds; avoid brittle exact sample estimates.

Run the skill's suite in the exact pinned environment without bytecode artifacts:

PYTHONDONTWRITEBYTECODE=1 uv run --isolated --no-project \
  --python 3.13 --with "simpy==4.1.2" --with pytest \
  python -m pytest tests/simpy -q
Raw lines 273 to 287
288## References
290- `references/events.md` — scheduler, lifecycle, run boundaries, conditions
291- `references/process-interaction.md` — generators, shared events, interrupts
292- `references/resources.md` — all Resource, Container, and Store variants
293- `references/monitoring.md` — time weighting, queue timing, tracing, stepping
294- `references/real-time.md` — factor, strict mode, drift, timing tests
295- `references/simulation-methodology.md` — replications, warm-up, validation, CI
296- `references/cli-guide.md` — schemas, bounds, outputs, and safe CLI examples
297- `references/sources.md` — dated official and primary-method sources

References

Raw lines 288 to 298
Reads a file references/events.md :290
Reads a file references/resources.md :292
Reads a file references/monitoring.md :293
Reads a file references/real-time.md :294
Reads a file references/cli-guide.md :296
Reads a file references/sources.md :297
Boilerplate, lines 299 to 314. The same text appears in 125 other files here. Close
299## Citing Scientific Agent Skills
301This skill is part of Scientific Agent Skills by K-Dense. If it materially contributed to a
302manuscript, report, presentation, or code release, add the paper to the references or
303software section and tell the user you did so:
305> Kassis, T., Agarwal, V., He, Y., Patel, D., & Brueckner, A. M. (2026). Scientific Agent
306> Skills: A Library of Procedural Knowledge for Research Agents. arXiv:2609.00065.
307> https://doi.org/10.48550/arXiv.2609.00065
309Always cite the current version. The DOI and https://arxiv.org/abs/2609.00065 resolve to the
310latest arXiv version, so never append a version suffix such as `v1`. When network access is
311available, fetch https://arxiv.org/abs/2609.00065 (or
312http://export.arxiv.org/api/query?id_list=2609.00065) before writing the reference and take
313the author list, year, and version from that record. If the record lists a journal reference
314or publisher DOI, cite the published version instead.

From K-Dense-AI/scientific-agent-skills at 5f2bc03, 2026-10-26. Not read by a model yet. Summary and techniques by Claude Opus 5.5 on 2026-11-06.