Spm Build Analysis

Testbericht

skills/spm-build-analysis/SKILL.md (92 Zeilen, frontmatter wird mit name+description geparst) wurde abgerufen und alle drei referenzierten Dateien sowie das Skript stichprobenartig überprüft — references/spm-analysis-checks.md, references/recommendation-format.md, scripts/check_spm_pins.py alle HTTP 200; kein curl|sh, base64-Blobs, geheime Exfiltration oder Injection-Text irgendwo (das Skript führt nur `git ls-remote --tags` auf URLs aus, die aus dem eigenen pbxproj des Projekts gelesen werden). Ich habe ein synthetisches Fixture erstellt (Modules/Package.swift mit einem @_exported-Stil Umbrella-Target, einer FeatureProfile→FeatureFeed-Schichtverletzung, TCA, iOS+watchOS-Plattformen; App.xcodeproj/project.pbxproj mit einem Alamofire branch=master Remote-Ref; und einem nicht verknüpften Vendor/LegacyCharts-Paket auf der Festplatte), eine Baseline-Antwort geschrieben und dann die Aufgabe gemäß dem Skill-Text erneut ausgeführt. Konkrete Unterschiede: Die Baseline empfahl, auf Vendor/LegacyCharts zu reagieren (ein Fehlalarm — es hat keine XCLocalSwiftPackageReference und trägt keine Build-Zeit bei), während der pbxproj-Verifizierungsschritt des Skills es explizit ausschloss; das Ausführen des gebündelten Skripts lieferte reale Daten (`Alamofire: branch=master -> tags available (latest: 5.7.1 … 5.9.1)`), sodass die Pin-Empfehlung „einen Semver-Tag verwenden“ anstelle einer Vermutung wurde; und der Skill-Lauf fing die von der Baseline verpassten Erkenntnisse test-target-depends-on-umbrella und iOS/watchOS build-multiplication ein. Kosten: 596 Wörter vs. 174. Nicht gemessen: tatsächliche Build-Zeit-Differenz — ich habe hier kein Xcode/xcodebuild, daher blieben alle Ergebnisse bei benchmark_verification_status „Not yet verified“, was der Skill selbst anweist. Trigger-Formulierungen bewertet — SOLLTE auslösen: (1) „Our clean builds take 9 minutes and I think it's the SPM dependency graph, can you look at Package.swift?“ (2) „Every tiny edit rebuilds half the app and we use TCA macros heavily — is our module structure to blame?“ (3) „How should I split my 400-file Core module so incremental builds get faster?“; SOLLTE NICHT auslösen: (4) „swift build fails with 'no such module Alamofire' after I added the dependency“ (Kompilierungsfehler, nicht Build-Performance) (5) „Which networking package should I pick for a new iOS app, Alamofire or URLSession?“ (Abhängigkeitsauswahl). Alle 5 korrekt gemäß der Beschreibung bewertet. Dokumentation um einen Punkt gekürzt: Die Installationsüberschrift der README, die 40-Checks-Tabelle und die „Community Results“-Build-Zeit-Gewinne gehören zum Sechs-Skill-Orchestrator-Plugin, nicht nur zu diesem Analysator, und das Banner verlinkt ein kommerzielles Produkt.

Getestet am: 2026-07-21 · Claude Code 2.x (agent harness)