Rule To Rubric

Rule to Rubric

Turn the actual event requirements into a usable project scorecard. Use supplied rules as provided, recording whether they are official excerpts, provisional notes, or hypothetical test material. Ask for an event URL only when verification is needed for the current decision and it is unavailable; useful independent work can continue meanwhile.

Workflow

1. Read the official rules, challenge/track pages, submission form requirements and linked organizer clarifications. Record retrieval date and direct URLs.
2. Extract hard requirements separately: eligibility, team size, region/age restrictions, build window, deadline/timezone, prior work, AI use/disclosure, required tools, licenses, submission artifacts and access requirements.
3. Label each gate pass, fail or unknown, with supporting evidence. A missing fact is unknown, never an assumed pass. Identify conflicts and quote only the short text needed to explain them.
4. Extract judging criteria and stated weights. Preserve official wording sufficiently to avoid changing meaning. Do not import generic MLH, Devpost or startup criteria into an unrelated event.
5. For each criterion, propose an observable demonstration or artifact and the smallest useful implementation that supports it. Distinguish the organizer's requirement from your recommendation.
6. Produce a submission checklist with owner, artifact, verification method and deadline. Include a dated source beside event-specific requirements.

Outputs

Create or update the project's existing brief, or write artifacts/event-brief.md if none exists. Include:

• Event identity and dates in the organizer's timezone plus the user's timezone when known.
• A hard-gate table: requirement, source, status, evidence, unresolved question.
• A rubric table: criterion, stated weight, proposed proof, current gap.
• A checklist of required links, files, disclosures and access checks.
• The few uncertainties that can change eligibility or the project decision.

Scoring and limits

• Never let a high weighted score cancel a failed eligibility gate.
• If no weights are published, leave them unspecified. Optional planning weights must be labeled assumptions.
• If published weights do not sum as expected, surface the discrepancy rather than silently normalizing it.
• Do not invent organizer answers, private judging preferences or exceptions.
• Do not present a checklist as legal advice or acceptance by the organizer.
• Do not register, submit, message organizers or alter a public project unless the user has authorized that action.
• Recheck volatile requirements before final submission; retain the original source and the change if rules differ.

Done when every known requirement has a source and verification path, while unknowns remain visible and separate from score estimates.