9.1 KiB
Contribution Checklist ✅
Problem Map 3.0 Troubleshooting Atlas
Minimum checklist for community fix contributions
Quick links:
- Back to Templates Hub
- Back to Community Fix Lab
- Back to Official Fixes
- Back to Atlas landing page
- Back to Atlas Hub
- Open Fix Recipe Template
- Open Prompt Template
- Open Colab Template
- Get the Atlas Router TXT
Use this checklist before submitting any contribution to the community fixes layer.
If the Templates Hub helps you choose the right template, this page helps you check whether the contribution is actually ready to submit 📌
The goal is simple:
make contributions easier to review, easier to reuse, and less likely to become chaos
Quick start 🚀
Use this page in the following order:
- scan the Checklist quick map
- do the 30-second self-check
- fix any obvious gaps
- run the full checklist section by section
- make sure the Minimum submit format is complete before submission
If you only do three things first, do these:
- identify the main family
- explain how to use the artifact
- state the expected result
That alone will prevent a lot of weak submissions.
Checklist quick map 🗂️
| Section | What it checks |
|---|---|
| Basic contribution identity | naming, purpose, audience |
| Atlas routing context | family fit, broken invariant, route-first discipline |
| Contribution scope | one clear problem, not a vague dump |
| Artifact clarity | what is included and how to use it |
| Reproducibility | whether someone else can run or inspect it |
| Repair logic quality | whether it supports a real first move |
| Misrepair awareness | whether it warns against a tempting wrong move |
| WFGY bridge discipline | whether deeper exploration stays in the right place |
| File hygiene | filenames, placement, reviewability |
| Writing quality | clarity, explanation, usability |
| Honesty check | limits, incompleteness, non-overclaiming |
| Minimum submit format | the minimum fields a reviewer should be able to find |
30-second self-check ⚡
If you are in a hurry, ask:
- What family is this for?
- What does this artifact actually do?
- How do I run or use it?
- What result should I expect?
- What wrong first move does it help avoid?
If you cannot answer these quickly, the contribution probably needs another pass.
Minimum submit format 📦
Before submitting, make sure your contribution includes at least:
- title
- artifact type
- primary family
- broken invariant
- short problem description
- short usage instructions
- expected output or outcome
- one misrepair warning
- limitations or notes
If these are missing, the contribution is usually too hard to review.
1. Basic contribution identity
- I gave the contribution a clear name.
- I know which folder it belongs in.
- I can explain in one sentence what this contribution does.
- I can explain who this contribution is for.
2. Atlas routing context
- I identified the main related family.
- I identified a secondary family if it is genuinely relevant.
- I can explain why this contribution belongs to that family region.
- I did not skip routing and jump straight into implementation.
Minimum expected routing context usually includes:
- primary family
- secondary family if relevant
- broken invariant
- best current fit or nearest fit
3. Contribution scope
- This contribution solves one clear problem, not five vague ones.
- The scope is small enough to review.
- I did not dump unrelated files together.
- I can explain what this contribution does not cover.
Good scope examples:
- one Colab demo
- one JSON fixture pair
- one prompt pack
- one workflow repair recipe
- one reproduction pack
4. Artifact clarity
- I stated what artifact type this is.
- I included the files needed to use it.
- I gave short usage instructions.
- I described the expected result.
Common artifact types:
- Colab notebook
- JSON input / output fixture
- prompt template
- workflow recipe
- benchmark rerun
- reproduction pack
5. Reproducibility
- I explained how to run or use this contribution.
- I listed any required inputs, dependencies, or assumptions.
- I stated what output or behavior should be expected.
- I noted any parts that are partial, unstable, or still experimental.
A contribution does not need to be perfect, but it should be honest.
6. Repair logic quality
- I explained what first repair move this contribution supports.
- I avoided pretending this is a universal solution.
- I did not confuse deeper WFGY exploration with the official first repair move.
- I can explain when this contribution should not be used.
This is important because a useful fix asset should help people avoid wrong first moves, not just generate more output.
7. Misrepair awareness
- I stated at least one common wrong first move to avoid.
- I explained why that wrong move is tempting.
- I kept the contribution aligned with route-first repair discipline.
This helps community assets stay consistent with:
8. WFGY bridge discipline
If the contribution uses WFGY 3.0 or a related deeper pack:
- I explained what the atlas routing was first.
- I explained what the first repair move was first.
- I explained what the deeper WFGY step added.
- I did not present deeper exploration as if routing were optional.
Short version:
- atlas first
- first repair second
- deeper WFGY exploration third
9. File hygiene
- File names are readable.
- The folder placement makes sense.
- The files are not mixed with unrelated junk.
- The contribution can be reviewed without guessing what is important.
Please do not submit giant unstructured dumps.
10. Writing quality
- The contribution is readable.
- The important parts are easy to find.
- I did not write only vague theory without use instructions.
- I did not write only raw implementation without explanation.
The best contributions are practical and legible.
11. Honesty check
- I clearly marked any unstable or incomplete parts.
- I did not exaggerate what this contribution proves.
- I did not imply official status if this is still community work.
- I did not claim universal applicability without evidence.
This project grows better when contributors are strong and honest at the same time.
12. Maintainer review principles
Passing this checklist does not guarantee merge.
Maintainers may still check:
- relevance
- clarity
- duplication
- usefulness
- routing accuracy
- review cost
- long-term maintainability
This checklist is a minimum gate, not the final decision.
Next steps ✨
After this page, most readers continue with:
If you want to return to the broader product surface:
If this checklist helps your workflow, consider:
- starring the WFGY repo
- opening an issue
- submitting one small clean contribution 🌱
One-line version
A good community contribution is small, clear, routed, usable, and honest about limits.
Closing note ✨
The goal of this checklist is not to slow contributors down.
The goal is to help the fix ecosystem grow without turning into a pile of random files.