add-geo-tool

Files (1)

• SKILL.md

SKILL.md (first lines)

# Create Repository Documentation Skill

## Purpose

This skill analyzes a repository from a user-provided GitHub URL and turns that analysis into a new repository-specific skill.

The generated output must be written to:

- `skills/<repository-name>/SKILL.md`

This is for cases where a user wants the workflow to clone another repository into `tools/` first and then create a reusable skill that explains:

- what the repository is for
- how it is structured
- how it works internally
- how to run the scripts, services, or applications it contains

## Invocation

Expected usage pattern:

```text
/create-doc {github-url}
```

Examples:

```text
/create-doc https://github.com/owner/some-repo
/create-doc https://github.com/owner/some-repo.git
```

## Required Outcome

Given a GitHub repository URL, this skill must:

1. Accept the GitHub repository URL.
2. Derive the repository name from that URL.
3. Clone the repository into `tools/<repository-name>`. Use `git clone {github-url}`.
4. Inspect the cloned repository contents directly.
5. Summarize what the repository is for.
6. Analyze the implementation meticulously, one important file at a time.
7. Go function by function or script by script where practical.
8. Explain execution flow and how components connect.
9. Determine how to run the repository from checked-in evidence.
10. Create a new folder under `skills/` named after the repository.
11. Write a new repository-specific `SKILL.md` in that folder.

## Operating Rules

### Stay grounded in the repository

- Do not invent features.
- Do not describe architecture that is not present.
- Do not infer behavior without evidence from code, metadata, or documentation.
- If the repository is incomplete, minimal, or scaffold-only, state that explicitly.

### Start from concrete control surfaces

Prioritize:

- `README.md`
- dependency and packaging files
- build or task files
- executable scripts
- application entrypoints
- CLI bootstrap modules
- test commands that reveal intended usage

Then step inward to the code that directly controls runtime behavior.

### Analyze in a strict order

Work in this sequence:

1. Purpose and top-level structure
2. Runtime and build metadata
3. Main entrypoints and executable scripts
4. Supporting modules and internal flow
5. Function-level behavior in important files
6. How to run the repository

### Spend depth where it matters

Give the deepest treatment to:

- files in `tools/`, `scripts/`, `bin/`, or equivalent folders
- main application entrypoints
- modules called directly by those entrypoints
- orchestration files that decide startup behavior

Use lighter treatment for:

- lockfiles
- generated files
- vendored code
- dependency directories
- build artifacts

## Recommended Workflow

### Step 1. Resolve the GitHub URL

- Accept the target GitHub repository URL.
- Confirm that it is a repository URL, not a local path.
- Derive the repository name from the URL.
- Define the clone destination as `tools/<repository-name>`.

If the target directory already exists:

- inspect whether it is the intended repository clone
- do not overwrite or delete existing contents blindly
- either reuse the existing clone if it matches the requested repository or state the conflict clearly

### Step 2. Clone into `tools/`

- Clone the repository into `/store005/yohanuwa/Code/boglodite/tools/<repository-name>`.
- Use the cloned checkout as the only source for subsequent analysis.
- Confirm the clone produced a plausible repository root.

From yohanesnuwara/boglodite, MIT.

More from yohanesnuwara/boglodite