Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add pjt222/agent-almanac --skill analyze-diffusion-dynamicsgit clone --depth 1 https://github.com/pjt222/agent-almanacWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pjt222/agent-almanac/analyze-diffusion-dynamics)<a href="https://agentmods.dev/skills/pjt222/agent-almanac/analyze-diffusion-dynamics"><img src="https://agentmods.dev/badge/skills/pjt222/agent-almanac/analyze-diffusion-dynamics.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00080 | $0.05450 |
| Opus 5 | $0.00040 | $0.02725 |
| Sonnet 5 | $0.00016 | $0.01090 |
| Haiku 4.5 | $0.00008 | $0.00545 |
Grade A, and why
analyze-diffusion-dynamics scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 500 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Analyze Diffusion Dynamics
Characterize the behavior of diffusion processes by specifying their stochastic differential equations, deriving the corresponding Fokker-Planck equation, computing first-passage time distributions analytically or numerically, performing parameter sensitivity analysis, and validating analytical results against Monte Carlo simulation.
When to Use
- Deriving the probability density evolution of a continuous-time diffusion process
- Computing mean first-passage times or full first-passage time distributions for bounded diffusion
- Analyzing how drift, diffusion coefficient, and boundary parameters affect process behavior
- Validating closed-form solutions against stochastic simulation
- Building intuition for the dynamics underlying drift-diffusion models or generative diffusion processes
Inputs
- Required: SDE specification (drift function, diffusion coefficient, domain/boundaries)
- Required: Parameter values or ranges for the drift and diffusion functions
- Required: Boundary conditions (absorbing, reflecting, or mixed)
- Optional: Time horizon for transient analysis (default: auto-detect from dynamics)
- Optional: Spatial discretization resolution for numerical PDE solvers (default: dx=0.001)
- Optional: Number of Monte Carlo trajectories for simulation validation (default: 10000)
Procedure
Step 1: Specify the SDE Model
Define the drift function, diffusion coefficient, and boundary conditions for the process.
- Write the SDE in standard Ito form:
dX(t) = mu(X, t) dt + sigma(X, t) dW(t)
where mu is the drift function, sigma is the diffusion coefficient, and W(t) is a standard Wiener process.
- Implement the SDE components in code:
import numpy as np
class DiffusionProcess:
"""A one-dimensional diffusion process specified by drift and diffusion functions."""
def __init__(self, drift_fn, diffusion_fn, lower_bound=None, upper_bound=None,
boundary_type="absorbing"):
self.drift = drift_fn
self.diffusion = diffusion_fn
self.lower_bound = lower_bound
self.upper_bound = upper_bound
self.boundary_type = boundary_type
# Example: Ornstein-Uhlenbeck process on [0, a]
ou_process = DiffusionProcess(
drift_fn=lambda x, t: 2.0 * (0.5 - x), # mean-reverting drift
diffusion_fn=lambda x, t: 0.1, # constant diffusion
lower_bound=0.0,
upper_bound=1.0,
boundary_type="absorbing"
)
# Example: Standard DDM (constant drift and diffusion)
ddm_process = DiffusionProcess(
drift_fn=lambda x, t: 0.5, # drift rate v
diffusion_fn=lambda x, t: 1.0, # unit diffusion (s=1, convention)
lower_bound=0.0, # lower absorbing boundary
upper_bound=1.5, # upper absorbing boundary (a)
boundary_type="absorbing"
)
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 500 lines · 80 tokens per session scan A 21c5724bd97e
analyze-diffusion-dynamics is a skill published in the GitHub repository pjt222/agent-almanac (32 stars, last pushed 2d ago), licensed MIT. It adds 80 tokens to every session and 5,450 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
audit-pr
Audit a whole PR against the delivery contract and return MERGE-READY or evidenced blockers with the full URL. Consumes the current review-change REVIEW-PASS receipt instead of re-running review axes; posts a SHA-bound ready comment; never edits or merges. Triggers: "audit-pr", "is this PR ready", "merge gate".
design-feature
Turn a raw idea or existing feature into a designed product SPEC by completing entity, integration, role, and expectation closure. Upserts never destroy recorded decisions. Triggers: "design-feature", "design this feature", "define product scope".
plan-feature
Route designed features or issues into engineering planning and roadmap registration; undesigned work stops at design-feature. Supports --next, --from-issue, and --scaffold. Triggers: "plan-feature", "plan a feature", "plan the next roadmap feature", "create SPEC and TASKS".
product-audit
Audit the whole product across code, quality, process, docs, roadmap, and tooling. Persist one severity-ranked, F-numbered report with proposals; never fix or file work. Triggers: "product-audit", "audit the product", "full health check", "are we product-ready", "CTO review".
audit-docs
Audit cross-document coherence: docs ↔ roadmap ↔ code ↔ fix index ↔ issues. Finds drift — features in docs/ not in the roadmap (or vice versa), fix-index entries already merged/closed, broken documentation-map links, dependency cycles, artifacts in the wrong language, naming-convention violations — and reports them…
plan-feature-from-issue
Internal step of plan-feature: turn a feature-request issue into a scoped, sized, roadmap-mapped SPEC product half (capability closure satisfied) with Closes #N traceability.