菜单
Use when creating a pull request, preparing changes for review, or pushing work to GitHub. Handles quality checks, branch management, conventional commits, openspec archival, and PR creation end-to-end.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when converting files to Markdown format for LLM consumption, document analysis, or text extraction. Supports PDF, Office documents, images, audio, HTML, and more via Microsoft's markitdown. Don't use for simple text file reads, existing Markdown files, or when the file is in a usable format.
Use when creating or modifying custom opencode commands in the `commands/` directory. Covers markdown command files, frontmatter options (description, agent, model, subtask), prompt templates with $ARGUMENTS, shell output injection, and file references.
Use when rendering mermaid diagrams to PNG, SVG, or PDF images. Handles both .mmd files and inline mermaid code blocks in markdown files. Don't use for creating mermaid syntax or GraphViz/DOT diagrams.
Use when creating a comprehensive architecture document for a codebase. First explores the codebase using the exploring-code skill, then writes a detailed architecture document. Don't use for quick documentation lookups or single-file questions: only use when asked to create or update architectural documents.
Use to do a thorough exploration of an existing codebase. Always use this when asked to explore a codebase/repo/project. Always use it when starting a task that requires deep knowledge of the codebase. Don't use for quick lookups or single-file questions.
You MUST use when creating, modifying, or reviewing GitHub Actions workflow files. For security reasons it is VITAL that you use this skill when working with third party actions (including `actions/checkout` and other official actions).
基于 SOC 职业分类
| name | making-prs |
| description | Use when creating a pull request, preparing changes for review, or pushing work to GitHub. Handles quality checks, branch management, conventional commits, openspec archival, and PR creation end-to-end. |
| license | MIT |
| metadata | {"author":"Robert Hafner","source":"https://github.com/tedivm/opencode-config"} |
Run quality checks, verify openspec status, create a feature branch, commit with conventional format, and open a PR.
Load and execute the quality-checks skill to ensure all tests, lints, and formatting pass before proceeding. Do not skip this step.
If quality checks fail, fix everything until the full suite passes green. Only continue to step 2 once all checks pass.
If the project uses OpenSpec (check for .openspec/ directory or openspec.json):
openspec list --json to find active changes.openspec list shows the change as active (not archived), ask the user: "The OpenSpec proposal [name] is still active. Should I archive it before creating the PR?"openspec-archive) and load it to handle the archival. If no archive skill exists, fall back to running openspec archive <change-name> --yes.git symbolic-ref refs/remotes/origin/HEAD or check git remote show origin for the HEAD branch.git branch --show-current.git diff --stat --cached or git status --short.feat/..., fix/..., chore/..., refactor/..., docs/....git checkout -b <branch-name>.Stage all changes: git add -A.
Determine the conventional commit type by analyzing the changes:
feat — new functionalityfix — bug fixesrefactor — code restructuring without behavior changeschore — maintenance, deps, configdocs — documentation onlytest — adding or modifying testsstyle — formatting, missing semicolons, etcperf — performance improvementsFunctional markdown: AGENTS.md files and skills (.opencode/skills/ or skills/) are markdown but function as agent instructions. Changes to them alter agent behavior — classify them as feat (new behavior), fix (corrected behavior), or refactor (restructured guidance), never chore or docs.
Write a conventional commit message:
<type>(<scope>): <description>Examples:
feat(auth): add JWT-based session management
fix(payments): retry failed transactions with exponential backoff
chore(deps): bump redis client to v4.2
refactor(parser): extract tokenization into standalone module
git commit -m "<title>" [-m "<body>"].git push -u origin <branch-name>.Implements [change-name] or link to the spec.gh-cli skill:
gh pr create --title "TITLE" --body "BODY"
When the user confirms the PR has been merged:
git checkout <default-branch>.git pull origin <default-branch>.