Description
Package name
Model Fit for Codex Desktop: explicit skill/CLI assessment and automatic hook integration.
What is the package needed for?
Continue the existing implementation in atls/codex PR #2 using the current merged Model Fit implementation as the source baseline. The delivery provides two Desktop-only distributions built from one maintained assessment core. TorinAsakura is the implementation owner.
The Plugins Directory package provides a skill, a standalone assessment CLI and its necessary runtime dependencies. It evaluates an explicitly supplied task, context and active profile and returns a recommendation. Its operation must not require installed or enabled lifecycle hooks, pending hook state, or installation of the automatic distribution.
The Git marketplace package additionally provides opt-in automatic Desktop integration: hooks, native input handoff and queue/replay guards. Both distributions use the same model-selection rules and assessment implementation. The distinction is behavior and packaging; mode=hooks or mode=cli was an illustrative suggestion, not a required API or naming decision.
Scope boundaries:
- Desktop only. Cloud execution and other platforms are separate future work driven by community requests.
- The explicit CLI scope is assessment and recommendation. Automatic switching remains in the automatic distribution; a separate explicit apply command is not assumed by this task.
- Development evals, judge calibration, benchmark runners and reports are development/CI tooling, not installation dependencies. Public synthetic regression fixtures can remain in the repository. Private conversations, corpus, credentials and attachment payloads remain private.
- The working assessment component required to evaluate a user's task belongs in both installation packages; it is distinct from development eval tooling.
- The public Directory package has no lifecycle hooks and does not install or enable them indirectly. README explains the automatic variant and its installation. The Directory listing describes only the delivered CLI variant; it does not promote the automatic variant. Repository metadata may identify atls/codex.
- Existing reviewed license and unrelated repository metadata are preserved.
- Public Directory approval/publication and any later contribution to openai/community-plugins are separate delivery stages. An uploaded ZIP or a merged source PR does not prove approval or public listing.
Implementation steps:
- Reconcile the existing PR with the current merged runtime, preserving confirmed fixes rather than reviving the earlier implementation. Identify and replace obsolete Python, layout and packaging assumptions from the old draft with requirements of the selected source baseline.
- Establish the explicit CLI contract and remove its dependency on hook admission and pending submission state. Reuse the existing assessment core; retain the automatic lifecycle under its existing owner.
- Update packaging to produce a functional CLI distribution and a full automatic distribution from the shared source. Replace the old guidance-only build rule that rejects all runtime scripts. Give both archives one valid plugin root and explicit versions.
- Update repository verification and release workflows to validate both package inventories and attach both ZIPs to the master release. Reusing an existing release version must fail visibly.
- Document prerequisites, installation, use, updates, mode boundaries and diagnostics in README. Mark the CLI submission as Desktop only and prepare its listing metadata under the applicable format. Verify the local authorization/isolation behavior against the supported submission route; do not invent publisher declarations or approvals.
- Verify both built archives from clean installations, then deliver the updated existing PR and reproducible release artifacts for user review. Prepare the Directory submission separately with the required publisher materials.
Acceptance criteria:
- Both distributions are built reproducibly from the same assessment rules and core, without a second evaluator implementation.
- With hooks absent and disabled, the installed CLI accepts its documented input, produces a valid assessment, and handles unavailable prerequisites without relying on a pending hook submission. It does not enable hooks or change the active profile as a side effect of assessment.
- The automatic package retains native input and attachment preservation, one queue/replay cycle, user profile preservation, and the verified recovery behavior in the supported Desktop environment.
- Equivalent assessment inputs reach the same shared assessment implementation in both entry paths; tests do not require a single hardcoded correct model or minimum effort.
- Development evals and private corpus are absent from both installation ZIPs. The CLI package additionally contains no lifecycle hook declarations, discovered hook configuration, or automatic hook installer.
- Clean-install checks establish the documented runtime prerequisites and standalone package completeness. Public instructions contain no personal paths, private accounts or embedded credentials.
- README explains both variants, including automatic installation through the repository marketplace. Directory metadata accurately describes the CLI-only Desktop package and its local-execution requirement.
- Verification checks package contents and the relevant behavior of both variants. A master release attaches the two verified archives at their declared version.
- The PR, actual verification results, package contents and remaining external submission requirements are reviewable. Source delivery, ZIP readiness, submitted review and approved publication have distinct observable statuses.
Usage example
A Desktop user installs the CLI distribution and explicitly invokes Model Fit through its skill or documented CLI to assess a task and receive a model/effort recommendation, with all lifecycle hooks disabled.
A user who wants automatic assessment follows the repository README to install the automatic distribution from the ATLS Git marketplace and explicitly enable and trust its hooks. A justified profile change then transfers the complete native request once and continues it on the chosen profile.
Activity
TorinAsakura commentedon Oct 23, 2026
Done
Next
Artifacts
TorinAsakura commentedon Nov 6, 2026
Что сделано
Что дальше
Артефакты