一键导入
architecture-design
Use only when creating new registrable ML components that require Factory or Registry patterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use only when creating new registrable ML components that require Factory or Registry patterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user wants to log meeting or call notes for a project — task assignments per student, follow-ups, deadlines. Creates Operon file-tasks in the vault (one .md per task, assigned to the person) and interleaves them on the project hub card via Task Wikilink Overlay. Trigger on: "запиши звонок", "записать встречу", "call notes", "что сделать студентам", "задачи после звонка".
Use when the user wants to set up the Operon task manager in their Obsidian vault the way this lab does it, or reproduce that setup on a fresh machine — flat project tags (no parentTask hierarchy), a "my tasks" table dashboard, service-link badges on project pages, emoji task icons, and day-boundary auto-archiving. Applies plugin settings (data.json), templates, a CSS snippet, optional main.js display patches, and an optional macOS launchd archiver. Trigger on "set up Operon", "настрой Operon как у тебя", "operon setup", "воспроизведи таск-систему Obsidian", "как у тебя задачи и страницы проектов в Obsidian".
This skill should be used when the user wants to write a peer-review of a research paper for any conference or journal, to the standard of a strong reviewer at a top venue. Trigger on "напиши ревью на статью", "write a review", "review this paper", "прогони ревьюера/теоретика/литератора", or when handed a paper PDF to review. Runs a thorough reviewer + theoretician (appendix/proofs) + literature-scout (related work, uncited papers) + experiments-auditor (numbers, hyperparameter search, released code) pass, extracts the user's own PDF annotations, surfaces a weakness skeleton in chat first, then writes one review markdown file per paper in the Summary / Strengths-and-Weaknesses / Questions / Limitations format. Handles prompt injections inside PDFs safely. Venue-agnostic.
Use when the user gives a code repository (a GitHub URL or a local/server path) and wants it added to the Obsidian Code library — a one-time deep analysis that produces a structured set of Markdown notes mapping how the repo works (entrypoint, modules, where to look to change X), without copying the code. Trigger on "add this repo to the code library", "разбери этот репозиторий", "code-ingest <url>", "задокументируй код", or when a project starts using an external repo that is not yet in Code/.
Reference for how the user runs and documents code. Use when an agent needs to understand the user's code workflow — which coding skills and rules apply, how the Obsidian Code library works, how a project hub card records the repo it uses and the project-specific edits, and how experiments are monitored (graphs + tables + loop). Trigger on "how do we work with code here", "что у меня есть для кодинга", "code workflow", before running experiments for a project, or when onboarding to a project that has code.
Use when the user wants to create a new research project, set up a new paper project, initialize a project folder, or says "create project", "new project", "setup project". Creates the standard ~/Papers/<project>/ folder structure with .claude/CLAUDE.md configured for SSH servers and code paths.
| name | architecture-design |
| description | Use only when creating new registrable ML components that require Factory or Registry patterns. |
| version | 1.2.0 |
This skill defines the standard code architecture for machine learning projects based on the template structure. When modifying or extending code, follow these patterns to maintain consistency.
The project follows a modular, extensible architecture with clear separation of concerns. Each module (data, model, trainer, analysis) is independently organized using factory and registry patterns for maximum flexibility.
Use this skill when:
@register_dataset@register_model__init__.py factory wiringDo not use this skill when:
Key indicator: if the task does not require a @register_* decorator or a Factory pattern, skip this skill.
Each module uses a factory to create instances dynamically:
# Example from data_module/dataset/__init__.py
DATASET_FACTORY: Dict = {}
def DatasetFactory(data_name: str):
dataset = DATASET_FACTORY.get(data_name, None)
if dataset is None:
print(f"{data_name} dataset is not implementation, use simple dataset")
dataset = DATASET_FACTORY.get('simple')
return dataset
For detailed guidance, refer to references/factory_pattern.md.
Components register themselves via decorators:
# Example from data_module/dataset/simple_dataset.py
@register_dataset("simple")
class SimpleDataset(Dataset):
def __init__(self, data):
self.data = data
For detailed guidance, refer to references/registry_pattern.md.
Modules automatically discover and import submodules:
# Example from data_module/dataset/__init__.py
models_dir = os.path.dirname(__file__)
import_modules(models_dir, "src.data_module.dataset")
For detailed guidance, refer to references/auto_import.md.
project/
├── run/
│ ├── pipeline/ # Main workflow scripts
│ │ ├── training/ # Training pipelines
│ │ ├── prepare_data/ # Data preparation pipelines
│ │ └── analysis/ # Analysis pipelines
│ └── conf/ # Hydra configuration files
│ ├── training/ # Training configs
│ ├── dataset/ # Dataset configs
│ ├── model/ # Model configs
│ ├── prepare_data/ # Data prep configs
│ └── analysis/ # Analysis configs
│
├── src/
│ ├── data_module/ # Data processing module
│ │ ├── dataset/ # Dataset implementations
│ │ ├── augmentation/ # Data augmentation
│ │ ├── collate_fn/ # Collate functions
│ │ ├── compute_metrics/ # Metrics computation
│ │ ├── prepare_data/ # Data preparation logic
│ │ ├── data_func/ # Data utility functions
│ │ └── utils.py # Module-specific utilities
│ │
│ ├── model_module/ # Model implementations
│ │ ├── brain_decoder/ # Brain decoder models
│ │ └── model/ # Alternative model location
│ │
│ ├── trainer_module/ # Training logic
│ ├── analysis_module/ # Analysis and evaluation
│ ├── llm/ # LLM-related code
│ └── utils/ # Shared utilities
│
├── data/
│ ├── raw/ # Original, immutable data
│ ├── processed/ # Cleaned, transformed data
│ └── external/ # Third-party data
│
├── outputs/
│ ├── logs/ # Training and evaluation logs
│ ├── checkpoints/ # Model checkpoints
│ ├── tables/ # Result tables
│ └── figures/ # Plots and visualizations
│
├── pyproject.toml # Project configuration
├── uv.lock # Dependency lock file
├── TODO.md # Task tracking
├── README.md # Project documentation
└── .gitignore # Git ignore rules
For detailed directory structure with file descriptions, refer to references/structure.md.
When adding a new dataset:
src/data_module/dataset/@register_dataset("name") decoratortorch.utils.data.Dataset__init__, __len__, __getitem__from torch.utils.data import Dataset
from typing import Dict
import torch
from src.data_module.dataset import register_dataset
@register_dataset("custom")
class CustomDataset(Dataset):
def __init__(self, data):
self.data = data
def __len__(self):
return len(self.data)
def __getitem__(self, i: int) -> Dict[str, torch.Tensor]:
return self.data[i]
CRITICAL: Models use config-driven pattern
When adding a new model:
src/model_module/model/ or appropriate module subdirectory@register_model('ModelName') decorator__init__ accepts ONLY cfg parameter - all hyperparameters come from configforward() returns dict: {"loss": loss, "labels": labels, "logits": logits}self.trainingfrom src.model_module.brain_decoder import register_model
@register_model('MyModel')
class MyModel(nn.Module):
def __init__(self, cfg):
super().__init__()
self.cfg = cfg
self.task = cfg.dataset.task
# ALL parameters from cfg
self.hidden_dim = cfg.model.hidden_dim
self.output_dim = cfg.dataset.target_size[cfg.dataset.task]
def forward(self, x, labels=None, **kwargs):
if self.training:
# Training logic
pass
else:
# Inference logic
pass
return {"loss": loss, "labels": labels, "logits": logits}
When adding augmentation:
src/data_module/augmentation/For comprehensive style guidelines, refer to references/code_style.md.
Key principles:
__init__.py files contain factory/registry logicThe project uses Hydra for configuration management:
run/conf/ organize by moduleFor detailed information, consult:
references/structure.md - Detailed directory structure with file descriptionsreferences/factory_pattern.md - Factory pattern in-depth explanationreferences/registry_pattern.md - Registry pattern in-depth explanationreferences/auto_import.md - Auto-import pattern in-depth explanationreferences/code_style.md - Comprehensive code style guidelinesWorking examples in examples/:
examples/custom_dataset.py - Custom dataset implementationexamples/custom_model.py - Custom model implementationexamples/augmentation_example.py - Data augmentation exampleexamples/config_example.yaml - Configuration file exampleexamples/pipeline_example.sh - Pipeline script example