인터페이스는 현지화되어 있으며, Skill 소개와 설명 문서는 선택한 언어로 AI가 자동 번역합니다. 코드·명령어·경로·전문 용어는 원문을 유지하며 원작자 문서가 우선합니다.
Skills 둘러보기
개발 및 엔지니어링 · SKILL.md

repo-development

repo-development

Use when a coding agent edits the Dagster OSS repository itself: package lookup, Python/UI/docs validation, coding conventions, mandatory ruff, safe test selection, CLI entry point reinstall notes, and git or stack constraints.

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill 문서

GitHub

name: repo-development description: "Use when a coding agent edits the Dagster OSS repository itself: package lookup, Python/UI/docs validation, coding conventions, mandatory ruff, safe test selection, CLI entry point reinstall notes, and git or stack constraints." disable-model-invocation: true metadata: disco-role: operating license: Apache 2.0

Repo Development

Use this sub-skill when changing the Dagster OSS monorepo rather than using Dagster as an application framework. It routes future agents to the repo-specific development workflow, package map, validation commands, style rules, and safety constraints needed for edits in this checkout.

Route First

  • Use this sub-skill for locating Dagster packages, choosing validation commands after repo edits, applying Python style conventions, docs checks, UI checks, or repository contribution workflow rules.
  • Route public dagster CLI usage and user-project local development to ../cli-local-development/SKILL.md if that sub-skill exists.
  • Route GraphQL API and webserver runtime behavior to ../graphql-and-webserver/SKILL.md if that sub-skill exists.
  • Route deployment operations, production instances, and daemon/run-launcher behavior to ../deployment-operations/SKILL.md if that sub-skill exists.
  • Do not use this sub-skill for broad integration-library internals, Dagster Cloud, release automation, Buildkite deep internals, or UI implementation details beyond validation workflow routing.

Start Here

  1. Identify changed paths and package ownership before editing; package paths and validation commands differ across core Python, libraries, webserver, GraphQL, Pipes, docs, and UI workspaces.
  2. After every Python file edit, run make ruff from the repository root before considering the task complete.
  3. Use uv for Python package management; if command-line entry points change in a setup.py or package metadata, reinstall the affected package with uv pip install -e . from that package root.
  4. For UI or GraphQL schema changes, run UI checks from js_modules/; schema changes require make generate-graphql before yarn tsgo or yarn lint.
  5. Prefer focused tests that match changed files before broad suites; avoid credentialed, networked, Docker-heavy, or expensive tests unless the user explicitly asks.
  6. Never push directly with git push; ask first. When stack metadata matters, inspect with gt log before manual git inference.

References

  • Repo development workflows for package locations, command selection, Python/UI/docs validation, style conventions, test strategy, and git constraints.
  • Troubleshooting for install/import failures, optional dependency gaps, CLI/API misuse while developing the repo, UI/docs validation failures, and workflow-specific recovery steps.
  • Validation command selector for a safe helper that suggests commands from changed paths without executing them.

Safety Notes

  • Treat make ruff as mandatory after Python edits even if the changed file is small or generated.
  • Do not search Python code under .tox directories; they are temporary environments and can mislead package ownership or dependency conclusions.
  • Search package dependencies in setup.py files as the source of truth for this repo.
  • Do not run broad native examples, Docker-backed tests, or external-service integrations as routine validation without confirming scope and cost with the user.
저장한 Skills