Dependency exploration
Explores installed ataraxis and Sun Lab library source code to build a live API snapshot for the current project.
You MUST run this skill before writing code that uses ataraxis library features. Static reference tables go stale; reading the actual installed source is the only reliable way to know what APIs are available and how they work.
Scope
Covers:
- •Discovering ataraxis and Sun Lab dependencies from
pyproject.toml - •Locating installed package source code on disk
- •Reading
__init__.pyand__all__exports to enumerate public API surfaces - •Reading source signatures, docstrings, and return types for each public asset
- •Cross-referencing project code against discovered APIs to find replacement opportunities
- •Producing a structured "Dependency API snapshot" organized by library
Does not cover:
- •Third-party library exploration (NumPy, Click, etc.) — read their docs directly
- •Modifying dependency versions or adding new dependencies (invoke
/pyproject-style) - •Applying Python coding conventions (invoke
/python-style) - •Exploring the project's own codebase structure (invoke
/explore-codebase)
Workflow
You MUST follow these steps when this skill is invoked.
Step 1: Load the library catalog
Read library-catalog.md to understand the ataraxis library ecosystem, domain-to-library mappings, and import names.
Step 2: Identify project dependencies
Read the project's pyproject.toml and extract all ataraxis and Sun Lab dependencies from
[project.dependencies] and [project.optional-dependencies]. Match package names that start
with ataraxis- or sl-.
If pyproject.toml is not found, check for setup.cfg, setup.py, or requirements.txt as
fallbacks.
Record each dependency with its package name and corresponding import name (replace hyphens with underscores).
Step 3: Locate installed source code
For each identified dependency, resolve the installed package location:
python -c "import <import_name>; print(<import_name>.__file__)"
This returns the path to the package's __init__.py. The parent directory contains all source
modules.
If a package is not installed, note it as unavailable and skip to the next dependency.
Step 4: Enumerate public APIs
For each installed dependency:
- •Read the package's
__init__.pyfile - •Extract the
__all__list to identify all public exports - •For each exported name, identify whether it is a class, function, constant, or enum
- •Group exports by category (classes, functions, constants/enums)
Step 5: Read API details
For each public class and function discovered in Step 4:
- •Locate the source module that defines it (follow the import in
__init__.py) - •Read the definition to extract:
- •Signature: Full function/method signature with type annotations
- •Docstring summary: First line of the docstring
- •Key parameters: Parameter names, types, and defaults
- •Return type: The annotated return type
- •For classes, also extract:
- •
__init__signature: Constructor parameters - •Public methods: Method names and their signatures
- •Class/static methods: Any
@classmethodor@staticmethodmethods
- •
Focus on signatures and summaries. Do not read full method bodies unless needed to understand behavior.
Step 6: Identify replacement opportunities
Scan the project's source code for patterns that duplicate functionality provided by the discovered dependency APIs:
| Pattern in project code | Likely replacement |
|---|---|
print() or click.echo() for output | console.echo() (with raw=True if needed) |
raise for error reporting | console.error() |
isinstance chains to normalize to list | ensure_list() |
| Manual slicing loops for batching | chunk_iterable() |
os.cpu_count() arithmetic | resolve_worker_count() |
time.sleep() or time.time() patterns | PrecisionTimer methods |
datetime.now().strftime() calls | get_timestamp() |
Manual yaml.dump()/yaml.load() calls | YamlConfig subclass |
multiprocessing.Array or Value usage | SharedMemoryArray |
| Direct file writes in acquisition loops | DataLogger + LogPackage |
os.makedirs() or Path.mkdir() patterns | ensure_directory_exists() |
Report each replacement opportunity with the file location and the suggested library alternative.
Step 7: Produce the dependency API snapshot
Present the results using the output format below. This snapshot gives the agent (and user) a complete picture of what the project's ataraxis dependencies provide.
Output format
Organize the snapshot by library, with sections for each dependency.
Per-library section
## <library-name> (v<version>) **Import:** `from <import_name> import ...` **Source:** `<installed_path>` ### Classes | Class | Summary | Key methods | |-------|---------|-------------| | `ClassName` | Docstring summary | `method_one()`, `method_two()` | ### Functions | Function | Signature | Summary | |----------|-----------|---------| | `function_name` | `(param: type, ...) -> return_type` | Docstring summary | ### Constants and enums | Name | Type | Summary | |------|------|---------| | `CONSTANT_NAME` | `type` | Description | | `EnumName` | `enum` | Members: `MEMBER_A`, `MEMBER_B`, ... |
Replacement opportunities section
After all per-library sections, include a summary of replacement opportunities:
## Replacement opportunities | File | Current pattern | Suggested replacement | |------|----------------|----------------------| | `src/module.py:42` | `print(table)` | `console.echo(message=table, raw=True)` | | `src/utils.py:15` | `time.sleep(0.1)` | `PrecisionTimer.delay()` |
If no replacement opportunities are found, state: "No replacement opportunities identified."
Handling large dependencies
For dependencies with many exports (15+ public names), use the Task tool with
subagent_type: Explore to parallelize the API reading. Assign one subagent per large library
to read source files concurrently.
For small dependencies (fewer than 15 exports), read the APIs directly without subagents.
Related skills
| Skill | Relationship |
|---|---|
/python-style | Requires this skill before writing code that uses ataraxis features |
/pyproject-style | Manages dependency versions and additions; defer dependency changes |
/explore-codebase | Explores project structure; complements dependency exploration |
/commit | Invoke after completing code changes informed by the API snapshot |
Proactive behavior
This skill should be invoked at session start alongside /explore-codebase when the project has
ataraxis or Sun Lab dependencies. The /python-style skill explicitly requires this skill before
writing code that touches ataraxis library domains.
When invoked proactively, present the dependency API snapshot and replacement opportunities before proceeding to code changes. Wait for user acknowledgment before modifying code.
Verification checklist
You MUST verify the exploration output against this checklist before presenting it to the user.
Dependency Exploration Compliance: - [ ] All ataraxis/Sun Lab dependencies identified from pyproject.toml - [ ] Each installed dependency's source location resolved - [ ] Unavailable packages noted and skipped - [ ] __all__ exports read for each installed dependency - [ ] Public classes documented with constructors and public methods - [ ] Public functions documented with signatures and summaries - [ ] Constants and enums documented with types and members - [ ] Replacement opportunities scanned and reported - [ ] Output organized by library with consistent table format - [ ] Snapshot includes version numbers where available - [ ] No code modifications made during exploration