How submissions work

The submission flow is fully automated. Here’s what happens between you clicking Submit and your contribution going live.

The pipeline

You fill the form  →  GitHub issue is opened
                           ↓
                  Issue-to-PR workflow runs
                           ↓
              Issue body parsed into structured JSON
                           ↓
        scripts/issue-to-files.mjs writes the right files
                           ↓
              npx astro sync validates the schema
                           ↓
              ┌─────────────┴─────────────┐
       Validation passes            Validation fails
              ↓                            ↓
         PR opened                  Bot comments error
       Comment added                Edit issue → retry
              ↓
        Maintainer review
              ↓
         Merge to main
              ↓
       Vercel deploys site

What the bot does

When you open an issue with one of the contribution forms, GitHub auto-applies a submission label plus a kind label (plugin, artifact, skill-page, or edit). That triggers .github/workflows/issue-to-pr.yml:

1. Parse — stefanbuck/github-issue-parser reads your issue body using the form template and outputs structured JSON.
2. Generate files — scripts/issue-to-files.mjs takes the JSON and the kind, and writes:
   • Plugin: plugins/<slug>/.claude-plugin/plugin.json, rba-meta.json, README.md, and the first skill’s SKILL.md.
   • Artifact: the right file under plugins/<target>/<kind>s/<name>.md (or merges into .mcp.json / hooks.json).
   • Skill page: src/content/docs/skills/<lifecycle>/<area>/<slug>.md.
   • Edit: a placeholder note under .contributions/ for a maintainer to apply.
3. Validate — npx astro sync runs the Zod schemas in src/content.config.ts. If anything’s invalid, the workflow fails and the bot comments on your issue.
4. Open PR — peter-evans/create-pull-request pushes a branch (contrib/issue-<n>) and opens a pull request titled “Submission from #N: <your title>”, linked to your issue with Closes #N.
5. Comment — the bot drops a comment on your issue with the PR link.

What the maintainer does

A reviewer opens the PR, runs the review checklist, and either:

• Approves and merges → the change deploys to https://rba-skills.tylerschroeder.net in ~60 seconds.
• Leaves comments on the PR for tweaks → you (or a maintainer) push fixes, then the PR re-runs validation.
• Asks a clarifying question on the original issue → you reply, the issue gets edited, and the bot rebuilds the PR.

What you can do mid-flight

• Edit the issue — the bot watches for edits and re-generates the PR.
• Comment on the issue or PR — questions, context, screenshots all welcome.
• Add reviewers — tag whoever should weigh in. The maintainer team is in CODEOWNERS.

Why GitHub forms instead of a website form?

We wanted contributing to require zero infrastructure beyond what GitHub already provides. No serverless functions, no auth tokens, no separate moderation queue. The trade-off: you need a GitHub account. For an RBA-internal contribution flow, that’s a small ask.

The guided wizard doesn’t change this. It’s a static, client-only page that asks plain-language questions and then deep-links you into a GitHub issue form with the fields pre-filled (GitHub fills issue-form fields from URL query parameters). Nothing is submitted from the site — GitHub still hosts the form and the issue, and the same bot pipeline runs. The wizard just removes the jargon and the form-picking; the zero-infrastructure guarantee is intact.

What if the bot is wrong?

If the bot opens a PR with files in the wrong place or with bad content, a maintainer can either:

• Push commits directly to the contrib/issue-<n> branch to fix it.
• Close the PR and ask you to edit the issue with corrections (the bot will reopen).
• Apply the change manually and close both the issue and PR with a note.

The bot’s job is to remove typing — not to bypass review.