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

create-zakura-pr

النجوم٣٧

التفرعات٦

آخر تحديث١٩ يوليو ٢٠٢٦ في ٢١:٤٢

Create and finish Zakura pull requests with a draft-first workflow. Use when the user mentions PR, pull request, open PR, draft PR, create PR, publish PR, or prepare PR.

التثبيت

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

تشغيل في Manus

المصدر

zakura-core

zakura-core/zakura

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

تنزيل

تشغيل في Manus

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

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

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

SKILL.md

readonly

name	create-zakura-pr
description	Create and finish Zakura pull requests with a draft-first workflow. Use when the user mentions PR, pull request, open PR, draft PR, create PR, publish PR, or prepare PR.

Create a Zakura Pull Request

Open pull requests in draft mode by default. Only create a ready-for-review PR when the user explicitly requests it.

Workflow

Review the complete branch diff and commit history.
Check IDE diagnostics for edited files and run any quick mandatory checks, including Markdown lint for changed Markdown.
Commit and push the focused change.
Open the PR immediately with gh pr create --draft, using the repository PR template and a conventional-commit title.
After the draft PR exists, run compilation and risk-proportional local verification.
Fix failures, commit the fixes as follow-up commits, push them, and update the draft PR's test evidence.
Keep the PR in draft until required checks pass and the user asks to mark it ready.

Do not wait for the branch to compile before opening the draft PR. A draft PR provides early visibility and starts CI while local compilation proceeds.

If compilation or tests cannot run, leave the PR in draft and state the blocker in the PR summary. Never represent an unrun check as passing.

Verification

High-risk changes: run all relevant CI-equivalent tests and lints after the draft is open and before marking it ready.
- Use this for changes over 300 LOC, or changes touching consensus, P2P, cryptography, serialization, database migrations, or other validation-critical logic.
Low-risk changes: skip local compilation unless the user requests it; rely on draft CI and report the skipped checks.
- Use this for small PRs, configuration changes, CI boilerplate, docs-only changes, or other low-risk edits.
Markdown changes: always run Markdown lint for the changed files.
Check IDE diagnostics for recently edited files before opening the draft and again after follow-up fixes.

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

نفس المستودع

release-zakura

zakura-core/zakura

Prepare, review, and publish Zakura releases and release candidates. Use when bumping Zakura versions, preparing a release PR, validating the crates.io package graph, reviewing release readiness, or running the protected Create release workflow.

2026-07-2337

deploy-all

zakura-core/zakura

Roll out one Zakura ref to every managed node in staged halves: testnet first, then mainnet. Use when the user asks to deploy all nodes, deploy the whole fleet, or perform a full Zakura rollout.

2026-07-1937

deploy-specific

zakura-core/zakura

Deploy one or more explicitly named Zakura testnet or mainnet nodes through GitHub Actions. Use when the user asks to deploy specific nodes or provides a node list. Use deploy-all for a complete fleet rollout.

2026-07-1937

zakura-trace-plots

zakura-core/zakura

Generate metrics-aware plots and summaries from Zebra Zakura perf trace directories. Use when the user asks to plot or analyze Zakura traces, block_sync.jsonl, commit_state.jsonl, feedrun CSVs, applying/reorder/stalls, HoL stalls, throughput, or commit metrics from a trace_dir.

2026-07-1437

zakura-trace-zip

zakura-core/zakura

Create shareable zip archives from Zebra Zakura perf trace directories. Use when the user asks to zip, package, archive, share, or export a trace_dir such as feedrun-*-traces or Zakura JSONL traces.

2026-07-1437

name	create-zakura-pr
description	Create and finish Zakura pull requests with a draft-first workflow. Use when the user mentions PR, pull request, open PR, draft PR, create PR, publish PR, or prepare PR.

Create a Zakura Pull Request

Open pull requests in draft mode by default. Only create a ready-for-review PR when the user explicitly requests it.

Workflow

Review the complete branch diff and commit history.
Check IDE diagnostics for edited files and run any quick mandatory checks, including Markdown lint for changed Markdown.
Commit and push the focused change.
Open the PR immediately with gh pr create --draft, using the repository PR template and a conventional-commit title.
After the draft PR exists, run compilation and risk-proportional local verification.
Fix failures, commit the fixes as follow-up commits, push them, and update the draft PR's test evidence.
Keep the PR in draft until required checks pass and the user asks to mark it ready.

Do not wait for the branch to compile before opening the draft PR. A draft PR provides early visibility and starts CI while local compilation proceeds.

If compilation or tests cannot run, leave the PR in draft and state the blocker in the PR summary. Never represent an unrun check as passing.

Verification

High-risk changes: run all relevant CI-equivalent tests and lints after the draft is open and before marking it ready.
- Use this for changes over 300 LOC, or changes touching consensus, P2P, cryptography, serialization, database migrations, or other validation-critical logic.
Low-risk changes: skip local compilation unless the user requests it; rely on draft CI and report the skipped checks.
- Use this for small PRs, configuration changes, CI boilerplate, docs-only changes, or other low-risk edits.
Markdown changes: always run Markdown lint for the changed files.
Check IDE diagnostics for recently edited files before opening the draft and again after follow-up fixes.