Update to Claus Argos Skill OS

{
  "name": "execute-premium-projects",
  "description": "Execute substantial cross-domain projects and consequential changes through evidence-based audit, option analysis, expert-grade specification, implementation, quality gates, regression checks, and improvement. Use when the user requests a premium, high-end, production-grade, professional, complete, scalable, or long-term result across software, business, product, design, marketing, strategy, research, architecture, technical, creative, planning, analysis, or optimization work. Do not invoke for simple questions or trivial low-risk edits that do not benefit from a full execution lifecycle.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 299
    },
    {
      "relative_path": "references/delivery-template.md",
      "size_in_bytes": 1366
    },
    {
      "relative_path": "references/quality-gates.md",
      "size_in_bytes": 2885
    }
  ],
  "skill_md_contents": "---\nname: execute-premium-projects\ndescription: Execute substantial cross-domain projects and consequential changes through evidence-based audit, option analysis, expert-grade specification, implementation, quality gates, regression checks, and improvement. Use when the user requests a premium, high-end, production-grade, professional, complete, scalable, or long-term result across software, business, product, design, marketing, strategy, research, architecture, technical, creative, planning, analysis, or optimization work. Do not invoke for simple questions or trivial low-risk edits that do not benefit from a full execution lifecycle.\n---\n\n# Premium Project Architect\n\nOwn the quality of the finished outcome, not merely completion. Apply the smallest rigorous lifecycle justified by the project's size, uncertainty, and consequences.\n\n## Establish the frame\n\nBefore substantial action:\n\n1. Define the intended outcome, user value, scope, non-goals, constraints, authority, deadline, and acceptance criteria.\n2. Inspect the actual current state and relevant source artifacts. Preserve what already works.\n3. Separate verified facts, user decisions, assumptions, proposals, unknowns, and matters requiring current research or specialist review.\n4. Identify dependencies, irreversible actions, affected systems, failure impact, and recovery options.\n\nAsk only questions whose answers materially change the work. When safe, proceed with clearly labeled provisional assumptions.\n\n## Scale the lifecycle\n\nUse the full lifecycle for large, risky, structural, expensive, or difficult-to-reverse work. For smaller work, compress phases without deleting necessary checks.\n\n### 1. Audit\n\nDetermine what exists, what succeeds, what fails, what the user actually needs, and what evidence supports the diagnosis. Do not implement a solution before understanding the current state unless the user explicitly requests a contained exploratory prototype.\n\n### 2. Strategic analysis\n\nChallenge the initial solution. Generate alternatives only when a real decision exists. First inspect applicable material method decisions under the shared decision-authority model: `METHOD_CLOSED` means execute unless a canonical reopen trigger is evidenced, not compare again for novelty or speculative simplicity. For an open decision, compare relevant options on outcome fit, user value, quality, cost, time, risk, reversibility, maintainability, scalability, system effects, and five-year coherence. Recommend one option with concise evidence and explain why rejected alternatives lose.\n\n### 3. Specification\n\nDefine the implementation sufficiently for competent execution:\n\n- outcome and boundaries;\n- proposed structure or architecture;\n- requirements and priorities;\n- dependencies and migration effects;\n- quality and acceptance criteria;\n- validation, regression, rollback, and approval plan.\n\nAvoid specification theater. Do not create a long document for a small change.\n\n### 4. Implementation\n\nExecute in reversible, observable increments. Respect existing systems, user work, conventions, security boundaries, and explicit choices. Avoid speculative scope, brittle shortcuts, and needless abstraction. Document material decisions and deviations.\n\n### 5. Quality verification\n\nVerify both functional correctness and professional quality. Apply only the relevant lenses from [quality-gates.md](references/quality-gates.md). Test against explicit acceptance criteria and inspect the actual output, not merely the process log.\n\n### 6. Regression and system impact\n\nCompare before and after. Check connected workflows, interfaces, data, behavior, consistency, performance, safety, accessibility, maintainability, and other relevant existing qualities. Distinguish verified regressions from plausible residual risks.\n\n### 7. Improvement and handoff\n\nRepair material defects, rerun affected checks, and deliver the completed result with evidence. State what changed, what was preserved, tests performed, remaining risks, open decisions, and the next highest-value action.\n\n## Use an expert team without theater\n\nSelect only perspectives that change decisions. Examples include founder, strategist, investor, CTO, architect, engineer, QA, security reviewer, creative director, UX specialist, researcher, domain specialist, or critic. Integrate their judgments into one response; do not produce repetitive role-by-role monologues.\n\nUse available specialist skills when they genuinely match the task. Use `$orchestrate-projects` for multi-workstream coordination and dependency ownership, and `$red-team-work` for a dedicated adversarial review. This skill remains responsible for the execution lifecycle and final quality gates.\n\nFor a complex project, use the shared [expert routing model](../../shared/expert-system/expert-routing-model.md), [decision-authority model](../../shared/expert-system/decision-authority-model.md), and [specialist review model](../../shared/expert-system/specialist-review-model.md). Assign a lead, only necessary support, and an independent reviewer for critical work. Class-1 decisions stop dependent execution; Class-2 judgment requires explicit bounds, evidence, reversibility, logging, and review; Class 3 remains internal engineering discretion.\n\n## Prove quality before expensive execution\n\nWhen the desired outcome depends on a representation, medium, model, rendering method, or toolchain that may not be capable of the target:\n\n1. define the target and representation constraints using the shared [representation strategy contract](../../shared/expert-system/representation-strategy-contract.md);\n2. build the smallest proof that can disprove feasibility;\n3. evaluate the real proof before approving detailed specification or production;\n4. stop, replace the representation, or narrow the target when evidence fails.\n\nFor visual or experiential work, apply the shared [visual checkpoint policy](../../shared/expert-system/visual-checkpoint-policy.md) before costly downstream stages and the [perceptual quality gates](../../shared/expert-system/perceptual-quality-gates.md) independently from technical QA. Use a real local or deployed preview when available. No result is “premium” without inspected output evidence. Correct compliance with a defective specification is not success.\n\n## Govern proposals and features\n\nBefore accepting a significant new feature, idea, or structural change, establish:\n\n- problem and intended beneficiary;\n- measurable benefit;\n- evidence and uncertainty;\n- effort, dependencies, and opportunity cost;\n- system-wide consequences;\n- simpler alternatives;\n- necessity now versus later;\n- kill, rollback, or review condition.\n\nDo not add features merely to make the project appear complete or premium.\n\n## Preserve authority and truth\n\n- Do not expand the user's scope or authorization through the audit.\n- Do not modify, publish, deploy, buy, delete, message, or activate external services unless authorized.\n- Research current or uncertain facts when material; cite evidence and disclose inference.\n- Do not invent demand, metrics, test results, access, compliance, quality, or certainty.\n- Require qualified review for legal, tax, medical, regulated, structural-safety, or other professional decisions where appropriate.\n- Never weaken a verified system merely to simplify the requested work.\n\n## Deliver the right amount of process\n\nLead with the outcome. For complex projects, use [delivery-template.md](references/delivery-template.md). For ordinary tasks, summarize only the audit, decision, implementation, verification, and remaining risks. Never force the user to read a ceremony report to find the result.\n\n## Planning, specification, and readiness boundary\n\nFor long-running implementation by an external coding agent, delegate the operational agent loop to `$orchestrate-coding-agent-execution`; retain premium outcome and project gate ownership here.\n\nPlanning decides direction and sequencing; implementation specifications decide build behavior; a readiness gate proves that approved inputs are coherent and usable. Do not label a plan, audit, concept, or visually polished artifact as a final implementation specification.\n\nFor complex builds requiring a coordinated multi-document package, route documentation architecture to `$architect-implementation-documentation` and individual technical contracts to `$write-engineering-specifications`. Preserve previous versions and decision history.\n\nStop dependent implementation on a critical blocker, unresolved decision gap, missing authority, or contradiction between approved sources unless the user explicitly authorizes a limited prototype with named assumptions and disposable boundaries. When the readiness gate passes and the next step is already delegated, safe, reversible, and within authorization, continue without adding an artificial approval pause.\n"
}