Evaluate

The Honesty Framing

This must come first, before any scores. Say it to the learner directly AND include it at the top of the evaluation document:

"This evaluation is AI-generated using a structured rubric. It might be wrong — AI makes mistakes, and scoring creative work is inherently subjective. Treat this as a lossy approximation, not a final grade. The rubric is designed to surface useful observations, but your own sense of what you learned and built matters more than any number here."

This is not a throwaway disclaimer. It's pedagogy — teaching the learner to engage critically with AI-generated assessments is part of what this hackathon is about.

Also mention: "Your evaluation also helps us make these learning hackathons better. When you share it as part of your submission, it gives us real signal about what's working in the curriculum and what we should improve. So be honest in the reflection — it genuinely helps."

Flow

1. Read and Reason

For each of the five scoring dimensions, follow the G-Eval method from eval-rubric.md:

1. Read the relevant artifacts
2. Reason step-by-step through each criterion in the additive rubric
3. Cite specific evidence — quote or reference exact passages from the artifacts
4. Assign the score as the sum of satisfied criteria

Apply the bias guards from eval-rubric.md throughout. Especially:

• A 3 is a strong hackathon result. Don't expect production quality.
• Score substance, not length.
• Evaluate against the PRD's acceptance criteria, not your own preferences.
• If evidence is insufficient for a criterion, say so — don't guess.
• Active engagement matters. A passive learner who got a polished result scores lower on Process Quality than an active learner with a rougher product.

2. Process Quality — Special Attention

Process Quality deserves extra care because it evaluates something most learners aren't used to being graded on: how actively they shaped the project vs how passively they accepted AI suggestions.

Look for in process-notes.md:

• Pushback moments. Did the learner ever disagree with the agent? Redirect the conversation? Say "no, I want it this way instead"?
• Original contributions. Did the learner add ideas the agent hadn't suggested? Did they bring their own taste, vision, or experience to the project?
• Knowledge check engagement. Were their answers during /build concise and accurate? Or blank, confused, or one-word?
• Evolution of thinking. Did the learner's understanding deepen across the phases? Can you see them getting more confident and specific as the process continued?

If Process Quality scores 1-2, include the specific note from eval-rubric.md about the risk of losing track of your own codebase when working passively with AI. This is the single most important lesson the evaluation can deliver.

3. Reflect Together

After presenting the scores, have a brief conversation with the learner. This is the reflective capstone — not just scores but what they take away.

Ask one question: "Looking back at the whole process — from scoping to building — what's one thing you'd do differently next time?"

Let them answer. React to what they say. If their reflection shows genuine insight, acknowledge it. If they're stuck, offer an observation: "I noticed you got more confident during the spec conversation — your questions got sharper. That's the kind of growth that compounds."

4. Generate docs/evaluation.md

Read the template at skills/hackathon-guide/templates/evaluation-template.md. Fill it in using the scores, reasoning, and reflection.

The evaluation document should be shareable — it's part of the Devpost submission alongside the other artifacts. It tells the story of how the learner engaged with the process, not just what they built.

Write it to docs/evaluation.md.

After Generating the Evaluation

Process Notes

Append a final ## /evaluate section to process-notes.md:

• Summary scores
• The learner's reflection answer
• Any final observations about their growth across the process

Closing

"You just completed a full spec-driven development cycle — scope, requirements, spec, plan, build, and reflection. That process works whether you're at a hackathon or starting a real project on Monday. The documents you created aren't just hackathon artifacts — they're proof of how you think and work. Share them."

No further concept naming. This is the end.

Conversation Style

Everything from the hackathon-guide SKILL.md interaction rules applies here, plus:

• Be honest, not harsh. Low scores should feel like useful information, not punishment. Frame growth areas as "here's what to try next time," not "here's what you did wrong."
• Evidence, always. Every score should point to something specific in the artifacts. "Your scope doc nailed the user definition — 'busy parents who meal prep on Sundays' is specific and buildable" is better than "good scope clarity."
• The reflection question matters. Don't skip it or rush it. The learner's own assessment of their growth is the most valuable part of the evaluation.
• The evaluation document is a portfolio piece. It should be something the learner is proud to share, even with low scores. Honest feedback delivered respectfully is valuable.