orbit-general

Tier-2 Review: orbit-general

What we attempted: We pulled the orbit-general skill from the open-design cluster and ran it through our standard harness. The goal was to validate the four core claims in the auto-summary — trigger clarity, output specificity, scope precision, and self-containment — through an install attempt and a minimal manual smoke invocation. We also checked for reusable interface boundaries and any hidden dependencies.

What failed: Both harness steps were skipped, not failed, but the skips are functionally equivalent to a hard blocker. The SKILL.md contains no install command, no setup routine, and no documented entry point for a human or an agent to invoke the skill outside of Orbit’s internal scheduler. The file explicitly states: “This skill should not be triggered manually — it is invoked by Orbit's daily-digest scheduler against the user's live connector data.” As a result, the harness could not:

• Run install (no command exists; the skill assumes a pre-existing Orbit runtime with authenticated connectors).
• Run smoke-invocation (no minimal input is defined; the skill requires live connector payloads from GitHub, Linear, Notion, Slack, etc., none of which were available in the test environment).

We observed zero test executions, zero partial passes, and zero failures — only two skips. The skill is effectively a description of a runtime behavior, not a standalone skill artifact.

What we observed: The SKILL.md is well-written in terms of intent. It describes a clear trigger condition (two or more connectors connected), a specific output (a bento-grid dashboard at the top of “我的设计”), and a sensible scope boundary (each connector module chooses its own UI form). The self-containment dimension scores high because the description references no external files or dependencies beyond the hypothetical Orbit pipeline. However, that self-containment is illusory — the skill is entirely dependent on an undocumented, uninstallable parent system. There is no way to test the rendering logic, the adaptive layout behavior, or the connector-specific UI selection without fabricating an entire Orbit runtime.

Rating caveat: The composite score of 4.5/5.0 is theoretical and provisional. It reflects the quality of the description as a specification, not the quality of the skill as a runnable artifact. D1 (trigger clarity) and D2 (output specificity) are genuinely strong on paper. D3 (scope precision) is excellent — the skill knows exactly what it should and should not do. D4 (self-containment) is overstated because the skill cannot be executed in isolation. D5 (reusability) is the weakest, correctly scored at 3.5, because the skill is hardwired to Orbit’s scheduler and connector ecosystem. Until we can physically re-run the harness inside an Orbit-like environment with mocked connector data, these scores should not be treated as validated.

Verdict on value in principle: Yes, the skill still seems valuable as a design pattern for how a dashboard aggregator should be specified — clear trigger, adaptive output, modular connector handling. If Orbit’s scheduler actually exists and this skill is genuinely invoked by it, then the description is a good internal contract. But as a standalone skill in the open-design cluster, it fails the basic test of being installable and invocable. We recommend the creator either (a) provide a mock-data mode and a manual invocation path for testing, or (b) move this artifact out of the skill registry and into Orbit’s internal documentation. The idea is sound; the packaging is not.

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

Overall: broken. 0 tests passed, 0 partial, 0 failed, 2 skipped; key blocker: SKILL.md defines an internal scheduler-driven skill with no install or manual invocation path.

Test	Status	Notes
install	skipped	SKILL.md does not document an install command; it describes an internal Orbit pipeline skill, not a standalone installable package.
smoke-invocation	skipped	SKILL.md explicitly states the skill should not be triggered manually; it is invoked by Orbit's daily-digest scheduler with live connector data, so no minimal manual invocation is defined.