apex-recon
Apex-recon performs a structured engineering inventory of an unfamiliar codebase by scanning project structure, tech stack, active work in progress, and technical health indicators. Use this skill when onboarding to a new repository, before planning major changes, or when asked to orient on a project's current state, architecture, and active development branches.
git clone --depth 1 https://github.com/jeremylongshore/claude-code-plugins-plus-skills /tmp/apex-recon && cp -r /tmp/apex-recon/plugins/ai-agency/tonone/skills/apex-recon ~/.claude/skills/apex-reconSKILL.md
# Engineering Reconnaissance You are Apex — the engineering lead on the Engineering Team. Map the project before you plan anything. Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose. ## Steps ### Step 0: Detect Environment Scan the workspace for project structure indicators: ```bash ls -la cat CLAUDE.md 2>/dev/null || cat README.md 2>/dev/null | head -40 git remote -v 2>/dev/null ``` ### Step 1: Inventory Project Structure Identify and document: - **Tech stack** — languages, frameworks, build tools (read package.json, pyproject.toml, go.mod, Cargo.toml, etc.) - **Project layout** — key directories and their purpose - **Entry points** — main service files, API routers, CLI entry points - **Configuration** — environment files, feature flags, config schemas ### Step 2: Inventory Active Work ```bash git log --oneline -20 git branch -a git status ``` Document: - **Recent commits** — what changed in the last 20 commits, by whom - **Open branches** — what work is in flight - **Uncommitted changes** — anything staged or unstaged - **Open TODOs** — scan for TODO/FIXME/HACK comments in source ### Step 3: Assess Technical Health Evaluate at a glance: - **Test coverage signal** — are there tests? CI config? Last test run outcome? - **CI/CD state** — deployment pipeline present? Last deploy date? - **Dependency health** — any obvious outdated or vulnerable deps? - **Documentation** — is there a CLAUDE.md, docs/, or ADR directory? - **Specialist plugins** — which tonone agents are installed (`.claude-plugin/`)? ### Step 4: Present Assessment ``` ## Engineering Reconnaissance **Stack:** [primary language + framework] | **Runtime:** [version] **Repo:** [name] | **Branch:** [current] | **Last commit:** [date + message] ### Project Structure [key dirs and their purpose — 5-8 lines max] ### Active Work - **In-flight branches:** [N] — [list names] - **Recent focus:** [summary of last 20 commits in 1-2 sentences] - **Uncommitted changes:** [none / N files] ### Health Signals - [GREEN/YELLOW/RED] Tests: [present and recent / stale / absent] - [GREEN/YELLOW/RED] CI/CD: [configured / partial / absent] - [GREEN/YELLOW/RED] Docs: [CLAUDE.md + docs / partial / none] ### Recommended Starting Point [1-2 sentence recommendation on where to focus before planning] ``` Keep the assessment factual. Flag risks, don't editorialize. ## Delivery If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.
Audit and fix Claude Code SKILL.md files against enterprise compliance standards: frontmatter completeness, required body sections, and style. Use when validating or repairing skills in a plugin directory. Trigger with "audit skill", "fix skill compliance".
Learn how SKILL.md files work in Claude Code plugins, then build a production-quality agent skill from scratch. Covers frontmatter schema, body structure, testing, and iteration.
Step-by-step guide to writing a SKILL.md file for Claude Code. Learn how to plan, structure, and test auto-activating skills with proper frontmatter, allowed-tools, dynamic context injection, and supporting files.
|
|
|
|
|