audit-type-ownership
Tooling for auditing type ownership and boundaries in the compartment repository.
Install
mkdir -p .claude/skills/audit-type-ownership && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12507" && unzip -o skill.zip -d .claude/skills/audit-type-ownership && rm skill.zipInstalls to .claude/skills/audit-type-ownership
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Audit type ownership and boundary placement in the compartment repo: misplaced or duplicated types, query/service leaks, root export surface, and phased move plans.Key capabilities
- →Inventory type declarations by package and file
- →Highlight duplicate type names
- →Identify suspicious cross-package imports
- →Detect query/service boundary leaks
- →Classify findings against layer architecture
How it works
This skill runs a script to inventory type declarations and classify them against established layer architecture, identifying ownership issues and boundary violations.
Inputs & outputs
When to use audit-type-ownership
- →Audit type boundaries
- →Check type ownership
- →Plan refactor
About this skill
Audit Type Ownership
Use this skill for non-mutating type ownership audits in the compartment repo.
Source of truth
AGENTS.mddocs/layers/README.mddocs/specs/type-placement.md- the relevant layer docs, starting with
docs/layers/api.mdwhen the user does not narrow the audit
Workflow
- Run
node .codex/skills/audit-type-ownership/scripts/audit_type_ownership.mjsfrom the repo root. - Narrow with
--package <api|contracts|sdk|cli|edge|worker|docker|kube-runtime|utils|test-support>when the request is scoped. Use--format jsononly when a structured artifact is more useful than Markdown. - Read the script output before making claims. It is a heuristic inventory, not proof.
- Treat declared workspace dependencies as package context, not automatic findings. A non-
contractsimport matters only when it is undeclared in the owning package or it conflicts with the relevant layer doc. - Treat duplicate names as move candidates only when they imply a shared serialized or cross-package owner. Package-local families such as
*Input,*Context,*Plan,*Result,*Options,*State,*Config, and*Appcan legitimately exist in multiple packages. - Classify findings with this matrix:
contracts: serialized DTOs, public*Request,*Response,*Summary, shared status/value aliases- query layer:
*Row,*Selection,*Transaction,*Executor, persistence mutation inputs - service layer:
*Input,*Context,*Plan,*Result - app/adapter layer:
*Options,*State,*Config,*App
- Treat cross-process or cross-package payloads as contract-owned, even when the current consumer is internal.
- Treat query/service boundary leakage and placement violations from
docs/specs/type-placement.mdas ownership bugs, including genericsrc/types/,routes/shared/, and route DTO mappers outside*.presenter.ts. - If the audit turns into implementation, run the narrowest relevant package checks first and then add any required special checks for the diff.
Default scope
- Start with
api. - Then sweep
contracts,sdk,cli,edge,worker,docker,kube-runtime,utils, andtest-support. - Keep the audit non-mutating unless the user explicitly asks for implementation after the audit.
Output
PolicyConcrete findingsMove listPhased refactor plan
Script
scripts/audit_type_ownership.mjsinventories namedinterfaceandtypedeclarations by package and file.- It highlights duplicate type names, suspicious
@compartment/*imports, query/service leaks, root export risks, package dependency context, and placement violations. - Final ownership decisions still come from
AGENTS.md, the architecture docs, and the relevant checks.
When not to use it
- →When performing mutating type ownership changes
- →When the request is not scoped to a specific package
Limitations
- →Performs non-mutating audits only
- →Script output is a heuristic inventory, not proof
- →Does not automatically fix issues, only reports them
How it compares
This workflow systematically audits type ownership using a heuristic script and classification matrix, unlike manual code inspection for type placement.
Compared to similar skills
audit-type-ownership side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| audit-type-ownership (this skill) | 0 | 2mo | Review | Advanced |
| deepwiki-rs | 25 | 9mo | Review | Intermediate |
| technology-stack | 3 | 3mo | No flags | Intermediate |
| vercel-reference-architecture | 3 | 27d | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
deepwiki-rs
sopaco
AI-powered Rust documentation generation engine for comprehensive codebase analysis, C4 architecture diagrams, and automated technical documentation. Use when Claude needs to analyze source code, understand software architecture, generate technical specs, or create professional documentation from any programming language.
technology-stack
ag-grid
Technology choices and architectural constraints for AG Grid. Use when choosing technologies, adding dependencies, or understanding zero-dependency requirements.
vercel-reference-architecture
jeremylongshore
Implement Vercel reference architecture with best-practice project layout. Use when designing new Vercel integrations, reviewing project structure, or establishing architecture standards for Vercel applications. Trigger with phrases like "vercel architecture", "vercel best practices", "vercel project structure", "how to organize vercel", "vercel layout".
obsidian-reference-architecture
jeremylongshore
Implement Obsidian reference architecture with best-practice project layout. Use when designing new plugins, reviewing project structure, or establishing architecture standards for Obsidian development. Trigger with phrases like "obsidian architecture", "obsidian project structure", "obsidian best practices", "organize obsidian plugin".
project-principles
vm0-ai
Core architectural and code quality principles that guide all development decisions in the vm0 project
tldr-code
parcadei
Token-efficient code analysis via 5-layer stack (AST, Call Graph, CFG, DFG, PDG). 95% token savings.