Clone Project

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, 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

1. 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.
2. 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.
3. 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.
4. Note the QC setup: Inspect the clone's CI configuration (e.g. .github/workflows/*.yml) so you know what checks the target repository runs on pull requests. QC for external contributions is run by the target repository's own CI, not locally—do not attempt to build or run the repo's ODK/ROBOT pipeline in this workspace.
5. Tell the user: Confirm the clone path (projects/<slug>/). Ontology edits are made with the ontology-editor tools; consistency/CQ checks use the owl-mcp check_consistency and sparql_query tools. Git operations (branch, commit, PR) are 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:

• Ontology-editor: Use absolute paths to OWL files in the clone (e.g. C:\...\ontology-builder\projects\owner-repo\ontology\edit.owl) for all axiom, prefix, and metadata changes.
• Consistency and CQ checks: Use owl-mcp check_consistency and sparql_query (absolute paths) for local validation. Full repository QC is left to the target repo's CI on the PR.
• 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.

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.