diff --git a/optimizing/index.md b/optimizing/index.md
index 1cd6a2e..8c96086 100644
--- a/optimizing/index.md
+++ b/optimizing/index.md
@@ -98,6 +98,8 @@ Several packages exist for this purpose:
 - [AirSpeedVelocity.jl](https://github.com/MilesCranmer/AirspeedVelocity.jl)
 - [PkgJogger.jl](https://github.com/awadell1/PkgJogger.jl)
 
+For tracking time-to-first-X (TTFX) performance across different Julia versions and package updates, [Julia-TTFX-Snippets](https://github.com/tecosaur/Julia-TTFX-Snippets) provides a collection of TTFX workloads specifically designed for longitudinal performance testing of Julia packages.
+
 ### Other tools
 
 Chairmarks.jl works fine for relatively short and simple blocks of code (microbenchmarking).
@@ -107,6 +109,8 @@ It allows you to label different sections of your code, then time them and displ
 [BenchmarkTools.jl](https://github.com/JuliaCI/BenchmarkTools.jl) is the older standard for benchmarking in Julia. It is still widely used today.
 However, its default parameters run benchmarks for longer than Chairmarks, and it requires interpolating variables into the benchmarked expressions with `$`.
 
+For command-line benchmarking outside of Julia, [hyperfine](https://github.com/sharkdp/hyperfine) is an excellent tool for timing the execution of entire Julia scripts or comparing different implementations at the process level.
+
 Finally, if you know a loop is slow and you'll need to wait for it to be done, you can use [ProgressMeter.jl](https://github.com/timholy/ProgressMeter.jl) or [ProgressLogging.jl](https://github.com/JuliaLogging/ProgressLogging.jl) to track its progress.
 
 ## Profiling
@@ -282,6 +286,10 @@ Note that every method that is called will be compiled, no matter how far down t
 To see if the intended calls were compiled correctly or diagnose other problems related to precompilation, use [SnoopCompile.jl](https://github.com/timholy/SnoopCompile.jl).
 This is especially important for writers of registered Julia packages, as it allows you to diagnose recompilation that happens due to invalidation.
 
+For alternative approaches to precompilation, [PrecompileSignatures.jl](https://github.com/rikhuijzer/PrecompileSignatures.jl) can generate precompile directives by reading method signatures, which can be especially useful when you want to ensure specific method combinations are precompiled.
+
+For managing precompilation after Julia version updates, [PrecompileAfterUpdate.jl](https://github.com/roflmaostc/PrecompileAfterUpdate.jl) can precompile your recent environments automatically after a Julia version update, saving you time when switching between Julia versions.
+
 ### Package compilation
 
 To reduce the time that packages take to load, you can use [PackageCompiler.jl](https://github.com/JuliaLang/PackageCompiler.jl) to generate a custom version of Julia, called a sysimage, with its own standard library.
@@ -322,6 +330,8 @@ The biggest tradeoff of not compiling a sysimage, is that Julia's garbage collec
 To get around this limitation, you can use static equivalents of dynamic types, such as a `StaticArray` ([StaticArrays.jl](https://github.com/JuliaArrays/StaticArrays.jl)) instead of an `Array` or a `StaticString` (StaticTools.jl), use `malloc` and `free` from StaticTools.jl directly, or use arena allocators with [Bumper.jl](https://github.com/MasonProtter/Bumper.jl).
 The README of StaticCompiler.jl contains a more [detailed guide](https://github.com/tshort/StaticCompiler.jl?tab=readme-ov-file#guide-for-package-authors) on how to prepare code to be compiled.
 
+For more advanced compilation workflows, [JuliaC.jl](https://github.com/JuliaLang/JuliaC.jl) provides tools for compiling and bundling Julia binaries with trimmed dependencies, particularly useful for creating minimal deployments.
+
 }
 
 ## Parallelism
diff --git a/sharing/index.md b/sharing/index.md
index 79f575b..76097e1 100644
--- a/sharing/index.md
+++ b/sharing/index.md
@@ -146,6 +146,12 @@ It is a good indicator of the exhaustiveness of your test suite, albeit not suff
 [Codecov](https://about.codecov.io/) is a website that provides easy visualization of this coverage, and many Julia packages use it.
 It is available as a PkgTemplates.jl plugin, but you have to perform an [additional configuration step](https://docs.codecov.com/docs/adding-the-codecov-token) on the repo for Codecov to communicate with it.
 
+\advanced{
+
+For local coverage analysis, [LocalCoverage.jl](https://github.com/JuliaCI/LocalCoverage.jl) provides trivial functions for working with coverage locally without requiring external services.
+
+}
+
 ## Style
 
 To make your code easy to read, it is essential to follow a consistent set of guidelines.
@@ -203,6 +209,14 @@ Note that both Aqua.jl and JET.jl might pick up false positives: refer to their
 Finally, [ExplicitImports.jl](https://github.com/ericphanson/ExplicitImports.jl) can help you get rid of generic imports to specify where each of the names in your package comes from.
 This is a good practice and makes your code more robust to name conflicts between dependencies.
 
+\advanced{
+
+For additional code quality tools, consider [ReLint.jl](https://github.com/RelationalAI-oss/ReLint.jl), which provides another linter for Julia code with different rules and checks compared to JET.jl.
+
+}
+
+You can also use [pre-commit](https://github.com/pre-commit/pre-commit) to set up hooks that automatically run code quality checks before each commit, ensuring consistent code standards across your project.
+
 ## Documentation
 
 Even if your code does everything it is supposed to, it will be useless to others (and pretty soon to yourself) without proper documentation.
@@ -268,6 +282,8 @@ Whether it is for package documentation or to write papers and books, you might
 In addition to the [Pluto.jl](https://github.com/fonsp/Pluto.jl) and [Jupyter](https://jupyter.org/) notebooks, take a look at [Literate.jl](https://github.com/fredrikekre/Literate.jl) to enrich your code with comments and translate it to various formats.
 [Books.jl](https://github.com/JuliaBooks/Books.jl) is relevant to draft long documents.
 
+For enhanced Pluto.jl workflows, [PlutoPapers.jl](https://github.com/mossr/PlutoPapers.jl) provides interactive and LaTeX-styled papers directly within Pluto notebooks, bridging the gap between computational documents and publication-ready papers.
+
 [Quarto](https://quarto.org/) is an open-source scientific and technical publishing system that supports Python, R and Julia.
 Quarto can render markdown files (`.md`), Quarto markdown files (`.qmd`), and Jupyter Notebooks (`.ipynb`) into documents (Word, PDF, presentations), web pages, blog posts, books, [and more](https://quarto.org/docs/output-formats/all-formats.html).
 Additionally, Quarto makes it easy to share or [publish](https://quarto.org/docs/publishing/) rendered content to Github Pages, Netlify, Confluence, Hugging Face Spaces, among others.
diff --git a/writing/index.md b/writing/index.md
index 44aa12a..565e44a 100644
--- a/writing/index.md
+++ b/writing/index.md
@@ -259,6 +259,12 @@ julia> using Pluto
 julia> Pluto.run()
 ```
 
+\advanced{
+
+For enhanced notebook-style development outside of the traditional notebook interfaces, [CodeCells.jl](https://github.com/MasonProtter/CodeCells.jl) provides code cell functionality that can be integrated into other development workflows, bridging the gap between notebook-style development and traditional script editing.
+
+}
+
 ## Markdown
 
 \tldr{Markdown is also a good fit for literate programming, and Quarto is an alternative to notebooks.}