osdc-project-structure

Guides engineers in modifying the OSDC infrastructure repository while preserving its architecture.

17|14|Updated Jun 15, 2023
One-click install
npx skills add https://github.com/pytorch/ci-infra --skill osdc-project-structure
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: osdc-project-structure
Source: https://github.com/pytorch/ci-infra/tree/main/osdc/.claude/skills/osdc-project-structure
Command: npx skills add https://github.com/pytorch/ci-infra --skill osdc-project-structure

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps engineers understand the OSDC platform's architecture and repository organization before making infrastructure changes, reducing misplaced files, dependency mistakes, and inconsistent module design.

Core Features & Use Cases

  • Architecture Guidance: Explains the separation between shared base infrastructure and optional service modules.
  • Repository Navigation: Maps key directories, files, deployment layers, technologies, and cloud-specific boundaries.
  • Operational Context: Summarizes cluster configuration, deployment workflows, observability components, external knowledge resources, and project documentation.
  • Use Case: When adding a new Kubernetes service or modifying an existing module, use this Skill to identify the correct directory, deployment contract, dependencies, and related documentation that must be updated.

Quick Start

Use the osdc-project-structure skill to explain where a new optional Kubernetes service belongs and which project files and deployment conventions I should inspect first.

Frequently Asked Questions about osdc-project-structure

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new Kubernetes service to an existing AWS EKS infrastructure repository?

To add a new Kubernetes service to an AWS EKS repository, identify the correct optional service module directory, inspect the base-versus-module boundaries, and update the corresponding deployment contracts and project documentation.

What is the correct way to structure Terraform modules for cloud separation?

Structuring Terraform modules for cloud separation requires maintaining module independence and enforcing strict boundaries between shared base infrastructure and optional service modules to preserve the intended repository architecture.

Where should deployment scripts and Helm configurations go in an OSDC platform repository?

Deployment scripts and Helm configurations belong in their designated deployment layers within the repository, adhering to project documentation conventions and operational workflows to ensure correct deployment ordering.

Does modifying an existing infrastructure module require updating operational documentation?

Yes, modifying an existing infrastructure module requires updating operational documentation to maintain consistency, ensuring that changes to cluster configuration, observability components, or deployment workflows are properly recorded.

What are the base-versus-module boundaries in infrastructure architecture?

Base-versus-module boundaries separate shared base infrastructure from optional service modules, preventing dependency mistakes and misplaced files while ensuring module independence across different cloud environments and technologies.

Why does deployment ordering matter when modifying Kubernetes and Terraform configurations?

Deployment ordering matters because infrastructure changes must follow established deployment workflows to prevent dependency conflicts, ensuring Terraform provisions resources correctly before Kubernetes and Helm deployments are applied.