anentrypoint codebase-text-report
Analyzes a codebase by ingesting it as plain-text chunks via gitoutput's default (non-image) mode, reading every chunk, and producing a report grounded in what was actually read. This is the regular, text-only counterpart to the codebase-vision-report skill, which instead renders the codebase as dense PNG pages via mdpix for token-efficient image-based reading — use that one if you want the image-packing pipeline instead.
Arguments
Invoke as /codebase-text-report <target> :: <prompt>, or Skill(skill="codebase-text-report", args="<target> :: <prompt>").
target— a local directory path or a remote Git URL (anythinggitoutputaccepts as itssourceargument).prompt— the question or report focus (e.g. "find security issues", "summarize the architecture", "does this codebase handle X correctly").
Split args on the first ::. If no :: is present, treat the whole string as target and use a default prompt: "Summarize this codebase's architecture and key components."
Optional trailing flags in args: --exclude-pattern <glob> / --include-pattern <glob> (repeatable, passed through to gitoutput to scope a large codebase). There is no image-profile equivalent in text mode.
Step 1 — Generate text chunks
Run gitoutput via npx with --json (no --images) so the result is machine-parseable, writing to a fresh output base name (use a timestamp or the target's basename plus a short random suffix to avoid colliding with a prior run of this skill in the same working directory):
npx github:AnEntrypoint/gitoutput "<target>" --json --output "./codebase-text-<slug>-<suffix>.txt" [--exclude-pattern <p> ...] [--include-pattern <p> ...]
Capture stdout and parse it as JSON: {outDir, chunkFiles, chunkCount}. A non-zero exit or a JSON body containing error means generation failed — report the error to the user directly, do not proceed to steps 2-3 on a failed generation.
chunkCount is never 0 for a real target: chunk 1 always holds at least the summary and mcp-thorns report text, even for an empty/trivial directory. If the digest is genuinely trivial (chunk 1 is short and later chunks are empty/near-empty, e.g. Files analyzed: 0), report accordingly rather than fabricating detail that isn't there.
Step 2 — Read every chunk
Read each path in chunkFiles, in order, as plain text — no vision step, no image rendering; these are ordinary .txt files.
For a large chunkCount (huge codebases can produce many 80,000-character chunks), read in batches: read a batch, write a running note of what it covered (file names visible, key structures noticed) before moving to the next batch, so the full codebase is covered without holding every chunk's full detail in context simultaneously. Text tokens are cheaper per byte than image tokens, so the practical batch size is typically larger than the image variant's, but the same discipline applies — never silently sample a subset and report as if it were the whole codebase.
There is no factsheet.txt in text mode (that artifact exists specifically to protect against vision misreads of rendered pages) — raw chunk text is read verbatim, so no exact-value cross-referencing step is needed here.
Step 3 — Write the report
Synthesize a report that directly addresses prompt, grounded in what was actually read across all chunks — never a generic description that could have been written without reading them. Structure:
- A one-paragraph direct answer to
prompt. - Supporting detail organized by the codebase's actual structure (as seen across the chunks), citing specific files/functions/patterns observed.
Write the report to a file (<outDir>/<slug>-report.md, next to the generated chunks) and also present it directly in the response. Leave the generated chunk files on disk for the user to re-inspect — do not delete them after the report is written.