Evaluate a Batch of Contest Submissions

Problem/Feature Description

A leaderboard organizer is processing several pending SKILL.md submissions for the AI Engineer London 2026 Skills Contest. They have a backlog of entries that need evaluation and want to process two of them at once. One of the entries is notably sparse — it was submitted by a first-time contestant who wasn't sure how detailed a skill needed to be. The organizer wants to see what the evaluation system does with it.

Please evaluate both skills below and produce the full scorecard for each.

Output Specification

Write both evaluations to evaluations.md in your working directory. Include the complete scorecard for each skill.

Input Files

The following files are provided as inputs. Extract them before beginning.

=============== FILE: inputs/skill-a.md ===============

name: emoji-picker description: Picks relevant emojis for text.

Emoji Picker

You suggest emojis for text content.

Look at the text and suggest 3-5 relevant emojis. Return emojis with a one-sentence explanation for each.

=============== FILE: inputs/skill-b.md ===============

name: git-commit-helper description: Writes conventional commit messages for staged changes. Use when you say "write a commit message", "help me commit this", "format my git commit", "what should I call this commit", or "generate a commit message from this diff". Works with staged diffs and change descriptions.

Git Commit Helper

You write conventional commit messages following the Conventional Commits specification.

Scope

Write commit messages only. Do not stage files, run git commands, or explain git concepts.

Workflow

Phase 1 — Parse Changes

Read the diff or change description. Extract:

• Files modified (count and names)
• Nature of change (new feature, bug fix, refactor, docs, test, style, chore)
• Affected components or modules

Phase 2 — Select Commit Type

Map the change to a conventional commit type:

• feat: new feature for the user
• fix: bug fix for the user
• docs: documentation only
• style: formatting, no logic change
• refactor: code restructure, no behavior change
• test: adding or fixing tests
• chore: build process, tooling

Phase 3 — Draft Message

Follow the format: <type>(<scope>): <subject>

Rules:

• Subject line: imperative mood ("add" not "added"), lowercase, no period, max 72 chars
• Scope: optional, lowercase, noun describing the module (e.g. auth, api, cli)
• Body (optional): wrap at 72 chars, explain why not what
• Footer (optional): reference issues (Closes #123, Fixes #456)

Phase 4 — Output

Return:

1. The commit message (ready to paste)
2. A one-line explanation of the type/scope choice if non-obvious