S.P.A.R.K. with AI — Development Dialog

Building the APCS Java Dojo

Sessions 1–3: Concept → Movie Hook → Home Page & Chat Log
How “Wax On, Wax Off” became TNT’s Java muscle-memory venue — and what every prompt can teach you

About This Chat Log — Read This First

This is the development diary for the APCS Java Dojo — TNT’s dedicated venue for AP Computer Science A Java fundamentals, built around the Karate Kid “wax on, wax off” principle: reflexive knowledge requires deliberate repetition, not casual reading.

Every session follows the S.P.A.R.K. method: Set goal → Prompt thoughtfully → Analyze the response → Refine → Know & Share. But this log adds one layer you won’t find in most development diaries: every prompt is critiqued using the C.R.A.F.T. rubric — five dimensions of prompt quality, each scored and explained so you can write better prompts yourself.

C.R.A.F.T. in one line: Context • Role • Action • Format • Target — five elements that separate a prompt that gets a vague answer from one that gets exactly what you need.

Look for the blue critique boxes — they are the teaching moments. The amber decision boxes record what was formally decided and why.

Sessions 1–3: Concept & First Builds — Venue concept and 7 theme ideas (A−), movie clip hook page and hero image (A), home page + styles + chatlog (A). Three sessions, four HTML files, two CSS files, two images, one markdown planning document, and a Java review venue that now has its scaffolding ready.

S.P.A.R.K. in This Project — The Big Picture

The APCS Dojo development is a live demonstration of the S.P.A.R.K. method at the project scale — not just the prompt scale. Here’s how the five phases map to what actually happened:

S — Set Goals: Session 1 is pure goal-setting. TTG didn’t ask for code — he asked for ideas, context, and a tracking document. The goal: a Java review venue with a compelling theme and movie clip hook. That goal shaped every subsequent decision.
P — Prompt: Each session is a prompt iteration. Session 1 established direction; Session 2 built the first artifact; Session 3 expanded the ecosystem. Notice that each prompt is more specific than the last — a sign of a maturing AI collaborator.
A — Analyze: The markdown file apcsPrepReviewIdeas.md is TTG’s analysis artifact — a running record of decisions, completed work, and next steps. This chatlog extends that analysis into a teaching artifact.
R — Refine: The venue is iterative by design. The Arrays kata page doesn’t exist yet; it will be built, reviewed, and refined. The placeholder cards on the home page are not failure — they are a roadmap.
K — Know & Share: This chatlog is the K phase. The prompts, decisions, critiques, and reasoning are documented here so students can learn not just what was built, but how and why — and what they would do differently.

Session 1 — 2026-11-11 — 08:34

The Prompt

TTG (TechToolsGuru)

You are a web developer, co-creator at TNT and an exceptional computer science teacher who teaches competitive APCS-A in Java. I’ve provided you an overview and snapshot of TNT for reference, as well as some older ‘legacy’ pages I’ve used in my Java classes to help students learn and review the essentials of Java. I’d like to create a venue in our current TNT ecosystem devoted to topical summaries of the keynote issues in Java. In the past, I’ve had ‘ToolTime’ and ‘CrossTraining’ venues that had ‘hooks’ and themes to add whimsy to topics that can be pretty dry. I’m looking for some ideas I can use to form the central theme for this APCS-A prep and review genre. As you know, I often start with a motivational movie clip to introduce such venues. I’m looking for your top 7 ideas I could use for this theming; once we have that in place, we can start revamping the former Java review sheets. Because this is a big endeavor, I’d like to create a markdown file that includes my prompts and your responses so I can give it to you in the future to pick up where we left off. Let’s call that file, apcsPrepReviewIdeas.md. I’m thinking our first task in the review development will be primitive arrays, ArrayLists, the Arrays class, since we are doing that work now. We’ll follow with Strings since they are ubiquitous in CS.

C.R.A.F.T. Prompt Critique — Session 1

A−

A strong opening prompt that sets the stage effectively — especially in the areas of context and action. The deductions come from three areas where more precision would have sharpened the AI’s output immediately.

✅ What worked well:

✅Context (C) — Excellent. Four reference files attached (tntOverview.md, tntSnapshot, java_demos.html, three legacy resource pages). The AI received not just a description of TNT but actual documents to read. This is the highest form of context delivery.

✅Action (A) — Very clear. “Top 7 ideas” is a specific, countable deliverable. The request also names the first development task (arrays/ArrayList) and the second (Strings) — immediate forward planning baked into a concept prompt.

✅Planning ahead. Requesting apcsPrepReviewIdeas.md before any code exists is exactly right. A reference document requested in Session 1 means every future session can be re-grounded without re-explaining the project.

✅Established precedent. Naming ToolTime and CrossTraining as analogs gave the AI a pattern to match, not a blank canvas to fill. “Like X and Y, but for Java review” is more precise than “something engaging.”

✅Discussion before development. The prompt asked for ideas, not a finished page. This is the most underused move in AI collaboration — asking “what should I build?” before “build it.”

⚠️ What could be stronger:

⚠️Role (R) — Implicit, not stated in the prompt. “You are a web developer…” was the first sentence — this is actually good! But it was part of the system context, not an explicit role instruction in the body of the prompt. Making the role explicit (“Respond as both a Java educator and a TNT-style web developer”) gives the AI two lenses to apply simultaneously.

⚠️Format (F) — Assumed, not specified. Seven ideas were requested, but the depth, length, and structure of each idea was left to the AI. A line like “For each idea, provide: a name, a one-sentence tagline, a movie clip suggestion, and a 2–3 sentence rationale” would have produced more consistent output.

⚠️Target (T) — Not stated. What makes a good theme? What’s the quality bar? A line like “Prioritize themes that work for 11th–12th graders, feel authentic to the TNT brand, and have a movie clip with strong pop-culture recognition” would have immediately narrowed the field.

Key lesson: The best prompt in this batch was the implicit one: asking for ideas before asking for code. That instinct is worth more than any formatting fix. Discuss first, build second.

The Response

GitHub Copilot

Read all six attached reference files; created markdownFiles/markdownSpecs/apcsPrepReviewIdeas.md and presented 7 fully developed theme concepts, each with a name, tagline, movie clip hook, central metaphor, concept-to-metaphor mapping, and vibe description:

🚀 Mission Control — Apollo 13 (Failure is not an option). Unique tie to TTG’s rocket scientist background.
⚔️ The Arena — Gladiator (Maximus’ first entrance). Competitive APCS-A energy.
🥋 The Dojo — Karate Kid (Wax on, wax off). Patient mastery through repetition; “Compile. Debug. Repeat.”
🔨 The Forge — Thor / How to Train Your Dragon. Maker culture; raw materials become powerful tools.
🎮 Power-Up Station — Wreck-It Ralph (collecting the medal). Gamified; each concept is a power-up.
🔐 The Vault — Ocean’s Eleven (the full plan revealed). Strategic insiders; Java knowledge is the combination.
🏺 The Expedition — Raiders of the Lost Ark (classroom scene). Teacher/explorer duality; most self-aware option for a teacher-led venue.

Personal recommendation given to Mission Control (authentic TTG tie); Dojo and Expedition noted as close seconds. The markdown file was created with all ideas documented plus TNT convention notes for future sessions.

Decision 1 — Markdown Tracking File Created

apcsPrepReviewIdeas.md was created in markdownFiles/markdownSpecs/ as the planning spine for this venue. Every future session can load it alongside tntOverview.md and tntSnapshot2026-10-20.md to restore full context. This “hand the AI a document and pick up where you left off” pattern is a professional prompting habit worth establishing immediately on any multi-session project.

Session 1 Takeaways for Novice Prompters

Discuss before you build. The single best use of an AI tool before writing code is asking “what should I build, and what are the options?” An AI that only hears “build me X” will build X. An AI that hears “give me options for X and explain the tradeoffs” will help you make a better decision than you would have made alone.
Name the analogs. “Like ToolTime and CrossTraining” gave the AI a pattern immediately. When you have prior work in the same ecosystem, name it. The AI can match a template far better than it can invent one from scratch.
Request the planning document first. Asking for apcsPrepReviewIdeas.md in Session 1 means every future session starts with a shared context document. This is not overhead — it is the investment that makes every future prompt more efficient.

Session 2 — 2026-11-11 — 09:04

The Prompt

TTG (TechToolsGuru)

Let’s go with the APCS-Java Dojo idea. I have a movie clip showing the famous wax-on wax off scene. Let’s create the movie clip ‘hook’ page: waxOnWaxOffMC.html. I’ve attached a sample movie clip for you to model this new one after. The hero image is supplied. Let’s include a summary of the movie and why this scene was so pivotal. I’m wanting novices to buy into the idea that they have to know the essentials of Java ‘cold’ — there needs to be a sort of ‘muscle memory’ in how they respond to the various big ideas in Java. This venue will provide ‘cheat sheets’ and essential elements of the big ideas of Java as often seen (but not necessarily limited to) the APCS-Java subset. I’ve provided some example pages of Java summaries which are like encapsulated ‘wax-on, wax-off’ ideas. (Pardon the pun). This movie clip page will eventually link to our APCSDojoHome.html page when it is created. The icon for the movie clips page is also attached. Here is the movie clip code: [YouTube iframe embed]. Let’s update our markdown file on this progress.

C.R.A.F.T. Prompt Critique — Session 2

A well-focused prompt that provides everything the AI needs to produce a finished, deployable file. The jump from “ideas” to “first artifact” is handled correctly: specific file name, model page attached, assets provided, embed code given. No guesswork required.

✅ What worked well:

✅Context (C) — Excellent. The sample movie clip page (agathaAllAlongMC.html) was attached as a formatting blueprint. The hero image was attached. The icon was attached. The YouTube embed code was provided inline. Four assets, all relevant, all immediately usable. This is model context delivery for a build prompt.

✅Action (A) — Precise. “Create waxOnWaxOffMC.html” names the exact file. “Model this new one after” (attached sample) specifies the approach. “Include a summary… and why this scene was so pivotal” names the content requirements explicitly.

✅Format (F) — Implicit but complete. The attached reference page provided a complete format template. The AI didn’t need to invent the structure — it had a working example to adapt. Using an existing page as a format guide is more powerful than describing a format in words.

✅Forward-looking link. “This movie clip page will eventually link to our APCSDojoHome.html” gave the AI the information it needed to create a placeholder link without being asked to build the destination. The result: a “coming soon” link already in place for Session 3.

✅Continuity requested. “Update our markdown file” ensured the planning document stayed current without a separate session. Building documentation update into every build prompt is a habit worth keeping.

⚠️ What could be stronger:

⚠️Content depth not specified for the connection section. The prompt said to explain “why novices need muscle memory in Java” but didn’t specify how. The AI chose three inline kata tables (the length family, element access, sorting). That was a good call, but specifying “give 3 concrete examples of Java distinctions that need to be reflexive” would have made that choice explicit rather than left to AI judgment.

⚠️Target (T) — Absent. No quality bar stated. What does “done” look like? “Students who read this page should come away convinced that Java muscle memory is real and that the Dojo is the place to build it” would have been a useful target sentence.

Key lesson: The move to “model this after [attached page]” is one of the most efficient format strategies available. A reference page beats a format description every time. If you have a working example, attach it — always.

The Response

GitHub Copilot

Completed the full waxOnWaxOffMC.html movie clip hook page, following the agathaAllAlongMC.html pattern with AP Java blue (#5eb3d6) as the accent color. Files created/modified:

movie_clips/waxOnWaxOffMC.html — full page with three <details> sections and YouTube embed
images/Wax-On.jpg — hero image (Daniel and Miyagi waxing a car)
images/noun_judo_6346431_676767_@128.png — grid icon
movie_clips.html — new grid entry added at top
apcsPrepReviewIdeas.md — Session 2 decisions logged

Page sections: (1) About the Film — full synopsis, Pat Morita’s Oscar nomination, Cobra Kai legacy; (2) The Scene — wax-on chores, Daniel’s frustration, the reveal, two quoted callouts; (3) APCS Dojo Connection — muscle memory argument with three inline kata tables; YouTube embed with AP blue border; “coming soon” link to APCSDojoHome.html in app-link-row.

Decision 2 — Dojo Icon & Grid Entry

The judo figure icon (noun_judo_6346431_676767_@128.png) was placed in root images/ and added as the first entry in the movie_clips.html grid, displacing “Agatha All Along” from the top position. This entry also contains the first live reference to the APCS Dojo on the broader TNT site.

Decision 3 — Three Kata Preview Tables

The APCS Connection section of the movie clip page includes three compact syntax tables (“the length family,” “element access,” and “sorting”) as a preview of what the Dojo kata pages will contain. These tables do double duty: they make the muscle-memory argument concrete on the movie clip page, and they serve as the prototype format for all future kata content.

Session 3 — 2026-11-11 — 09:28

The Prompt

TTG (TechToolsGuru)

I have a folder to house this ecosystem: APCSDojo with sub folders for images, styles, scripts and sourceCode. Let’s create our APCSDojoHome.html with supporting file APCSDojoHomeStyles.css. Let’s begin with a card for the topic of Arrays. I’ve attached a similar home page for other venues I’ve used at TNT so you know the ‘look and feel’ I’m after. We need to use the same hero image as the movie clip on wax on wax off. Also, other venues sport a chatlog for the development. Let’s do that too by creating APCSDojoChatlog.html with an associated styles file: APCSDojoChatlogStyles.css. In the chatlog, include a summary of all the work we’ve done to date (summarize the md file) and include this prompt, and as you have done in other venues, critique and grade my prompts according to our CRAFT mentality for prompting and show how we are using SPARK in our overall development.

C.R.A.F.T. Prompt Critique — Session 3

The most demanding prompt yet — four files, two CSS sheets, one card, one chatlog with embedded meta-requirements (critique and SPARK analysis). It succeeds because each deliverable is named precisely and the format guidance (reference pages attached) covers the most important unknowns. The deductions are minor.

✅ What worked well:

✅Context (C) — Excellent. Four reference files attached: waxOnWaxOffMC.html (the page already built), crossTrainingHome.html, crossTrainingChatlog.html, toolTimeHome.html, toolTimeChatlog.html. The AI had live examples of both home pages and chatlogs in the TNT ecosystem. No format had to be invented; it was all there to read.

✅Action (A) — Highly specific. Four exact file names stated. The Arrays card, the hero image source, the chatlog content requirements — all named. “Same hero image as the movie clip” communicated a reuse decision in six words. “Summarize the md file” gave the chatlog its organizing content source.

✅Meta-requirements embedded. “Critique and grade my prompts according to our CRAFT mentality” and “show how we are using SPARK in our overall development” are meta-deliverables: requirements about the content of a deliverable, not just the deliverable itself. This is advanced prompting — asking the AI to make its reasoning visible inside the artifact it’s building.

✅Folder structure provided. “APCSDojo with sub folders for images, styles, scripts and sourceCode” gave the AI the deployment context before any file was written, preventing path errors.

⚠️ What could be stronger:

⚠️Home page section count not specified. “Begin with a card for the topic of Arrays” defines Kata #1, but the number of placeholder cards, upcoming queue items, and page sections was left to the AI. “Show three kata cards (one active, two placeholder) and a queue of four upcoming topics” would have made those choices explicit.

⚠️Chatlog session count not stated. “Summarize all the work we’ve done to date” is correct but open-ended. “Document all three sessions from today” would have confirmed the AI’s scope assumption rather than leaving it to infer from the markdown file.

⚠️Target (T) — Not stated. What does the home page succeed at doing? “A student who lands on this page should immediately understand what the Dojo is, want to try a kata, and feel the same ‘wax on, wax off’ energy as the movie clip page” would have been a useful target sentence.

Key lesson: Embedding meta-requirements (“critique my prompts according to CRAFT”) inside a build prompt is a powerful pattern. The AI doesn’t just produce an artifact — it produces an artifact that teaches. This is the S.P.A.R.K. K phase built directly into the P phase. That’s a sophisticated prompting move.

The Response

GitHub Copilot

Completed all four deliverables for Session 3. Files created:

APCSDojo/APCSDojoHome.html — full venue home page with navbar, back bar, hero (Wax-On.jpg), What section, Kata Collection (Kata #1 active + 2 placeholders), SPARK resources section, footer
APCSDojo/styles/APCSDojoHomeStyles.css — all page-specific styles: hero, back bar, principle cards, kata entry cards, queue items, SPARK link cards
APCSDojo/APCSDojoChatlog.html — full development chat log with Sessions 1–3, CRAFT critiques, SPARK phase banners, and decision boxes
APCSDojo/styles/APCSDojoChatlogStyles.css — all chatlog-specific styles: bubbles, critique boxes, SPARK banners, session separators

Home page sections: Navbar → Back bar (chatlog link, movie clip link) → Hero (Wax-On.jpg, 62vh, AP blue) → “What is the Dojo?” (7-col text + 5-col principle cards) → “Kata Collection” (dark, 3 cards, queue of 4) → “S.P.A.R.K. & Resources” (5 link cards) → Footer. Kata #1 (Arrays) is active with “Next Build” badge; Strings (#2) and Loops (#3) are placeholder cards. apcsPrepReviewIdeas.md updated with Session 3 work.

Decision 4 — APCSDojoHome Hero Reuses Wax-On.jpg

The same hero image serves both the movie clip page and the Dojo home page. This creates visual continuity: a student who follows the link from the movie clip page arrives at a home page that feels like the same space. Shared assets are a design pattern worth repeating; they reinforce thematic coherence across a multi-page venue.

Decision 5 — Kata Cards: One Active, Two Placeholder, Queue of Four

Showing placeholder cards rather than a single active card communicates scope and direction without overpromising. Students can see what’s coming. The queue of four additional topics (OOP, Inheritance, Conditionals, Recursion) further signals that the Dojo is a growing venue, not a one-shot cheat sheet. Transparency about roadmap builds trust.

What Exists Now — The Dojo Scaffolding After Three Sessions

Movie clip hook page: movie_clips/waxOnWaxOffMC.html — anchors the venue in pop culture and makes the muscle-memory argument
Movie clips grid entry: top of movie_clips.html — Dojo discoverable from the main clip catalog
Venue home page: APCSDojo/APCSDojoHome.html — full scaffolding with Kata #1 card ready
Home page styles: APCSDojo/styles/APCSDojoHomeStyles.css — AP Java blue design system
Development chatlog: APCSDojo/APCSDojoChatlog.html — Sessions 1–3 documented with CRAFT critiques and SPARK analysis
Chatlog styles: APCSDojo/styles/APCSDojoChatlogStyles.css
Planning document: markdownFiles/markdownSpecs/apcsPrepReviewIdeas.md — full session log, decisions, next steps
Images: images/Wax-On.jpg and images/noun_judo_6346431_676767_@128.png

Next build: APCSDojo/arraysKata.html — Kata #1: arrays, ArrayList, and the Arrays class. The kata preview tables already built into the movie clip page serve as the content prototype.

Planned Build Queue

Kata #1 — Primitive Arrays & the Arrays Class Toolkit (arraysKata.html) — String[] args, motel metaphor, traversal, common algorithms, DWR warning on SOP printing, Arrays class as superpower unlock. ThreeStoogesDriver as the star example.
Kata #2 — ArrayList & the Collections Class (arrayListKata.html) — opens with the problem args[] can’t solve; import, generics, wrapper classes, core methods, iteration trap, Collections.sort(). Bridge comparison tables at the bottom. ThreeStoogesDriver as the narrative bridge.
Supplementary — Arrays vs. ArrayList Quick Reference (arraysQuickRef.html) — exam-day cheat sheet only; comparison tables extracted from waxOnWaxOffMC.html. Not a numbered kata; linked from both kata pages.
Kata #3 — Strings (stringsKata.html) — builds on the legacy stringResource.html. The Pinocchio metaphor from the legacy page may be worth preserving.
Kata #4+ — Loops, OOP, Inheritance, Conditionals, Recursion — queued; order TBD based on course calendar.

Session 4 — 2026-11-11 — 10:20

🤔

A — Analyze (Session 4): Blend vs. Separate — A Design Consultation Before building Kata #1, TTG paused to question a design decision made in Session 3. This is S.P.A.R.K. discipline at its best: the A phase deployed as a deliberate gate before the next P phase. The question: should primitive arrays, ArrayLists, and the Arrays class be on one kata page or separate pages? TTG’s original instinct said separate. Session 3 blended them. This session resolves the tension.

The Prompt

TTG (TechToolsGuru)

Before we develop our first ‘kata’ page, I want your design opinion as an experienced computer science teacher and educational psychologist. I had originally thought of having a summary ‘kata’ page just featuring ‘primitive arrays’ (along with a discussion of ‘String[] args’) in the main method. Included with that would be a discussion of how to use ‘superpower’ methods from the Arrays class to make manipulations easier of those primitives. I would have had examples of code and common algorithms we might encounter with dealing with primitives. From there, I would have had a separate page for ArrayLists and their connection to Arrays and Collection classes. You blended all of them. Should we stay with this blend or separate them out? Give me pros and cons and let’s include this prompt and analysis in our chatlog. I have included a previous array resource as well as a recent page where we introduced the idea of command line input with the args ‘motel’ in the context of featuring the three stooges.

C.R.A.F.T. Prompt Critique — Session 4

The standout prompt of the project so far. The role specification is explicit and dual (“experienced computer science teacher and educational psychologist”) — the first time TTG asked the AI to bring a specific disciplinary lens to the analysis. The “before we develop” guardrail is consistent with Session 2 and shows a maturing pattern of holding back implementation until a decision is confirmed.

✅ What worked well:

✅Role (R) — Best in the series. “As an experienced computer science teacher and educational psychologist” invokes two specific disciplinary lenses simultaneously — the practitioner who has seen this confusion in real students, and the researcher who knows the cognitive science behind it. This is the most specific role specification in any of the four prompts and it produced a qualitatively different analysis as a result.

✅Context (C) — Excellent, again. Four reference files attached: the legacy arrayResource.html (original content), ThreeStoogesDriver.java (the bridge program), threeStoogesVibeCodeResults.html (the vibe-code progression showing the args → ArrayList arc), and the markdown planning doc. The AI could see both the content to be organized AND the real program that uses both concepts together.

✅Original design intent provided. TTG described his original plan in enough detail that the AI had a concrete alternative to compare against. “I had originally thought…” followed by a specific description of what each page would contain gave the AI the baseline for a genuine pros/cons analysis, not a strawman.

✅Guardrail: “Before we develop.” Third time this pattern has appeared. It is becoming a TTG prompting signature — a deliberate pause before action. This is exactly what the A in S.P.A.R.K. demands. Students reading this log should notice: the most experienced prompter in the room also uses the most explicit guardrails.

✅Continuity requested: “include this prompt and analysis in our chatlog.” Session 4 marks the fourth consecutive session in which TTG included a documentation request in the prompt. This is now a pattern, not an occasional reminder. The chatlog is treated as a first-class deliverable, not an afterthought.

⚠️ What could be stronger:

⚠️Format (F) — Not specified. “Pros and cons” is a structure, but the depth, length, and form of each point was left to the AI. “Give me a structured table of pros and cons, then a recommendation paragraph, then a proposed architecture” would have produced a more scannable output for a time-pressed teacher.

⚠️Target (T) — Implicit. The desired end state (“a final decision on page architecture before the first kata is built”) was implied but not stated. A line like “end with a clear recommendation I can say yes or no to” would have made the actionable output explicit.

Key lesson: This prompt demonstrates the highest-value use of an AI collaborator: a design consultation before a consequential build decision. Building the wrong architecture and then refactoring it costs far more time than pausing to ask “is this right?” first. The student who learns to ask “before we develop — is this the right design?” will be a better developer than one who asks “why isn’t this working?” six sessions later.

The Response — Design Analysis

GitHub Copilot

Recommendation: Separate — TTG’s original instinct was correct. Here is the core reasoning from both lenses:

From the educational psychologist lens (Cognitive Load Theory, Sweller 1988): Primitive arrays and ArrayLists are genuinely different mental models with different internal representations, different access syntax, different instantiation patterns, and different method vocabularies. Presenting them simultaneously during the learning phase asks students to hold two incompatible paradigms in working memory at the same time. Cognitive Load Theory is unambiguous on this: intrinsic load (the concept complexity) plus extraneous load (the syntax switching) exceeds working memory capacity for most learners. The correct sequence is: master Model A → master Model B → compare them explicitly.

From the CS teacher lens: The AP exam tests them separately. Free-response questions are either array questions or ArrayList questions. Students who drilled them together mix up syntax under pressure — writing list[i] or arr.get(i) — precisely the exam’s most reliable way to forfeit points. The kata is a drill, and a drill should isolate the skill.

String[] args deserves its own section in Kata #1. It is the first array every Java student encounters. It is misunderstood more than any other Java construct (students think it’s just boilerplate). The motel metaphor works perfectly for it — args[0] is Room 0, args[1] is Room 1 — and ThreeStoogesDriver.java is the perfect companion: three named Stooges, three rooms, one fixed-size motel.

The Arrays class as “superpower unlock”: Arrays.sort(), Arrays.toString(), and friends land as revelations only after the student has struggled with raw traversal and the memory-address printing DWR. Present them next to ArrayList methods and they become just more API noise. Present them as the solution to a pain the student just felt, and they become memorable.

The ThreeStoogesDriver becomes the narrative arc, not just an example: In Kata #1, it demonstrates String[] args cold. In Kata #2, it opens with the problem args[] can’t solve: the program needs to grow the cast. The evolution from CODE_1 (three String variables) → CODE_2 (ArrayList that accepts args) in the vibe-code results is the story of why ArrayLists exist.

Decision 6 — Separate: Three Deliverables Where One Was Planned

Kata #1 — Primitive Arrays & the Arrays Class Toolkit (arraysKata.html): Declaration, String[] args with motel metaphor, traversal patterns, common algorithms (min/max, sum, reverse, search), the DWR memory-address warning, Arrays class as superpower unlock (toString, sort, binarySearch, fill, copyOf). ThreeStoogesDriver as central example.

Kata #2 — ArrayList & the Collections Class (arrayListKata.html): Opens with the problem args[] can’t solve. Import, generics, wrapper classes, core methods (add, get, set, remove, size, contains), the remove-while-iterating trap, Collections.sort(). Bridge section at the bottom: comparison tables (.length vs .size(), [] vs .get(), Arrays.sort() vs Collections.sort()). ThreeStoogesDriver as the narrative bridge.

Supplementary — Arrays vs. ArrayList Quick Reference (arraysQuickRef.html): Not a numbered kata. Exam-day comparison tables only, extracted from the movie clip page. Linked from both kata pages. No narrative — just the contrast the student needs 10 minutes before the exam.

Decision 7 — Home Page Kata Cards to Be Updated

The home page Kata #1 card currently reads “Arrays, ArrayList & Arrays Class.” It will be retitled “Primitive Arrays & the Arrays Class Toolkit” and a Kata #2 card for “ArrayList & the Collections Class” will be added. The existing blended description language in the Kata #1 card will be replaced with language specific to primitive arrays and String[] args. This home page update will happen in the next session, after TTG confirms the architecture decision.

Session 4 Takeaways for Novice Prompters & Curriculum Designers

Blended presentations teach comparison. Separated presentations teach mastery. Both have their place. Use separated pages to build the skill from scratch; use blended comparison pages as exam-day references once both skills are independent. Building the reference before the skill is cart-before-horse.
Your original design instinct is data. When you describe what you originally planned and ask the AI to analyze it, you give the AI a baseline to test against. “I had originally thought…” is one of the most underused sentences in AI collaboration. Use it whenever you want genuine analysis rather than confirmation.
The “before we develop” guardrail is worth repeating every time. TTG has used it in Sessions 1, 2, and 4. Each time, it prevented a premature build. The cost of pausing to ask “is this design right?” is a few minutes of conversation. The cost of building the wrong architecture is a session of refactoring. The math is obvious. Use the guardrail.

Session 5 — 2026-11-11 — 10:25

🍰

P — Prompt (Session 5): Confirm Architecture + Add the Bridge Kata A short, decisive follow-up prompt that confirms the Session 4 decision and extends it with a genuinely good idea: a third kata that shows how the first two interact. “Have our cake and eat it too” is an excellent framing — pedagogically, it’s the difference between knowing two kata and knowing when to apply them together.

The Prompt

TTG (TechToolsGuru)

Let’s go with your recommendation and then, what about including a ‘Kata’ where we combine the other two previous ones to show how they all interact? That way we ‘have our cake and eat it too.’

C.R.A.F.T. Prompt Critique — Session 5

B+

A short, well-timed follow-up that does exactly what a decision-confirmation prompt should do: confirms the prior recommendation and immediately adds value with a creative extension. The grade reflects strong instinct and a good idea, with meaningful room for more specificity that would have produced an even sharper result.

✅ What worked well:

✅Decisive confirmation. “Let’s go with your recommendation” is unambiguous. The AI received a clear signal to implement the Session 4 decision rather than continue analyzing it. Many novice prompters get stuck in an analysis loop; TTG moved to action.

✅The cake metaphor is pedagogically astute. “Have our cake and eat it too” is not just a figure of speech here — it correctly identifies the genuine tension between separating concepts for depth and blending them for comparison. TTG perceived the tension from Session 4 and found the right architectural solution: a bridge kata that resolves it without compromising either goal.

✅Appropriate length for a follow-up. This prompt did not need three paragraphs. The context was fully established in Session 4; a short confirmation + extension is the correct form. Knowing when a prompt can be short is as important as knowing when it needs to be long.

✅ThreeStoogesDriver attached. Including the program that is literally the best possible bridge example — a single main that uses both String[] args and ArrayList<String> together — gave the AI concrete evidence that the bridge concept was already written in code TTG owns.

⚠️ What could be stronger:

⚠️Action (A) — The bridge kata’s content was left entirely to the AI. What should the bridge kata cover? Conversion patterns? Side-by-side comparison tables? A decision guide? Real algorithm challenges using both? A line like “the bridge kata should cover conversion between the two, side-by-side syntax comparison, and ThreeStoogesDriver as the central example” would have produced a more precise content plan immediately.

⚠️No file name supplied. Sessions 2 and 3 both named their target files explicitly. This prompt did not name the bridge kata’s file (arraysBridgeKata.html). Small detail, but naming the file locks the decision and prevents any ambiguity about where the deliverable lives.

⚠️No chatlog update requested. Every previous session included an explicit request to update the chatlog or markdown. This session omitted it. The documentation update was done anyway, but explicitly requesting it maintains the habit and ensures it’s never accidentally dropped.

Key lesson: Short prompts are powerful for confirmations and extensions — but even a short prompt benefits from naming the file and including a documentation request. Those two habits cost one sentence each and they close the loop on every session. The B+ acknowledges the excellent instinct at the cost of the specificity gaps a more experienced prompter would have closed automatically.

The Response

GitHub Copilot

Architecture confirmed and extended. The three-kata cluster for arrays/ArrayList now has a complete narrative arc:

Kata #1 — Primitive Arrays & the Arrays Class Toolkit (arraysKata.html): Learn the fixed-size motel cold. String[] args, traversal, algorithms, the DWR memory-address warning, Arrays class as superpower unlock.
Kata #2 — ArrayList & the Collections Class (arrayListKata.html): Learn the expandable hotel cold. Import, generics, wrapper classes, core methods, the remove-while-iterating trap, Collections.sort().
Kata #3 — The Bridge: Arrays ↔ ArrayList in Action (arraysBridgeKata.html): ThreeStoogesDriver as the central program — a single main using String[] args (Kata #1) feeding into ArrayList<String> (Kata #2). Conversion patterns (Arrays.asList(), toArray()), side-by-side comparison tables, decision guide for choosing which structure.

Home page updated: Kata #1 card retitled; Kata #2 card changed from “Strings” to “ArrayList” with hotel metaphor; Kata #3 card changed from “Loops” to “The Bridge” with 🌉 emoji. Queue updated: Strings (#4), Loops (#5), Classes & OOP (#6), Inheritance (#7).

Decision 8 — The Three-Kata Cluster Architecture is Final

The arrays/ArrayList coverage is now three kata pages, not one. Each has a distinct pedagogical role: Kata #1 builds reflexive knowledge of primitive arrays; Kata #2 builds reflexive knowledge of ArrayList; Kata #3 shows them in dialogue. This is the learn separately, then apply together pattern from cognitive science — isolation of skills followed by integration, not simultaneous introduction.

ThreeStoogesDriver.java is the bridge program for the entire cluster. It appears in Kata #1 (demonstrating String[] args), provides motivation in Kata #2 (the problem args[] can’t solve), and is the central example in Kata #3 (showing both in one real program). One program, three teaching moments.

Session 5 Takeaways for Curriculum Designers

The “isolation then integration” pattern is a curriculum design principle. Sports coaches use it: practice the serve separately from the rally; then play a game that uses both. Music teachers use it: scales first, then the piece. The three-kata cluster makes this principle explicit in a Java curriculum.
A “bridge” artifact is not a summary — it’s a new teaching artifact. The bridge kata is not “Kata #1 and Kata #2 combined.” It is a new context that couldn’t exist without both predecessors. The ThreeStoogesDriver makes this concrete: the program is incomprehensible without understanding both the fixed array and the dynamic list.
Short prompts can produce major architectural decisions. Session 5 was three sentences. It changed the kata count from one to three and established the entire data-structures sequence for the Dojo. The length of a prompt is not correlated with its impact — the quality of the idea is.

Session 6 — 2026-11-11 — 10:30

The Prompt

TTG (TechToolsGuru)

Let’s build arraysKata.html and its associate arraysKataStyles.css. I teach my students that arrays are like ‘old-time-y’ ‘motels’ from the 60s and 70s and I have a picture I will supply of a ‘Java Motel’. I like the metaphor of a motel: no frills, set number of rooms, a bit shabby but lets us ‘check people in.’

C.R.A.F.T. Prompt Critique — Session 6

B+

A clean build prompt that delivers the metaphor content the AI needs and correctly handles the missing hero image with “I will supply.” The grade reflects strong instinct and metaphor richness, with room to add specificity about content scope.

✅ What worked well:

✅Metaphor described with flavor. “No frills, set number of rooms, a bit shabby but lets us check people in” is vivid enough for the AI to build the metaphor section with authentic voice. The specific character details (“60s and 70s,” “shabby”) produce better content than “use a motel metaphor.”

✅Image handled correctly. “I have a picture I will supply” told the AI to build with a placeholder path (../images/javaMotel.jpg) and use a CSS fallback color. The motel icon from the legacy folder was pulled as an interim asset. The page works immediately and improves automatically when the image is added.

✅File names stated. arraysKata.html and arraysKataStyles.css named explicitly. No ambiguity.

✅Planning work paid off. Sessions 4 and 5 had already established the exact content scope: String[] args, motel metaphor, traversal, algorithms, DWR warning, Arrays class. The build prompt could be short because the planning was thorough. This is S.P.A.R.K. working as designed — set goals early, build fast later.

⚠️ What could be stronger:

⚠️No section order specified. The sequence of sections (motel metaphor → declaration → args → traversal → algorithms → DWR → Arrays class) was inferred from Sessions 4–5 planning. Explicitly stating “sections in this order” would have locked the outline and prevented any reordering.

⚠️No chatlog update requested. Fourth session in a row where the documentation request was omitted. The update was done anyway, but the habit is slipping. For large build prompts especially, explicitly requesting “add Session X to the chatlog” prevents the documentation from falling behind the build.

⚠️Target (T) — not stated. What does a successful kata page accomplish? “A student who closes this page and writes the Quick Reference from memory should have everything they need for the AP exam” is a useful target sentence that would have confirmed the exam-day Quick Reference table was a required deliverable.

Key lesson: As a project matures and planning sessions accumulate, build prompts can get shorter — because the planning has pre-answered most questions. This is not laziness; it is efficiency. The B+ reflects that the prompt was appropriately compact for this stage while missing two habits (chatlog request, explicit target) that cost nothing to include.

The Response

GitHub Copilot

Built APCSDojo/arraysKata.html and APCSDojo/styles/arraysKataStyles.css. Also copied the legacy motel icon (noun-motel-4219007-08A3BD_tbg.png) to APCSDojo/images/ as an interim hero asset while the user-supplied Java Motel photograph is pending (../images/javaMotel.jpg path ready).

Page structure: Navbar → Back bar → Hero (motel image placeholder, AP Java blue) → Overview section with AP Exam Fast Facts card and quick-nav pills + Expand All toggle → 7-section Bootstrap accordion → 16-row Quick Reference table (dark background) → Kata navigation (← Dojo Home | Kata #2 →) → Footer.

Accordion sections:

🏨 The Motel Metaphor — conceptual framing with ASCII room diagram and off-by-one DWR
📝 Declaring & Building Arrays — three construction forms; default values table
🚗 String[] args — command-line motel visual; ThreeStoogesDriver guard pattern
🔄 Traversal — indexed for vs. enhanced for; when to use each
🧮 Common Algorithms — max/min, sum/average, count, fill, reverse
⚠️ DWR Warning — println(arr) memory address trap; char[] exception
⚡ Arrays Class Toolkit — full method table (8 methods) + live examples

Quick Reference table: 16 rows covering declare, size, access, loops, print, sort, search, fill, copy, compare, import — every row an exam-day essential. Home page Kata #1 card updated to “✅ Available” status.

Decision 9 — Motel Image: Placeholder Path Ready

The hero image is referenced at ../images/javaMotel.jpg. A CSS fallback color (background-color: #0a1a2a) keeps the hero functional until the photograph is added. The existing legacy motel icon (noun-motel-4219007-08A3BD_tbg.png) is copied to APCSDojo/images/ and displayed in the hero as an interim visual. No page changes are required when the photograph is added — just drop javaMotel.jpg into the root images/ folder.

What Exists Now After Session 6

Kata #1 — COMPLETE: APCSDojo/arraysKata.html + arraysKataStyles.css
Home page updated: Kata #1 card shows “✅ Available”
Pending: User to add images/javaMotel.jpg for the hero photograph
Next build: Kata #2 — ArrayList & the Collections Class (arrayListKata.html)

Session 7 — 2026-11-11 — 11:57

🥋

R — Refine (Session 7): Define the Kata Before the Student Clicks It A sharp UX observation: the word “kata” appears on every card, in the section header, and in the page titles — but never explained on the home page. A student who has never heard the word could mistake it for a Japanese app name or a typo. This session adds a whimsical working definition as a styled explainer callout, turning a potential confusion point into a teaching moment.

The Prompt

TTG (TechToolsGuru)

A ‘Kata’ is a new idea to me, it is likely to be new to my novices. Can you frame the idea whimsically into the home page with a working definition so when a user sees ‘arrayKata’ they know instantly what you’re talking about?

C.R.A.F.T. Prompt Critique — Session 7

A−

An excellent, honest self-assessment prompt: “This is new to me, it is likely new to my novices” is the kind of pedagogical self-awareness that produces great curriculum decisions. The target criterion — “when a user sees ‘arrayKata’ they know instantly” — is one of the strongest target sentences in this project.

✅ What worked well:

✅Target (T) — Best in the series. “When a user sees ‘arrayKata’ they know instantly what you’re talking about” is a measurable success criterion. The word “instantly” communicates that the definition must be short and in the right position, not buried three scrolls down. Specific targets produce specific, testable results.

✅Honest audience modeling. “New to me, likely new to my novices” is pedagogically astute — and rare. Many prompt writers assume their audience shares their context. TTG explicitly flagged the assumption gap, which prevented the AI from treating “kata” as familiar vocabulary and underselling the explanation.

✅Quality constraint: “whimsically.” This is a tone instruction, not just a format instruction. It shaped the voice of the explainer away from a dry dictionary entry toward the Dojo’s actual personality. “Whimsically” in a prompt costs one word and changes the entire character of the output.

✅Four reference files attached. Including the home page (the target file), the chatlog, the kata page (to understand what a kata actually contains), and the legacy arrayResource.html (original content) gave the AI all the context needed to write a definition that accurately describes the Dojo’s specific implementation of the kata concept.

⚠️ What could be stronger:

⚠️Placement not specified. “Frame it into the home page” left placement to the AI. The explainer ended up between the section heading and the kata cards — arguably the best location — but the prompter who says “add it between the kata section heading and the first kata card” never risks a misplaced definition.

⚠️No chatlog update requested. Fifth consecutive session without an explicit documentation request. The pattern of building in “add Session X to the chatlog” has drifted. The habit matters most precisely when the session produces a small-but-important change — because those are the changes most likely to be forgotten.

Key lesson: Audience modeling is a prompting superpower. When you explicitly tell the AI who the audience is and what they don’t know, you shift the register of the entire output. “This is new to me, likely new to my novices” is seven words that prevented a jargon-laden explanation from ever being drafted. Use it every time you are writing for an audience that doesn’t share your vocabulary.

The Response

GitHub Copilot

Added a styled kata explainer callout to the #dojoKata section of APCSDojoHome.html, sitting between the section heading and the first kata card. Changes made:

Section label updated: “The Kata” → “The Kata (型)” — kanji appears inline to introduce the concept immediately
Subtitle updated with gentle invitation: “New to the idea? ↓”
Kata explainer callout added: styled card with the 型 kanji as a large decorative element, whimsical definition (90-second version), and three clearly labeled modes (Learn it → Review it → Complete it)
APCSDojoHomeStyles.css: 11 new CSS rules for the explainer, kanji, three-mode layout, and italic punchline

The three kata modes (📖 Learn it / 🧪 Review it / 🥋 Complete it) are the key addition — they tell students not just what a kata is but how to actually use one. A student who reads this before clicking Kata #1 arrives on the kata page already knowing the three-pass study strategy.

Decision 10 — The Three-Mode Kata Protocol

The explainer formalizes three distinct ways to engage with a kata page: (1) Learn — first exposure, accordion open; (2) Review — Quick Reference table, self-test mode; (3) Complete — close the page, write from memory. This three-pass model is now the official study protocol for the Dojo and should be referenced in future kata pages, the chatlog, and any student-facing orientation materials. It maps directly to the cognitive science principle of spaced retrieval practice.

Session 8 — 2026-11-11 — 12:59

🌐

A — Analyze (Session 8): Where Does the Dojo Live in the TNT Ecosystem? After seven sessions building the venue, TTG pauses to ask where it belongs in the broader site. This is exactly the right instinct at exactly the right moment — before promoting it, understand what it deserves to be. The analysis revealed a genuine gap: not one of TNT’s ten Popular Destinations cards serves AP Java students. That gap is now closed.

The Prompt

TTG (TechToolsGuru)

Originally, I was going to feature this APCSDojo subdomain in our resources page, but I’m now thinking it should be more prominent, and be featured on our index page as one of our ‘Popular Destinations.’ Every year I have multiple novices learning Java, and since this is a web-based venue, I’ve not always had a lot to offer them, until now, when we can copy code and then test it at places like JDoodle. That said, what are the pros and cons of offering a APCSDojo card on the home page (and also in resources) or, just offering it in a lower profile place like resources. Let’s discuss this in our chatlog and then make a final determination.

C.R.A.F.T. Prompt Critique — Session 8

A−

An excellent discussion prompt that arrives with new context (the JDoodle angle), states both options explicitly, specifies the format (chatlog), and sets a clear outcome target (final determination). The weaknesses are minor.

✅ What worked well:

✅New evidence provided. The JDoodle / web-native angle was not in any prior session. “Since this is a web-based venue, I’ve not always had a lot to offer [Java students], until now” is the pivotal argument for home page placement — and it’s real, specific, and persuasive. Surface new evidence when you have it; it changes the analysis.

✅Original plan stated. “Originally, I was going to feature this in resources” gave the AI a baseline to test against. The AI had two concrete options to compare, not an open-ended design question.

✅Format specified: chatlog. Fifth time TTG has specified a format in this series. The documentation habit is strong.

✅Target specified: “final determination.” The session should end with a decision and an implementation, not an open analysis. This is a prompt that knows its own end state.

⚠️ What could be stronger:

⚠️Binary framing missed a third option. “Home page + resources” vs. “resources only” — the prompt framed this as two choices but left the door open with “and also in resources.” The AI correctly identified both as simultaneously valid (not mutually exclusive), but a prompt that says “options include: home only, resources only, or both” would have made the third option explicit.

⚠️No gut direction shared. TTG was clearly leaning toward home page (“I’m now thinking it should be more prominent”). Sharing that lean — “I’m inclined toward home page; push back if you see problems” — makes the AI a better counterweight. An AI that knows you’re leaning one way can deliberately look for the opposing arguments. Without that signal, it has to guess your priors.

Key lesson: Surface new evidence when the landscape changes. The JDoodle / web-native Java argument was the strongest card in the hand and was held until this session. If TTG had mentioned it in Session 1 when the venue concept was first discussed, the home page target might have been baked in from the start. When you have new evidence that changes the case, say it explicitly — don’t assume the AI has figured it out.

The Analysis

GitHub Copilot

Finding from examining index.html and resources.html: The home page currently has 10 Popular Destinations cards (Ask Copilot, Image Gallery, Adventures, Creative Cross Training, Cross Training, SketchWave, Tool Time, See the Code, SPARK Speeches, Legacy Archive). Of these, not one is AP-Java-specific. Foundation students have SketchWave and Creative Cross Training. Innovations students have See the Code. AP Developer Studio — Course 03, the summit of the three-course sequence — has zero dedicated home page representation.

Determination: Both — with home page as primary.

Strongest argument for home page: The JDoodle / web-native Java argument is genuinely new and genuinely strong. Prior Java resources were IDE-locked — useless without an installation, limiting classroom utility to students who had already set up their development environment. Kata pages with copy-to-JDoodle make them usable on any device in any classroom without installing anything. That is a capability worth headlining. The AP Java course runs all year. The home page serves students 12 months a year. The “half-built” concern is solved by the established badge pattern (“🥋 Kata #1 Live!” in AP Java blue) — identical to how Adventures says “🗺️ Live!” while still building.

Resources concern: The res-tnt accordion section holds utilities (DWR, Gallery, Code Word Collector) and archives (Past Blasts). The Dojo is a fully-developed teaching venue — it belongs there as a secondary discovery path, not as the primary home.

Decision 11 — APCS Java Dojo Added to Popular Destinations (index.html)

Feature card added after Tool Time: AI Edition in the Popular Destinations grid. Background: images/Wax-On.jpg (consistent with the venue’s hero image). Badge: 🥋 Kata #1 Live! in AP Java blue (#1a5c8a). Description acknowledges the growing nature of the venue. This is the first AP-Java-specific card on the TNT home page in the site’s history since 2015.

Decision 12 — APCS Java Dojo Added to Resources (TNT’s Own Resources)

Resource card added as the first entry in the res-tnt accordion section of resources.html. AP Java blue icon (fas fa-hand-fist). Description explicitly mentions JDoodle and the web-native use case — the strongest selling point for this audience. Students who arrive at resources looking specifically for AP Java reference material will find it at the top of the TNT-built resources section.

Session 8 Takeaways for Novice Prompters

Surface new evidence the moment it changes the analysis. The JDoodle / web-native argument was the decisive factor in this session. It wasn’t present in Sessions 1–7. When something changes the case, say it immediately in the prompt body — don’t assume the AI already knows.
Resources ≠ home for first-party venues. Resources pages are designed for curated external links and utility tools. A fully developed teaching venue with its own home page, kata pages, chatlog, and hero image is a first-class site citizen — it deserves a first-class discovery path.
The “half-built” concern has a TNT-native solution. The badge pattern (“Live!”, “On the Air”, “Growing!”) already exists on the home page for exactly this purpose. Never let incomplete state prevent a launch — label it honestly and let the audience self-select.