Run any Skill in Manus with one click

clone-project

Stars0

Forks1

UpdatedMarch 7, 2026 at 21:46

Clone an ontology repository into the workspace's projects directory for local contribution. Use whenever the user wants to clone an ontology repo, set up a project locally, or get a copy to work on—e.g. "clone this ontology", "set up this repo locally", "get a copy of this project to work on". All subsequent work (edits, branch, PR) is done from the cloned project directory.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Minitour

Minitour/agentic-ontology-development-kit

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	clone-project
description	Clone an ontology repository into the workspace's projects directory for local contribution. Use whenever the user wants to clone an ontology repo, set up a project locally, or get a copy to work on—e.g. "clone this ontology", "set up this repo locally", "get a copy of this project to work on". All subsequent work (edits, branch, PR) is done from the cloned project directory.

Clone Project Skill

Use this skill when the user wants to clone an ontology repository so they can work on it in this workspace. Clones go into a single, predictable location: projects/<slug>/ at the root of the Ontology Builder repo. All later steps (implement, ODK/ROBOT, branch, commit, PR) are performed from that project directory—the agent (or user) changes directory into the clone and runs everything there.

When to Use

User says "clone this ontology", "set up this repo locally", "get a copy of this project to work on", or provides a repo URL to clone.
As the second step in the external-contribution workflow (after analyze-project, or in parallel): clone into projects/, then the user or agent will cd into the clone for implement and PR.

Use this skill so clones land in one place and paths stay consistent; do not clone into arbitrary directories.

Workflow

Resolve repo URL: From the user's message or a prior analyze step, get the clone URL (e.g. https://github.com/owner/repo or git@github.com:owner/repo.git) and derive a stable slug (e.g. owner-repo) so the same repo always lands in the same path.
Ensure projects/ exists: At the root of the Ontology Builder repo, create the directory projects/ if it does not exist. The projects/ directory is gitignored.
Clone: Run git clone <url> projects/<slug>. Use the slug consistently (e.g. from GitHub: owner-repo). If projects/<slug> already exists, do not overwrite—report that the project is already cloned and where it is; offer to pull latest or to use the existing clone.
Verify build (optional but recommended): Use the built-in ODK tools with project_dir set to the clone path. For example: odk_make with target: test, project_dir: projects/<slug>, and make_path: the path to the Makefile in the clone (e.g. ontology). Do not run node scripts/odk-docker-run.js manually—use odk_robot and odk_make with project_dir so the correct project is mounted. Report success or any failure.
Tell the user: Confirm the clone path (projects/<slug>/). For ODK/ROBOT and Make, use odk_robot and odk_make with project_dir set to projects/<slug> (and make_path when using odk_make). Git operations (branch, commit, PR) are still done from the clone directory (cd into it).

Slug Convention

Prefer a slug that is stable and readable: e.g. from https://github.com/org/ontology-name use ontology-name. Avoid spaces and characters that are problematic in paths.
The same repo URL should always map to the same slug so repeated clones or "open this project" workflows find the same folder.

Working on the Clone

After cloning:

ODK/ROBOT and Make: Use the built-in odk_robot and odk_make tools with project_dir set to the clone root (e.g. projects/owner-repo). Paths in robot_args are relative to the clone root (e.g. ontology/edit.owl or the project's edit file). For odk_make, also set make_path to where the Makefile lives (e.g. ontology). Do not run node scripts/odk-docker-run.js from the shell—using the tools with project_dir ensures the correct project is mounted and keeps the workflow consistent.
Ontology-editor: Use absolute paths to OWL files in the clone (e.g. C:\...\ontology-builder\projects\owner-repo\ontology\edit.owl) or load the file and register it by name.
Git operations (branch, commit, push, PR): Perform these from the clone root (cd into projects/<slug>/). The create-pull-request skill assumes the agent is in that directory for Git commands.

Prerequisites

Git installed; network access to the clone URL.
For running ODK/QC after clone: Docker (and optionally Make) as required by the target project; the Ontology Builder script uses the ODK Docker image and mounts the clone when run with that project_dir.

Output

Report the clone path: projects/<slug>/.
If build/QC was run, report pass/fail.
Remind that subsequent steps (implement, branch, PR) are done from that directory.

More from this repository

same repository

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	clone-project
description	Clone an ontology repository into the workspace's projects directory for local contribution. Use whenever the user wants to clone an ontology repo, set up a project locally, or get a copy to work on—e.g. "clone this ontology", "set up this repo locally", "get a copy of this project to work on". All subsequent work (edits, branch, PR) is done from the cloned project directory.

Clone Project Skill

When to Use

User says "clone this ontology", "set up this repo locally", "get a copy of this project to work on", or provides a repo URL to clone.
As the second step in the external-contribution workflow (after analyze-project, or in parallel): clone into projects/, then the user or agent will cd into the clone for implement and PR.

Use this skill so clones land in one place and paths stay consistent; do not clone into arbitrary directories.

Workflow

Resolve repo URL: From the user's message or a prior analyze step, get the clone URL (e.g. https://github.com/owner/repo or git@github.com:owner/repo.git) and derive a stable slug (e.g. owner-repo) so the same repo always lands in the same path.
Ensure projects/ exists: At the root of the Ontology Builder repo, create the directory projects/ if it does not exist. The projects/ directory is gitignored.
Clone: Run git clone <url> projects/<slug>. Use the slug consistently (e.g. from GitHub: owner-repo). If projects/<slug> already exists, do not overwrite—report that the project is already cloned and where it is; offer to pull latest or to use the existing clone.
Verify build (optional but recommended): Use the built-in ODK tools with project_dir set to the clone path. For example: odk_make with target: test, project_dir: projects/<slug>, and make_path: the path to the Makefile in the clone (e.g. ontology). Do not run node scripts/odk-docker-run.js manually—use odk_robot and odk_make with project_dir so the correct project is mounted. Report success or any failure.
Tell the user: Confirm the clone path (projects/<slug>/). For ODK/ROBOT and Make, use odk_robot and odk_make with project_dir set to projects/<slug> (and make_path when using odk_make). Git operations (branch, commit, PR) are still done from the clone directory (cd into it).

Slug Convention

Prefer a slug that is stable and readable: e.g. from https://github.com/org/ontology-name use ontology-name. Avoid spaces and characters that are problematic in paths.
The same repo URL should always map to the same slug so repeated clones or "open this project" workflows find the same folder.

Working on the Clone

After cloning:

ODK/ROBOT and Make: Use the built-in odk_robot and odk_make tools with project_dir set to the clone root (e.g. projects/owner-repo). Paths in robot_args are relative to the clone root (e.g. ontology/edit.owl or the project's edit file). For odk_make, also set make_path to where the Makefile lives (e.g. ontology). Do not run node scripts/odk-docker-run.js from the shell—using the tools with project_dir ensures the correct project is mounted and keeps the workflow consistent.
Ontology-editor: Use absolute paths to OWL files in the clone (e.g. C:\...\ontology-builder\projects\owner-repo\ontology\edit.owl) or load the file and register it by name.
Git operations (branch, commit, push, PR): Perform these from the clone root (cd into projects/<slug>/). The create-pull-request skill assumes the agent is in that directory for Git commands.

Prerequisites

Git installed; network access to the clone URL.
For running ODK/QC after clone: Docker (and optionally Make) as required by the target project; the Ontology Builder script uses the ODK Docker image and mounts the clone when run with that project_dir.

Output

Report the clone path: projects/<slug>/.
If build/QC was run, report pass/fail.
Remind that subsequent steps (implement, branch, PR) are done from that directory.