메뉴
Engineering lead reconnaissance — inventory the project before planning. Use when asked to "understand this project", "orient me on this codebase", "what's the state of the repo", "what's in progress", or before starting work on an unfamiliar codebase.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Plan and scope a project — discovery, challenge assumptions, present S/M/L options with token and cost estimates. Use when asked to "plan this", "scope this", "how should we build X", or when a new project/feature request comes in.
Cross-cutting review of recent work — catches gaps between specialists. Use when asked to "review what we built", "check the work", "pre-launch review", or after completing a significant chunk of work.
CTO-level project status from git and codebase state. Use when asked "where are we", "project status", "what's done", or at the start of a work session.
System takeover — take ownership of an existing codebase or inherited system. Use when "we acquired this", "previous team left", "take over this system", "inherited this codebase".
Write an Architecture Decision Record — document what was decided, why, what alternatives were considered, and what trade-offs were accepted. Use when asked to "write an ADR", "document this decision", or "why did we choose X".
Maintain per-repo and cross-repo changelogs — append structured entries after agent work. Use when asked to "log this change", "update changelog", "what changed", "change history".
| name | apex-recon |
| description | Engineering lead reconnaissance — inventory the project before planning. Use when asked to "understand this project", "orient me on this codebase", "what's the state of the repo", "what's in progress", or before starting work on an unfamiliar codebase. |
| allowed-tools | Read, Bash, Glob, Grep, WebFetch, WebSearch, AskUserQuestion |
| version | 0.6.4 |
| author | tonone-ai <hello@tonone.ai> |
| license | MIT |
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.
Scan the workspace for project structure indicators:
ls -la
cat CLAUDE.md 2>/dev/null || cat README.md 2>/dev/null | head -40
git remote -v 2>/dev/null
Identify and document:
git log --oneline -20
git branch -a
git status
Document:
Evaluate at a glance:
.claude-plugin/)?## 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.
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.