Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

create-pull-request

Estrelas0

Forks1

Atualizado7 de março de 2026 às 21:03

Create a branch, commit, push, and open a pull request from the current project directory. Use whenever the user wants to create a PR for their changes, open a pull request for an issue, or draft a PR description—e.g. "create a PR for this change", "open a pull request for issue

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

Minitour

Minitour/agentic-ontology-development-kit

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	create-pull-request
description	Create a branch, commit, push, and open a pull request from the current project directory. Use whenever the user wants to create a PR for their changes, open a pull request for an issue, or draft a PR description—e.g. "create a PR for this change", "open a pull request for issue

Create Pull Request Skill

Use this skill when the user wants to create a pull request for changes made in a cloned ontology project. You work from the project directory (e.g. projects/<slug>/): create a branch, commit, push, then open a PR with a description that matches the project's norms (summary, "Closes #N", optional change table and checklist). If GitHub CLI (gh) is available, use it to create the PR; otherwise provide the exact commands and a ready-to-paste PR body.

When to Use

User says "create a PR for this change", "open a pull request for issue #N", "draft a PR description", or similar.
After implementing an issue in a clone: changes are in projects/<slug>/; the agent has already cd'd into that directory. This skill handles branch, commit, push, and PR creation from there.

Assumption: The current working directory is the clone root (e.g. projects/owner-repo/). All Git commands (branch, commit, push) and any gh calls run from that directory. If the user is not in the clone root, remind them to cd into the project directory first (or do it as part of the workflow).

Workflow

Confirm context: Ensure you are in the clone root (e.g. projects/<slug>/). If not, change directory there before running Git or gh commands.
Branch: Create a branch name that matches the project's conventions (often issue-<N> or feature/<term-name>). Run git checkout -b <branch-name>.
Commit: Stage the relevant files and commit with a clear message (e.g. "Add term X (Closes #N)" or "Fix synonym for Y"). Run git add and git commit.
Push: Push the branch to the user's fork or the same repo: git push -u origin <branch-name>. If the clone points to upstream, the user may need a fork and a remote named origin; document that if needed.
PR description: Compose a PR body that fits the project's expectations (from analyze-project or CONTRIBUTING):
- Summary: One line and "Closes #N" (or "Fixes #N").
- Changes: Optional table (term added, obsoletion, etc.) or bullet list.
- Rationale: Brief justification (e.g. design pattern, references, annotation impact) if the project uses it.
- Checklist: If the project expects one (e.g. "pre-validation done", "term search done", "CI passes"), include a checklist and mark items or state that they are done.
Open the PR: If GitHub CLI (gh) is available and authenticated, run e.g. gh pr create --title "..." --body "..." from the clone root. Otherwise, output the PR title and body for the user to paste into the GitHub "Open pull request" form, and give the URL or steps to open the PR in the browser.

Branch Naming

Prefer patterns observed in the repo (e.g. issue-123, feature/term-label, fix/synonym-xyz). If unknown, use issue-<N> when closing an issue, or feature/<short-description>.

PR Body Conventions

Many ontology repos expect:

Link to issue: "Closes #N" or "Fixes #N" in the description.
Structured change: For term additions/obsoletions, a small table (term ID, label, definition, parent, etc.) or a bullet list of changes.
Checklist: Items such as: plan reviewed, pre-validation done, term search done, edits done, automated validation (e.g. make test) passed. If the project has a PULL_REQUEST_TEMPLATE or CONTRIBUTING section on PRs, align with it.

Use hypothetical wording (e.g. "a repo that uses NTR templates"); do not name specific ontologies.

GitHub CLI

If gh pr create is available, use it so the user gets a single command flow. If not, provide the full PR title and body and the URL to open a PR (e.g. https://github.com/owner/repo/compare/main...<branch>).
If the user has not configured a fork or origin, explain that they may need to add a remote and push to their fork, then open the PR from the fork to the upstream repo.

Output

Confirm branch name, commit message, and that push succeeded.
Either: link to the new PR (from gh pr create output) or the PR title + body + URL for the user to open the PR manually.

Mais deste repositório

mesmo repositório

ontology-reuse

Minitour/agentic-ontology-development-kit

Search ontology registries for existing terms to reuse before defining new ones. Use during Step 2 (Knowledge Exploration) and Step 3 (Knowledge Organization), or whenever the user asks to find existing ontology terms, search OLS, look up IRIs, check if a concept already exists, or reuse external terms—e.g. "find an existing class for fatigue", "search OLS for cancer", "is there an ontology term for this?", "reuse terms from OBO Foundry".

2026-04-110

cq-verification

Minitour/agentic-ontology-development-kit

Verify competency questions against an OWL ontology using SPARQL queries with test data. Use to verify every CQ with real query execution. Also use whenever the user asks to test, validate, or verify an ontology against its CQs, run SPARQL verification, check CQ coverage, or asks "does the ontology answer the competency questions?"—e.g. "verify CQs", "test the ontology", "run CQ checks", "validate against competency questions".

2026-03-290

ontology-editor

Minitour/agentic-ontology-development-kit

Read, edit, and manage OWL ontologies with OWL-MCP (axioms, prefixes, metadata, pitfall scanning). Use whenever the user wants to add or remove axioms, search axioms, add prefixes, set the ontology IRI, inspect ontology metadata, scan for pitfalls, or formalize an ontology in OWL—e.g. "add this axiom", "find axioms for class X", "add prefix", "check for pitfalls". Align with Ontology Builder workflow (formalization step); use absolute paths for OWL files. Never edit OWL files by hand.

2026-03-290

odk-robot

Minitour/agentic-ontology-development-kit

Run ROBOT for ontology QC, merge, reason, convert, template, or query. Use whenever the user needs to verify an ontology, validate OWL profile, merge OWL files, run a reasoner, convert OWL/OBO, build terms from CSV+template, or run SPARQL/DL over an ontology—e.g. "run robot verify", "merge these OWL files", "convert to OBO", "template from this CSV". This is the only skill for ROBOT; do not use odk-run for robot.

2026-03-280

odk-run

Minitour/agentic-ontology-development-kit

Run custom Make targets or ODK tools that have no dedicated skill. Use when the user wants a one-off make target (other than test, prepare_release, refresh-imports, update_repo, odkversion) or to run Konclude, jena, relation-graph, jinjanate, OORT, souffle, dicer-cli, yq-mf, or sssom-cli. Do not use for robot, owltools, dosdp-tools, fastobo-validator, riot, sparql, runoak, or sssom—use those skills instead.

2026-03-280

odp-pattern-selector

Minitour/agentic-ontology-development-kit

Browse and select Ontology Design Patterns (ODPs) from the ODP catalogue for ontology modeling. Use whenever the user needs to choose a modeling pattern, asks "how should I model X?", wants to represent parts, roles, events, time, collections, situations, n-ary relations, or any recurring ontology structure. Also use proactively during Step 3 (Knowledge Organization) and Step 4 (Draft Proposal) of the ontology-builder workflow when identifying candidate axiom patterns. Covers 55+ patterns from ontologydesignpatterns.org and the ODPA repository.

2026-03-210

name	create-pull-request
description	Create a branch, commit, push, and open a pull request from the current project directory. Use whenever the user wants to create a PR for their changes, open a pull request for an issue, or draft a PR description—e.g. "create a PR for this change", "open a pull request for issue

Create Pull Request Skill

When to Use

User says "create a PR for this change", "open a pull request for issue #N", "draft a PR description", or similar.
After implementing an issue in a clone: changes are in projects/<slug>/; the agent has already cd'd into that directory. This skill handles branch, commit, push, and PR creation from there.

Workflow

Confirm context: Ensure you are in the clone root (e.g. projects/<slug>/). If not, change directory there before running Git or gh commands.
Branch: Create a branch name that matches the project's conventions (often issue-<N> or feature/<term-name>). Run git checkout -b <branch-name>.
Commit: Stage the relevant files and commit with a clear message (e.g. "Add term X (Closes #N)" or "Fix synonym for Y"). Run git add and git commit.
Push: Push the branch to the user's fork or the same repo: git push -u origin <branch-name>. If the clone points to upstream, the user may need a fork and a remote named origin; document that if needed.
PR description: Compose a PR body that fits the project's expectations (from analyze-project or CONTRIBUTING):
- Summary: One line and "Closes #N" (or "Fixes #N").
- Changes: Optional table (term added, obsoletion, etc.) or bullet list.
- Rationale: Brief justification (e.g. design pattern, references, annotation impact) if the project uses it.
- Checklist: If the project expects one (e.g. "pre-validation done", "term search done", "CI passes"), include a checklist and mark items or state that they are done.
Open the PR: If GitHub CLI (gh) is available and authenticated, run e.g. gh pr create --title "..." --body "..." from the clone root. Otherwise, output the PR title and body for the user to paste into the GitHub "Open pull request" form, and give the URL or steps to open the PR in the browser.

Branch Naming

Prefer patterns observed in the repo (e.g. issue-123, feature/term-label, fix/synonym-xyz). If unknown, use issue-<N> when closing an issue, or feature/<short-description>.

PR Body Conventions

Many ontology repos expect:

Link to issue: "Closes #N" or "Fixes #N" in the description.
Structured change: For term additions/obsoletions, a small table (term ID, label, definition, parent, etc.) or a bullet list of changes.
Checklist: Items such as: plan reviewed, pre-validation done, term search done, edits done, automated validation (e.g. make test) passed. If the project has a PULL_REQUEST_TEMPLATE or CONTRIBUTING section on PRs, align with it.

Use hypothetical wording (e.g. "a repo that uses NTR templates"); do not name specific ontologies.

GitHub CLI

If gh pr create is available, use it so the user gets a single command flow. If not, provide the full PR title and body and the URL to open a PR (e.g. https://github.com/owner/repo/compare/main...<branch>).
If the user has not configured a fork or origin, explain that they may need to add a remote and push to their fork, then open the PR from the fork to the upstream repo.

Output

Confirm branch name, commit message, and that push succeeded.
Either: link to the new PR (from gh pr create output) or the PR title + body + URL for the user to open the PR manually.