Update Docs

Update only documentation relevant to the requested or completed work. Do not change application code, configuration, dependencies, infrastructure, generated files, or remote services.

Documentation Process

Before editing:

1. Read the existing target documents and any repository files needed to verify their claims.
2. Identify which documents are materially affected. Do not update every document by default.
3. Preserve useful content, established organization, links, identifiers, and historical context unless they are demonstrably stale.
4. Distinguish verified repository state from assumptions. Do not invent features, commands, support guarantees, architecture, or completion status.
5. Use concise language appropriate to each document's audience.

When editing:

• Merge overlapping material instead of adding duplicate sections.
• Keep commands and paths consistent with current project configuration.
• Do not include secrets, private personal data, transient command output, local-only paths, or unsupported claims.
• Do not describe planned work as implemented.
• Do not remove historical TODO entries merely because they are complete or stale.
• If evidence is insufficient, preserve the existing claim or label the uncertainty rather than guessing.

README.md

README.md is public-facing documentation for collaborators and end users. Describe what the project is, what it does, its current status, prerequisites, setup, usage, and other public technical information that is verified and useful.

Do not put user-specific instructions, private operational notes, secrets, local machine details, or internal task management in README.md.

AGENTS.md

AGENTS.md provides durable project guidance for coding agents. Record verified information such as:

• Tech stack and important versions
• Architecture and the reasons for material decisions
• Repository layout and ownership boundaries
• Setup, development, testing, linting, type-checking, and build commands
• Security, data, dependency, and migration constraints
• Project-specific conventions that are not already obvious from code

Do not repeat generic agent behavior or volatile session details.

TODO.md

TODO.md is the active project task and findings record. This skill is the canonical source for its structure. Other skills should delegate creation and formatting here rather than defining their own templates.

Before updating TODO.md:

• Read the entire existing file.
• Preserve user-entered items and useful historical entries.
• Add only confirmed work, findings, or explicitly labeled verification tasks.
• Merge duplicates and update an existing item when it represents the same underlying issue.
• Inspect existing identifiers and continue the sequence for the relevant severity.
• Move an item to Completed only after its resolution is verified.
• Mark invalid or superseded entries as [STALE] with a reason instead of deleting them.
• Do not modify the file when no task, finding, status, or resolution materially changed.

When another skill delegates findings here, make TODO.md the detailed authoritative record. Preserve concrete evidence and impact in Issue, and put the actionable recommendation and verification criteria in Fix. Do not shorten entries to match a concise chat summary.

Use this canonical structure:

### User list

Issues listed specifically by the user. Move an item to the appropriate severity section once it is sufficiently understood, or leave it here.

- Description of problem or addition, applicable file(s) if known.

---

### 🔴 Critical — Fix Immediately

Security vulnerabilities, data-loss risks, or issues that will cause production failure.

**[CRIT-1] [Short title]**
- **File**: `path/to/file.ts` (line N if known) or platform such as `Supabase`
- **Issue**: What is wrong, the supporting evidence, and why it matters.
- **Fix**: Concrete recommendation and verification criteria.

---

### 🟠 High — Fix Soon

Issues that meaningfully degrade reliability, security, performance, or maintainability.

**[HIGH-1] [Short title]**
- **File**: `path/to/file.ts` (line N if known) or platform such as `Supabase`
- **Issue**: What is wrong, the supporting evidence, and why it matters.
- **Fix**: Concrete recommendation and verification criteria.

---

### 🟡 Medium — Address in Next Refactor

Code quality, architecture, consistency, or resilience issues that create meaningful maintenance cost without immediate incident risk.

**[MED-1] [Short title]**
- **File**: `path/to/file.ts` (line N if known) or platform such as `Supabase`
- **Issue**: What is wrong, the supporting evidence, and why it matters.
- **Fix**: Concrete recommendation and verification criteria.

---

### 🔵 Low — Nice to Have

Minor polish, naming, dead code, or small inconsistencies that can be safely deferred.

**[LOW-1] [Short title]**
- **File**: `path/to/file.ts` (line N if known) or platform such as `Supabase`
- **Issue**: What is wrong and why it matters.
- **Fix**: Concrete recommendation and verification criteria.

---

### 🟢 Completed — Verified Resolutions

Items completed and independently verified.

**[RESOLVED] [CRIT] [Short title]**
- **Location**: `path/to/file.ts` (line N if known) or platform such as `Supabase`
- **Issue**: What was wrong.
- **Resolution**: What changed and how the resolution was verified.

Omit empty issue templates when creating a real project file, but retain the canonical section headings so future entries have a stable destination.