AU

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.zip

Installs 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.
164 charsno explicit “when” trigger
Advanced

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

You give it
A request to audit type ownership in the compartment repo, optionally scoped to a package
You get back
An audit report with policy, concrete findings, a move list, and a phased refactor plan

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.md
  • docs/layers/README.md
  • docs/specs/type-placement.md
  • the relevant layer docs, starting with docs/layers/api.md when the user does not narrow the audit

Workflow

  1. Run node .codex/skills/audit-type-ownership/scripts/audit_type_ownership.mjs from the repo root.
  2. Narrow with --package <api|contracts|sdk|cli|edge|worker|docker|kube-runtime|utils|test-support> when the request is scoped. Use --format json only when a structured artifact is more useful than Markdown.
  3. Read the script output before making claims. It is a heuristic inventory, not proof.
  4. Treat declared workspace dependencies as package context, not automatic findings. A non-contracts import matters only when it is undeclared in the owning package or it conflicts with the relevant layer doc.
  5. 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 *App can legitimately exist in multiple packages.
  6. 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
  1. Treat cross-process or cross-package payloads as contract-owned, even when the current consumer is internal.
  2. Treat query/service boundary leakage and placement violations from docs/specs/type-placement.md as ownership bugs, including generic src/types/, routes/shared/, and route DTO mappers outside *.presenter.ts.
  3. 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, and test-support.
  • Keep the audit non-mutating unless the user explicitly asks for implementation after the audit.

Output

  • Policy
  • Concrete findings
  • Move list
  • Phased refactor plan

Script

  • scripts/audit_type_ownership.mjs inventories named interface and type declarations 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.

SkillInstallsUpdatedSafetyDifficulty
audit-type-ownership (this skill)02moReviewAdvanced
deepwiki-rs259moReviewIntermediate
technology-stack33moNo flagsIntermediate
vercel-reference-architecture327dReviewIntermediate

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.

25170

technology-stack

ag-grid

Technology choices and architectural constraints for AG Grid. Use when choosing technologies, adding dependencies, or understanding zero-dependency requirements.

321

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".

31

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".

11

project-principles

vm0-ai

Core architectural and code quality principles that guide all development decisions in the vm0 project

11

tldr-code

parcadei

Token-efficient code analysis via 5-layer stack (AST, Call Graph, CFG, DFG, PDG). 95% token savings.

10

Search skills

Search the agent skills registry