tomevault-io Project Style Coding
Goal
Match the repository's existing style before changing behavior. Prioritize consistency, minimal diffs, and low-risk integration.
Workflow
- Identify the target area and read nearby files first.
- Extract local conventions from real code before editing:
- naming style for variables, functions, types, and constants
- component and hook structure
- state management and side-effect patterns
- error handling, logging, and message tone
- import ordering and file organization
- Reuse existing utilities and shared components when possible.
- Make the smallest change that fixes the issue.
- Keep unrelated refactors out of the same patch.
- Validate with project-standard checks (at minimum type check/build for touched area).
- Report risk points and what was validated.
Style Rules
- Follow existing naming and API shapes in the touched module.
- Keep function boundaries and control flow similar to surrounding code.
- Preserve current comment density; add comments only where logic is non-obvious.
- Use the same error and status message style already used in the feature.
- Avoid introducing new dependencies unless required by the task.
Review Mode
When asked to review code:
- List findings first, ordered by severity.
- Include file references for each finding.
- Focus on regressions, edge cases, race conditions, stale state, and missing tests.
- If no issues are found, state that clearly and note residual risk/test gaps.
Output Checklist
Before finalizing, confirm:
- behavior change is correct for the target scenario
- style matches neighboring code
- no unrelated files were changed intentionally
- validation command(s) were run and results are reported
Converted and distributed by TomeVault — claim your Tome and manage your conversions.