agentleFS
terrene-foundationterrene-foundation/pact/.claude/skills/10-deployment-git/SKILL.md

deployment-git

Skill0 starsChanged 7 months agoApache-2.0View on GitHub

SDK release and Git workflow guides for the Kailash Python SDK including PyPI publishing, CI/CD pipelines, documentation deployment, and Git workflows. Use when asking about 'deployment', 'release', 'PyPI publish', 'CI/CD', 'GitHub Actions', 'documentation deployment', 'TestPyPI', 'wheel building', 'version bump', 'changelog', 'Git workflow', 'Git branching', 'package release', or 'multi-package coordination'.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Test matrix (Python versions x OS)

    line 48
  2. Distinctive:

    Run full test suite before any release

    line 154
  3. Distinctive:

    NEVER commit PyPI tokens to source

    line 160
  4. Distinctive:

    NEVER publish with failing CI

    line 161
  5. Distinctive:

    Use feature branches for development

    line 165
  6. Distinctive:

    Write descriptive commit messages

    line 166
  7. Distinctive:

    Use pull requests for code review

    line 168
  8. Distinctive:

    NEVER commit directly to main

    line 170
  9. Distinctive:

    NEVER force push to shared branches

    line 171
  10. Distinctive:

    NEVER commit sensitive data

    line 172
  11. Distinctive:

    Use this skill when you need to:

    line 176
  12. Distinctive:

    Run SDK release onboarding for a new project

    line 178

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

SDK Release & Git Workflows

Comprehensive guides for releasing the Kailash Python SDK to PyPI, managing CI/CD pipelines, deploying documentation, and Git workflow best practices.

Overview

SDK release and development infrastructure patterns for:

  • PyPI package publishing (TestPyPI + production)
  • CI/CD pipelines (GitHub Actions)
  • Multi-platform wheel building
  • Documentation deployment
  • Git workflows and branching strategies
  • Multi-package version coordination

Reference Documentation

Deployment Lifecycle

  • deployment-onboarding - SDK release onboarding process
    • Codebase analysis (packages, build system, CI, docs)
    • Structured questions for human architect
    • Research current PyPI/CI best practices
    • Create deployment-config.md
  • release-runbook - SDK release runbook (detailed procedures)
    • Version locations for all packages (pyproject.toml + init.py)
    • SDK dependency pin rules
    • Version consistency verification commands
    • Pre-release, build, publish, post-release step-by-step procedures
  • deployment-packages - Package release workflow
    • PyPI and GitHub release process
    • Multi-package coordination and publish order
    • Version bumping and changelog
    • CI-triggered releases
    • TestPyPI validation
    • Rollback procedures
  • deployment-ci - CI/CD infrastructure
    • GitHub Actions workflows for Python packages
    • Multi-platform wheel building
    • Test matrix (Python versions x OS)
    • Tag-triggered publishing pipeline
    • Documentation deployment (ReadTheDocs, GitHub Pages)
    • Self-hosted runner management

Docker

  • deployment-docker-quick - Docker deployment patterns
    • Dockerfile setup for Kailash apps
    • Docker Compose configurations
    • Multi-stage builds
    • Health checks

Kubernetes

  • deployment-kubernetes-quick - Kubernetes deployment patterns
    • Deployment manifests
    • Service configuration
    • Scaling strategies

Git Workflow

  • git-workflow-quick - Git workflow best practices
    • Branching strategies
    • Commit conventions
    • Pull request workflow
    • Code review process
    • Release management
    • Hotfix procedures

GitHub Management

  • github-management-patterns - GitHub project and issue management
    • Issue templates (User Story, Bug, Technical Task)
    • Story points and estimation
    • Project board organization
    • Label system

Project Management

  • project-management - Project management architecture
    • Dual-tracking system overview
    • GitHub Issues vs Local Todos
    • Agent coordination flow
    • Sprint management
  • todo-github-sync - Todo ↔ GitHub issues sync patterns
    • Naming conventions (Story X format)
    • Workflow for creating, starting, completing stories
    • Sub-issue management
    • Label system
    • Periodic sync checklists
    • Agent coordination (todo-manager ↔ gh-manager)

SDK Release Patterns

Release Flow

Version bump + CHANGELOG → Build wheels → TestPyPI → Verify → PyPI → GitHub Release → Deploy Docs

CI-Triggered Release (Preferred)

git tag v1.2.3 → push tag → CI builds wheels → CI tests → CI publishes TestPyPI → CI publishes PyPI → CI creates GitHub Release

Multi-Package Release Order

kailash (core)
  ↓
kailash-dataflow (depends on core)
kailash-nexus (depends on core)
kailash-kaizen (depends on core)

Git Workflow Patterns

Branch Strategy

main (production)
  ↓
develop (integration)
  ↓
feature/* (new features)
hotfix/* (urgent fixes)
release/* (release prep)

Commit Conventions

feat: Add user authentication workflow
fix: Resolve async runtime threading issue
docs: Update DataFlow integration guide
test: Add cycle workflow test cases
chore: Bump version to 0.9.25

Critical Rules

SDK Release

  • Run full test suite before any release
  • TestPyPI validation required for major/minor releases
  • Wheel-only publishing for proprietary code
  • Version consistency across all sub-packages
  • Publish in dependency order (core first)
  • Security review before every publish
  • NEVER commit PyPI tokens to source
  • NEVER publish with failing CI

Git

  • Use feature branches for development
  • Write descriptive commit messages
  • Squash commits before merging
  • Use pull requests for code review
  • Tag releases semantically
  • NEVER commit directly to main
  • NEVER force push to shared branches
  • NEVER commit sensitive data

When to Use This Skill

Use this skill when you need to:

  • Run SDK release onboarding for a new project
  • Release packages to PyPI or GitHub
  • Set up or debug CI/CD pipelines
  • Configure GitHub Actions workflows
  • Build multi-platform wheels
  • Deploy documentation
  • Coordinate multi-package releases
  • Establish Git workflows
  • Manage test matrices

Related Skills

  • 03-nexus - Application deployment (end-user)
  • 02-dataflow - Database operations
  • 01-core-sdk - Runtime selection
  • 17-gold-standards - Release best practices

Support

For SDK release help, invoke:

  • release-specialist - Release onboarding, PyPI publishing, CI management
  • release-specialist - Git workflows, releases, version management

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.