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'.
In this repository37 other files it gives its agents.
- .claude/rules/agents.mdAGENTS.md
- .claude/guides/claude-code/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- core-sdkSkill
- dataflowSkill
- nexusSkill
- kaizenSkill
- kailash-mcpSkill
- cheatsheetsSkill
- development-guidesSkill
- nodes-referenceSkill
- workflow-patternsSkill
- frontend-integrationSkill
- testing-strategiesSkill
- architecture-decisionsSkill
- code-templatesSkill
- enterprise-infrastructureSkill
- validation-patternsSkill
- gold-standardsSkill
- security-patternsSkill
- flutter-patternsSkill
- interactive-widgetsSkill
- enterprise-ai-uxSkill
- conversation-uxSkill
- uiux-design-principlesSkill
- value-auditSkill
- ai-interaction-patternsSkill
- eatp-referenceSkill
- coc-referenceSkill
- 29-pactSkill
- claude-code-patternsSkill
- error-troubleshootingSkill
- kailash-mlSkill
- kailash-alignSkill
- co-referenceSkill
- managementSkill
- projectSkill
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
- Distinctive: line 48
Test matrix (Python versions x OS)
- Distinctive: line 154
Run full test suite before any release
- Distinctive: line 160
NEVER commit PyPI tokens to source
- Distinctive: line 161
NEVER publish with failing CI
- Distinctive: line 165
Use feature branches for development
- Distinctive: line 166
Write descriptive commit messages
- Distinctive: line 168
Use pull requests for code review
- Distinctive: line 170
NEVER commit directly to main
- Distinctive: line 171
NEVER force push to shared branches
- Distinctive: line 172
NEVER commit sensitive data
- Distinctive: line 176
Use this skill when you need to:
- Distinctive: line 178
Run SDK release onboarding for a new project
≈ “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.
Files
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 DocsCI-Triggered Release (Preferred)
git tag v1.2.3 → push tag → CI builds wheels → CI tests → CI publishes TestPyPI → CI publishes PyPI → CI creates GitHub ReleaseMulti-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.25Critical 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 managementrelease-specialist- Git workflows, releases, version management
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
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.

