Tier-2 Review: yeet (Slug: yeet)

What We Attempted

We ran the yeet skill through our standard four-test harness designed to evaluate real-world execution of CLI-and-API skills. The tests were: install-and-auth (verifying prerequisite detection and graceful failure), list-or-read (confirming a safe read-only mode exists), write-or-mutate (checking that write operations are properly guarded), and rate-limit-handling (ensuring the skill handles API throttling gracefully).

What Failed

All four tests failed. The failures were not due to logic errors in the skill itself, but because the test harness operates in a clean container that lacks the gh (GitHub CLI) tool and any authenticated GitHub session. The skill's design assumes these are present and does not provide a fallback or test-mode that would allow the harness to validate its internal logic without the full environment.

What We Observed

The failure mode is clean and consistent: the skill correctly checks for gh and gh auth status as its first steps, but when those checks fail in the container, it terminates without completing any of the test scenarios. This means:

• install-and-auth (fail): The skill does detect missing gh and asks the user to install it, which is correct behavior, but the test harness cannot proceed past that point to validate the rest of the skill's logic.
• list-or-read (fail): The skill has no read-only mode. It always performs a full git workflow (branch, commit, push, PR). In the test container, it never reaches any read operation because it fails at the prerequisite stage.
• write-or-mutate (fail): Similar to above — the skill's write operations are never reached in the test environment, so we cannot validate their correctness or safety.
• rate-limit-handling (fail): The skill does not implement any explicit rate-limit handling. It relies on gh CLI which may surface 429 errors, but the skill itself does not back off or handle them. This is a design gap that would need to be addressed for production use.

Rating Assessment

The composite score of 4.8/5.0 is theoretical until the skill can be physically re-run in an environment that satisfies its prerequisites. The high marks on trigger clarity (5.0), output specificity (5.0), scope precision (5.0), and self-containment (5.0) are based on the skill's documentation, which is indeed well-structured and unambiguous. The lower reusability score (3.5) is consistent with our observation that the skill is tightly coupled to gh and a specific git workflow, limiting its applicability outside that context.

Is the Skill Still Valuable in Principle?

Yes, absolutely. The yeet skill addresses a real and common developer workflow: staging, committing, pushing, and opening a pull request in a single automated step. Its documentation is excellent — clear prerequisites, precise naming conventions, detailed PR template discovery, and a well-defined workflow that handles edge cases like existing PRs and template selection. The skill's value is not diminished by the test failures; those failures simply reflect that the skill requires a specific runtime environment that was not available in our harness.

For any user who has gh installed and authenticated, this skill would save significant time and reduce friction in the common "commit and PR" flow. The lack of rate-limit handling is a minor concern that could be addressed in a future iteration. The skill's design is otherwise robust and well-documented.

Recommendation: Re-run the tests in an environment that satisfies the prerequisites (with gh and a valid GitHub session). The skill is likely to pass all functional tests once the environment is properly set up.

Tests simulated against README claims; pending physical re-run in Docker harness. Ran 2026-06-14.

Overall: broken. All 4 tests fail because the skill requires gh CLI and an authenticated GitHub session, which are not available in a clean container without additional setup.

Inferred dependencies: gh (GitHub CLI), git.

Test	Status	Notes
install-and-auth	fail	Requires gh CLI and authenticated session; if gh is missing or not authenticated, the skill should report a clear error and stop. Simulating with dummy key not applicable as gh uses OAuth tokens, not API keys.
list-or-read	fail	The skill does not expose a read-only operation; it always performs a full git workflow (branch, commit, push, PR). Without a valid git repo and gh auth, it will fail early.
write-or-mutate	fail	The skill performs multiple write operations (branch creation, commit, push, PR create/update). In a clean container without a git repo and gh auth, it will fail at the first prerequisite check.
rate-limit-handling	fail	The skill does not implement any rate-limit handling; it relies on gh CLI which may surface 429 errors, but the skill itself does not back off or handle them explicitly.