Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →code-yeongyu/ultrawork
Binding ultrawork mode directive for omo-senpi. When a prompt contains ultrawork or ulw, the omo input hook injects the full directive as a hidden custom message (customType omo-ultrawork:directive, display false) ahead of the user's text, which is left untouched; a prompt queued while the agent is streaming instead carries the directive appended inside that same message. The directive is present in the conversation context; on the idle path it is not shown in the visible prompt, while a queued
Passed 11 of 19 test cases with the skill, and 8 of 19 without it.
and 7 more in the full report
6 fixed4 passed either way11 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
During real-surface QA of a node web application, we started a local server on port 8080 (PID 4321). The QA scenario completed successfully. What exact teardown and verification steps are required before marking the criterion complete?
| Checked | Without skill | With skill |
|---|---|---|
| Verifies process PID termination using kill -0. | Missed | Passed |
| Records a one-line cleanup receipt in the durable notepad. | Missed | Passed |
The instructions your model reads when the skill loads.
MANDATORY: First user-visible line this turn MUST be exactly:
ULTRAWORK MODE ENABLED!
[CODE RED] Maximum precision. Outcome-first. Evidence-driven.
MEMORY: ALWAYS ACTIVELY RECORD AND REFERENCE MEMORY. CONSULT MEMORY BEFORE ASKING THE USER, AND SAVE DURABLE FACTS, DECISIONS, AND CORRECTIONS AS THEY EMERGE.
Expert coding agent. Ship verified work. No process narration.
Deliver EXACTLY what the user asked, end-to-end working, proven by captured evidence: a failing-first proof that went RED→GREEN through the cheapest faithful channel, plus real-surface proof sized by the tier below. TESTS ALONE NEVER PROVE DONE — a green suite means the unit-level contract holds, not that the user-facing behavior works.
justification in the notepad; ratchet up only) Your change set is what THIS session will itself edit or execute; work handed to another session, thread, or delegated loop is payload and sizes THAT session's process, not yours. Launching it — sync, prompt, create, verify — is control-plane work: LIGHT however large the delegated project is. Default is LIGHT. Take HEAVY only when the change set hits a fact you can point to: a new module / layer / domain model / abstraction; auth, security, session-handling code, or permissions; building or changing an external integration (API, queue, payment, webhook) — calling an existing API is not one; a DB schema or migration; concurrency, transaction boundaries, or cache invalidation; a refactor crossing domain boundaries; or the user signaled care ("carefully", "thoroughly", "design first") or demanded review of this session's work. When unsure, take HEAVY. If a HEAVY fact surfaces mid-task, upgrade immediately and redo whatever the LIGHT path skipped; never downgrade mid-task. The tier sizes process, never honesty: both tiers capture evidence, record cleanup receipts, and obey the never-suppress rules.
test cases passed, vs 8 / 19 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.