| name | new-file-placement |
| description | Verify that newly created files follow the repo's existing directory layout, naming conventions, and export patterns. Trigger when a new file is created. |
| owner | any |
| trigger | new_file_created |
| version | 2 |
New File Placement
Use this when creating a new file so it lands in the right part of the repo and matches existing structure.
For scaffold, shared-types, or contract-related work: create a single minimal path/export map first, and treat it as the only authoritative placement plan. If you cannot name exactly one location and one export for every required file, stop and resolve the ambiguity before creating anything.
For scaffold, shared-types, or contract-related work: before creating any files, read .swx/runtime-docs/spec.md and .swx/runtime-docs/architecture.md, inspect neighboring files, and write one minimal path/export map with exactly one authoritative location and export name for every required file. If the map is ambiguous, stop and resolve it first. Do not create files or hand off until the map exists and the narrowest compile-focused check against those exact paths/imports has passed.
Before handoff, run and pass the repo's narrowest compile/type-check command for the affected paths; if it fails, fix placement/exports first and do not hand off.
Workflow
- Inspect neighboring files before creating the new one.
- Prefer the existing local pattern over generic conventions.
- Keep related files together:
tests near the feature or in the repo's established test location,
hooks with hooks,
shared types with shared types,
task-view private modules under the existing view subdirectory.
- Match existing naming style:
PascalCase, camelCase, kebab-case, or suffix conventions already used nearby.
- If the file needs exports, update the nearest existing barrel or module surface instead of inventing a new one.
- Avoid adding files at the repo root unless the repo already keeps that kind of file there.
- After creation, run the narrowest relevant check before creating the next new file.
Repo-Specific Heuristics
- In the dashboard, prefer existing
views/<feature>/state.ts and sections.tsx structure before adding a new one-off layout.
- In Rust crates, prefer existing module trees and
mod.rs/file naming conventions already used in the crate.
- If placement is ambiguous, choose the nearest existing pattern and note the assumption.
This skill is about placement and consistency, not about forcing immediate file creation with no analysis.
Hard stop: for scaffold, shared-types, or contract-related work, do not create any extra files or game logic until the minimal project skeleton plus one shared types module exists and a narrow compile-focused check passes. If that check fails, fix placement/exports first and do not hand off.
