Structure Codebase

Design the source tree as a truthful map of meaning, ownership, runtime boundaries, and change cohesion. Do not start from a universal template. Select the lightest structure that makes this project's real seams easy to see and proportionately difficult to violate.

Use this skill for physical placement, package shape, migration, and dependency enforcement. Domain modeling and port or adapter implementation are separate concerns. If the repository has dedicated guidance for DDD or hexagonal architecture, follow it alongside this skill; never infer that adopting one pattern requires the other.

Operating Guardrails

• Read the repository's instructions, architecture decisions, and framework conventions before proposing a new taxonomy.
• Preserve a coherent existing structure unless the user asked for redesign or evidence shows a concrete navigation, ownership, runtime, or dependency problem.
• Separate observations from proposals. Label inferred boundaries and unverified change-cohesion claims as hypotheses.
• For an audit or proposal, do not move files. For an implementation, preserve unrelated work and migrate in reviewable slices.
• Prefer project-native enforcement and verification over introducing new tooling solely to defend a diagram.

Read the relevant reference before producing a target tree: