repo-context

name	repo-context
description	Use when a request starts with scanning the Hussh repository, establishing repo context, mapping code/docs/skills, or deciding which owner skill should own the next step.

Hussh Repo Context Skill

Purpose and Trigger

• Primary scope: repo-context-intake
• Trigger on broad repository scans, cross-domain mapping, surface discovery, and choosing the correct owner skill before implementation work starts.
• Avoid overlap with frontend, backend, security-audit, and docs-governance.

Coverage and Ownership

• Role: owner
• Owner family: repo-context

Owned repo surfaces:

1. README.md
2. data

Non-owned surfaces:

1. frontend
2. mobile-native
3. backend
4. security-audit
5. docs-governance
6. repo-operations
7. analytics-observability-governance

Do Use

1. First-pass repository orientation before any narrower implementation workflow.
2. Mapping the full skill taxonomy and the meaningful repo surface coverage.
3. Routing recurring work into explicit workflow packs and impact bundles.
4. Finding code/docs/skill drift or orphaned areas in the repository map.
5. Running the data-model audit workflow when table-family drift, migration classification, or runtime DB ownership is the starting question.

Do Not Use

1. Narrow work that is already clearly inside a domain owner skill.
2. Docs-only governance once the correct docs home is already obvious.
3. Deep product, ops, or security implementation work.

Read First

1. .codex/skills/repo-context/references/index-contract.md
2. .codex/skills/repo-context/references/ownership-map.md
3. docs/project_context_map.md

Workflow

1. Run summary first to get owners, spokes, surface coverage, and uncovered surfaces.
2. Open exactly one deeper section next: docs, frontend, backend, skills, or commands.
3. Use list-workflows and route-task <workflow-id> when the request matches a recurring execution shape.
4. Use data-model-audit before data-model implementation when migration/table classification, retention posture, or legacy write drift is in scope.
5. Use impact <workflow-id> before implementation when blast radius, docs, or verification scope is unclear.
6. Keep the first pass compact by default; use --verbose only when a heavy section such as skills or backend needs deeper inspection.
7. Use --text when a human-readable low-token routing summary is enough.
8. Route the task into the recommended owner skill as soon as the domain is clear.
9. Use validate or audit when changing the taxonomy, coverage map, workflow packs, or skill-routing docs.
10. Treat low-severity context-size and modularity findings from audit as review-required signals only; do not split files or add folders unless a bounded owner, workflow, or navigation problem is proven.

Handoff Rules

1. Route broad frontend work to frontend, native work to mobile-native, backend work to backend, trust and audit work to security-audit, docs work to docs-governance, analytics observability work to analytics-observability-governance, and generic ops work to repo-operations.
2. Route licensing and notice-governance work to oss-license-governance.
3. Route bootstrap, devcontainer, doctor, and contributor-first-run work to contributor-onboarding.
4. Route optional-mirror sync and subtree-governance work to subtree-upstream-governance.
5. Route skill-system work to codex-skill-authoring.
6. Route board workflows to planning-board and public/community reply work to comms-community.

Required Checks

./bin/hushh codex scan summary
./bin/hushh codex list-workflows
./bin/hushh codex route-task repo-orientation
./bin/hushh codex impact repo-orientation
./bin/hushh codex data-model-audit
./bin/hushh codex audit
python3 .codex/skills/repo-context/scripts/repo_scan.py validate