harness-startup-path

Detects project stack signals and recommends a repeatable baseline verification command.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill harness-startup-path-maicongambini
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: harness-startup-path
Source: https://github.com/MaiconGambini/opencode-harness-guide/tree/main/skills/harness-startup-path
Command: npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill harness-startup-path-maicongambini

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting a new session or handoff without knowing how to verify a project leads to broken assumptions and wasted setup time. This Skill discovers the safest repeatable startup and verification command for any project without assuming a specific init script exists. ## Core Features & Use Cases - Stack Signal Discovery: Scans for explicit scripts (init.ps1, init.sh, Makefile), package manager lockfiles (npm, pnpm, yarn, bun), Python files (uv.lock, pyproject.toml), and other stacks (Cargo.toml, go.mod, docker-compose.yml) in a defined priority order. - Candidate Command Mapping: Maps each detected signal to concrete candidate commands such as npm test, uv run pytest, cargo test, or go test ./.... - Structured Audit Output: Produces a Startup Path Audit report covering detected stack, baseline command, required setup, skipped checks, risks, and a recommended artifact. - Use Case: At the start of a PREVC session on an unfamiliar repository, run this Skill to identify that the project uses pnpm and establish pnpm install && pnpm test as the baseline verification command for future sessions. ## Quick Start Analyze this repository and tell me the safest baseline startup and verification command I should use at the beginning of each session.

Frequently Asked Questions about harness-startup-path

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I find the right verification command for an unfamiliar project?

Scan the repository for stack signals in priority order: explicit scripts like init.ps1 or Makefile first, then lockfiles such as package-lock.json or uv.lock, then CI configs. Map the detected signal to a candidate command like npm test, uv run pytest, or go test ./... and pick one baseline command.

What should I do at session start when a project has no init script?

Do not assume init.ps1 exists. Detect the stack from lockfiles and manifests, choose a safe candidate command such as pnpm install followed by pnpm test, and if no safe command exists, recommend creating docs/harness/startup.md to document the path first.

Which package manager should I use when multiple lockfiles exist?

Follow the discovery order: check for explicit scripts first, then package manager lockfiles in the order package-lock.json, pnpm-lock.yaml, yarn.lock, bun.lockb. The first matching signal determines the candidate commands, so a pnpm-lock.yaml means pnpm install and pnpm test.

Can this skill modify my project files automatically?

No. The skill only audits and recommends; it does not create or edit files without explicit approval. Its output is a Startup Path Audit report suggesting an artifact such as init.ps1, init.sh, a Makefile target, or docs/harness/startup.md.

What are the limitations of automatic startup command detection?

Detection relies on recognizable signals like lockfiles, manifests, and CI configs, so unconventional stacks or projects with multiple mixed stacks may yield ambiguous results. In those cases the audit reports skipped checks and risks, and recommends documenting a manual startup path.