codebase-onboarding-c4
Skill2 starsChanged 13 days agoMITView on GitHub
Use when an engineer needs to understand product and business journeys, C4 architecture, runtime boundaries, major dependencies, or safe implementation entry points in a large unfamiliar codebase.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- design-taste-frontendSkill
- eraser-diagramsSkill
- copywritingSkill
- frontend-designSkill
- html-docs-standardSkill
- html-slidesSkill
- presentation-brandSkill
- problem-presentationSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 6 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Run these read-only checks first:
- Very specific: line 25
If CodeGraph or RTK is unavailable, report the missing prerequisite.
- Distinctive: line 31
Read these references before forming conclusions:
- Distinctive: line 41
Use Quick, Standard, or Deep depth as defined by the Product Journey and Technical C4 contracts.
- Very specific: line 47
Use compact RTK commands such as rtk ls, rtk grep -r "pattern" ., rtk read FILE, and rtk git log to establish repository boundaries.
- Distinctive: line 56
Before selecting the journey, check repository guidance and overview documents against current routes, service calls, package scripts, and …
- Very specific: line 65
Check existing target files and ask before replacing them.
- Distinctive: line 68
Keep artifacts free of credentials, private URLs, customer data, and unsupported business claims.
- Very specific: line 71
Before approved HTML delivery, run the installed HTML standard's ensure-brand-profile.mjs against the target root.
- Distinctive: line 87
Use these package assets as the canonical artifact shapes:
- Very specific: line 95
Follow references/workspace-and-state.md before any artifact write.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Codebase Onboarding C4
Map an unfamiliar system before changing it. Return evidence-backed findings in chat first; create or replace onboarding artifacts only after user approval.
For installation, invocation, examples, and troubleshooting, follow
references/real-project-usage.md.
Preconditions
Run these read-only checks first:
codegraph --version
rtk --version
git status --short
codegraph statusIf CodeGraph or RTK is unavailable, report the missing prerequisite. If the
project has no valid CodeGraph index, ask before running codegraph init. Never
install global tools, change agent configuration, or create an index implicitly.
Required contracts
Read these references before forming conclusions:
references/product-business-journey.mdreferences/technical-c4-navigation.mdreferences/evidence-and-output-contract.mdreferences/adaptive-coordinator.mdreferences/workspace-and-state.mdreferences/evaluation-contract.mdreferences/diagram-contract.md
Use Quick, Standard, or Deep depth as defined by the Product Journey and Technical C4 contracts. Follow the coordinator for stages, routing, external access, root ownership, quality gates, and targeted retries.
Investigation tools
Use compact RTK commands such as rtk ls, rtk grep -r "pattern" .,
rtk read FILE, and rtk git log to establish repository boundaries. Use
CodeGraph first for structural questions about entrypoints, routes, calls, data
paths, ownership, and impact. Read raw source when the graph is stale or lacks
the required detail; do not replace structural exploration with broad grep
loops.
Record evidence before conclusions. Preserve contradictory sources and use
inferred-from-source or needs-confirmation instead of inventing intent.
Before selecting the journey, check repository guidance and overview documents
against current routes, service calls, package scripts, and tests. Record stale
claims as contradictions; do not use them as the sole architecture evidence.
Show the primary journey and the system boundary as diagrams in chat before
the detailed explanation. Follow references/diagram-contract.md for the
required views and their evidence; diagram accuracy is a quality gate.
Artifact generation
Check existing target files and ask before replacing them. Use
html-docs-standard for light-only responsive HTML. Keep Mermaid as the
editable diagram source and render corresponding accessible inline SVG in HTML.
Keep artifacts free of credentials, private URLs, customer data, and unsupported
business claims.
Before approved HTML delivery, run the installed HTML standard's
ensure-brand-profile.mjs against the target root. Reuse a valid local profile
without prompting or network access. On first-use or invalid, ask only for
Brand name and Brand website, run bounded static extraction, try an available
read-only browser only when the result is insufficient, and write a fallback
candidate otherwise. Apply the temporary candidate with
apply-brand-profile.mjs before writing HTML so .onboarding/brand/DESIGN.md
and docs/onboarding/assets/docs-brand.css stay synchronized. Do not preview
or request approval for extracted colors.
Browser-assisted inspection reads computed homepage styles only and returns the same temporary candidate contract as static extraction. If browser capability is absent or still insufficient, pass the insufficient candidate to the writer; it creates the deterministic fallback and records that outcome. Brand auto-save occurs only inside the already-approved durable delivery phase.
Use these package assets as the canonical artifact shapes:
assets/product-business-template.mdassets/technical-architecture-template.mdassets/state-template.yamlassets/evidence-template.yamlassets/run-summary-template.yaml
Follow references/workspace-and-state.md before any artifact write.
After writing, run
node scripts/verify-onboarding-workspace.mjs PROJECT_ROOT from the installed
skill directory. Run the brand verifier and the HTML Documentation Standard
verifier on each HTML artifact.
Completion report
Report the mode, primary Journey ID, Product Journey coverage, C4 levels,
Engineering Navigation, important evidence paths, quality-gate status,
contradictions, grey zones, and next concrete action. Assess implementation
readiness only for a named bounded task. Follow
references/evaluation-contract.md before claiming topology behavior is
verified.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

