Digitalmodel Code Explorer

Digitalmodel Code Explorer

Purpose

Use this skill to navigate digitalmodel/src/digitalmodel/ and its tests without bulk-reading large numbers of files. It is intended to reduce repeated manual source exploration by giving a fast module map and lookup workflow.

Core Areas in digitalmodel/src/digitalmodel/

Examples of major areas present on this machine include:

• fatigue/
• cathodic_protection/
• structural/
• subsea/
• reservoir/
• signal_processing/
• well/
• workflows/
• top-level helpers like engine.py, units.py, __main__.py

Recommended Exploration Pattern

1. Find the relevant package first

find digitalmodel/src/digitalmodel -maxdepth 2 -type f | head -50

2. Narrow by topic before reading files

Examples:

rg -n "rainflow|sn curve|fatigue" digitalmodel/src/digitalmodel/fatigue
rg -n "orcawave|diffraction|rao" digitalmodel/src/digitalmodel
rg -n "cathodic|anode|iccp" digitalmodel/src/digitalmodel/cathodic_protection

3. Read only the most relevant files

Prefer:

• package __init__.py
• API-facing modules
• the exact function/class implementation you matched
• the corresponding tests

Source -> Test Mapping Pattern

Before editing a source file, look for mirrored or neighboring tests.

Examples:

find digitalmodel/tests -type f | rg "fatigue|cathodic|orcawave|orcaflex"

Heuristic mapping:

• digitalmodel/src/digitalmodel/fatigue/<module>.py -> search under digitalmodel/tests/ for <module> or the package name
• package-level behavior -> check digitalmodel/tests/<package>/ and digitalmodel/tests/unit/

Useful Fast Questions This Skill Helps Answer

• Which package owns a domain concept?
• Where is the public API versus a helper implementation?
• What tests exist for a module before changing it?
• Which neighboring files should be compared for similar patterns?

Practical Workflow

1. identify the domain/package
2. grep for the concrete symbol or topic
3. read the smallest relevant set of files
4. map to tests before implementation
5. only then expand outward if architecture context is still missing

Common Pitfalls

• reading an entire package tree before asking a narrower question
• editing a module without finding its tests first
• assuming domain ownership without checking sibling packages
• mixing package discovery and implementation in the same pass

Good Companion Commands

find digitalmodel/src/digitalmodel -maxdepth 2 -type f | sort
find digitalmodel/tests -type f | sort | head -100
rg -n "class |def " digitalmodel/src/digitalmodel/<package>

Notes

This is an orientation skill, not a replacement for reading source. Its goal is to reduce repeated bulk-read behavior by making the first pass targeted and test-aware.