Repo Preflight

---
name: repo-preflight
description: Design a bounded, low-risk trial for an unfamiliar open source tool before it touches real data, credentials, or a real workflow. Use before installing or granting access to a tool you have not verified yourself.
license: All-Rights-Reserved
metadata:
  author: Zain Haseeb
  version: 1.0.2
  changed: "2026-09-08"
  category: ai-safety
  tags: [open-source, trial, safety, verification]
---

# Repo Preflight

Design a trial that could establish whether an unfamiliar open source tool does useful work on synthetic data, within an explicitly approved environment. The deliverable is a plan, not an executed trial or a safety certificate.

Invoking this skill does not authorize installation, execution, network requests, credential use, permission changes, or deployment. Work from supplied material and already-authorized read-only inspection. Mark any unavailable evidence as unverified. If the user separately authorizes a trial, record its exact tool/version, environment, data, network access and allowed actions before executing within that scope; a successful trial does not authorize broader access.

## Critical behavior

1. Define the question the proposed trial must answer: does this tool do what it claims without needing full access on day one? A plan alone does not answer it.
2. Plan the first trial with synthetic or throwaway data and no real credentials.
3. Check maintenance activity, license terms, requested permissions, and network access before installing anything.
4. Name the specific signals that justify expanding access and the specific signals that should stop the trial immediately.
5. Never vouch for a tool's safety based on general reputation or popularity alone.
6. Label anything not directly verified from the person's own research as unverified.

## When to use

Use this before installing an open source tool that would touch real data, real credentials, production systems, or a workflow other people depend on. It is especially important for tools discovered through a quick search or a recommendation rather than a formal vetting process.

Do not use it for a tool already running safely in an isolated sandbox with no path to real access; the point of this skill is the transition from trial to trusted use.

## Run the preflight

### 1. Check before installing

Look at maintenance activity, license terms, what permissions or network access the tool requests, and whether its stated purpose matches what it actually does based on available documentation or source.

### 2. Specify an isolated first run

Specify the proposed isolation: a sandbox, a disposable container, or a machine with nothing sensitive on it. State the filesystem mounts, network policy, resource limits and synthetic input. Do not assume a container alone prevents network access or access through mounted folders. List the commands as proposed steps, not instructions already authorized to run.

### 3. Define the pass condition

State what a clean run looks like: the tool does what it claims, its behavior is explainable, and it made no unexplained network calls or unrelated permission requests.

### 4. Define the stop condition

State what should halt the trial immediately: undocumented network calls, requests for permissions unrelated to the stated purpose, undocumented data collection, or behavior that contradicts the tool's own documentation.

### 5. Decide on expansion

Specify what evidence would justify proposing an incremental expansion after a clean pass. Any proposal to use real data, credentials, scheduling or production access needs its own explicit approval; it is not an automatic next step.

## Output format

Return: evidence reviewed and missing, proposed environment and permissions, ordered trial steps with pass/stop conditions, cleanup and recovery plan, and the exact approval needed before execution. Label the result "trial plan — not executed" unless a separately authorized run actually happened. A completed trial alone grants no production data, credentials, scheduling or expanded access.

## Example

A team supplies the documentation and permissions manifest for an open source scraping tool recommended in a forum thread. The manifest requests broader filesystem access than its stated purpose needs. The plan flags the unexplained permission as a stop condition, proposes a disposable environment with no host mounts and synthetic input, and asks the owner to resolve the permission request before authorizing execution. No tool is installed or run during planning.

## Troubleshooting

- If the tool's documentation does not explain a requested permission, treat that as unverified rather than assuming it is benign.
- If synthetic data cannot reasonably exercise the tool's real function, explain the coverage gap and propose the smallest nonsensitive real-data sample for separate approval. Do not use it automatically.
- If the tool has no visible maintenance activity, weigh that against how critical the workflow is before proceeding.

## What not to do

- Do not grant production data, real credentials, or scheduling access merely because a trial passed; require explicit approval for the proposed expansion.
- Do not treat a high star count or popularity as evidence of safety.
- Do not skip the permissions and license check because the tool "looks simple."
- Do not present a partial trial as a completed safety review.