Shipping ScoreStarling to ChatGPT: our 16-day review

The short answer

ScoreStarling's final ChatGPT plugin submission entered review on October 6, 2026, and was approved and published on October 22: 16 calendar days. We submitted one OAuth-connected MCP server, two Skills, five positive and three negative test cases, a walkthrough, and private reviewer access. A support inquiry midway through the wait produced no decision or completion date; we cannot tell whether it affected the review.

This is our record of one submission, checked on October 22, 2026. It is not an estimate of OpenAI's average review time or a promised turnaround. An earlier 0.1.31 submission was voluntarily withdrawn before the final 1.0.0 package; that was our replacement decision, not a rejection.

What did we submit?

Our approved 1.0.0 package contained 14 runtime files, one hosted MCP connection using OAuth, and two Skills: scorestarling-notation and scorestarling-score. The listing included an icon, example prompts, and website, support, privacy and terms URLs. We also completed publisher identity and MCP domain verification.

ScoreStarling turns recordings, notation images and score files into editable, playable scores. The submission had to explain the whole workflow: bringing music in, opening the result, reviewing changes and exporting it. A reachable server alone would not demonstrate those steps. Our remote MCP OAuth notes cover the sign-in work separately.

We keep the distributable plugin in a public repository with a fixed version tag. The backend is a separate deployment. Reviewer credentials and private review recordings stay outside that repository and its release ZIPs.

What did the reviewer receive?

We supplied a dedicated test account with sample data, sign-in instructions, an accessible walkthrough recording, and release notes. The account did not require us to relay an email code or approve a second-factor prompt. Credentials went into the private reviewer field. The recording was shared through a read-only, link-accessible Drive file.

The five positive cases covered a guitar recording, an original ABC melody, previewing a note change, accepting and undoing an edit, and exports. Each named the prompt, expected tools and observable result. The three negative cases covered requests to return separated original stems, distribute a song on Spotify, or access another account's private score. Those requests needed a refusal or an explanation of the supported alternative.

The distinction mattered in our preparation: checking a ZIP's structure does not show that the reviewer can sign in, and a successful tool call does not show that the visible score changed. We checked those separately. These cases also do not establish that every supplier-dependent paid tool was tested.

For the current required fields, use OpenAI's submission guide, checked October 22, 2026. Treat our account and examples as a concrete case, rather than a substitute for that guide.

Our submission and support timeline

The 16-day count starts with the final 1.0.0 submission, not the beginning of development or the earlier withdrawn package. All dates below use Asia/Bangkok time, UTC+7.

1. Oct 6

   The final 1.0.0 submission showed In review / Pending review.

2. Oct 14

   We asked OpenAI support for a status check. The help interface showed Escalation requested.

3. Oct 15

   A support email acknowledged our information, with no final decision or completion date.

4. Oct 22

   Approval arrived at 05:28. We published later that day and opened the public listing without signing in.

What did OpenAI support actually tell us?

Support did not give us a review decision or an estimated completion date. Our October 14 inquiry included the plugin and submission identifiers and asked whether five automated MCP findings were affecting review. The help interface said escalation had been requested and that replies would also arrive by email.

The October 15 email acknowledged the information we had supplied. It could not confirm whether the findings were delaying review without verification by the review team, and said we did not need to resend the same identifiers. That was the useful outcome of the exchange: the information was acknowledged, while the cause and timing remained unknown.

We cannot infer a fresh inspection by an app reviewer from a support signature or an escalation message. We also have no evidence that the inquiry accelerated approval. The approval notification arrived separately a week later. Our public account paraphrases the exchange; it does not reproduce private correspondence or account details.

Why was GitHub at 1.2.2 while the directory published 1.0.0?

The approved package was still the 1.0.0 ZIP we had submitted. Development continued while it waited, and our public repository reached 1.2.2. Those releases did not replace the package under review.

OpenAI's update instructions distinguish packaged metadata and Skills, which need a new ZIP, from hosted MCP tool updates, which go through MCP scans. A backend deployment or GitHub release is therefore not evidence that a new packaged version is live in the directory.

What would we repeat for another submission?

We would make the submission reproducible for someone who has never used the product, then keep a dated record of what the platform actually reports.

• Fix the package to a version tag and retain the submitted ZIP. Keep its version separate from ongoing server and repository changes.
• Give the reviewer a working account, permitted sample inputs and an observable expected result for every case, including requests the product must refuse.
• Keep credentials in private review fields. Check access to the recording without publishing it in a public code repository.
• When asking support for help, include the identifiers and a precise question. Record the reply without treating an acknowledgment as a review decision.
• After approval, publish deliberately and check both the dashboard and the public detail page.

What is public now?

On October 22, our dashboard showed version 1.0.0 as Published, and the ScoreStarling listing in ChatGPT opened without signing in. It displayed developer HAIYI MEI, version 1.0.0 and an Install plugin button. We checked those states after publication, rather than stopping at the approval email.

That confirms the public listing. It does not measure search placement, successful use by new installers, sign-ups, revenue or transcription accuracy. Our Anthropic and WorkBuddy submissions are separate reviews; OpenAI's approval does not establish their status. Those are the next observations to collect, not results of this launch.

Sources

1. OpenAI: upload, review, publish and update a plugin. Current process reference, checked October 22, 2026.
2. ScoreStarling plugin source at v1.0.0. Public source for the submitted package; private reviewer access is excluded.
3. ScoreStarling's public ChatGPT listing. Publication and displayed version checked October 22, 2026.

Questions and answers

Is 16 days the usual ChatGPT plugin review time?

We cannot establish a usual wait from one submission. Our final 1.0.0 package was in review on October 6, 2026, and approved and published on October 22, a difference of 16 calendar days. Other submissions may take a different amount of time.

Did contacting OpenAI support speed up approval?

We have no evidence that it did. Support acknowledged our inquiry and supplied no decision or completion date. Approval arrived later in a separate notification; the sequence does not establish a causal link.

Does an approved plugin become public automatically?

Our approval notification said the package was ready to publish. We then published it, checked the dashboard's Published state, and opened the public listing without signing in.

Why did the directory publish 1.0.0 when GitHub had 1.2.2?

Version 1.0.0 was the package submitted for review. Later GitHub releases did not replace that package. Updating packaged metadata or Skills requires a new ZIP through the existing plugin's update process.