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

ابدأ الآن

$pwd:

commit

Name: Commit
Author: HazAT

// Read this skill before making git commits

تشغيل في Manus

$ git log --oneline --stat

stars:٣٩٣

forks:٣٩

updated:٩ أبريل ٢٠٢٦ في ٠٩:٠١

SKILL.md

readonly

name	commit
description	Read this skill before making git commits

Create a git commit for the current changes using Conventional Commits format with a polished, highly descriptive message. If there are commit hooks - do not skip them, it's your responsability to leave things better than they were.

Format

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

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).

related-skills.json

نفس المستودع

plan.md

from "HazAT/pi-config"

Solo-native planning workflow. Use when asked to "plan", "brainstorm", "design", "create a plan", "I want to build", or "let's build". Runs a scout, opens a planner that is interactive through approach selection, creates Solo todos, then automatically executes and reviews through Solo subagents and scratchpads.

2026-05-23393

handoff.md

from "HazAT/pi-config"

Start a fresh Solo Pi session from the current conversation. Use when asked to hand off, continue in a clean context, or run `/handoff <new prompt>`. Writes a Solo scratchpad summary of the important current-session context, then launches an interactive Solo agent in the same project with that handoff and the new prompt.

2026-05-18393

write-todos.md

from "HazAT/pi-config"

Write clear Solo todos that workers can execute without losing architectural intent. Use when asked to "create todos", "write todos", "break into tasks", "plan todos", or create work items from a plan. Ensures each todo has outcomes, examples, constraints, and verification criteria.

2026-05-14393

iterate-pr.md

from "HazAT/pi-config"

Iterate on a PR until CI passes. Use when you need to fix CI failures, address review feedback, or continuously push fixes until all checks are green. Automates the feedback-fix-push-wait cycle.

2026-04-09393

skill-creator.md

from "HazAT/pi-config"

Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, planning, writing, registration, and verification.

2026-03-31393

session-reader.md

from "HazAT/pi-config"

Efficiently read and analyze pi agent session JSONL files. Use when asked to "read a session", "review a session", "analyze a session", "what happened in this session", "load session", "parse session", "session history", "go through sessions", or given a .jsonl session file path.

2026-03-31393

package.json

"author": "HazAT"

"repository": "HazAT/pi-config"

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

$ install --global

$ download --local

تشغيل في Manus

$ useful --forSOC

مديرو الشبكات وأنظمة الحاسوبمهن الحاسوب والرياضيات15-1244L4

مطوّرو البرمجياتL4

name	commit
description	Read this skill before making git commits

Format

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

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).

commit

Format

Notes

Steps

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

Format

Notes

Steps

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