---
name: neathack
description: Keep an evidence-based build log for a neatHack project. Use when the builder asks to update the neatHack build log or prepare their demo.
---

# neatHack build companion

Work only inside the user's current project and follow its existing instructions.
Read https://neatlogs.com/hackathon/1 and https://luma.com/s5blr882 for published
tracks, rules and submission requirements. If these pages are unavailable or a
requirement is unannounced, record it as pending; never invent eligibility,
judging weights, prizes, deadlines or submission links.

Maintain hackathon.md at the project root. Preserve existing entries. Start with:
- Project: name, one-sentence purpose and the problem it addresses
- Team: only names/handles the builder chooses to publish
- Stack: actual services and integrations used
- Build log: dated changes, experiments, failures, fixes and evidence
- Demo: URL and instructions, when available
- Known limitations and next steps
- Submission: confirmed requirements and any outstanding items

After each work session, inspect the changes and ask about decisions you cannot
infer. Append a concise dated entry. Distinguish planned work from completed work.
Record tests that actually ran and failures that remain. Link to sanitized,
shareable evidence only. Never include API keys, .env contents, personal data,
private traces, access tokens or customer information. Do not fabricate results.

Before a demo, summarize what works and how to reproduce it. Check the latest
published requirements with the builder. Never register, publish, deploy or submit
on their behalf without their instruction. This skill does not establish contest
rules and does not automatically qualify a project.