Plan a twelve-week after-school coding curriculum for elementary students using Scratch

## Role and objective

You are an elementary computing-education designer. Create a twelve-week after-school curriculum that teaches elementary students to code with Scratch. Produce a practical plan that an educator can deliver, including observable learning objectives, activities, timing, materials, assessment items, differentiation, and post-lesson checks. Treat the student age or grade range, meeting frequency, session length, class size, device access, and prior experience as confirmed values only when supplied; otherwise use the corresponding slots below.

The deliverable is complete only when all twelve weeks have a coherent progression, every session has an actionable plan, and each objective can be checked through student work or observable performance.

## Scope and given facts

**Confirmed facts**
- The setting is an after-school program.
- The learners are elementary students.
- The tool is Scratch.
- The curriculum lasts twelve weeks.
- The requested subject is coding.

**In scope**
- Computational thinking and beginner programming concepts taught through Scratch.
- Projects, guided practice, independent practice, reflection, assessment, and differentiation.
- Classroom-ready sequencing from introductory work to a final student-created project.

**Out of scope**
- Advanced programming beyond what the stated learners can reasonably use.
- Coding in another platform or language.
- Claims about student outcomes not supported by supplied evidence.
- A fixed schedule, age band, class size, device ratio, or assessment policy unless provided.

Use these slots when needed:
- `[FILL IN: student age or grade range]` — enter the participating elementary grades.
- `[FILL IN: session length and meetings per week]` — enter the duration and frequency.
- `[FILL IN: prior Scratch experience, class size, and available devices]` — enter the classroom conditions.

Do not arbitrarily fill the curriculum's student age, session length, number of meetings, class size, or device availability.

## Working rules

1. Build a progression in which each week prepares students for later work. Introduce concepts through concrete Scratch actions before expecting independent design.
2. Use observable objectives with verbs such as create, sequence, modify, test, debug, explain, compare, and demonstrate. Do not use “understand” as the sole objective.
3. Cover age-appropriate foundations, including sequences, events, sprites and backdrops, motion, looks, sound, control flow, repetition, conditionals, sensing, variables or data, debugging, and project design. If a concept would exceed the supplied learner level, either simplify it or label it `[OPTIONAL: concept]` with a condition.
4. For each activity, state what students do in Scratch, what the educator models, what students produce, and how success is observed.
5. If the session length is unknown, use `[FILL IN: minutes]` for timing rather than inventing a duration. If the class has mixed experience, provide beginner support and an extension only when it can be completed with the available Scratch features.
6. Include accessibility and participation supports suited to the supplied learner profile. Do not diagnose disabilities or assume individual needs; offer adaptable choices such as visual instructions, pair programming, verbal explanation, and keyboard or mouse alternatives.
7. Assess process as well as product: planning, sequencing, testing, debugging, explanation, and revision. Provide answers and rationales for any quiz or worksheet items.
8. Because this is an education-design request, identify any standards framework only as a named slot—`[FILL IN: applicable standards framework]`—unless the user supplies one. Do not invent standards codes or requirements.
9. For copyrighted material, use original Scratch prompts or educator-created assets. If external music, images, or text are needed, leave `[FILL IN: source-clearance plan]` and do not paste protected passages.
10. Use US grade-level phrasing only if the audience is in the United States; otherwise leave `[FILL IN: target education system]`.

## Output structure

Produce the curriculum in the following order:

1. **Program overview** — State the learner profile, assumptions and slots, overall goals, prerequisites, Scratch setup, and the twelve-week progression in a short table.
2. **Week-by-week plan** — Provide exactly twelve numbered week entries. For each week include:
   - theme and rationale;
   - observable objectives;
   - session sequence with activity names and `[FILL IN: minutes]` where timing is unknown;
   - educator modelling;
   - student practice and Scratch artifact;
   - formative assessment;
   - differentiation or extension;
   - required materials.
3. **Final project pathway** — Explain proposal, planning, build, playtesting, debugging, revision, presentation, and reflection. If the number of final sessions is uncertain, mark it `[FILL IN: final-project session allocation]`.
4. **Assessment plan** — Give a rubric with criteria for coding concepts, functionality, debugging, creativity, explanation, and revision. State performance levels without inventing numerical weights.
5. **Materials and preparation** — List devices, Scratch accounts or access method, handouts, starter files, accessibility supports, and source-clearance items as confirmed values or slots.
6. **Post-lesson checks** — Provide educator prompts for reviewing learning, participation, technical problems, and changes needed before the next week.

## Style rules

Use a hybrid style. Present the twelve-week schedule, objectives, checklists, rubrics, materials, and assessments in itemized tables or numbered lists. Use concise narrative paragraphs only for the progression rationale, differentiation guidance, final-project explanation, and assessment interpretation. Keep the register encouraging and educator-facing, while using language elementary students could recognize. Avoid empty clichés such as “make learning fun,” “unlock creativity,” and “the sky’s the limit”; replace them with a specific student action or observable result.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable is a Scratch curriculum for elementary students in an after-school setting and covers exactly twelve weeks.
2. Check that every week has objectives, activities, Scratch work, assessment, differentiation, and materials.
3. Verify that objectives use observable actions and that each can be checked through student work, explanation, demonstration, or debugging.
4. Confirm that the sequence progresses from introductory Scratch actions toward a final project rather than repeating disconnected activities.
5. Check that session timing, student age or grade, class conditions, standards framework, and other unknowns remain slots unless supplied.
6. Identify any facts added beyond the input, especially invented ages, meeting schedules, class sizes, device counts, outcomes, standards codes, or assessment weights; remove them or mark them as slots.
7. Identify every arbitrarily filled slot, including `[FILL IN: student age or grade range]` and `[FILL IN: session length and meetings per week]`; replace unsupported values with the required slot.
8. Confirm that the plan does not drift into another programming platform, advanced curriculum, unrelated theory, or a general school-day course.
9. Check that assessment items include answers, explanations, and distractor rationales whenever quizzes or worksheets are included.
10. Check that external assets are not presented as cleared and that source-clearance needs remain explicit.
11. Confirm that the required hybrid style is visible: planning information is itemized, while rationale and guidance use concise narrative.
12. Confirm that the final output follows the specified section order and contains no unrequested curriculum type, invented evidence, or missing week.