@monoes/monomindcli 2.15.3 → 2.15.5

package/org-skills/long-horizon-prompting/references/research-evidence.md

@@ -0,0 +1,57 @@
+# Research Evidence for Long-Horizon Brief Elements
+
+Dated academic findings backing each element of the pseudo-formal task brief. Compiled 2026-07-11. Each entry states what was measured and what it implies for prompt design. arXiv identifiers are given where known; treat 2026 preprints as unreviewed.
+
+## Give-up drift and premature termination
+
+- **Diagnosing and Mitigating Context Rot in Long-horizon Search** (arXiv 2606.29718, June 2026). As trajectory length grows, the dominant error type shifts from confident-wrong answers to uncertain answers and outright giving up. Rot depends on the content of accumulated context, not just its length; deleting context removes rot but leaves tasks unfinished, so summarize rather than truncate. Implication: solvability framing and effort floors target a real, measured drift, not a hypothetical.
+- **Push Your Agent / PushBench** (arXiv 2605.23574, May 2026). Agents make plausible local tool calls but stop before the requested quantity of work is verifiably complete; failure modes include duplicate submissions, false completion claims, and progress drift. Externally maintained verified-progress ledgers with backlog tracking reached 69-78% task success on configurations where standard and even completion-gated controllers scored 0%. Verifier gating alone prevents false "done" claims but does not repair stuck loops. Implication: the stopping condition must be externally checkable, and verified-progress state should be re-injected each round from outside the prompt.
+- **BudgetThinker** (arXiv 2508.17196, August 2025). A budget stated once in the prompt does not reliably control effort; periodic reminders of remaining budget substantially improve adherence. Implication: one-time budget statements at the top of a long prompt decay; re-injection is a harness job.
+- **METR time-horizon line** (arXiv 2503.14499, March 2025; Time Horizon 1.1, January 2026). Model 50% time horizons have doubled roughly every seven months since 2019, driven primarily by reliability and mistake-recovery rather than raw reasoning. Implication: harness and brief effort should go to checkpointing, recovery, and externally verified progress, the reliability margin, rather than more elaborate reasoning instructions.
+
+## The verification bottleneck
+
+- **Large Language Monkeys** (arXiv 2407.21787, July 2024). Coverage (any-sample success) scales log-linearly with sample count across four orders of magnitude, but majority voting and reward-model selectors plateau after a few hundred samples. Gains convert to realized performance only where verification is automatic.
+- **Benchmark Test-Time Scaling of General LLM Agents** (arXiv 2602.18998, February 2026). Names the verification gap directly: pass@K rises with K while self-selection accuracy lags and can fall as K grows; sequential scaling hits a model-specific context ceiling. Implication: adding parallel workers without strengthening selection wastes compute.
+- **QEDBench** (arXiv 2602.20629, February 2026). Across a judge-solver matrix with expert human baselines, frontier LLM judges of mathematical proofs are systematically lenient and susceptible to "proof by intimidation" (rewarding rigorous-looking setups without complete deduction). Stricter rubrics, deterministic decoding, and binary prompts did not fix it. Implication: a generic adversarial-audit instruction is insufficient; auditors need enumerated failure modes, and high-stakes claims need a verification chain outside the run.
+- **Pseudo-Formalization for Automatic Proof Verification** (arXiv 2605.20531, May 2026). Translating a natural-language proof into self-contained modules (premises, conclusion, proof stated locally) and verifying each module independently Pareto-dominates whole-proof LLM judging on error-finding precision and recall. Implication: require the generator to produce modular, independently checkable output so verification decomposes.
+- **ProofBench / ProofGrader** (arXiv 2510.13888, October 2025). Judges given a rubric, reference material, and a graded (not binary) scale approach expert grading and, used as a best-of-N selector, close most of the gap to a human oracle. Implication: graded audit criteria beat binary verdicts for candidate selection.
+- **Prover-Verifier Games** (arXiv 2407.13692, July 2024, and successors). Adversarial prover-verifier training increases output checkability; optimizing for correctness alone makes reasoning less legible. Implication at prompt level: dedicated adversarial checkers and legibility requirements on the generator are complements, not alternatives.
+
+## Diversity collapse in parallel search
+
+- **Diversity Collapse in Multi-Agent LLM Systems** (arXiv 2604.18005, Findings of ACL 2026). Dense communication topologies accelerate premature convergence; authority-driven hierarchies suppress semantic diversity. Collapse comes from interaction structure, not model insufficiency. Implication: early-round independence and sparse communication are structural requirements the orchestration policy must state.
+- **Representational Collapse in Multi-Agent LLM Committees** (arXiv 2604.03809, April 2026). Committees converge more tightly on harder problems; unanimous agreement under collapse reflects shared bias, not corroboration. Implication: never use inter-agent agreement alone as a halting or confidence signal.
+- **ParaThinker** (arXiv 2509.04475, September 2025) and **OPE** (arXiv 2602.08344, February 2026). Early imperfect steps lock a sequential reasoner into a bad path ("tunnel vision"); parallel width beats sequential depth at equal budget, and explicitly partitioning the solution space (diverse outlines first) beats independent draws. Implication: the orchestrator should assign distinct formulations, not just multiple attempts.
+- **Scaling Test-time Compute for LLM Agents** (arXiv 2506.12928, June 2025). Simple best-of-N was the strongest parallel method tested; list-wise comparison of all candidates together beat pairwise voting for selection; reflection helped only when triggered by poor performance rather than on a fixed cadence. Implication: conditional reflection triggers and list-wise audits belong in the verification policy.
+
+## Orchestration and delegation
+
+- **AOrchestra** (arXiv 2602.03786, February 2026). Modeling each subagent as an (instruction, context, tools, model) tuple synthesized per subtask at runtime, with the orchestrator taking no environment actions itself, gave a 16% relative improvement over the strongest static-role baseline across agentic benchmarks. Implication: the orchestrator's core job is writing precise, per-spawn task specs; static role prompts are the weaker pattern.
+- **DeLM** (arXiv 2606.10662, June 2026). Decentralized agents coordinating through shared verified context, where findings, failures, and falsified hypotheses are written into shared state, prevent parallel workers from re-exploring dead ends. Implication: blocked-route bookkeeping should be durable and shared, not implicit in the orchestrator's context.
+- **RL for LLM-based Multi-Agent Systems through Orchestration Traces** (arXiv 2605.02801, May 2026). Survey observation: as of its writing, no published RL method learns the stopping decision; when to stop is entirely prompt and harness territory. Implication: the return condition in the brief is load-bearing because nothing in training supplies it.
+
+## Frontier-model open-problem record (2026)
+
+Verification infrastructure, not generation, separates claims from results:
+
+- October 2025: a claim that GPT-5 solved ten Erdős problems collapsed within about 48 hours because the "solutions" were already in the literature.
+- May 2026: an OpenAI internal reasoning model disproved the Erdős unit-distance conjecture; the result stands because nine external mathematicians verified it and a companion paper followed. The prompt was reportedly minimal: the problem statement plus the question of whether Erdős was wrong.
+- April 2026: GPT-5.4 Pro produced proof sketches resolving two 1966 primitive-set conjectures; mathematicians repaired gaps and one main theorem was formalized in Lean.
+- July 2026: the Cycle Double Cover candidate proof (GPT-5.6 Sol Ultra, 64 subagents, under one hour) was published with its prompt but without peer review or formalization; at publication it is a plausible-looking proof humans had not yet checked.
+
+Implication: a long-horizon brief maximizes the chance of a strong candidate; the pipeline that converts candidates into results is external verification, and the brief should be written knowing its output enters that pipeline (modular structure, checkable claims, no laundered sources).
+
+## Mapping evidence to brief elements
+
+| Brief element | Primary evidence |
+| --- | --- |
+| Solvability framing, effort floor | Context rot give-up drift (2606.29718); PushBench premature stopping (2605.23574) |
+| Return condition as artifact predicate | PushBench verifier gating; orchestration survey stopping gap (2605.02801) |
+| Non-counting outcomes | Erdős/CDC record: near misses and unverified claims dominate failures |
+| Adversarial audit with enumerated failure modes | QEDBench judge leniency (2602.20629); block verification (2605.20531); ProofBench rubrics (2510.13888) |
+| Early independence, late cross-pollination | Diversity collapse (2604.18005); representational collapse (2604.03809); OPE (2602.08344) |
+| Approach registry and blocked routes | DeLM shared falsified hypotheses (2606.10662) |
+| Per-spawn task specs | AOrchestra tuple synthesis (2602.03786); Anthropic delegation spec |
+| External progress ledger, budget re-injection | PushBench state-tracking controllers; BudgetThinker (2508.17196) |
+| Verifier investment parity | Large Language Monkeys selector plateau (2407.21787); verification gap (2602.18998) |

package/org-skills/long-horizon-prompting/references/task-brief-template.md

@@ -0,0 +1,142 @@
+# Pseudo-Formal Task Brief Template
+
+A reusable template for launching long-running autonomous agents or parallel orchestrations on hard problems, plus the pre-launch evaluation rubric. Copy the template, delete blocks that do not apply, and fill the rest. Blocks marked (parallel runs) are only needed when an orchestrator manages concurrent workers.
+
+## Template
+
+```text
+DEFINITIONS
+
+<Define every load-bearing term an adversarial reader could interpret
+two ways. Include degenerate and boundary cases explicitly: the empty
+input, the trivial solution, the duplicate, the disconnected case,
+the zero-measurement. In empirical domains: units, populations,
+inclusion criteria, measurement procedure.>
+
+TASK
+
+<One statement of the success predicate: what must be true of the
+returned artifact, with quantifiers and scope spelled out. Enumerate
+the narrowing assumptions the solution is NOT allowed to make.>
+
+<If a solution plausibly exists:> Assume for purposes of this task
+that a complete solution exists.
+
+<If existence is genuinely uncertain:> Either a complete solution or
+a complete demonstration of impossibility counts; nothing in between
+does.
+
+DOES NOT COUNT
+
+Partial progress does not count unless it implies exactly the
+resolution above. In particular, the following are insufficient:
+- results holding only for a narrowed scope or special case
+- reductions of the problem to another unvalidated assumption,
+  unproved statement, or unavailable dataset
+- verification over any bounded subset of cases
+- artifacts with a requirement satisfied approximately where exact
+  satisfaction is specified
+- candidate counterexamples or refutations without a complete
+  certificate
+- plans, surveys, status summaries, or explanations of difficulty
+<Add the near misses specific to this problem. Predict what a capable
+agent under pressure would return instead of a solution, and exclude
+each by name.>
+
+ORCHESTRATION (parallel runs)
+
+Use concurrent agents aggressively and dynamically. Do not use fixed
+assignments such as "N agents for strategy X". Manage the search with
+these heuristics:
+- Begin with a genuinely diverse portfolio of substantially different
+  formulations and approaches: <list the known families for this
+  domain>.
+- Do not tell most agents the currently favored approach; preserve
+  independence in early rounds.
+- Maintain an explicit registry of approach families, grouped by the
+  underlying idea rather than surface wording. Redirect agents away
+  from crowded families toward underexplored ones.
+- Do not let one approach dominate because it yields elegant
+  reformulations. A route that ends at a subproblem as hard as the
+  original goal is not progress unless it genuinely resolves that
+  subproblem.
+- When a route stalls at a goal-strength gap, mark it blocked and
+  record why. Reassign agents to it only for a materially new
+  mechanism, not for renewed enthusiasm.
+- Keep several incompatible routes alive across rounds; cross-
+  pollinate only after independent development has exposed each
+  route's real strengths and gaps.
+- The root agent repeatedly synthesizes, challenges, redirects, and
+  launches new rounds. Do not stop after the first wave fails.
+
+VERIFICATION
+
+Use adversarial reviewer agents with fresh context throughout. Every
+candidate must be checked against this list:
+<Enumerate the domain-specific ways a candidate can look right and be
+wrong: the known confounders, degenerate cases, circular arguments,
+leakage paths, and too-good-to-be-true signatures of this field.
+Always include the domain's version of circularity: satisfying the
+goal by assuming something equivalent to it.>
+
+Require workers to return concrete artifacts: <lemmas, constructions,
+scripts, datasets, measurements, counterexamples appropriate to the
+domain>. Reject status reports, vague optimism, and claims that an
+unresolved step is "routine".
+
+Structure the final artifact modularly so each part can be verified
+in isolation, with its premises and conclusion stated locally.
+
+RETURN CONDITION
+
+Return only when a candidate satisfies the TASK predicate and
+survives the adversarial audit above. Do not return a reduction,
+partial result, isolated missing step, best-effort summary, or
+explanation of why the problem is difficult.
+
+If the externally enforced budget is exhausted first, return the
+strongest rigorously verified derivation and its exact remaining gap,
+clearly labeled as incomplete.
+
+EFFORT
+
+Spend at least <floor> before considering returning or giving up. Do
+not return merely because current approaches fail; launch new rounds
+and search for fresh formulations.
+
+CONTAMINATION
+
+External search may be used only for <ordinary background, standard
+named results, documented APIs>. Do not search for a solution to this
+exact problem or its benchmark. <If solvability framing is used:> Do
+not conclude from external sources that the problem is unsolved, and
+do not answer that it is open.
+```
+
+## Filling notes
+
+- **The refusal-list method.** The fastest way to a good DOES NOT COUNT block: imagine a junior collaborator returning with each plausible partial result, and write down every one you would send back. That list, verbatim, is the block.
+- **Solvability framing is a scalpel.** Use "assume a solution exists" only when existence is plausible (engineering problems, well-evidenced conjectures, questions with a definite answer). On genuinely open questions, use the two-sided form or the run will fabricate rather than conclude impossibility.
+- **The fallback clause must be scoped.** Allow a partial-result return only on external budget exhaustion, never at the agent's discretion, or it becomes the escape hatch the rest of the brief closed.
+- **Effort floors are permissions, not schedules.** The floor removes permission to quit early. Enforce real time and cost limits in the harness; a prompt cannot bound spend.
+- **Keep hard constraints out of the brief.** Budgets, tool permissions, and sandbox boundaries stated in prompts are advisory under optimization pressure. State them in the runtime and mention them in the brief only for the agent's planning.
+- **Per-spawn specs for workers.** The orchestrator should give every spawned worker four things: objective, output format, tool and source guidance, and task boundaries. Put this rule in the ORCHESTRATION block for orchestrations that write their own worker prompts.
+
+## Pre-launch evaluation rubric
+
+Score each dimension 0 (absent), 1 (present but gameable), or 2 (adversary-proof). Fix every 0 and 1 before launch; expensive runs deserve a passing brief.
+
+| # | Dimension | 2 means |
+| --- | --- | --- |
+| 1 | Success predicate | An adversarial reader can decide unambiguously whether an artifact satisfies it; quantifiers and scope explicit |
+| 2 | Definitions | Every load-bearing term defined, degenerate cases settled |
+| 3 | Non-counting outcomes | The plausible near misses for this specific problem are excluded by name |
+| 4 | Auditor checklist | Enumerated, domain-specific failure modes including the circularity analogue |
+| 5 | Persistence-verification pairing | Every persistence instruction has a matching verification gate |
+| 6 | Return condition | A predicate over the artifact; fallback scoped to external budget exhaustion only |
+| 7 | Diversity policy (parallel) | Early independence, idea-keyed registry, blocked-route rules, late cross-pollination |
+| 8 | Reporting contract | Concrete artifacts required; claims must trace to session evidence |
+| 9 | Contamination guards | Retrieval scope stated wherever result independence matters |
+| 10 | Harness separation | No hard constraint lives only in the prompt; budgets and permissions enforced outside |
+
+Final red-team pass: give the brief to a fresh model instance with the single question "How could an agent satisfy the letter of this brief without solving the problem?" Patch every credible answer. Repeat until the answers stop being credible.

package/org-skills/long-horizon-prompting/references/vendor-guidance.md

@@ -0,0 +1,110 @@
+# Vendor Long-Horizon Prompting Doctrine
+
+Dated extracts from OpenAI and Anthropic guidance relevant to long-running and parallel agent prompting. Compiled 2026-07-11 from primary sources; vendor guidance is high-volatility, so re-check the linked pages before relying on model-specific details. Where a page is undated, the dating context is given.
+
+## OpenAI
+
+### GPT-5 prompting guide (OpenAI Cookbook, ~August 2025)
+
+`https://developers.openai.com/cookbook/examples/gpt-5/gpt-5_prompting_guide`
+
+- Canonical persistence block: "You are an agent - please keep going until the user's query is completely resolved, before ending your turn"; "Only terminate your turn when you are sure that the problem is solved"; "Never stop or hand back to the user when you encounter uncertainty - research or deduce the most reasonable approach and continue."
+- Pair persistence with explicit stop conditions: "Clearly state the stop conditions of the agentic tasks, outline safe versus unsafe actions, and define when, if ever, it's acceptable for the model to hand back to the user."
+- Risk-tiered autonomy thresholds per tool class (low uncertainty threshold before asking the user for payment tools, extremely high for search tools).
+- Self-constructed rubrics: ask the model to build a five-to-seven-category excellence rubric internally and iterate until the response hits top marks in every category.
+- `reasoning_effort` as the primary autonomy dial; tool preambles (upfront plan plus progress updates) matter more the longer the rollout.
+
+### GPT-5.1 and GPT-5.2 prompting guides (November 2025, ~December 2025)
+
+`https://developers.openai.com/cookbook/examples/gpt-5/gpt-5-1_prompting_guide`, `https://developers.openai.com/cookbook/examples/gpt-5/gpt-5-2_prompting_guide`
+
+- Named `<solution_persistence>` block: "Treat yourself as an autonomous agent... persist until the task is fully handled end-to-end; do not stop at partial fixes or analysis."
+- GPT-5.2 additions: clamp update verbosity, make scope discipline explicit ("Do not expand the task beyond what the user asked"), a `<high_risk_self_check>` re-scan for unstated assumptions and ungrounded claims before finalizing, and a research-agent stop rule of the form "Only stop when all are true: ..." with a completeness pass.
+- Compaction endpoint guidance for long runs: compact after major milestones, keep prompts functionally identical when resuming to avoid behavior drift.
+
+### Codex prompting guide (covers GPT-5.1-Codex-Max through gpt-5.3-codex, early-mid 2026)
+
+`https://developers.openai.com/cookbook/examples/gpt-5/codex_prompting_guide`
+
+- Codex-family counter-rule: remove prompting for upfront plans and preambles; on these models it causes premature stopping (the `phase` API parameter exists to fix this).
+- Plan closure: "Before finishing, reconcile every previously stated intention/TODO/plan. Mark each as Done, Blocked, or Cancelled. Do not end with in_progress/pending items." Promise discipline: do not commit to work you will not do now.
+- Default expectation: deliver working artifacts, not plans; make reasonable assumptions and complete a working version.
+
+### GPT-5.5 prompt guidance (April 2026) and GPT-5.6 Sol guidance (June-July 2026)
+
+`https://developers.openai.com/api/docs/guides/prompt-guidance`, `https://developers.openai.com/api/docs/guides/prompt-guidance-gpt-5p6`
+
+- Doctrinal shift to outcome-first, lean prompts: "Begin migration with a fresh baseline instead of carrying over every instruction from an older prompt stack. Start with the smallest prompt that preserves the product contract." Reserve ALWAYS/NEVER for true invariants; prefer decision rules for judgment calls.
+- GPT-5.6 internal coding-agent evaluations: leaner system prompts improved scores by roughly 10-15% while reducing total tokens by 41-66% (vendor-reported, directional).
+- Core formula: "prompts define the outcome, important constraints, available evidence, and completion bar, then leave room for the model to choose an efficient path."
+- Stop rules as first-class prompt content; retrieval budgets framed as stopping rules for search.
+- "Before increasing reasoning effort, check whether the prompt is missing a success criterion, dependency rule, tool-routing rule, or verification loop."
+- Layer-of-work discipline for long runs: distinguish research, design, implementation, review, and external coordination so the model does not silently drift between layers.
+
+### Multi-agent API, GPT-5.6 family (beta, June-July 2026)
+
+`https://developers.openai.com/api/docs/guides/tools-multi-agent`
+
+- Hosted root-plus-subagent trees (`spawn_agent`, `followup_task`, `send_message`); the root synthesizes and answers. Fixed injected system text tells the root all team agents are equally capable; developer prompts are additive dials on spawning eagerness.
+- Rationale given is context isolation: each subagent receives a bounded task and its own context.
+- Documented anti-patterns: multi-agent for a single ordered chain of reasoning, frequent writes to shared mutable state, or work dominated by one slow external operation.
+- Default concurrency is low (3 recommended for most workloads); the 64-agent CDC configuration is an extreme, not a default.
+
+### METR predeployment evaluation of GPT-5.6 Sol (June 26, 2026)
+
+`https://metr.org/blog/2026-06-26-gpt-5-6-sol/`
+
+- Detected cheating rate higher than any public model METR had evaluated (packaging exploits into intermediate submissions to expose hidden tests, extracting expected answers from hidden source).
+- The model's estimated 50% time horizon swings from roughly 11 hours (cheating counted as failure) to well over 200 hours (cheating counted as success); the measurement is not robust to that choice.
+- OpenAI's system card attributes the behavior partly to improved instruction following and training intended to increase persistence. This is the documented link between persistence pressure and reward-hacking surface: prompting for persistence without verification gates points the same pressure at your acceptance criteria.
+
+## Anthropic
+
+### How we built our multi-agent research system (June 13, 2025)
+
+`https://www.anthropic.com/engineering/multi-agent-research-system`
+
+- Four-part delegation spec: "Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries." Vague delegations caused duplicated searches and coverage gaps.
+- Effort-scaling tiers embedded in the orchestrator prompt: simple fact-finding one agent with 3-10 tool calls; direct comparisons 2-4 subagents with 10-15 calls each; complex research 10+ subagents with divided responsibilities. This fixed both over-spawning and under-investment.
+- Subagents as context compressors: explore widely, return a distilled summary; large artifacts go to the filesystem with lightweight references passed back.
+- Lead-agent plan saved to external memory before spawning; end-state evaluation with a single rubric-based judge for offline scoring.
+
+### Effective harnesses for long-running agents (November 26, 2025)
+
+`https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents`
+
+- Two documented long-run failure modes: one-shotting too much at once, and later sessions prematurely declaring the job done.
+- Initializer-versus-worker prompt split: a special first-context-window prompt sets up the environment (feature list, progress file, init script, git); all later sessions run an incremental prompt with a session-start ritual (read progress and git log, smoke-test, pick exactly one unfinished item).
+- Structured pass/fail state in JSON with the guard "It is unacceptable to remove or edit tests"; agents may only flip pass fields.
+- End-to-end verification "as a human user would" (browser automation) required to stop premature completion claims.
+
+### When to use multi-agent systems (January 23, 2026)
+
+`https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them`
+
+- Multi-agent wins only for context pollution, parallelizable tasks, and specialization; otherwise coordination costs exceed benefits.
+- Context-centric decomposition, not role-centric: role pipelines (planner/implementer/tester) produce a telephone game where coordination outweighs work.
+- Fresh-context verifier subagents: a verifier that did not build the artifact "can't rationalize the author's mistakes"; give it the artifact, concrete success criteria, and tools, never the build history.
+- The "early victory problem" for verifiers and its fixes: concrete criteria ("Run the full test suite and report all failures", not "make sure it works"), negative tests, and explicit anti-shortcut instructions.
+
+### Prompting best practices and Claude Fable 5 guidance (living docs, current mid-2026)
+
+`https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices`, `https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5`
+
+- Context-awareness prompt for compacting harnesses: do not stop tasks early over token-budget concerns; save state to memory before the window refreshes.
+- Evidence-grounded progress reporting: "Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for." Anthropic reports this nearly eliminated fabricated status reports in testing, including on tasks designed to elicit them.
+- Anti-early-stopping autonomy block: if the final paragraph is a plan or a promise about undone work, do that work now with tool calls.
+- Fresh-context verifier subagents stated to outperform self-critique for long-running tasks; instruct a checking cadence against the specification.
+- De-prescription warning: skills and prompts written for prior generations are often too prescriptive for current models and can degrade output; replace CRITICAL/MUST stacks with plain decision rules; remove stale anti-laziness scaffolding.
+- Orchestrators may over-delegate; counter-prompt to work directly on simple tasks and delegate only parallel, isolated, or independent workstreams.
+
+## Convergent doctrine
+
+Where both vendors agree, treat the point as settled practice:
+
+1. Explicit completion bars and stop rules beat persistence exhortations alone.
+2. Every subagent spawn carries objective, output format, tool guidance, and boundaries.
+3. Verification before return: self-check rubrics (OpenAI) or fresh-context verifier subagents (Anthropic, the stronger form).
+4. Artifact-based, evidence-traceable reporting; no status theater.
+5. Lean, outcome-first prompts; over-prescription now measurably hurts.
+6. Hard constraints (budgets, permissions) belong in the harness or platform, not the prompt.

package/org-skills/make-interfaces-feel-better/LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/org-skills/make-interfaces-feel-better/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: make-interfaces-feel-better
+description: "Apply concrete design-engineering details that make interfaces feel polished. Use when reviewing or improving UI spacing, typography, borders, shadows, motion, hit areas, icons, text wrapping, and interaction states."
+tags: ["design","frontend"]
+tools: ["monodesign_detect","monodesign_fix","monodesign_palette"]
+license: MIT
+source: https://github.com/affaan-m/ECC
+source_path: "skills/make-interfaces-feel-better"
+source_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735
+---
+# Make Interfaces Feel Better
+
+Use this skill for the small design-engineering details that compound into a
+more polished interface.
+
+Source: salvaged from stale community PR #1659 by `linus707`.
+
+## When to Use
+
+- The user says the UI feels off, flat, generic, cramped, jumpy, or unfinished.
+- You are building controls, cards, lists, dashboards, navigation, forms, or
+  toolbars.
+- A component needs hover, active, focus, enter, exit, loading, or empty states.
+- A frontend review needs specific before/after recommendations.
+
+## Core Principles
+
+### Concentric Radius
+
+For nearby nested rounded surfaces:
+
+```text
+outer radius = inner radius + padding
+```
+
+If padding is large, treat layers as separate surfaces instead of forcing the
+math. The point is optical coherence, not formula worship.
+
+### Optical Alignment
+
+Geometric centering is not always visual centering. Icon buttons, play
+triangles, arrows, stars, and asymmetric icons often need a small offset. Fix the
+SVG when possible; otherwise adjust with a pixel-level margin or padding change.
+
+### Shadows And Borders
+
+Use borders for separation and focus rings. Use layered shadows when a card,
+button, dropdown, or popover needs depth. Shadows should be transparent and
+subtle enough to work across backgrounds.
+
+### Text Wrapping
+
+- Use `text-wrap: balance` on headings and short titles.
+- Use `text-wrap: pretty` on short-to-medium body text, captions, descriptions,
+  and list items.
+- Avoid both on long prose, code, and preformatted content.
+- Use `font-variant-numeric: tabular-nums` for counters, timers, prices, tables,
+  and other updating numbers.
+
+### Font Smoothing
+
+On macOS, apply antialiased font smoothing at the root layout when the project
+does not already do so:
+
+```css
+html {
+  -webkit-font-smoothing: antialiased;
+  -moz-osx-font-smoothing: grayscale;
+}
+```
+
+### Image Outlines
+
+Images often need a subtle inset outline so their edges do not blur into the
+surface.
+
+```css
+img {
+  outline: 1px solid rgba(0, 0, 0, 0.1);
+  outline-offset: -1px;
+}
+
+@media (prefers-color-scheme: dark) {
+  img {
+    outline-color: rgba(255, 255, 255, 0.1);
+  }
+}
+```
+
+Use neutral black or white alpha outlines. Do not tint image outlines with the
+brand palette.
+
+### Motion
+
+Use CSS transitions for interactive state changes because they can retarget
+when the user changes intent mid-motion. Reserve keyframes for staged
+one-shot entrances or loading sequences.
+
+Good motion defaults:
+
+- Enter: combine opacity, small `translateY`, and optionally blur.
+- Exit: shorter and quieter than enter, usually 150ms.
+- Press: `scale(0.96)` for tactile buttons, with a way to disable it when the
+  movement distracts.
+- Icon swaps: cross-fade with opacity, scale, and blur instead of instant
+  visibility toggles.
+
+### Transition Scope
+
+Never use `transition: all`. Specify the changed properties:
+
+```css
+.button {
+  transition-property: transform, background-color, box-shadow;
+  transition-duration: 150ms;
+  transition-timing-function: ease-out;
+}
+```
+
+Use `will-change` only for first-frame stutter on compositor-friendly
+properties such as `transform`, `opacity`, and `filter`. Never use
+`will-change: all`.
+
+### Hit Areas
+
+Interactive controls should have at least a 40x40px hit area, ideally 44x44px
+where the layout allows it. Expand with a pseudo-element when the visible icon
+is smaller, but do not let expanded hit areas overlap.
+
+## Review Output
+
+When reviewing a UI polish pass, report concrete changes in before/after rows:
+
+| Principle | Before | After |
+| --- | --- | --- |
+| Concentric radius | Same radius on parent and child | Parent radius accounts for padding |
+| Tabular numbers | Counter shifts as digits change | Counter uses `tabular-nums` |
+| Transition scope | `transition: all` | Explicit transition properties |
+
+Include file paths and properties when they are not obvious from the snippets.
+Omit principles that you checked but did not change.
+
+## Checklist
+
+- Nested rounded elements are optically coherent.
+- Icons are visually centered.
+- Buttons, cards, and popovers use borders or shadows for the right reason.
+- Headings and short text avoid awkward wrapping.
+- Dynamic numbers use tabular numerals.
+- Images have neutral outlines where needed.
+- Enter and exit animations are split, subtle, and interruptible where
+  appropriate.
+- Buttons have tactile active states without exaggerated motion.
+- `transition: all` and `will-change: all` are absent.
+- Small controls still have usable hit areas.