Verify Your Setup Once, Then Let Agents Run Free

Where this fits

You've just pulled a fresh repo, and the agent you're running needs to boot the app, seed data, and run health checks. But every time, it asks the same questions: which port, which env file, does it need login? That's the interview loop. verify-setup ends it: run it once, it sniffs the repo, confirms boot/seed/health with you, and writes .verify/setup.json. Later /verify runs read that file and ask nothing.

Why agents benefit

• Zero-question repeat runs – After setup, /verify uses the stored config, so agents skip the interactive interrogation and get straight to verifying.
• Auth state without secret storage – The skill captures browser session cookies into .verify/auth.json (gitignored), letting agents act as a logged-in user without ever seeing passwords or API keys.
• Repo-aware defaults – It sniffs the project structure (package.json, docker-compose, etc.) to propose sensible boot commands and health endpoints, reducing guesswork.
• Safe secret handling – It refuses to write pasted secrets and only references local .env files you choose, keeping production credentials out of repo files.
• Team-shareable config – It offers to commit .verify/setup.json so every developer on the team skips the same interview.

Practical scenarios

Onboarding a legacy monorepo

You point the agent at a 3-year-old Rails app. verify-setup detects the Gemfile, proposes bin/rails server, asks you to confirm the seed command and health endpoint, then writes config. The next agent run boots and verifies without a single prompt.

Testing an authenticated dashboard

Your app requires SSO. You run verify-setup, and its auth step opens a browser where you log in once. It saves the session cookies to .verify/auth.json. Now /verify can run integration tests as that user, and deleting the file revokes access.

CI parity for local verification

Your CI uses a specific env file and seed script. verify-setup captures those choices in .verify/setup.json (committed). Now every local agent run matches CI exactly, reducing "works on my machine" surprises.

Add it to your agent workflow

Install with:

npx skills add opslane/verify --skill verify-setup

Then run /verify-setup in your repo. It will ask a few confirming questions, write the config, and offer to commit it. After that, /verify just works. For a deeper look at how this skill fits into a broader agent toolkit, check out the OpenAgentSkill listing.

Compare before adopting

Before you add this skill, evaluate: Quality signals – Does the repo have recent commits, tests, and clear docs? Maintenance freshness – Is it actively updated to handle new package managers or auth flows? Alternatives – Compare with rolling your own setup script or using a generic setup skill that doesn't capture auth. Workflow fit – Does your team standardize on one verification flow? If not, the shared config might be ignored.

Why it is worth tracking

With 115 stars and a focused scope, verify-setup solves a real pain point: the repetitive setup interview that wastes agent time and developer attention. Its strict secret-handling policy and gitignored auth file show careful design. Watch it for adoption growth and updates—if it gains traction, it could become the standard pre-step for any /verify command in agent workflows. Evaluate it now if you're building agents that need repeatable, low-friction verification.