SubmitSloth：讓 AI 協助整理作業提交清單

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Finishing an assignment and getting it ready to submit are two different jobs.

The first involves solving the problem. The second involves rereading instructions, checking page limits, finding screenshots, renaming files, and wondering whether you put the right version in the ZIP.

I built SubmitSloth to make that second job less tedious.

It is an AI-assisted submission workspace that turns assignment instructions into an editable checklist, checks your completed files, and packages them into an organized ZIP.

You do the assignment. SubmitSloth helps you wrap it up.

The workflow has four stages:

1. Understand the brief: paste or import the instructions and generate a checklist.
2. Gather your files: upload reports, source code, screenshots, and supporting material.
3. Check the details: review structural checks and their evidence.
4. Pack and relax: preview the output paths and download the package.

Students and project teams get to spend less effort on submission preparation without handing over responsibility for their actual work.

One important design decision: “Needs review” is a valid result.

If a requirement says “explain your approach clearly,” the app should not pretend that counting files proves you satisfied it. Requirements that need human judgment remain visible for you to review.

Demo

🦥 Try SubmitSloth live

The interface includes a midnight-blue theme, an animated sloth, drag-and-drop uploads, editable requirements, and a package preview.

For a quick walkthrough:

• Click Try a sample to load an example brief and a hand-written checklist.
• Upload the bundled files from examples/before/ in the repository.
• Run the checks to find a report that exceeds the page limit and a missing screenshot.
• Replace the report with the corrected version from examples/fixed/ and add the third screenshot.
• Recheck, review the remaining human-review items, and download the ZIP.

The sample checklist is explicitly hand-written; it does not pretend to be a live AI response. To try AI extraction, paste your own instructions and choose Build with AI.

I have personally downloaded a ZIP from the hosted application.

The service is hosted on Render. If it is waking up, the first visit may take a little longer.

Code

GitHub repository: https://github.com/Imran-Ghafoor594/submitsloth.git

The repository includes the application source, setup instructions, Docker configuration, automated tests, and synthetic demonstration files.

The application code is released under the MIT License.

How I Built It

SubmitSloth combines an open-weight language model with deterministic Python checks.

The AI integration is configured for openai/gpt-oss-120b through Groq, using an OpenAI-compatible chat-completions endpoint. Its job is to interpret natural-language instructions and propose structured requirements.

Each proposed requirement includes:

• A description.
• A check type.
• The relevant file group.
• A comparison value, when applicable.
• A supporting quote from the original instructions.

Users can edit these suggestions before checking their files. If a source quote is missing or does not match the original instructions, the requirement is downgraded to human review.

The model does not calculate PDF page counts or decide whether a ZIP contains enough screenshots. Those checks belong to ordinary code.

The supplied Dockerfile installs Tesseract on the server, so image instruction OCR does not require visitors to install it on their computers.

The checking engine supports file presence, PDF page limits, minimum file counts, literal text matches, and exact original filenames. Results include evidence rather than just a green tick.

For example:

report.pdf: 3 pages, against a limit of 2.

That is a narrow, observable claim. It does not imply the report is academically correct.

ZIP export preserves the uploaded file contents and includes a review manifest. Failed checks and unresolved review items require acknowledgment before export.

During development, the original 16 workflow tests passed. Three additional mocked tests checked provider error reporting and request construction. The bundled before-and-after scenario also verified structural failures, corrected inputs, and preservation of the exported report’s bytes.

Those tests validate application behavior—not the language model’s extraction accuracy. That still needs evaluation against representative briefs.

Why Does Open Innovation Matter?

Assignment instructions are messy. Different teachers describe similar requirements in different ways, and a fixed form cannot capture every variation.

An open-weight model provides a flexible way to interpret those instructions while leaving the measurable checks transparent and inspectable.

The important benefit is control over the inference setup.

The hosted demo uses Groq, but the application exposes the provider URL and model identifier through configuration. A compatible local server can also be configured separately, allowing someone with suitable hardware to run an open-weight model on their own machine.

A closed API could perform the extraction task too. What open weights add is the option to self-host and experiment with the model itself, instead of being limited to a provider’s hosted endpoint.

The application’s prompt, schema validation, and checking rules are also visible in the repository. Contributors can inspect how an instruction becomes a check and improve the parts that fail.

There are trade-offs: local inference needs hardware, hosted inference can have usage costs, and model output still needs review. Open innovation makes those choices more flexible; it does not make them disappear.

For privacy, the app sends instruction text to the configured model only after consent. Assignment file contents are processed by the application server and are not sent to the model by this implementation.

The Lazy Payoff

The payoff is having fewer small things to keep track of after the main work is finished.

Instead of repeatedly switching between the assignment brief, a PDF viewer, and a folder of files, I can bring the requirements and deliverables into one workspace, inspect the issues, and export a package.

I used the hosted application to download a ZIP myself. I have not measured a reliable time-saving percentage, so I will not claim one.

What the app already automates is concrete:

• Counting PDF pages.
• Checking whether expected file groups are present.
• Counting files assigned as screenshots.
• Looking for explicitly required text.
• Applying the chosen folder structure and filenames during export.
• Recording the check results alongside the package.

The user still reviews ambiguous requirements and submits the final work.

That is my interpretation of Slow and Steady: let software handle the repetitive preparation, and keep human attention on the decisions that actually need it.

Prize Categories

Best Use of Render

SubmitSloth is hosted as a Docker web service on Render. The service delivers the interface and runs the Flask backend for file inspection, optional image instruction OCR, AI API requests, and ZIP generation.

The model inference is hosted through Groq; Render runs the application that connects the workflow.

Less scramble. More slow. 🦥