mis-github-contribution

Standardizes GitHub branching, Conventional Commits, pull requests, and pre-commit gates for MIS repositories.

Updated Oct 7, 2023
One-click install
npx skills add https://github.com/AhmedElbialy148/Portfolio --skill mis-github-contribution-ahmedelbialy148
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: mis-github-contribution
Source: https://github.com/AhmedElbialy148/Portfolio/tree/main/.cursor/skills/mis-github-contribution
Command: npx skills add https://github.com/AhmedElbialy148/Portfolio --skill mis-github-contribution-ahmedelbialy148

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve? Teams working across multiple repositories often drift into inconsistent branching models, messy commit histories, and uneven code review practices. This Skill enforces a single, machine-readable contribution workflow so changelogs, release notes, and triage tooling work without manual curation. ## Core Features & Use Cases - Branching model: Two protected long-lived branches (main for production, dev for staging) plus short-lived typed feature branches cut from dev, with a documented hotfix path. - Conventional Commits & PR standards: Strict commit message format, PR templates, sizing rules (< 400 LOC), review SLAs, and merge strategies per target branch. - Pre-commit gates & repo bootstrapping: Shared lint, format, type-check, and test gates for Python, TypeScript, Go, and Terraform, plus ready-to-copy assets (CODEOWNERS, PR template, branch protection settings) for new repos. - Use Case: When starting a new feature, ask the assistant to cut a properly named branch from dev, write a compliant commit, and open a PR with the standard template — all following MIS rules automatically. ## Quick Start Ask the assistant to create a new feature branch from dev and open a pull request following the MIS contribution workflow.

Frequently Asked Questions about mis-github-contribution

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

FAQPage Schema
How do I create a feature branch in this GitHub workflow?▼

Always branch from dev, never main. Run git switch dev, pull with --ff-only, then create a branch named with a type prefix and ticket id, such as feat/MIS-142-stripe-webhook-retry. Keep the branch short-lived and rebase on dev daily.

How do I write a Conventional Commits message?▼

Use the format type(optional-scope): imperative summary under 72 characters, followed by a body explaining what and why, and a footer with ticket references like Closes: MIS-142. Breaking changes need a ! after the type and a BREAKING CHANGE footer line.

What merge strategy should I use for pull requests?▼

Use squash and merge for PRs targeting dev and for hotfixes to main, keeping one commit per task. Use a merge commit only for dev-to-main release promotion PRs so individual feature commits stay visible. Rebase merges are not allowed.

How do I handle a production hotfix without waiting for release?▼

Branch hotfix/<ticket>-<summary> directly off main, open a PR targeting main, and get an immediate review. After merging, back-merge main into dev right away so dev does not regress on the next promotion.

What pre-commit hooks should run before opening a PR?▼

Every repo runs four gate classes: lint, format check, type-check, and tests for affected packages. The shared pre-commit config covers Python with ruff and mypy, TypeScript with eslint, prettier, and tsc, plus generic hooks like secret scanning and large-file guards.

Can I push directly to main or dev branches?▼

No. Both main and dev are protected branches that reject direct pushes and force pushes. All changes must go through pull requests with at least one CODEOWNER approval, green CI checks, and resolved review threads.