The “every task” rule exceeds the stated scope and may override a user’s brevity request
Source references: 3The metadata says the Skill applies to tasks requiring exhaustive, unabridged output, but the body then treats “every task” as production-critical and forbids optimizing for brevity. This expands specialized behavior to every request where the Skill remains active.
If enabled persistently, it may produce unnecessary material and require multiple continuation turns even when the user wants a summary, diff, or short answer. This can increase time and usage cost while obscuring the most important information.
The metadata targets tasks needing exhaustive, unabridged output, but the active baseline treats “every task” as production-critical and explicitly rejects optimizing for brevity. If enabled for a summary or short-answer request, it could produce unnecessarily long responses and override the user's brevity preference. Users can ask the author to limit this rule to requests that explicitly require complete files or lists.
name: full-output-enforcementdescription: Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.---Show 2 other places
Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity — optimize for completeness. If the user asks for a full file, deliver the full file. If the user asks for 5 components, deliver 5 components. No exceptions.- Do not compress remaining sections to squeeze them in.- Do not skip ahead to a conclusion.- Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).- End with: