تشغيل أي مهارة في Manus بنقرة واحدة

git-workflow

النجوم٤

التفرعات٠

آخر تحديث٥ مايو ٢٠٢٦ في ٠٣:٤٠

Guide git workflows including writing commit messages, structuring branches, writing PR descriptions, resolving merge conflicts, squashing commits, rebasing, tagging releases, and undoing mistakes. Use this skill whenever the user wants help with a commit message, pull request, branching strategy, git history, rebasing, undoing a commit, stashing, or anything git-related. Trigger on phrases like "write a commit message", "help me PR this", "how should I branch", "clean up my commits", "git conflict", "undo", "revert", "stash", or any git command question.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

YSMsimon

YSMsimon/Warden

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

مستكشف الملفات

4 ملفات

SKILL.md

readonly

name

git-workflow

description

Git Workflow

Help the user work effectively with git — from individual commits to full branching strategies and pull request descriptions.

Commit messages — Conventional Commits

Format

<type>(<scope>): <short summary>

<optional body — explain WHY, not what>

<optional footer>

Types

Type	When to use
`feat`	New user-facing feature
`fix`	Bug fix
`refactor`	Code restructuring, no behaviour change
`perf`	Performance improvement
`test`	Adding or fixing tests
`docs`	Documentation only
`chore`	Build, deps, tooling
`ci`	CI/CD pipeline
`revert`	Reverting a previous commit

Rules

Summary: max 50 chars, imperative mood ("add" not "added"), no trailing period
Blank line between summary and body
Body: explain why — the diff shows what
Wrap body at 72 characters
Reference issues in footer: Closes #42

Branching strategy

GitHub Flow (default — simple projects, CI/CD)

main is always deployable
Branch for every feature or fix
PR → review → merge to main

Branch naming: feature/jwt-refresh, fix/profile-update-race, chore/upgrade-dependencies

Git Flow (versioned releases, larger teams)

main: production, always tagged
develop: integration branch
feature/*: from develop, back to develop
release/*: from develop when prepping a release
hotfix/*: from main for urgent fixes, merge back to both main and develop

When the user provides context

If they share a diff or describe changes — write the commit message directly, don't just explain the format.

If they show a messy branch history — recommend the exact rebase commands with the real commit count.

If they describe a PR — write the full PR description using the template.

المزيد من هذا المستودع

نفس المستودع

api-designer

YSMsimon/Warden

Design REST APIs including endpoints, URL structures, HTTP methods, request/response bodies, status codes, authentication, versioning, pagination, and error formats. Use this skill whenever the user wants to design an API, plan endpoints, structure a backend, decide on REST conventions, write an API spec, design request/response shapes, or asks "how should I structure this API?" Trigger on phrases like "design an API", "what endpoints do I need", "REST API for", "API structure", "request/response format", "status codes", or "API versioning".

2026-05-054

code-review

YSMsimon/Warden

Perform a structured, thorough code review on a file, function, snippet, or entire module. Use this skill whenever the user asks to review code, check code quality, audit a function, look for bugs, find security issues, assess readability, or wants feedback on their implementation. Trigger even if the user phrases it casually like "what do you think of this?", "is this good?", or "any issues here?" when code is present.

2026-05-054

db-schema

YSMsimon/Warden

Design, review, and improve PostgreSQL database schemas including tables, columns, data types, indexes, constraints, foreign keys, relationships, migrations, and query optimisation. Use this skill whenever the user wants to model data, design a database, write a migration, optimise queries with indexes, normalise a schema, add pgvector support, or asks "how should I structure this in the database?" Trigger on mentions of tables, schemas, migrations, ERDs, relationships, PostgreSQL, pgvector, or database design questions.

2026-05-054

debug-assistant

YSMsimon/Warden

Systematically debug errors, exceptions, unexpected behaviour, and failing tests. Use this skill whenever the user shows an error message, stack trace, wrong output, or describes something that isn't working. Trigger on phrases like "I'm getting an error", "this isn't working", "why is this failing", "I don't understand this traceback", "help me debug", "getting a TypeError/ValueError/KeyError/AttributeError", or when any stack trace or error message is present in the conversation.

2026-05-054

dockerfile

YSMsimon/Warden

Write, explain, debug, and optimise Dockerfiles and docker-compose.yml files for any language or stack. Use this skill whenever the user wants to containerise an application, write a Dockerfile, set up docker-compose, configure environment variables in containers, set up multi-stage builds, reduce image size, fix Docker build errors, or debug container networking issues. Trigger on words like "Dockerfile", "docker-compose", "containerise", "container", "docker build", "image size", "port", or "volume".

2026-05-054

test-writer

YSMsimon/Warden

Write unit tests, integration tests, and test fixtures for any function, class, module, or API endpoint. Use this skill whenever the user wants to write tests, increase test coverage, test edge cases, set up pytest fixtures, mock external dependencies, test database operations, test an API endpoint, or debug a failing test. Trigger on phrases like "write tests for", "add unit tests", "test this function", "how do I test", "mock this", "pytest", "test coverage", "failing test", or "fixture".

2026-05-054

name

git-workflow

description

Git Workflow

Help the user work effectively with git — from individual commits to full branching strategies and pull request descriptions.

Commit messages — Conventional Commits

Format

<type>(<scope>): <short summary>

<optional body — explain WHY, not what>

<optional footer>

Types

Type	When to use
`feat`	New user-facing feature
`fix`	Bug fix
`refactor`	Code restructuring, no behaviour change
`perf`	Performance improvement
`test`	Adding or fixing tests
`docs`	Documentation only
`chore`	Build, deps, tooling
`ci`	CI/CD pipeline
`revert`	Reverting a previous commit

Rules

Summary: max 50 chars, imperative mood ("add" not "added"), no trailing period
Blank line between summary and body
Body: explain why — the diff shows what
Wrap body at 72 characters
Reference issues in footer: Closes #42

Branching strategy

GitHub Flow (default — simple projects, CI/CD)

main is always deployable
Branch for every feature or fix
PR → review → merge to main

Branch naming: feature/jwt-refresh, fix/profile-update-race, chore/upgrade-dependencies

Git Flow (versioned releases, larger teams)

main: production, always tagged
develop: integration branch
feature/*: from develop, back to develop
release/*: from develop when prepping a release
hotfix/*: from main for urgent fixes, merge back to both main and develop

When the user provides context

If they share a diff or describe changes — write the commit message directly, don't just explain the format.

If they show a messy branch history — recommend the exact rebase commands with the real commit count.

If they describe a PR — write the full PR description using the template.