ego-submit

name	ego-submit
description	Complete pre-submission validation for EGO (extensions.gnome.org). Runs automated lint, performs manual code review, validates packaging, and produces a submission readiness report. Use as the final check before uploading to extensions.gnome.org.

ego-submit

Complete pre-submission pipeline for extensions.gnome.org.

This skill orchestrates the full validation sequence before EGO submission, combining automated checks with manual review in a structured pipeline.

Parallelization Strategy

For extensions with 10+ JS files, run in two phases:

Phase A — Automated baseline (sequential, ~30s): Run ego-lint → capture full output (PASS/FAIL/WARN/SKIP counts, metrics, resource graph summary).

Phase B — Manual review (parallel, ~3-4 min):

• Agent 1: ego-review Phases 1-4 (discovery, licensing, lifecycle, signals, security, accessibility). Receives ego-lint output as context.
• Agent 2: ego-review Phases 5-5a (quality, AI patterns) + Phase 4 metadata
  • disclosure matrix + package validation + readiness report draft. Receives ego-lint output as context.

Both agents use ego-lint results to skip already-covered checks (Phases 3, 5a). For smaller extensions (<10 JS files), sequential execution is fine.

Parallel Execution Protocol

• Phase A: Run ego-lint + capture output. This is fast (~30s) and provides the baseline for both review agents.
• Phase B: Launch both agents with ego-lint output in their context. Each agent skips checks already covered by ego-lint and focuses on semantic, cross-file, and design-level issues.

No early stopping: Both agents complete regardless of findings. If ego-lint reports FAILs, the final readiness report verdict is NEEDS FIXES with FAIL items listed first as blocking action items.

Deduplication: Inherent — both agents see ego-lint results and skip covered items. The orchestrator merges remaining findings. When ego-lint and ego-review flag the same issue, prefer ego-lint's categorization (it has the rule ID).

STOP condition: Applied by the orchestrator after both agents complete, not by individual agents during their work.

Pipeline Phases

Pre-flight: Review Simulation (skip if running full pipeline)

gnome-extension-reviewer:ego-simulate provides a quick (<1 min) reviewer's-eye-view with a pass/fail score. Use it for iterative development during active coding; skip it when running the full submission pipeline since Phases 1-5 provide strictly more coverage.

• If the simulation score is 10+: strongly recommend fixing blocking issues before proceeding with the full pipeline
• If the simulation score is 5-9: note the concerns but proceed
• If the simulation score is 0-4: proceed normally

The simulation is advisory — it does not block the pipeline.

Phase 1: Automated Lint

Invoke gnome-extension-reviewer:ego-lint against the extension directory.

• Run all automated checks
• Sequential mode: If any FAIL results: STOP — fix failures before proceeding to Phase 2
• Parallel mode: All agents complete regardless. If FAILs are found, the final readiness report verdict is NEEDS FIXES with FAIL items listed first as blocking action items
• Report all WARN results for the developer to review

Phase 2: Manual Code Review

Invoke gnome-extension-reviewer:ego-review against the extension directory.

• Perform the 5-phase review (discovery, lifecycle, signals, security, quality)
• If any BLOCKING issues found: STOP — fix before proceeding
• Report all ADVISORY issues

Phase 3: Package Validation

ego-lint's check-package.sh already covers forbidden files, required files, nested structure, and compiled schemas. Phase 3 only needs to cover:

1. Check if a distribution zip exists
2. If no, advise the developer to create one:
   • List what should be included (extension.js, metadata.json, schemas/, stylesheet.css, LICENSE, locale/)
   • List what should NOT be included (node_modules/, .git/, CLAUDE.md, .claude/, *.pot, tests/, docs/)
3. Verify extension-specific inclusions (e.g., resources/, locale/, helper scripts)
4. Check zip file size (warn if > 5MB)
5. Scan for secrets or dev artifacts not caught by check-package.sh

Phase 4: Submission Metadata

Review the metadata and suggest improvements:

1. Description quality: Is it clear what the extension does? Are permissions disclosed?
2. Screenshots: Does the extension have screenshots ready? (not checked automatically)
3. Shell versions: Are the listed versions actually tested?
4. Reviewer notes: Draft notes for the EGO reviewer using reviewer-notes-template.md, especially for:
   • pkexec/polkit usage
   • Private API usage
   • Network access
   • Clipboard access
5. Disclosure cross-reference: Compare what the code actually does against what the description declares:
   • Does code use pkexec/Subprocess? → Must be disclosed
   • Does code access clipboard (St.Clipboard)? → Must be disclosed
   • Does code make network requests (Soup.Session)? → Must be disclosed
   • Does code read/write files outside GSettings? → Must be disclosed

Phase 5: Readiness Report

Generate a final report using readiness-report-template.md.

Reference

For detailed submission guidance, see submission-checklist.md.