$npx -y skills add kecoma1/MQL5-SKILLS --skill gitUse when creating branches, writing commits, or following repository Git conventions in this workspace. Follow the local branch naming and commit message patterns, including issue references when available.
| 1 | # Git |
| 2 | |
| 3 | Use this skill when the user asks for help with branches, commits, or Git naming conventions in this repository. |
| 4 | |
| 5 | ## Branch Names |
| 6 | |
| 7 | Create short, lowercase branch names with hyphens. |
| 8 | Use one of these prefixes: |
| 9 | |
| 10 | - `feature/branch-name` |
| 11 | - `bug/branch-name` |
| 12 | - `hotfix/branch-name` |
| 13 | - `chore/branch-name` |
| 14 | - `docs/branch-name` |
| 15 | - `refactor/branch-name` |
| 16 | - `test/branch-name` |
| 17 | |
| 18 | Choose the prefix by intent: |
| 19 | |
| 20 | - `feature/` for new functionality |
| 21 | - `bug/` for defect fixes that are not urgent production fixes |
| 22 | - `hotfix/` for urgent fixes |
| 23 | - `chore/` for maintenance, config, tooling, or cleanup |
| 24 | - `docs/` for documentation-only changes |
| 25 | - `refactor/` for structural code improvements without intended behavior change |
| 26 | - `test/` for test-only additions or fixes |
| 27 | |
| 28 | Examples: |
| 29 | |
| 30 | ```text |
| 31 | feature/add-git-skill |
| 32 | bug/fix-backtest-report-path |
| 33 | hotfix/repair-mt5-launch-command |
| 34 | chore/normalize-skill-path-placeholders |
| 35 | docs/update-run-backtests-skill |
| 36 | refactor/simplify-fvg-loader |
| 37 | test/add-backtest-config-coverage |
| 38 | ``` |
| 39 | |
| 40 | ## Commit Format |
| 41 | |
| 42 | Use this format for commit subjects: |
| 43 | |
| 44 | ```text |
| 45 | type(scope): summary |
| 46 | ``` |
| 47 | |
| 48 | Preferred example: |
| 49 | |
| 50 | ```text |
| 51 | feat(skills): add git conventions skill |
| 52 | ``` |
| 53 | |
| 54 | When there is a related issue, add a blank line and reference it like this: |
| 55 | |
| 56 | ```text |
| 57 | feat(skills): add git conventions skill |
| 58 | |
| 59 | refs #123 |
| 60 | ``` |
| 61 | |
| 62 | ## Commit Types |
| 63 | |
| 64 | Use these commit types: |
| 65 | |
| 66 | - `feat` for new behavior or new functionality |
| 67 | - `fix` for bug fixes |
| 68 | - `hotfix` for urgent production fixes when the repository uses a distinct hotfix commit type |
| 69 | - `chore` for maintenance or tooling updates |
| 70 | - `docs` for documentation changes |
| 71 | - `refactor` for internal code restructuring without intended behavior change |
| 72 | - `test` for test changes |
| 73 | - `perf` for performance improvements |
| 74 | - `build` for build pipeline or dependency packaging changes |
| 75 | - `ci` for CI workflow changes |
| 76 | |
| 77 | ## Scope |
| 78 | |
| 79 | Use a short scope that matches the affected area. |
| 80 | |
| 81 | Examples: |
| 82 | |
| 83 | - `skills` |
| 84 | - `backtests` |
| 85 | - `compile` |
| 86 | - `mt5` |
| 87 | - `docs` |
| 88 | |
| 89 | ## Summary Rules |
| 90 | |
| 91 | Keep the summary short and action-oriented. |
| 92 | |
| 93 | - Use lowercase unless a term requires uppercase. |
| 94 | - Do not end the summary with a period. |
| 95 | - Prefer specific outcomes over vague wording. |
| 96 | |
| 97 | Good: |
| 98 | |
| 99 | ```text |
| 100 | fix(backtests): use placeholder report path in ini example |
| 101 | ``` |
| 102 | |
| 103 | Avoid: |
| 104 | |
| 105 | ```text |
| 106 | fix(stuff): various updates |
| 107 | ``` |
| 108 | |
| 109 | ## Issue References |
| 110 | |
| 111 | Use issue references when the repository tracks work with issue IDs. |
| 112 | |
| 113 | - Use `refs #issue-id` when the commit relates to an issue |
| 114 | - Use `closes #issue-id` when the commit is intended to close the issue |
| 115 | |
| 116 | Examples: |
| 117 | |
| 118 | ```text |
| 119 | fix(mt5): handle missing tester log gracefully |
| 120 | |
| 121 | refs #45 |
| 122 | ``` |
| 123 | |
| 124 | ```text |
| 125 | docs(skills): clarify branch naming rules |
| 126 | |
| 127 | closes #52 |
| 128 | ``` |
| 129 | |
| 130 | ## Pull Request Alignment |
| 131 | |
| 132 | When preparing multiple commits for one branch: |
| 133 | |
| 134 | - keep commits focused |
| 135 | - do not mix unrelated changes in the same commit |
| 136 | - keep the branch name aligned with the main intent of the work |
| 137 | |
| 138 | If the work is small and tightly related, prefer one clean commit over many noisy commits. |