원클릭으로 Manus에서 모든 스킬 실행

github-flow-change

스타3

포크0

업데이트2026년 4월 13일 08:54

Use when the task involves modifying files in this repository and preparing the work as a GitHub Flow change. The change should follow qrlib's spec-driven workflow: decide a change slug, sync local main with origin/main, recommend a branch name, plan commit boundaries, and prepare a PR-ready summary that references spec/design docs. Do not use for read-only explanation tasks.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

qrhuang2021

qrhuang2021/qrlib

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 개발자컴퓨터 및 수학직·SOC 15-1252

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

qrlib-library-authoring

qrhuang2021/qrlib

Use when adding or modifying Python library code under src/qrlib. Start from an existing or new developer spec/design, keep public API boundaries explicit, separate internal modules from stable exports, and update tests plus public docs together. Do not use for pure Git workflow tasks or read-only explanation tasks.

2026-04-133

qrlib-spec-driven-change

qrhuang2021/qrlib

Use when planning or executing any non-trivial change in qrlib. Decide whether the change needs a full spec/design, create or update docs/developer/specs and docs/developer/design first, then map the change to implementation, tests, public docs, and verification. Do not use for typo-only or read-only tasks.

2026-04-133

name	github-flow-change
description	Use when the task involves modifying files in this repository and preparing the work as a GitHub Flow change. The change should follow qrlib's spec-driven workflow: decide a change slug, sync local main with origin/main, recommend a branch name, plan commit boundaries, and prepare a PR-ready summary that references spec/design docs. Do not use for read-only explanation tasks.

在开始实施前，先用一句话概括这次改动的单一目标，并给出建议的 change slug。
先判断这次改动是否需要完整规范与设计。只要它影响公开能力、行为、架构、文档结构或协作流程，就应在开始编码前准备：
- docs/developer/specs/<slug>.md
- docs/developer/design/<slug>.md
在开始开发前，同步主线：
- 切换到 main
- 获取远端更新，并让本地 main 与 origin/main 保持一致
- 不要基于落后的本地 main 创建新分支
- 如果本地 main 有未同步或额外提交，先显式处理
基于该目标，给出推荐 branch 名称：
- 使用小写 ASCII 和 kebab-case
- 名称应短、可读、能直接表达改动目标
- 可按需要添加 feature/、fix/、refactor/、docs/、test/、chore/ 前缀
- 若合适，尽量让 branch 名称与 change slug 对齐
遵循 GitHub Flow：
- 一个 short-lived topic branch 只承载一个清晰目标
- 一个清晰目标最终对应一个 PR
- 与当前目标无关的改动必须拆分到新 branch
先规划 commit 边界，再组织修改。每个 commit 都应独立、完整、便于 review、revert 和 cherry-pick。
推荐 commit message 时，优先使用简洁的 Conventional Commits 风格：
- feat: ...
- fix: ...
- refactor: ...
- docs: ...
- test: ...
- chore: ...
如果改动天然包含多个步骤，主动给出“建议的 commit 划分”，并明确哪些 commit 对应规范 / 设计，哪些 commit 对应实现 / 测试 / 文档。
进入 PR 阶段前，实际运行 ./scripts/check.sh，或等价执行：
- ruff check .
- pytest
- mkdocs build
PR 成功合并后，执行收尾：
- 切回 main
- 再次同步本地 main 与 origin/main
- 删除本地已合并的 topic branch
最终输出时，至少给出：
- change slug
- 规范与设计路径
- 推荐 branch 名称
- 建议的 commit 划分
- 每个 commit 的 message
- 一段可直接用于 PR 描述的变更摘要