Inspiration
I enter design and software calls solo, and I kept making the same mistake: reading an announcement twice, copying a deadline by hand, and hoping I had not misread the prize table. Summarisers make it worse — they are confident and uncheckable. I wanted the opposite: a brief where every value shows the characters it came from, or says it is not stated.
What it does
Paste the text of a competition page, a call for entries or a set of rules. A reader — a deterministic offline one, or an optional language model — proposes the key dates, prize structure, submission channel, deliverables and eligibility, quoting the page for every value. Then deterministic Python decides what is true: every quote must exist in the pasted text, every number must appear on the page (an invented number is rejected in public, with the reason), dates are re-parsed and re-rendered as ISO 8601 with a zone, and prize amounts are read from the quoted sentence instead of being computed. Anything the page does not state becomes the literal string "page does not state".
The result is a brief where each field carries its value, its verdict (accepted / corrected / rejected / not stated), the quote and the character offsets — with the raw machine proposal shown next to the validated one. Validated dates become an .ics calendar with reminders, the whole brief exports as a single self-contained HTML file that still shows its evidence with the app closed, and every analysis is kept in a local sqlite3 history.
How I built it
I ran the Devpost Learn Skill Pack in my coding agent and let it drive the build: scope, then PRD, then a technical spec with the exact validation rules, then a build checklist of eight slices — each slice verified and committed on its own, which is where the self-contained HTML brief and its download route came from. Python standard library only: no framework, no npm, no account, no API key needed. The interface is hand-written HTML/CSS with one small script, and the brief is rendered server-side, so a screenshot and a user see the same markup.
Challenges
The hard part is not reading a page, it is refusing to trust what you read. Dates were the worst case: 10月26日 5:00pm ET carries no year on the page, so the year has to be inferred and then labelled as corrected, and US daylight-saving boundaries have to be right or the reminder fires an hour off. Rejecting a fabricated prize amount without also rejecting a legitimate one took several passes, and the rule "a number that is not on the page is rejected" had to be written into the spec before it could be tested.
What I learned
Two things I will reuse. First, planning before building paid off: writing the validation rules into a spec first gave the tests something exact to check. Second, making a failure visible is a feature — the audit view that lists what was thrown away is the most convincing part of the app.
What's next
A watchlist of the calls I am following, and Markdown/JSON export next to the HTML brief.
Log in or sign up for Devpost to join the conversation.