dl-core

Imported from Blazkowiz47/dl-core (AGENTS.md). Install upstream with npx skills add Blazkowiz47/dl-core. Copyright stays with the author.

<agent_spec>

<project_structure> Repository root includes .github/, src/, tests/, readme/, README.md, pyproject.toml, and uv.lock. src/dl_core/ stores the reusable framework package. src/dl_core/core/ stores base abstractions and registries. src/dl_core/templates/ stores bundled scaffold files copied into generated experiment repositories. tests/ stores repository-level pytest coverage for scaffolding, CLI behavior, and local components. readme/ stores extended user and technical documentation. .github/workflows/ stores CI and publishing workflows. dist/ contains generated build artifacts; treat it as output, not source. </project_structure>

<command_policy> Run commands from the repository root unless a narrower directory is clearly better for the task. Prefer fast search commands: rg, rg --files. Use non-destructive commands by default. Prefer repository-standard uv commands for Python execution, validation, and build steps. Standard validation commands are uv run --extra dev pytest, uv run python -m compileall src/dl_core, and uv build --no-sources. Do not invent alternate environment-management flows when uv already covers the task. </command_policy>

<development_rules> Type hints are required for Python code. Public modules, public APIs, and CLI entry points should include concise docstrings. Match the existing style: 4-space indentation, snake_case functions and modules, PascalCase classes, and short module docstrings. Use f-strings for string formatting. Keep functions focused and avoid unnecessary nesting. Keep new components direct and readable. Start from the generated method stub, implement only the required behavior, and avoid pass-through helpers, unnecessary wrappers, or configuration options with only one use. Do not extract one-off component logic into a helper unless it is reused more than twice or represents a distinct operation that benefits from independent testing. Keep BaseModel.compute_forward() linear when the architecture allows it: retrieve and prepare batch data, run the model elements in execution order, then build and return the final output dictionary. Keep losses, metrics, logging, and optimizer work outside this method. When documentation, commands, or generated files name a PyTorch version, verify the latest stable release from the official PyTorch releases page first. Label older versions as compatibility pins and keep related torchvision and torchaudio versions compatible. No formatter or linter configuration is defined in pyproject.toml; mirror nearby files instead of re-styling code arbitrarily. Whenever package behavior, public APIs, CLI behavior, scaffold output, dependencies, or versions change, review README.md and the relevant readme/ docs and keep them consistent with the code. If no documentation update is needed, state why. </development_rules>

<architecture_rules> Keep dl-core reusable and vendor-neutral; company-specific integrations belong outside the core package. Preserve the registry-driven extension model in src/dl_core/core/registry.py and related package exports. Keep scaffold logic in src/dl_core/init_experiment.py aligned with the bundled files in src/dl_core/templates/. Keep generated config conventions consistent: top-level accelerator, dataset, singular trainer, and plural component sections such as models, optimizers, criterions, metric_managers, and callbacks. Use dataset.classes for class ordering, and keep sweep dotted paths aligned with the generated config structure. Do not introduce experiment-specific assumptions into the library when the behavior belongs in a generated consumer repository. </architecture_rules>

<execution_policy> Never run training jobs, sweeps, worker processes, or publish workflows unless explicitly requested. Prefer targeted validation for the files you changed; full test runs are appropriate for code, packaging, or release work. If validation was not run, state it explicitly in the final response. Do not push commits or trigger manual GitHub Actions unless the user asked for that outcome. </execution_policy>

<editing_policy> Keep edits minimal and task-scoped. Do not refactor unrelated code. Prefer apply_patch for focused, reviewable edits. Do not overwrite user changes or revert unrelated work in a dirty tree. When changing scaffolded files or config conventions, update both the generator and the bundled templates together. </editing_policy>

<parallel_agent_policy> Assume multiple agents may edit in parallel. If a file changes while being edited, re-read the latest content and integrate safely. Only stage or commit the specific changes created for the current task. Before any commit, verify that staged changes match the intended scope. </parallel_agent_policy>

<versioning_policy> When bumping the package version, update pyproject.toml, src/dl_core/init.py, and the scaffold dependency floor in src/dl_core/init_experiment.py. Unless the user explicitly requests otherwise, alpha releases must stay on the exact same base version and only increment the alpha suffix, for example 0.0.1 -> 0.0.1a1 or 0.0.1a0 -> 0.0.1a1. Do not change the stable portion of the version for alpha work. If the current release line is 0.0.1, do not jump to 0.0.2a0 unless the user explicitly asks to start the 0.0.2 line. Before any version bump or publish action, explicitly restate the current version and intended target version in a progress update and verify that the base version is unchanged unless the user requested that change. If the version bump affects package metadata or the local project entry in uv.lock, refresh the lockfile rather than editing it by hand. Before any publish action, make sure version references are internally consistent and validation has passed. Use concise release commits such as release: bump dl-core to 0.1.8. </versioning_policy>

<github_actions_policy> Use gh to inspect workflows and runs when GitHub Actions work is requested. The repository workflows are CI, Publish TestPyPI, and Publish. Prefer checking existing runs with gh run list, gh run view, and gh run watch before dispatching anything new. When the user says publish, push the current commits and trigger Publish TestPyPI by default. Only trigger the Publish workflow when the user explicitly says publish on pypi or clearly requests a PyPI release. After dispatching a workflow with gh workflow run, monitor it and report the final status and run identifier or URL. Do not cancel, rerun, or approve workflows unless the user explicitly asks for that action. </github_actions_policy>

<jira_policy> Use acli for Jira issue lookup, creation, and status tracking when Jira work is requested. Before starting substantial new implementation work, first create appropriately nested Jira work items that match the repository task hierarchy. When work spans multiple steps or components, create parent and child Jira tasks instead of tracking everything in a single flat issue. Do not create Jira tasks for very small edits, narrow documentation changes, or other low-overhead work unless the user explicitly asks for Jira tracking. When creating a Jira task, include a concise summary, repository context, affected paths, and clear acceptance criteria. When tracking work against Jira, report the issue key and the exact status change or comment that was added. After completing a task, transition the corresponding Jira issue to Done. If the Jira project, issue type, assignee, or workflow step is unclear, inspect existing issues first instead of guessing. </jira_policy>

<git_policy> After every completed repository change, stage the task-scoped files and create a concise local git commit. Do not push commits by default; pushing is reserved for an explicit publish request. Use clear, imperative, prefix-based commit messages such as docs: update contributor guide, test: add scaffold smoke coverage, or release: bump dl-core to 0.1.8. Keep pull requests focused and include scope summary, validation evidence, and any config or release implications. When CLI behavior, scaffold output, or release flow changes, include sample commands or output in the PR description. Never mention tool-generated authorship metadata such as co-authored-by unless the user explicitly asks for it. </git_policy>

<agent_behavior> Before substantial tool use, restate the goal and provide a short plan. For multi-step tasks, provide concise progress updates. Complete end-to-end resolution in one turn when feasible. If uncertain, gather evidence with tools rather than guessing. When a task involves release, packaging, GitHub Actions, or Jira, summarize the intended commands before executing them. When helping with release work, prefer validating locally first, then using gh for workflow dispatch or inspection only if the user asked for it. </agent_behavior> </agent_spec>