agentleFS
moh-obaidamoh-obaida/ReadyVibe-Skills/skills/core/site-reconnaissance/SKILL.md

site-reconnaissance

Skill2 starsChanged 25 days agoApache-2.0View on GitHub

Use when you need to know what a website or web app actually is and does before reviewing or changing it: its framework, routes, audience, accounts, payments, email, analytics, forms, third parties, and deployment. It builds a short evidence-labeled context from the repository, config, and running site without a questionnaire. Do not use it to draft policies, apply fixes, or ask the user questions the repository can answer.

  • Reads credentials

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every other ReadyVibe skill is only as good as its picture of the product.

    line 13
  2. Very specific:

    Forms and data: Every <form>, submit handler, and API route: which fields, where they go, whether stored.

    line 28
  3. Distinctive:

    Do not ask a questionnaire.

    line 32
  4. Distinctive:

    Do not infer a legal jurisdiction.

    line 41
  5. Very specific:

    Only an optional working note, .readyvibe/context.md, which other skills may read but none require.

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

site-reconnaissance

Every other ReadyVibe skill is only as good as its picture of the product. This skill builds that picture from the artifacts, and writes it down briefly so nobody re-derives it.

Activate when

  • Starting any substantial launch review, or the first time a specialist is invoked on a project.
  • The applicable checks depend on facts you do not yet have (is there email? accounts? payments? which markets?).
  • Skip it when .readyvibe/context.md exists, is recent, and nothing relevant changed. Update rather than redo.

Inspect

Work from the cheapest, most reliable sources first.

  1. Project shape. package.json (framework, dependencies, scripts), lockfile, framework config (next.config.*, vite.config.*, astro.config.*), deployment files (vercel.json, netlify.toml, wrangler.toml, Dockerfile, CI workflows), README and docs.
  2. Routes and surfaces. File-based routes (app/, pages/, src/routes/), router config, API routes, server actions. Separate public, authenticated, admin, and utility routes.
  3. Data and services. Dependencies and imports that imply auth (next-auth, Clerk, Supabase auth, Firebase), payments (Stripe, Paddle, Lemon Squeezy, PayPal), email (Resend, SendGrid, Postmark, Mailchimp), analytics/ads/replay (GA, GTM, Meta Pixel, PostHog, Hotjar, Clarity, Plausible), error monitoring, AI providers, CMS, databases, storage, maps, chat, captcha. Environment templates (.env.example) name services; never read secret values from .env.
  4. Forms and data. Every <form>, submit handler, and API route: which fields, where they go, whether stored.
  5. Audience and markets. Copy, currencies, languages/locales, hreflang, shipping or pricing regions, legal pages already present, "who is this for" text, age or DOB fields. Only documented markets count; a TLD or timezone is a weak hint, not a jurisdiction.
  6. Runtime, when a URL exists. node scripts/inspect-metadata.mjs --url <site> for public structure and hosts; the running site for what actually renders. For what loads and stores, hand off to cookie-and-storage-audit.

Do not ask a questionnaire. Ask only when an unresolved fact changes what will be done, at most three questions, and keep working meanwhile. Typical justified questions: "Is this meant to be indexed?", "Which countries do you sell to?", "What is the production URL?".

Evidence that counts

Label each claim OBSERVED, SOURCE-INDICATED, DECLARED, INFERRED, UNKNOWN, or REVIEW REQUIRED. UNKNOWN is never a pass and never a failure.

  • A dependency in package.json is SOURCE-INDICATED. It may be unused. Check for an import or a script tag before saying the product "uses Stripe".
  • An .env.example entry says a service is expected, not that it is live.
  • README claims are DECLARED. Treat as leads.
  • Do not infer a legal jurisdiction. Record markets as DECLARED (stated) / INFERRED (from a strong documented signal, with the signal) / UNKNOWN.

May change

Only an optional working note, .readyvibe/context.md, which other skills may read but none require. Never product code.

Suggested shape (short, human-readable, each line evidence-labeled):

# Launch context (updated <date>)
Product: invoicing app for freelancers  [DECLARED: README]
Stack: Next.js 14 (App Router), Vercel  [OBSERVED: package.json, vercel.json]
Public vs internal: public marketing site + authenticated app under /app  [SOURCE-INDICATED: routes]
Audience/markets: freelancers; English only; markets not documented  [UNKNOWN]
Accounts/auth: yes, Supabase auth  [SOURCE-INDICATED]
Payments: none found  [OBSERVED: no processor imports or scripts]
Email: Resend, transactional only so far; no newsletter form  [SOURCE-INDICATED]
Analytics/ads/cookies: Vercel Analytics; PostHog imported in app/layout.tsx  [SOURCE-INDICATED; runtime not tested]
Forms: waitlist (email), contact (name/email/message)  [OBSERVED]
Third parties: Google Fonts, Stripe.js? (no)  [OBSERVED]
Age/children: no DOB field; adult B2B copy  [OBSERVED]
Indexing intent: marketing pages public, /app private  [DECLARED by user]
Production URL: https://ledgerly.app  [DECLARED]
Open questions: which countries do you sell to?

Must not claim

That a service is live, a market is targeted, or a feature is absent from code alone. "No payments found" means none were found in the places searched (say which).

Verify

Cross-check two independent sources for anything that will drive a decision (a dependency and an import or network request; a route file and a live response). Note where you relied on one source.

Escalate

Contradictions between docs and code, or signs of a regulated domain (health, finance, children, legal, education) or of unusual data (biometrics, precise location): flag for regulated-domain-triggers immediately.

No change is valid when

.readyvibe/context.md is already accurate. Say "context unchanged" and do not rewrite it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.