Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →hashgraph-online/developing-julia-package
Use when you write a Julia package
Passed 21 of 22 test cases with the skill, and 18 of 22 without it.
3 fixed18 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
I am setting up a new Julia package for statistical smoothing. I want to structure the main entry module cleanly with external file includes, but I have a few helper functions used in calculations that I need to unit test without exposing them in the package's public API exports. Could you show me an example of how to lay out the primary module file and write a test file that tests both the exported functions and the unexported helpers?
| Checked | Without skill | With skill |
|---|---|---|
| The module entry file does not export internal helper functions. | Passed | Passed |
| The test file explicitly imports internal helper functions using `using ModuleName: helper_function` syntax. | Missed | Passed |
The instructions your model reads when the skill loads.
Notes on developing Julia packages.
Assume the package is named MyPkg. Substitute your actual package name wherever MyPkg appears.
Use src/MyPkg.jl as the package entry point. Keep the module declaration, exports, and include list there; put substantial implementation in focused files under src/.
module MyPkg
export fit_model, FitResult, GaussianModel
include("models.jl")
include("fit.jl")
include("preprocess.jl")
end
Split files to improve readability, not to recreate Python-style class or submodule hierarchies. Prefer one public module unless there is a real user-facing namespace boundary.
Guidelines below.
exportsexport helpers that are only used internally just so tests can reach them. Prefer importing explicitly in tests:# test/runtests.jl
using Test
using MyPkg: <internal-only helper>
Test public behavior through the public API first. Import internals only when the helper has meaningful behavior that is hard to exercise through the public path:
using Test
using MyPkg
test cases passed, vs 18 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.