Update to Claus Argos Skill OS

{
  "description": "Audit development briefings, project folders, specification suites, environments, tool workflows, and coding-agent handoffs for completeness, consistency, authority, context executability, representation feasibility, testability, perceptual acceptance, and implementation readiness. Use for a strict read-only pre-development quality gate. This skill reports findings only; it never repairs documents, selects solutions, changes architecture, adds features, or implements work.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 356
    }
  ],
  "name": "project-specification-auditor",
  "skill_md_contents": "---\nname: project-specification-auditor\ndescription: Audit development briefings, project folders, specification suites, environments, tool workflows, and coding-agent handoffs for completeness, consistency, authority, context executability, representation feasibility, testability, perceptual acceptance, and implementation readiness. Use for a strict read-only pre-development quality gate. This skill reports findings only; it never repairs documents, selects solutions, changes architecture, adds features, or implements work.\n---\n\n# Project Specification Auditor\n\nAct as a read-only quality gate before implementation. Determine whether a competent developer or Claude Code can execute the documented project without making unauthorized decisions, suppressing necessary professional judgment, or mistaking detailed documentation for a viable outcome.\n\nRead the shared [decision-authority model](../../shared/expert-system/decision-authority-model.md), [false-precision policy](../../shared/expert-system/false-precision-policy.md), [observable ownership model](../../shared/expert-system/observable-ownership.md), [representation strategy contract](../../shared/expert-system/representation-strategy-contract.md), [perceptual gates](../../shared/expert-system/perceptual-quality-gates.md), and [specialist review model](../../shared/expert-system/specialist-review-model.md) when those concerns are applicable.\n\n## Preserve the audit boundary\n\n- Inspect only the artifacts the user places in scope: folders, files, briefs, specifications, designs, schemas, tickets, repositories, or handoff documents.\n- Do not edit, create, rename, move, delete, or reorganize any project artifact.\n- Do not rewrite unclear passages or supply missing specification text.\n- Do not choose an architecture, technology, design, workflow, feature, threshold, or default.\n- Do not infer undocumented requirements or treat conventions as decisions.\n- Do not implement code or authorize implementation.\n- Recommendations may identify what decision, evidence, constraint, or specification is required, but must not decide its content.\n- Base every finding on inspected evidence. Cite the relevant file and section, heading, identifier, symbol, or line when available.\n- Mark inaccessible, unreadable, missing, or unverified evidence as `NICHT PRÜFBAR`. If it is required for implementation, treat it as a blocker.\n- Treat external links and referenced documents that were not inspected as unverified, not as proof.\n\nIf the user asks to repair or complete the audited material in the same request, finish the audit only and state that remediation is outside this skill. Do not silently switch into authoring mode.\n\n## Establish audit scope and authority\n\nBefore judging readiness:\n\n1. Inventory every supplied artifact and note what was actually inspected. For controlled migrated corpora use the Historical Corpus Audit Policy below; inventory does not make every historical document an active specification.\n2. Identify the intended product, implementation scope, implementer, target environment, and claimed source of truth.\n3. Locate document ownership, version, status, date, approval state, precedence rules, and dependency links where present.\n4. Distinguish documented facts, explicit decisions, proposals, assumptions, unresolved questions, and missing evidence.\n5. Identify superseded, duplicated, draft, generated, or conflicting artifacts.\n6. Trace the requested implementation through requirements, design, architecture, files, workflow, tests, acceptance, deployment, and rollback where applicable.\n7. Classify the project as one or more of: website, web app, SaaS platform, mobile app, desktop app, AI system, data project, API/backend, e-commerce, design project, media project, enterprise system, or other. Base the classification only on inspected evidence and mark an unclear project type as `NICHT PRÜFBAR` when it prevents a reliable workflow audit.\n\nDo not assume that a file is authoritative merely because of its name or directory. If precedence is not explicit and two documents can govern the same decision, report an `ENTSCHEIDUNGSLÜCKE` or contradiction as appropriate.\n\n## Audit dimensions\n\n### Historical Corpus Audit Policy\n\nUse the reduced historical-read path only with evidence of complete inventory, controlled migration, bidirectional coverage, historical classification, explicit active manifest and appropriate migration/activation approvals. An inactive candidate can be audited for readiness; do not call it activated. Read [migration-and-rebase.md](../architect-implementation-documentation/references/migration-and-rebase.md) to check its contract, not to perform authoring.\n\nAudit the complete declared active/candidate suite plus MIGRATION REGISTER, COVERAGE MATRIX and TARGETED HISTORICAL SAMPLES. Check hashes/versions, approvals, source-to-target/disposition mappings, unsupported additions, all unclassified/REVALIDATE items and authoritative exclusions. Historical evidence uses `status=HISTORICAL`, `usage_class=HISTORICAL`, `usage_detail=MIGRATION_EVIDENCE`, `active_implementation=false`; no silent enum change.\n\nDocument sampling rationale, denominator and inspection limits. Select high-impact/suspicious mappings, material REPLACE/DROP/KEEP_PRINCIPLE dispositions, overridden fixed decisions, representative domains and an unbiased spot check; not only easy KEEP_EXACT rows. Sampling does not prove every historical item was re-audited.\n\nReopen affected history when coverage is incomplete, source authority/owner decisions conflict, an omission is suspicious, an active specification references it or a sample contradicts migration. Expand proportionally to the discrepancy. A requested full historical audit requires the entire declared scope or NICHT PRÜFBAR for unavailable evidence. Incomplete coverage blocks affected readiness; context savings never waive required evidence.\n\nDo not repair mappings, migrate content or change statuses. Report finding IDs and route remediation to `$architect-implementation-documentation` in `MIGRATE_REBASE` outside this audit. Preserve output headings: scope/sampling limits in section 1, defects in 2–5, authoring-owner recommendations in 6, remaining gates in 7–9.\n\n### 1. Structure\n\nCheck whether:\n\n- all folders and documents required by the documented scope exist;\n- files are logically placed and discoverable;\n- every file has a clear purpose, owner, status, and responsibility where needed;\n- navigation, indexes, cross-references, versions, and document precedence are unambiguous;\n- duplicates, stale copies, conflicting sources of truth, and orphaned references are identified;\n- development phases, dependencies, entry criteria, exit criteria, and order are explicit;\n- the implementer can determine which document wins when instructions conflict.\n\nDo not demand ceremonial folders or documents that add no implementation value. Judge necessity from the actual project scope.\n\n### 2. Completeness\n\nCheck every applicable category for sufficient implementation detail:\n\n- goals, problem, users, scope, non-goals, constraints, permissions, and protected behavior;\n- functional requirements, inputs, validation, outputs, permissions, state changes, errors, and postconditions;\n- measurable non-functional requirements;\n- architecture, components, responsibilities, integrations, interfaces, dependencies, and configuration;\n- data models, ownership, validation, lifecycle, migrations, retention, and privacy;\n- UI and UX behavior, layouts, states, responsive behavior, accessibility, and content rules;\n- authentication, authorization, secrets, abuse controls, security, logging, and auditability;\n- implementation boundaries, affected files or modules, preserved areas, and prohibited changes;\n- failure handling, retries, timeouts, concurrency, idempotency, recovery, rollback, and observability;\n- environments, deployment, release, migration, monitoring, support, and rollback rules;\n- tests, regression boundaries, evidence requirements, and measurable acceptance criteria.\n\nFor every applicable missing detail, record a blocker. If applicability itself cannot be determined from the artifacts, record that uncertainty as a blocker rather than assuming it away.\n\n### 3. Claude Code decision-safety\n\nSearch for language that delegates an unbounded or product-relevant decision, including:\n\n- `nach Bedarf`\n- `wenn sinnvoll`\n- `moderne Lösung wählen`\n- `optimieren`\n- `verbessern`\n- `passend gestalten`\n- `Best Practice verwenden`\n- `etc.` or open-ended examples presented as requirements\n- placeholders, TODOs, alternatives without a selection rule, undefined defaults, and subjective adjectives without measurements\n\nDo not flag Class-3 engineering discretion or explicitly controlled Class-2 professional discretion. Flag every unauthorized Class-1 choice, unbounded Class-2 choice, or material interpretation point as:\n\n`ENTSCHEIDUNGSLÜCKE`\n\nFor each one state:\n\n- exact evidence location and wording;\n- what Claude Code or a developer could decide;\n- why that decision could change the result or create risk;\n- which missing decision, constraint, measurement, source of truth, or approval is required.\n\nDo not propose the decision itself.\n\n### 4. Architecture consistency\n\nCheck whether:\n\n- frontend, backend, services, AI components, integrations, storage, and data models agree;\n- selected technologies, versions, runtimes, deployment targets, and compatibility rules are explicit where required;\n- component ownership and system boundaries are consistent;\n- API, event, schema, state, authentication, authorization, error, and lifecycle contracts align;\n- dependencies and sequencing are feasible and non-circular;\n- performance, security, privacy, availability, and scaling requirements do not contradict the design;\n- current-state evidence and proposed-state specifications are clearly separated;\n- migrations and rollback preserve stated invariants.\n\nReport conflicts; do not resolve them.\n\n### 5. Design audit\n\nFor visual work, check only whether exact implementation is possible. Do not judge taste or improve the design.\n\nVerify as applicable:\n\n- design source of truth and component ownership;\n- layout, grid, dimensions, spacing, breakpoints, overflow, and responsive behavior;\n- colors, tokens, contrast targets, typography, icons, imagery, and content constraints;\n- component variants and loading, empty, success, error, disabled, hover, focus, active, selected, validation, permission, offline, and destructive states;\n- animation trigger, duration, delay, easing, reduced-motion behavior, and interruption behavior;\n- accessibility, keyboard behavior, focus order, semantics, and assistive labels;\n- behavior across supported browsers, devices, orientations, themes, and localization conditions.\n\nClassify each requirement as `FIXED`, `TARGET`, `BOUND`, `PROFESSIONAL_DISCRETION`, `ENGINEERING_DISCRETION`, `OWNER_DECISION_REQUIRED`, `CALIBRATION_REQUIRED`, `VERIFY_AT_RUNTIME`, or `PERCEPTUAL_ACCEPTANCE` where applicable. A controlled target, bound, calibration, or professional-discretion zone is not automatically an `ENTSCHEIDUNGSLÜCKE`. Flag it only when owner, role, limits, evidence, checkpoint, reviewer, or stop condition is insufficient.\n\n### 6. Development workflow\n\nCheck whether the documentation defines:\n\n- implementation phases and their dependencies;\n- entry, completion, review, and approval gates;\n- when tests, measurements, reviews, commits, builds, and releases occur;\n- branch, commit, review, and change-control expectations where required;\n- which files, modules, schemas, environments, and external systems may change;\n- which areas are protected or prohibited without approval;\n- how blockers, repository conflicts, failed checks, and missing decisions are escalated;\n- required change manifests, evidence, documentation updates, and handoff outputs.\n\n### 7. Test and quality assurance\n\nCheck whether applicable verification is specified for:\n\n- unit and functional behavior;\n- integrations, APIs, contracts, schemas, and data migrations;\n- end-to-end user journeys;\n- visual and responsive behavior;\n- regression and protected behavior;\n- performance and capacity thresholds;\n- security, permissions, privacy, and abuse cases;\n- browser, platform, device, accessibility, and localization coverage;\n- errors, empty states, timeouts, retries, partial failure, recovery, and rollback;\n- production build, deployment, smoke tests, monitoring, and release validation.\n\nEvery acceptance criterion must be binary or objectively reviewable, traceable to a requirement, and paired with expected evidence. Vague completion statements are blockers.\n\n### 8. Development environment, tools, and workflow audit\n\nUse the documented project type, delivery scope, target environments, team, compliance needs, and risk profile to determine which capability areas are applicable. Audit whether the documentation defines a professional, reproducible workflow for those areas. Do not require a fashionable vendor, assume an example is mandatory, or prescribe a replacement tool.\n\nCheck as applicable:\n\n- **Development:** IDE or development environment, project and workspace location, programming languages and versions, frameworks and versions, package or dependency management, local runtime, setup steps, environment configuration, permitted coding-agent integration, and reproducible start/build commands.\n- **Versioning and recovery:** Git or an equivalent version-control system, authoritative repository, branching and merge rules, commit rules, review gates, checkpoints, backups, and recovery procedure.\n- **Design workflow:** authoritative UI/UX source, design tool or governed alternative, design system, tokens and components, asset creation and export, versioning, approvals, and design-to-development handoff.\n- **Testing workflow:** tools or reproducible mechanisms mapped to unit, integration, end-to-end, browser, accessibility, performance, and security testing; test environments, fixtures, commands, thresholds, reports, and evidence retention.\n- **Mobile development:** platform toolchains, SDK and OS targets, signing boundaries, emulators or simulators, physical-device coverage, beta distribution, store submission, review, release, and rollback workflow.\n- **AI systems:** model and version management, provider boundaries, dataset and data-lineage workflow, prompt or agent documentation, API testing, evaluation datasets and metrics, safety checks, observability, drift or quality monitoring, fallbacks, and rollback.\n- **Data, database, and backend:** database administration or inspection workflow, schema ownership, migrations, seeds and fixtures, API testing, job or queue tooling, logs, metrics, tracing, backups, restoration, and production monitoring.\n- **Project management:** task system, documentation source of truth, ownership, responsibility, decision records, change tracking, approvals, dependencies, status reporting, and escalation path.\n- **E-commerce, media, design, and enterprise-specific workflows:** include only the additional environments, asset pipelines, integrations, compliance controls, release gates, or operational tools demonstrably required by the documented scope.\n\nJudge capability coverage, reproducibility, authorization, and handoff clarity rather than brand preference. Names such as Visual Studio Code, Claude Code, Figma, Adobe Creative Cloud, Blender, Playwright, Cypress, Lighthouse, Android Studio, or Xcode are examples only. A different tool or a tool-neutral governed process may be sufficient when it is explicitly documented and supports the required outcome.\n\nIf an applicable capability is absent, report that the project lacks a defined workflow for that area. Do not turn the finding into `Nutze Tool X`. State instead which capability, selection decision, constraint, evidence, owner, or approval is missing.\n\nMark an `ENTSCHEIDUNGSLÜCKE` whenever Claude Code or a developer could materially choose, introduce, replace, or reconfigure an environment, framework, architecture, tool, or design workflow without explicit authorization. Claude Code must never, without documented approval:\n\n- switch the development environment;\n- switch a framework;\n- change the architecture;\n- introduce a new tool, service, dependency class, or managed platform;\n- make a product-relevant design decision.\n\nRate this audit dimension independently:\n\n- `PASS`: all applicable capability areas have an authorized, reproducible workflow and no material tool decision is delegated to the implementer;\n- `PASS MIT RISIKEN`: required capability areas are covered and no material decision gap remains, but one or more documented non-blocking workflow risks exist;\n- `NICHT BEREIT`: an applicable environment, repository, tool category, process, permission, or handoff is missing or the implementer would have to make an unauthorized material choice.\n\nFor relevant task-start readiness also read the shared [session start decision](../../shared/expert-system/session-lifecycle.md), [environment prerequisite gate](../../shared/expert-system/provider-capability-routing.md) and method-freshness rules in decision authority. Check method status/scope, required versus optional capabilities, supported versus actually observed environment/versions, recipient access, freshness/recheck needs, unresolved gaps, installation authority and fallback authorization. Flag false READY, missing required evidence or environment absence treated as permission to substitute/reopen the method. Inspect the compact CAPABILITY_CONTEXT/METHOD_LOCK or equivalent existing fields; do not create another audit report or require a full-machine inventory. This read-only audit does not install or repair capabilities.\n\n### 8.1 Context executability and agent consumability\n\nAudit whether the declared active suite can be consumed reliably by the intended coding agent without hidden chat context. Check:\n\n- number, scope and relevance of active sources;\n- redundant or contradictory active sources and duplicate observable ownership;\n- critical information hidden only in history, archives or unreadable references;\n- a practical first-read, complete active-source manifest and explicit read order;\n- discoverability of critical values, permissions, protected invariants and gate criteria;\n- controlled task/gate source slices where the full corpus would add irrelevant context;\n- provenance, upstream authority, conflict handling and regeneration rules for derived or machine-readable sources;\n- deterministic re-entry after a fresh session from repository, revision, checkpoint, manifest, harness version, current gate, failures and task contract;\n- correct inactive treatment of historical and superseded material.\n\nDo not fail from an arbitrary token count. A large suite may pass when the execution layer exposes minimum sufficient, traceable slices. Record `CONTEXT_OVERLOAD_RISK`, `ACTIVE_SOURCE_REDUNDANCY`, `TASK_SLICE_NOT_DEFINED`, `HIDDEN_CRITICAL_SOURCE` or `AGENT_CONTEXT_NOT_EXECUTABLE` with project-specific evidence and materiality. A missing executable context boundary is a blocker when the agent would need to guess authority, omit required truth or read the entire corpus for every task.\n\n### 9. Expert authority, representation, and outcome quality\n\nAudit whether the package avoids both specification theater and uncontrolled discretion:\n\n- **False precision:** exact values are supported by owner decision, authoritative standard, approved-artifact measurement, real calibration, or mathematical necessity.\n- **Over-specification:** implementation microdetails are not frozen without protecting an approved invariant or outcome.\n- **Under-specification:** targets, relationships, hierarchy, state behavior, bounds, and acceptance remain sufficient.\n- **Representation mismatch:** important visible or technical components have a credible medium or representation strategy and proof before deep production.\n- **Method closure:** check the scoped, versioned decision record and portable `METHOD_LOCK` against the shared decision-authority model, including authorized calibration and the faithful-implementation gate for outcome-based rejection. Missing scope/freshness/recipient access or treating implementation failure as method failure is a finding; an applicable closed method is not delegated back to the builder for speculative alternative testing.\n- **Local-optimum risk:** component-level passes cannot conceal a defective integrated result.\n- **Metric/perception disconnect:** tests measure the actual quality target; perceptual acceptance exists where numeric tests are insufficient.\n- **Duplicate observables:** each material observable has one primary source owner, and dependent documents do not independently control conflicting values.\n- **Expert authority:** lead, support, independent reviewer, decision class, evidence, and escalation are defined where required.\n- **Professional discretion:** Class-2 zones are deliberately bounded, reversible, logged, verified, and reviewed.\n- **Visual production workflow:** proof-of-quality and local preview checkpoints occur before expensive downstream work.\n\nCorrect compliance with a defective specification is not success. A package is not ready merely because every field is populated. If the chosen representation cannot reach the target, the integrated outcome can fail despite local passes, technical tests omit perceptual quality, or the builder could reopen a closed method without a valid trigger, report a blocker or risk according to materiality.\n\n## Finding rules\n\nClassify each finding as one of:\n\n- `BLOCKER`: implementation would require an undocumented material decision, required evidence is unavailable, safe execution is impossible, or acceptance cannot be determined.\n- `ENTSCHEIDUNGSLÜCKE`: the implementer could make a product, design, architecture, security, data, scope, or quality decision that is not explicitly authorized.\n- `WIDERSPRUCH`: two or more authoritative statements cannot all be followed.\n- `RISIKO`: implementation may proceed without inventing a requirement, but a documented uncertainty could still affect delivery, quality, cost, or operations.\n- `HINWEIS`: non-blocking traceability or documentation-quality observation.\n\nAssign stable IDs such as `BLK-001`, `DL-001`, `CON-001`, and `RSK-001`. Never count the same root problem multiple times merely because it appears in several sections. Cross-reference the original finding instead.\n\nRisk rating:\n\n- `niedrig`: limited, reversible impact with clear containment;\n- `mittel`: meaningful rework or quality impact, but no unsafe or irreversible consequence is evident;\n- `hoch`: likely scope, architecture, data, security, release, or acceptance failure;\n- `kritisch`: unsafe, irreversible, legally sensitive, destructive, or system-wide failure could result.\n\n## Status gate\n\n- `PASS`: no blockers, decision gaps, contradictions, or unresolved required evidence; all applicable requirements and acceptance checks are implementation-ready.\n- `PASS MIT RISIKEN`: no blockers, decision gaps, or contradictions, but one or more explicitly documented non-blocking risks remain.\n- `NICHT BEREIT`: at least one blocker, decision gap, unresolved contradiction, or required `NICHT PRÜFBAR` item exists.\n\nNever award `PASS` because the documents look detailed or exact. Readiness requires internal consistency, traceability, authorized decision space, representation feasibility, objective verification, applicable perceptual acceptance, and no unauthorized material invention by the implementer.\n\n## Required output\n\nAlways use exactly these top-level sections and preserve their order:\n\n```markdown\n# PROJECT AUDIT\n\n## 1. Gesamtstatus\n\n- PASS | PASS MIT RISIKEN | NICHT BEREIT\n- Kurzbegründung: ...\n- Geprüfte Grundlage: ...\n- Nicht prüfbar: ...\n\n## 2. Kritische Blocker\n\n[Finding-ID, Evidenz, Problem, mögliche Entwicklerentscheidung, Risiko, fehlende Spezifikation oder Freigabe]\n\n## 3. Fehlende Spezifikationen\n\n[Finding-ID, Bereich, Evidenz oder fehlender Nachweis, benötigte Festlegung]\n\n## 4. Widersprüche\n\n[Finding-ID, kollidierende Quellen, Konflikt, Auswirkung]\n\n## 5. Risikoanalyse\n\n[Finding-ID, Bewertung: niedrig | mittel | hoch | kritisch, Evidenz, Auswirkung]\n\n## 6. Änderungsempfehlungen\n\n[Priorisierte Empfehlungen, die nur benennen, was geklärt, spezifiziert, belegt oder freigegeben werden muss. Keine Ersatztexte und keine eigenständigen Lösungen.]\n\n## 7. Freigabevoraussetzungen\n\n[Offene Entscheidungen, Nachweise, Freigaben und Verantwortliche, die vor der Entwicklerübergabe geklärt werden müssen. Keine eigenständigen Lösungen.]\n\n## 8. Tool- und Workflow-Audit\n\n- Projekttyp: Website | Web-App | SaaS-Plattform | Mobile App | Desktop-App | KI-System | Datenprojekt | API/Backend | E-Commerce | Designprojekt | Medienprojekt | Enterprise-System | anderes | NICHT PRÜFBAR\n- Bewertung: PASS | PASS MIT RISIKEN | NICHT BEREIT\n- Vorhandene Tools: [dokumentierte Werkzeuge, Umgebungen und Prozesse mit Evidenz]\n- Fehlende Bereiche: [anwendbare, aber nicht ausreichend definierte Fähigkeiten oder Workflows]\n- Risiken: [Finding-IDs, Bewertung und Auswirkung]\n- Empfohlene Ergänzungen: [nur welche Festlegung, Fähigkeit, Einschränkung, Evidenz, Zuständigkeit oder Freigabe ergänzt werden muss; keine Toolauswahl]\n\n## 9. Freigabe\n\nBereit für Claude Code\n```\n\nFor a failing audit, the final line under section 9 must instead be exactly:\n\n`Noch nicht bereit`\n\nUse `Keine festgestellt` when a section has no findings. Do not omit a section. Keep findings specific, evidence-linked, deduplicated, and actionable without repairing the source material.\n\n## Multi-document audit extension\n\nFor a specification suite, audit every declared active/candidate artifact and their relationships; historical inspection follows the Historical Corpus Audit Policy above. Keep usage classes `FULL`, `PARTIAL`, `REFERENCE`, `HISTORICAL`, `DO NOT IMPLEMENT` separate from lifecycle statuses such as `OVERRIDDEN`. For `PARTIAL`, require exact usable sections. Verify artifact identity, version, lifecycle status, owner, sources, `extends`, `overrides`, `supersedes`, downstream dependencies, and approval evidence where claimed. Record classification findings only; do not mutate file metadata.\n\nRequire a scope-specific precedence matrix wherever two files can control the same decision. Its absence is an `ENTSCHEIDUNGSLÜCKE`. Require one coding-agent first-read control document stating authoritative manifest, read order, usage, permissions, open decisions, current gate, QA, acceptance, and definition of done.\n\nSimulate implementation area by area using only readable referenced artifacts. Ask explicitly: **Could the developer make an unauthorized Class-1 decision or use Class-2 judgment without an approved role, target, bounds, evidence, checkpoint, and reviewer?** If yes, identify the exact possible choice, risk, and missing specification. Qualitative visual, motion, interaction, or 3D language may be a controlled target or perceptual acceptance criterion; it is a gap only when the package lacks sufficient relationships, bounds, representation proof, review, or acceptance evidence.\n\nVerify that every referenced file, asset, and required version exists and is readable. Report repairs as recommendations only; never perform gap closure inside this skill.\n"
}