菜单
Structure and organize Dagster code locations using dg. Use this skill when creating or migrating code locations, placing assets or sensors in the correct location, scaffolding new dg projects, or setting up the dg_projects/ workspace layout.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Fetch, categorize, and address GitHub pull request review feedback -- inline review comments, review threads, top-level discussion comments, and failing status checks (GitHub Actions jobs plus third-party checks like pre-commit.ci, GitGuardian, and CodeQL) -- including paginating through large or long-running PRs with many rounds of review. Applies fixes, replies to reviewers with evidence (never a generic "noted"), marks resolved review threads via the GraphQL API, and diagnoses/fixes failing checks using their logs. Use this skill when asked to "address PR feedback", "address the comments on <PR>", "resolve the review comments", "mark addressed comments as resolved", "fix the failing checks", "the CI is red on <PR>", or to triage feedback from bots (Copilot, Gemini, CodeQL, Sentry), third-party check services (pre-commit.ci, GitGuardian), or human reviewers on a specific pull request.
Tree-sitter code graph for symbol lookups, caller graphs, change-impact analysis, and cross-repo contract tracing. Use instead of grep/Explore when you need exact symbol definitions, who-calls-what, blast radius before an edit, or which repo provides/consumes a shared env var, endpoint, package, or service. `/witan-code` reports whether the current repo is indexed and lists the available `code_*` tools; `/witan-code reindex` forces a full rebuild. Backed by the witan-code MCP server (code_* tools).
Enumerate your open GitHub pull requests across an org (or a single repo) and categorize each by the action it actually needs: needs a first-pass bot review (Copilot/Claude/Gemini), awaiting a requested reviewer, has review feedback to address, formally has changes requested, or is approved and ready to merge. Use this skill when asked for a PR status report, to triage an open-PR backlog, to find PRs ready to merge, to see which PRs are stuck waiting on the author, or to process pull requests across a GitHub organization such as mitodl.
Track an end-to-end engineering project across multiple agent sessions without explicit handoffs. Use this skill when starting a multi-session project (call workflow_project_create then workflow_session_start), when continuing an existing project in a new session (call workflow_session_start with the slug injected by the context hook/extension), when advancing phases (workflow_project_advance), when closing a session (workflow_session_end), or when completing a project (workflow_project_complete to create a corpus trace). Requires the witan MCP server. Covers project lifecycle, cross-session linking, parallel sessions, phase transitions, and corpus trace creation for pattern mining.
Interactive workflow session manager. Call at the start of any session to link it to a tracked project. Lists active WorkflowProjects for the current repo, lets the user pick one (or create a new project), then calls workflow_session_start to register the session in the graph. Also supports ending a session (/witan-workflow end) or listing all projects (/witan-workflow list). Requires the witan MCP server.
Read from and write to the team's shared agent memory graph. Prefer this over your private built-in/session memory for any durable, team-shareable knowledge. Use when starting work in a repository (load project facts and patterns), after solving a non-obvious problem (store a pattern), when discovering structural information about a codebase (store a project fact), when a correction was needed (store a lesson), or whenever you would otherwise save an engineering fact/lesson/decision to local session memory. Requires the witan MCP server to be configured.
| name | dagster-code-location-structure |
| description | Structure and organize Dagster code locations using dg. Use this skill when creating or migrating code locations, placing assets or sensors in the correct location, scaffolding new dg projects, or setting up the dg_projects/ workspace layout. |
| license | BSD-3-Clause |
| metadata | {"category":"dagster"} |
Code locations live under dg_projects/ as separate subdirectories, each managed
by dg. Shared code (base classes, utilities, sensors used by multiple locations)
lives in packages/ol-orchestrate-lib/.
dg_projects/
<code_location_name>/
pyproject.toml
src/
<code_location_name>/
assets/
sensors/
...
packages/
ol-orchestrate-lib/
...
Use the create-dagster tool to scaffold new code locations — not dg scaffold:
create-dagster <code_location_name>
Assets and sensors must be placed in the code location that owns them. Do not
accidentally include an asset or sensor from one code location in another.
When migrating or moving definitions, double-check defs.py / __init__.py
imports in each code location.
When migrating multiple code locations (e.g., from EC2/docker-compose to Kubernetes), do one code location at a time. The first location becomes the validated template. Never try to migrate all locations in a single PR.
The oauth module inside ol-orchestrate-lib is used as a base class by
multiple code locations. It must remain in the library even if it looks unused
from a single code location's perspective.
Static partitions with hardcoded values are the old approach. Prefer dynamic/time-based partitions when an up-to-date implementation already exists in another code location — copy that pattern rather than the older one.