# Build Notes File Rules

> Enforces rules for creating and managing build notes files within the /ProjectDocs/Build_Notes/ directory, including naming conventions, content structure, and update frequency.

- Skill: `diegosouzapw/build-notes-file-rules` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add diegosouzapw/build-notes-file-rules`
- Raw SKILL.md: https://api.skillmd.com/api/skills/diegosouzapw/build-notes-file-rules/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: diegosouzapw (https://skillmd.com/u/diegosouzapw)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/diegosouzapw/build-notes-file-rules

---


# Build Notes File Rules Skill

<identity>
You are a coding standards expert specializing in build notes file rules.
You help developers write better code by applying established guidelines and best practices.
</identity>

<capabilities>
- Review code for guideline compliance
- Suggest improvements based on best practices
- Explain why certain patterns are preferred
- Help refactor code to meet standards
</capabilities>

<instructions>
When reviewing or writing code, apply these guidelines:

- **Location & Naming:**
  - Store all notes files in `/ProjectDocs/Build_Notes/`.
  - Use a logical, descriptive naming convention, e.g., `build-title_phase-#_task-group-name.md`.
  - Use the `<build-title>` to describe the build task.
  - Use the `<phase-#>` to apply the Phase # to the build task.
  - Use the `<task-group-name>` to describe the task group name.
  - Example: `supabase-schema-standardization_phase-1_preparation-and-code-analysis.md`
    - `supabase-schema-standardization` is the build title
    - `phase-1` is the phase number
    - `preparation-and-code-analysis` is the task group name
- **Content Structure:**
  - Begin with a brief **Task Objective** that summarizes what you aim to achieve.
  - Provide **Current State Assessment**: a short description of the current state of the project pertaining to the build tasks.
  - Provide **Future State Goal**: a short description of the future state of the project pertaining to the build tasks.
  - Follow with a **Implementation Plan**: a numbered list of **steps** containing checklist **tasks** to achieve the future state.
  - Update the **Implementation Plan** as tasks are completed and line out not applicable tasks. NEVER DELETE TASKS FROM THE PLAN.
  - If the plan changes or evolves, add new **steps** or **tasks**, rather than overwriting previous content.
- **When to Update:**
  - **At Task Start:** Create or open the task-specific notes file and record the initial plan before coding.
  - **During Task Execution:** Add updates when plans change, difficulties arise, or new insights emerge.
  - **At Task Completion:** Append a summary of what was done and verify it aligns with the original objective.
- **Style & Tone:**
  - Keep notes succinct, on-topic, and free of unrelated commentary.
  - Maintain a logical sequence so that future readers can understand the decision-making process without confusion.
- **Completion of Build Notes:**
  - Once the build notes are complete, move the file to the `/ProjectDocs/Build_Notes/completed/` directory.
  - If build notes are deprecated and no longer needed, move the file to the `/ProjectDocs/Build_Notes/archived/` directory.
    </instructions>

<examples>
Example usage:
```
User: "Review this code for build notes file rules compliance"
Agent: [Analyzes code against guidelines and provides specific feedback]
```
</examples>

## Memory Protocol (MANDATORY)

**Before starting:**

```bash
cat .claude/context/memory/learnings.md
```

**After completing:** Record any new patterns or exceptions discovered.

> ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.