sponsor-fit-auditor

name	sponsor-fit-auditor
description	Audit a hackathon project against a sponsor's prize criteria and tech stack, then score and harden the alignment to maximise the chance of winning. Domain-agnostic — works for any sponsor, any stack, any project. Catches the #1 score-killer learned the hard way: a sponsor tech integrated CORRECTLY but not on the LOAD-BEARING path (the engine runs the side-quest while your own code runs the boss fight). Use when: prepping a hackathon submission, deciding which sponsor track to enter, reviewing an integration before judging, or writing a devpost/submission blurb. Produces a 0-10 scorecard, a ranked list of cheap high-leverage fixes, and an honest-but-best-light submission paragraph.
license	MIT
metadata	{"version":"0.1.0","role":"capability","author":"Jacky Siu","domain":"meta / hackathon-strategy","tags":["hackathon","sponsor-prize","tech-stack-alignment","submission-review","judging-rubric","integration-audit"],"inputs":[{"name":"project","type":"path-or-description","desc":"Repo path or a description of what the project does and how it's built."},{"name":"sponsors","type":"list","desc":"One or more sponsors/prize-tracks being targeted, each ideally with its prize criteria text (paste the devpost/rules blurb) and its key tech (SDK, API, model)."}],"outputs":[{"name":"scorecard","type":"markdown","desc":"Per-sponsor 0-10 score across five dimensions, with the load-bearing test called out."},{"name":"fixes","type":"ranked-list","desc":"Cheapest-first changes that move the score most (effort vs. score delta)."},{"name":"blurb","type":"markdown","desc":"An honest, best-truthful-light submission paragraph per targeted sponsor."}]}

sponsor-fit-auditor

Aligns a hackathon project to its sponsors and tech stack so it scores as high as a truthful submission can. It does not fabricate alignment — it measures real alignment, then tells you the cheapest changes that make the alignment real.

The core lesson this skill encodes

A sponsor judge rewards the sponsor tech doing the load-bearing work — the thing the product actually decides or produces — not merely being present and correct.

The most common, most expensive failure is "integrated but not load-bearing": the sponsor's engine/SDK/model is wired in correctly and genuinely runs, but only on a supporting path. Your own code still does the marquee logic. To a judge this reads as "they used us for the side-quest and did the boss fight themselves." It caps the score even when the integration is technically flawless.

(Worked example, the one this skill was distilled from: a project integrated a sponsor's reasoning engine correctly — right SDK calls, real auth, working live path — but ran only supporting inference on it, while the product's actual verdict was computed in its own code that mirrored rules the engine never executed. Correct integration, wrong path. Scored ~6.5/10 on sponsor-fit when ~9 was one wiring step away.)

The five scoring dimensions (0-10 each)

Score each targeted sponsor on these. The Depth-on-load-bearing-path score is the one that usually decides prizes, so weight it accordingly.

1. Integration correctness — does the sponsor tech actually run? Right calls, auth, error handling, no fake/stubbed-out usage. (Necessary, not sufficient.)
2. Conceptual fit — is this the right tool for the job, or a tech bolted on to tick a box? Judges can smell a forced fit.
3. Depth on the load-bearing path ⭐ — does the sponsor tech derive/produce the thing the product is about? Or does your own code do that while the sponsor tech does support work? THE deciding dimension.
4. Showcase / explainability payoff — are you using the sponsor tech's differentiated feature (the thing that makes it better than rolling your own), and is it visible in the demo/report?
5. Honesty & robustness — graceful degradation, no fabricated results, claims match reality. Protects against a judge finding the gap themselves (which zeroes trust).

The load-bearing test (apply to each sponsor)

Ask, in order:

• What is the single output the product exists to produce? (the verdict, the answer, the generated artifact, the decision.)
• Trace that output backwards. Whose code computed it? If the answer is "ours, not the sponsor's," you have the integrated-but-not-load-bearing gap — flag it red.
• Is the sponsor tech on the critical path, or could you delete it and still ship the core output? If deletable → it's supporting, not load-bearing.
• Does the demo/report show the sponsor tech's native differentiated output (e.g. an engine's own explanation chain, a model's reasoning trace), or a value you reformatted yourself? Native = full marks; reformatted = points left on the table.

Process

1. Map the product's core output(s). One sentence each. This is the thing judges ultimately grade.
2. Inventory each sponsor's tech and prize criteria. Pull the rubric language if available — score against their words, not generic notions of "good."
3. Run the load-bearing test per sponsor → assign the five scores → overall.
4. Generate the fix list, sorted by score_delta / effort. Favor fixes that are wiring, not redesign — the highest-leverage hackathon fixes are usually "the logic already exists, just route it through the sponsor tech." Always include the honest minimum (do nothing, submit as-is, here's the realistic score) as the baseline.
5. Verify the cheapest top fix is actually cheap — confirm the redirected logic exists and the sponsor SDK supports the call before promising the delta. Don't over-promise a "1-line fix" that's really a rewrite.
6. Write the submission blurb — honest, best truthful light. Lead with the load-bearing claim if (and only if) it's true after fixes; never claim the sponsor tech does the verdict if your code still does.

Multi-sponsor strategy

When several sponsors/tracks are in play:

• Concentrate, don't sprinkle. Three shallow integrations lose to one load-bearing one. Recommend dropping a track if its tech can't reach the critical path cheaply.
• Find the natural load-bearer. Usually one sponsor's tech is the right tool for the core output (best conceptual fit). Make that one load-bearing; let the others be honest supporting roles and don't oversell them.
• Watch for "best use of X" vs "uses X" prizes. "Best use" prizes are won almost entirely on dimension 3+4; "uses X" prizes only need dimension 1. Tell the user which bar each prize sets so they don't over-invest in a low bar or under-invest in a high one.

Anti-patterns to flag (each costs real points)

• Mirror-not-execute — sponsor's language/rules written but your code re-implements and runs them instead (the reasoning-engine case above). The sponsor tech becomes documentation, not computation.
• Reformatted output — you compute the value, then ask the sponsor tech to "explain" a result it didn't derive. Use its native derivation.
• Box-tick bolt-on — tech with no conceptual fit, present only for the prize. Judges penalize this harder than not entering the track.
• Silent divergence — the sponsor path and your fallback can return different answers (e.g. an aggregation bug live that the local code gets right). If you flip to sponsor-primary, the verdict must match. Audit for this before switching.
• Over-honest erasure — deleting a genuinely-good local fallback to "be pure." Keep fallback; make the sponsor tech primary, log which engine ran, prove it ran live.

Output format

## <Sponsor> — sponsor-fit: X.X / 10
| Dimension | Score | Why |
| Integration correctness        | n/10 | ... |
| Conceptual fit                  | n/10 | ... |
| Depth on load-bearing path ⭐    | n/10 | ... |   <- the deciding one
| Showcase / explainability       | n/10 | ... |
| Honesty & robustness            | n/10 | ... |

Load-bearing verdict: <on critical path | supporting only — RED FLAG>

### Cheapest high-leverage fixes (score Δ / effort)
1. [Δ +2.5, ~wiring] ...
2. [Δ +1.0, ~small]  ...
   (baseline: submit as-is → realistic X.X)

### Submission blurb (honest, best light)
<one paragraph, leads with the load-bearing claim iff true>

Guardrails

• Never invent alignment. Score what's real; the value is an honest map plus the cheapest path to making alignment real.
• Score against the sponsor's actual rubric words when provided; say so when inferring.
• Distinguish "wiring" from "redesign" honestly — the user is on a clock.
• The honest-as-is baseline is always an option, never hidden.