repo-diagnostics

Inspect a repository's package manager, scripts, entrypoints, env shape, and database markers before edits.

2|Updated Jun 1, 2026
One-click install
npx skills add https://github.com/FluxonLab/Skillry --skill repo-diagnostics-fluxonlab
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: repo-diagnostics
Source: https://github.com/FluxonLab/Skillry/tree/main/plugins/core-operations/skills/01-repo-diagnostics
Command: npx skills add https://github.com/FluxonLab/Skillry --skill repo-diagnostics-fluxonlab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Before fixing a bug or building a feature in an unfamiliar repository, engineers often guess the package manager, framework, or run commands — leading to corrupted lockfiles, wrong test runs, and fixes that never address the real failure. This Skill grounds every repair plan in evidence gathered from the actual files, with read-only inspection and secret redaction. ## Core Features & Use Cases - Environment Detection: Identifies the package manager from lockfiles, confirms runtime versions against pins like .nvmrc, and maps the real dev/build/test script surface. - Failure Reproduction: Captures the exact failing command, full error output, and exit code before any edit is proposed. - Structural Mapping: Includes an absorbed codebase-cartography reference for tracing module layout, entry points, data flow, and high-risk files in sprawling codebases. - Use Case: You inherit a monorepo with no onboarding docs and a reported build failure. Run this Skill to confirm it uses pnpm workspaces, locate the owning package, list required env vars (values redacted), and reproduce the failure with its exit code before touching code. ## Quick Start Ask the AI to inspect this repository and report the package manager, scripts, framework, entrypoints, env variables, and reproduce the reported failure before making any changes.

Frequently Asked Questions about repo-diagnostics

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

FAQPage Schema
How do I inspect an unfamiliar repository before making changes?▼

Start by identifying the package manager from its lockfile, then read the script surface in package.json or Makefile, detect the framework from config markers, and locate entrypoints. Reproduce any reported failure with the exact command and exit code before proposing edits.

How to detect which package manager a project uses?▼

Check the lockfile: pnpm-lock.yaml means pnpm, yarn.lock means yarn, package-lock.json means npm, and bun.lockb means bun. Multiple lockfiles in one repo is a red flag signaling an ambiguous package manager setup.

Why does a project work on one machine but fail on another?▼

Runtime drift is a common cause: the repo pins a version via .nvmrc, .tool-versions, or engines, but the shell runs a different one. Compare installed runtime versions against the pinned versions before investigating code bugs.

Can I map module structure and data flow in a large codebase?▼

Yes, use the absorbed codebase-cartography reference for structural mapping: entry points, high-fan-in modules, end-to-end data-flow traces, cross-runtime boundaries, and high-risk files. It is read-only and never executes scripts or installs dependencies.

Is it safe to inspect env files during repo diagnostics?▼

Yes, when done correctly: list only environment variable names from .env.example or config files and mark them required versus optional. Never echo values, and flag any committed .env containing real values as a secret-exposure finding.

When should I not run a full repo diagnostic?▼

Skip it when the task is unrelated to core operations work, when it would require production deploys or destructive data actions, or when a narrower skill or existing project instruction already covers the need.