repo-intake
Repo Intake
When to Use
- First time onboarding a project
- Rebuilding cache after major project structural changes
- Cache expired, needs updating
When NOT to Use
- Already familiar with project structure (read cache directly)
- Only need to find specific files (use Glob/Grep)
- Day-to-day development (cache already exists)
Workflow
Docs -> Entrypoints -> Tests Map -> Next Steps
Usage
bash scripts/run-skill.sh repo-intake intake_cached.js --mode auto --top 10
Cache Location
Cache stored at: ~/.claude/cache/repo-intake/<repoKey>/
| File | Description |
|---|---|
latest.md |
Latest scan results |
latest.json |
Latest scan results (JSON) |
LATEST.json |
Cache metadata |
Output
## Overview
<summary>
## Entrypoints
- {CONFIG_FILE}
- {BOOTSTRAP_FILE}
## Test Map
| Type | Pattern |
| ----------- | ----------------- |
| Unit | test/unit/ |
| Integration | test/integration/ |
| E2E | test/e2e/ |
## Next Steps
- <questions>
Verification
- Output includes Overview, Entrypoints, Test Map, Next Steps
- Entrypoints correctly identify
{CONFIG_FILE},{BOOTSTRAP_FILE} - Test Map covers Unit/Integration/E2E layers
References
references/archived/MIDWAY_HEURISTICS.md— Legacy MidwayJS heuristics (archived, for reference only)
Scripts
| Script | Purpose |
|---|---|
scripts/intake_cached.js |
Main intake with caching |
scripts/scan_repo.js |
Full repo scanner (framework-agnostic) |
scripts/scan_delta.js |
Delta scan for changed files |
Examples
Input: /repo-intake
Action: Execute intake script -> Output project map
Input: /repo-intake save
Action: Execute intake script -> Output and write to docs/ai/intake/
More from sd0xdev/sd0x-dev-flow
statusline-config
Customize Claude Code statusline. Use when: user says 'statusline', 'status line', 'customize statusline', 'modify statusline', 'statusline settings', 'statusline theme', 'change theme', 'color scheme', wants to add/remove/change segments (cost, git, model, context), switch color themes (catppuccin, dracula, nord), or asks what can be shown in the statusline.
52tech-spec
Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.
45codex-brainstorm
Adversarial brainstorming via Claude+Codex debate. Use when: exploring solutions, feasibility analysis, exhaustive enumeration. Not for: implementation (use feature-dev), architecture only (use codex-architect). Output: Nash equilibrium consensus + action items.
7test-review
Test coverage review via Codex MCP. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
7post-dev-test
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
6project-audit
Project health audit with deterministic scoring. Use when: evaluating project quality, onboarding to new codebase, periodic health checks. Not for: runtime performance analysis, security-specific audits (use /codex-security). Output: 5-dimension score + actionable findings.
6