ankhorage-project-structure

Defines and enforces the standard source structure for Ankhorage repositories.

3|Updated Apr 18, 2026
One-click install
npx skills add https://github.com/ankhorage/zora --skill ankhorage-project-structure-ankhorage
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ankhorage-project-structure
Source: https://github.com/ankhorage/zora/tree/main/.agents/skills/ankhorage-project-structure
Command: npx skills add https://github.com/ankhorage/zora --skill ankhorage-project-structure-ankhorage

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Ankhorage repositories need a consistent, enforceable source layout covering features, CLI commands, hexagonal boundaries, type ownership, constants, and utilities. Without a shared standard, modules drift into catch-all folders, types get misplaced, and cross-repository contracts get duplicated. ## Core Features & Use Cases - Required source layout: Defines the canonical src/cli/, src/features/, src/types/, src/constants/, and src/utils/ structure, including the rule that CLI command files mirror the public command path. - Ownership rules: Specifies where types, constants, and utility functions belong based on their consumers, including when shared serializable contracts must move to @ankhorage/contracts. - Contracts repository profile: Applies a dedicated, restricted profile for the ankhorage/contracts repository allowing only portable, serializable interfaces and types. - Use Case: When adding a new feature to an Ankhorage package, use this Skill to decide the correct folder layout, name modules with the one-export rule, and place shared types in the right owning location. ## Quick Start Use the ankhorage-project-structure skill to review this repository's source layout and tell me where my new feature module and its shared types should live.

Frequently Asked Questions about ankhorage-project-structure

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a new feature in an Ankhorage repository?▼

Create the feature under src/features/<feature>/ with its own hexagonal structure: domain, application (ports and use-cases), adapters (inbound and outbound), and composition. Use domain names for features, not technical categories, and do not create empty layers.

Where should shared TypeScript types live in a monorepo?▼

Types used by one module stay private below their owning function. Types reused within a repository go in src/types/<topic>.ts. Serializable types shared by at least two repositories belong in @ankhorage/contracts at the owning topic's public subpath.

How should CLI command files be organized?▼

CLI modules live in src/cli/ as thin inbound adapters. Files under src/cli/commands/ mirror the public command path after the package prefix, and each command file exports exactly one declaration matching its filename.

When does a utility function belong in @ankhorage/utility?▼

A function belongs in @ankhorage/utility when it is generic, reusable across repositories, and free of product or framework policy. You must first inspect the published Utility API and reuse an existing export when its semantics match instead of duplicating it locally.

What restrictions apply to the ankhorage/contracts repository?▼

The contracts repository may contain only portable, serializable interfaces and types with no functions, classes, enums, or runtime behavior. A contract belongs there only when at least two consuming repositories require it, and consumers import it through published public subpaths.