Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

pr-draft-summary

Sterne23

Forks20

Aktualisiert17. März 2026 um 02:29

Create a branch suggestion, PR title, and draft description after substantive Qubex changes are finished. Trigger when wrapping up a moderate-or-larger change that touched runtime code, tests, build config, or docs with behavior impact and you need a PR-ready handoff block with summary, compatibility notes, and verification results.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

amachino

amachino/qubex

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

Datei-Explorer

2 Dateien

SKILL.md

readonly

name	pr-draft-summary
description	Create a branch suggestion, PR title, and draft description after substantive Qubex changes are finished. Trigger when wrapping up a moderate-or-larger change that touched runtime code, tests, build config, or docs with behavior impact and you need a PR-ready handoff block with summary, compatibility notes, and verification results.

PR Draft Summary

Overview

Create a review-ready handoff summary from the current diff and repository conventions. Prefer one focused PR and make verification explicit.

Workflow

Inspect current context.
- Read git status --short, the current branch name, and a concise diff summary.
- If the branch already exists, keep it unless the user asks for a rename.
Suggest branch naming.
- Choose fix, feature, docs, or refactor based on the dominant change.
- Suggest codex/<type>/<short-slug> for new agent-created branches.
Draft the PR title.
- Use a concise prefix such as fix:, docs:, refactor:, or test:.
- Keep the title aligned with the smallest coherent user-visible change.
Draft the PR body.
- background and reason
- summary of changes
- user or API impact
- compatibility or migration notes
- validation commands and outcomes
- open risks or follow-ups
Use repository guidance.
- Keep the PR focused on one concern.
- Mention docs updates when public behavior changed.
- Include exact verification commands run in the uv environment.
Keep handoff honest.
- Separate work completed from follow-up ideas.
- State if tests, docs build, or release checks were not run.

Mehr aus diesem Repository

gleiches Repository

code-change-verification

amachino/qubex

Run the mandatory Qubex verification stack when changes affect runtime code, tests, examples, packaging, or build/test behavior. Use after substantive code changes, and do not mark the work complete until the required checks pass in the `uv` environment.

2026-03-1823

docs-sync

amachino/qubex

Audit Qubex documentation against code changes and report missing, incorrect, or outdated docs. Use when public APIs, behavior, setup, dependencies, examples, release notes, or developer guidance change; by default, inspect and prioritize the required updates first, then edit only after the user asks for docs changes.

2026-03-1823

examples-auto-run

amachino/qubex

Run Qubex examples in non-interactive auto mode, capture logs, and provide exact rerun commands. Use when validating notebooks or tutorial examples after code, docs, or dependency changes, especially for simulator and other offline examples; use the bundled script for execution, logging, and rerun-file generation instead of rebuilding the shell recipe by hand.

2026-03-1723

final-release-review

amachino/qubex

Compare the current Qubex release candidate against the previous tag and review release readiness. Use before beta, rc, or GA cuts to check version drift, release notes, compatibility messaging, build health, and validation status; use the bundled script to resolve the comparison range and collect the release diff mechanically.

2026-03-1723

implementation-strategy

amachino/qubex

Choose the Qubex compatibility boundary and implementation approach before editing runtime code, public APIs, imports, config formats, or behavior. Use before making API or runtime changes, especially when you must decide between direct cleanup and backward-compatibility handling.

2026-03-1723

openai-knowledge

amachino/qubex

Pull current OpenAI API and platform documentation through the official docs workflow. Use when a task depends on current OpenAI models, APIs, SDKs, or platform behavior and memory could be stale.

2026-03-1723

name	pr-draft-summary
description	Create a branch suggestion, PR title, and draft description after substantive Qubex changes are finished. Trigger when wrapping up a moderate-or-larger change that touched runtime code, tests, build config, or docs with behavior impact and you need a PR-ready handoff block with summary, compatibility notes, and verification results.

PR Draft Summary

Overview

Create a review-ready handoff summary from the current diff and repository conventions. Prefer one focused PR and make verification explicit.

Workflow

Inspect current context.
- Read git status --short, the current branch name, and a concise diff summary.
- If the branch already exists, keep it unless the user asks for a rename.
Suggest branch naming.
- Choose fix, feature, docs, or refactor based on the dominant change.
- Suggest codex/<type>/<short-slug> for new agent-created branches.
Draft the PR title.
- Use a concise prefix such as fix:, docs:, refactor:, or test:.
- Keep the title aligned with the smallest coherent user-visible change.
Draft the PR body.
- background and reason
- summary of changes
- user or API impact
- compatibility or migration notes
- validation commands and outcomes
- open risks or follow-ups
Use repository guidance.
- Keep the PR focused on one concern.
- Mention docs updates when public behavior changed.
- Include exact verification commands run in the uv environment.
Keep handoff honest.
- Separate work completed from follow-up ideas.
- State if tests, docs build, or release checks were not run.