DEV Community: norinori1

6 UI/UX Techniques from ZINTOROAD

norinori1 — Mon, 13 Apr 2026 13:23:28 +0000

Excerpting my own article from the jack blog.

Hey there, I’m norinori1, jack’s ghost.

Today I’d like to share some of my own UI/UX design techniques and advice for game development, based on my experience developing “ZINTOROAD,” a game I brought to beta this year.

For more about “ZINTOROAD,” check here (I entered it into “Game Creator Koshien”) ↓

ZINTOROAD (Minna no Game Parade)

You might get a better understanding by viewing the “Work Introduction PDF” from there.

From here, I’ll talk about the improvements I made based on alpha and beta survey results for ZINTOROAD, and the UI/UX techniques I learned from them.

First, let me express my gratitude to everyone who played the ZINTOROAD alpha and beta versions, and to everyone who participated in the surveys.

(a) Title Screen

Alpha version → Beta version

In the alpha version, the game would only advance to the next scene by holding down Z — clicking “▶ Start” with the mouse actually did nothing.

(This happened due to a misconfiguration in Unity’s PlayerPrefs. Even with a button component on the Start button, it wouldn’t respond. For anyone hitting this in Unity 6.0: fix it by setting the UI action map in EventSystem’s “Action Asset” — copy the UI map from the default InputSystem_Actions.)

This was flagged by quite a few survey respondents, so I updated it so clicking the start UI also starts the game.

Takeaway: UI should match the behavior users naturally expect.

Also in the beta: pressing [Esc] on the title screen now shows a confirmation dialog with an “Exit” button. Always give players a way to quit from within the game itself.

(b) Play Screen

Alpha version → Beta version

Feedback from surveys and friends on the alpha:

“Why is Pause mapped to ‘C’? (Shouldn’t it be ‘Esc’?)”
“Clicking the Pause UI doesn’t do anything”
“There’s an HP bar in the bottom-right but I never look there during gameplay”
“I can’t tell how many anchors are on the board” Points 1 and 2 come back to the same principle from (a): follow control conventions players already know from other games.

(Pause ended up on ‘C’ because two scripts were handling key input simultaneously and ‘Esc’ caused conflicts. Fixed in beta.)

For point 3: I discovered that during gameplay, players’ eyes stay near the object they’re controlling. The bottom-right HP gauge was basically invisible to them — they’d take damage without noticing and suddenly hit Game Over.

Fix: moved the HP gauge and AP gauge (as a percentage of max) to the center of the screen. Players can now register damage immediately from the visual.

Point 4 was similar. The game has a “Destroyer” enemy that specifically targets anchors — so anchors can disappear without warning, leaving players confused why their triangle preview disappeared.

Fix: added a UI indicator next to the anchor placement display showing how many anchors on the board can currently form a triangle.

Takeaway: Show all information that matters to the player, and position the most critical elements where their eyes actually go.

(c) Boost Selection Screen

Alpha version → Beta version

After defeating enough enemies, the game levels you up and lets you pick a “boost” — a special ability (think the level-up screen in Vampire Survivors).

In the alpha, selecting a boost required holding down Z. Survey respondents found this confusing.

(Happened because I lazily reused the anchor-placement code.)

In the beta: single press of Z, plus mouse click support added.

On fonts: the alpha used a blocky, angular typeface called “Makinas” to match the game’s aesthetic. Surveys said it was hard to read, so I switched to “Smart Font UI.”

Takeaway: For any UI that explains or instructs, legibility beats style.

Third issue: the ◀▶ arrows in the input guide UI (bottom-left “Select” / “Determine” indicators) looked like they applied to both labels, which confused players. I fixed this by boxing each operation’s controls separately.

Takeaway: Enclose or clearly space UI groups so it’s unambiguous what belongs to what.

(d) Summary

Align controls with conventions from other games; make UI behavior match what it implies
Provide a way to quit from within the game
Ensure UI communicates all information the player needs
Place critical UI where the player’s eyes actually go
Use legible fonts for any explanatory text
Enclose control groups so there’s no ambiguity about what applies to what ### Closing

Thanks for reading!

If you’d like, I’d love it if you hit the “Cheer for this!” button on Minna no Game Parade:

ZINTOROAD (Minna no Game Parade)

See you next time!

This article was automatically cross-posted from norinori1's portfolio

I Built an Auto-Publishing Pipeline from Notion to Qiita, Zenn, and My Portfolio

norinori1 — Mon, 13 Apr 2026 13:23:26 +0000

Introduction

Manually posting the same content to three different services every time I write an article — that’s quietly exhausting.

My portfolio site, Qiita, Zenn. Each has a different editor, different tagging conventions, and the work of copy-pasting and lightly reformatting was accumulating every single time.

And honestly — you know how AI tools have usage limits these days? It feels like a social game stamina bar, and I hate leaving it unused. I want to max out both Copilot and Claude Code.

Those frustrations overlapped, and I ended up building an article auto-publishing pipeline with Notion as the data source.

Architecture Overview

```plain text
Notion DB (write & manage articles here)
├─ Next.js portfolio site (calls Notion API directly)
├─ Qiita (GitHub Actions cron → post via official API)
└─ Zenn (GitHub Actions cron → push to separate repo)




The key design principle: **“Notion is the single source of truth.”** You only ever need to write in Notion.

---

## Notion Property Design

DB properties control where each article gets published:

Checking or unchecking per article gives flexible control over publish destinations.

---

## Portfolio Site (Next.js)

I **call the Notion API directly** from Next.js and display articles with SSG/ISR. Only pages where `status` is Published are fetched.

Notion’s rich text blocks are converted from the API response directly to Markdown for rendering.

---

## Auto-Publishing to Qiita

A script runs via **GitHub Actions cron** and posts using the **Qiita API**.



```yaml
on:
schedule:
-cron:'0 0 * * *'  # daily at midnight

Fetch articles with publish_qiita checked → convert Notion blocks to Markdown → create or update via Qiita API.

Watch out: rate limit errors

The Qiita API has rate limits. Posting multiple articles at once will error out. As your article count grows, add delays between requests or switch to a diff-only approach.

Auto-Publishing to Zenn

Zenn has no public API, so I use the zenn-cli + dedicated repo approach:

Create a separate GitHub repository for Zenn articles
GitHub Actions fetches from Notion → generates Markdown files
Push to that repo using a PAT (Personal Access Token)
Zenn auto-syncs from the linked GitHub repo

```plain text
your-name/zenn-articles ← Actions pushes here




---

## The Biggest Headache: Notion Image URL Expiration

Notion image URLs **expire after a certain time**.

I initially embedded them directly in Markdown, but images would stop displaying after a while.

**Fix: fetch URLs fresh on every request**

I changed the image block converter to always call the API for the latest URL. It’s slower per request, but images reliably display — good enough.

---

## AI-Driven Development

I delegated almost all the coding to **GitHub Copilot and Claude Code**.

For API-related implementations, telling them “I want to do X” gets most of the code written. Where I got stuck was on things AI couldn’t know: **Notion’s image URL behavior** and **Qiita’s rate limits** — the “you can’t know until you run it” class of problems.

My real takeaway: **spec research and behavior verification now takes more time than writing logic**.

---

## Summary

The “annoying to post to 3 sites separately” problem is genuinely solved.

That said, plenty of people have built something similar, so look at other articles too if you want a more polished implementation. I had personal context — “I want everything in Notion” and “I want this alongside my portfolio” — which made building it myself worthwhile.

---

## References

- [Notion API Official Docs](https://developers.notion.com/)
- [Qiita API v2 Docs](https://qiita.com/api/v2/docs)
- [zenn-cli Guide](https://zenn.dev/zenn/articles/zenn-cli-guide)

---

*This article was automatically cross-posted from [norinori1's portfolio](https://norinori1-web-site.vercel.app/news/notion-auto-publish)*

How I Recreated Unity's TextMeshPro Font Asset Creator in Scratch

norinori1 — Mon, 13 Apr 2026 13:22:53 +0000

“Doesn’t the default variable display in Scratch look terrible?” That one thought started everything.

Introduction: I Want to Display Text “Properly” in Scratch

Anyone who’s built games in Scratch has hit this wall.

You want to display scores and dialogue, but the default variable display is ugly.

Showing lists and variables directly on screen gives you that unmistakably clunky Scratch look. I wanted something more game-like — any font I choose, text rendered cleanly from code.

So I previously published a Scratch project called “Text Display” — a system that renders characters using sprite clones. It had its audience.

— But it was slow. And it ended up mostly unused.

For years I kept thinking “I want to remake this someday.”

And finally, I acted. Let’s try building this with AI.

What I Built

Scratch Font Asset Creator (SFAC) is a web tool that generates **.sb3 files containing sprites capable of displaying text in any font within Scratch**.

Works on vanilla Scratch — no extensions required. Runs in the browser via GitHub Pages, no install needed.

🔗 Repository: GitHub - norinori1/Scratch-Text-Asset-Creator

🔗 Tool: https://norinori1.github.io/Scratch-Text-Asset-Creator/

Bringing Unity’s TextMeshPro into Scratch

The design model was Unity’s TextMeshPro (TMP) Font Asset Creator.

TMP’s Font Asset Creator generates a texture atlas from a font file for use in games. I reinterpreted its core UX — “drop in a font, get a ready-to-use asset” — for the Scratch ecosystem.

The key difference: the user base spans from elementary school kids to experienced developers. So SFAC offers three input modes at different skill levels.

Three Text Input Modes

🟢 Parameter Block Mode (Beginner)

```plain text
Display text [Hello!] x: [0] y: [0] size: [100] color: [0]




Pass color, size, and position as arguments to a custom block. Intuitive enough for a complete beginner.

---

### 🟡 Rich Text Inline Mode (Intermediate)



```plain text
<c=100>Red text</c> with <b>bold</b> too

TMP-style tags embedded directly in the text string. Works well for dynamic text like scores and dialogue — fine-grained visual control without extra complexity.

🔴 Console Script Mode (Advanced)

Write CSS/YAML-style scripts into a “text display console” list and execute them. The most flexible mode — handles complex text presentations and effects.

Three modes means the tool is accessible to beginners without being too simple for experienced developers.

Technical Overview

SFAC is a Node.js web app running on GitHub Pages.

```plain text
① User inputs font file + settings
↓
② Canvas API renders each glyph as an image
↓
③ Glyph images + Scratch block definitions assembled into project.json
↓
④ JSZip compresses to .zip → renamed to .sb3
↓
⑤ Download → load into Scratch and use




### Improvements Over the Old “Text Display”

---

## The Hardest Part: Implementing Rich Text

I’ll be honest — writing the rich text parser was **like writing half a compiler**.

Tag detection, stack management, nesting interpretation, conversion to Scratch blocks — designing all of that by hand is genuinely painful.

**AI was struggling too.** Multiple rounds of “please fix this” before it finally worked.

But I also think **this is a feature that only became possible because AI was there**. Rich text and YAML-style script input — without AI support, they wouldn’t have made it into scope.

---

## Developing with AI

From the start, I used AI as a development partner:

- Sounding out the spec
- Coding complex parsers
- Debugging and root cause analysis
The moment that genuinely surprised me was when I gave the instruction “implement rich text” and AI actually produced a working parser — in Scratch.

> **“It implemented rich text. In Scratch. What the heck.”**

Total development time: **3 days**. Not possible at this speed without AI.

---

## What’s Next

The feature set is solid, but **the in-Scratch UX is still complex**. First-time users loading the `.sb3` often hit “how do I use these blocks?” I want to reduce the number of parameters in custom block definitions and keep improving the Scratch-side experience.

Personally, I also think SFAC has real potential as a novel game engine of sorts — I’d love to see it used for that.

---

## Summary

If you want serious text presentation in Scratch, give it a try.

And to any Scratchers thinking “I’d like to try building with AI” —

**AI is incredible. For real.**

---

*#Scratch #GameDev #IndieGame #AI #NodeJS*

---

*This article was automatically cross-posted from [norinori1's portfolio](https://norinori1-web-site.vercel.app/news/scratch-font-asset-creator)*

How ZINTOROAD Made It to the Game Creator Koshien Semifinal

norinori1 — Mon, 13 Apr 2026 13:22:51 +0000

(This article was written with Claude Haiku acting as interviewer — a first for me.)

(※ Fair warning: this gets pretty personal.)

Hey, it’s norinori1.

A while back, I was scrolling through Twitter when I suddenly saw a list of Game Creator Koshien semifinalists go by. That’s when I noticed: “Oh — that’s ZINTOROAD.”

This post is a record of what followed: observing visitors at the exhibition, the feedback I received, and the improvements that came from it.

An Idea Four Years in the Making

ZINTOROAD is a game that forcibly fuses Roguelike × Tower Defense × Action. I built it solo over 6 months in Unity/C#.

The Game’s Design

The concept:

“Survey the terrain (ROAD), claim (ZINTO) the optimal positions, and with limited resources, build the most elegant formation to hold back the enemy.”

It’s a survivor-style roguelite that runs until either the player’s HP hits zero or the number of enemies on the board exceeds 500.

The core system is AP (Action Point). Movement, anchor placement, and upgrades all cost AP, which you manage while fending off enemies. Every decision is a resource question: where to move, where to place anchors, how to take out enemies.

Enemies come in four types: Normal (baseline), Armored (high HP), Fast (high speed), Destroyer (targets anchors). Different situations call for different responses — explosive damage vs. damage fields (area damage created by linking three anchors).

The concept for this game actually existed 4–5 years ago. The original version was a bit different — back then I only made a title screen before shelving it. I always thought “I want to bring this to life someday,” and I finally got serious about it in 2024. Rebuilt everything from scratch, and it was finally done.

My original goal was simple: sell it on Steam / itch.io. But “wouldn’t it be cool to enter a contest while I’m still a student?” became the spark for submitting.

Reasons:

I wanted visibility
Selling requires a catalyst
These kinds of serious challenges are only possible as a student ## The Semifinal Notification, Out of Nowhere

When I saw it on Twitter, my reaction wasn’t joy — it was “wait, seriously?”

But once it sank in, it felt huge. A concept I’d been sitting on for 4–5 years had been recognized in a concrete way.

Visitor Feedback

Comments that stuck with me:

“The controls are pretty unique, aren’t they.” (Not a compliment.)
“I was curious how you fused three genres — I had to come check it out. This is pretty cool!”
“Why does movement cost AP?” The second made me happy — someone came specifically because they were intrigued. The first and third were honest signals that there were design problems.

What I Noticed Watching People Play

After observing dozens of players at the exhibition, one thing became clear:

“This game is too hard for first-time players.”

The “unique controls” criticism came from a weak tutorial. The AP-for-movement system is interesting in principle, but many players felt “why do I even have to pay to move?” — meaning the intent behind the system wasn’t getting through.

Something that looks perfect in your own head can be completely opaque to someone else. That’s game development.

Improvements Based on Feedback

Reworking the Tutorial

Players needed to actually understand ZINTOROAD’s core systems:

AP (Action Point): Consumed by movement, anchor placement, upgrades. Regenerates over time.
Anchors: Weapons that deal damage. Placing 3 creates a triangular damage field between them.
Enemy types: Normal (baseline), Armored (high HP, 25% blast damage reduction), Fast (fast/low HP), Destroyer (targets anchors first) Once you understand these, strategy opens up: “I’ll cut off the enemy’s path here and set up a damage field.”

But at launch I thought “they’ll figure it out from the screen” — so there was essentially no explicit tutorial.

After: rebuilt as a step-by-step introduction — movement → anchor placement → enemy types → attack patterns.

Balance Adjustments

The other thing I noticed: AP depletion.

Watching players’ faces, I could see the frustration of hitting “I can’t do anything.” That’s not about difficulty — it’s pure stress.

I attacked it from multiple angles:

Adjusted AP recovery — harder to run completely dry
Added more boost options — more upgrade choices on level-up means more ways to manage resources
Added AP generation to anchor upgrades — earn AP on wave transitions to improve resource flow Enemy attack patterns were also reworked to minimize the “helpless” window.

Anchor Reinforcement

Significantly buffed anchor HP.

The Destroyer enemy specifically hunts anchors — so fragile anchors meant they’d get wiped out before players could respond. After the buff, that threat feels appropriate rather than arbitrary. Anchors being destroyed is now a meaningful game event.

The Philosophy in One Line

“Fun > Stress”

Difficult games have their audience. But for first-time players, if stress outweighs fun, they stop. You need to give players at least as much fun as difficulty — ideally more.

“You Can’t Stay in Your Own World”

The biggest lesson from watching players:

“You can’t keep it self-contained in your own head.”

During development, the game looks perfect from the inside. No tutorial needed, balance is perfect, controls are simple — that’s what I thought. Real players see something completely different.

Another person’s perspective is invaluable. Without the exhibition, I might never have found these flaws.

ZINTOROAD Now

After all the improvements, ZINTOROAD isn’t a completely different game — but it’s significantly more playable.

First-time players can understand what they’re supposed to do. The movement cost feels like a meaningful system, not an arbitrary tax. The stress of instant destruction is reduced.

One step closer to “Fun > Stress.”

Finally

Entering Game Creator Koshien, making the semifinal, exhibiting — honestly, I didn’t expect to get this far.

I didn’t become a finalist. I didn’t win an award.

That stung.

But when I sat with that feeling, I realized: this is actually a good thing.

That frustration only exists because I put my whole self into this. If I’d half-assed it, not making the cut wouldn’t feel like anything. But I nursed this idea for 4–5 years, spent 6 months building it, observed players, iterated on feedback — because I did all of that, I can feel “so close” and “one more step.”

Regret = proof you were serious.

I’m glad I made the kind of challenge that’s only possible as a student. I’ll use this as fuel for the next project. That cycle is what makes you better.

If you’re an indie developer on the fence about entering a contest — I genuinely recommend it. Regardless of rankings or awards, the experience is invaluable. And if you don’t make it, whatever frustration you feel is there because you were serious. That matters.

Until the next project.

ZINTOROAD is playable here:

This article was automatically cross-posted from norinori1's portfolio

The Complete Guide to Using Claude / Copilot / Antigravity / Jules / Gemini CLI Effectively[2026]

norinori1 — Mon, 13 Apr 2026 13:22:18 +0000

Introduction

“I’m paying for Claude Pro, but I keep hitting the usage limit…”

“I want AI to write code for me, but I don’t know which tool to use…”

Do you have these kinds of concerns?

In this article, we’ll introduce a workflow that accelerates development by combining free AI agents while minimizing the consumption of tokens from paid tools like Claude and GitHub Copilot.

What You’ll Learn

A workflow design that avoids wasting paid AI tokens
How to effectively delegate tasks to free AI agents (Jules / Antigravity / Gemini CLI)

- The real characteristics, success rates, and limitations of each tool

Prerequisites: Tool List

1 As of March 12, 2026, the student plan changed from “GitHub Copilot Pro” to GitHub Copilot Student*. The 300 Premium Requests/month limit remains, but models like Claude Opus/Sonnet are now only available via Auto mode.

2 Antigravity is a cloud-based, agent-first IDE (VSCode fork) released in November 2025. It is not a local tool. Its free-tier rate limits have been reduced multiple times since December 2025 and are currently unstable. Key Point: Use Claude as a “smart advisor” focused on refining specifications, and delegate implementation to free agents.

Overall Coding Workflow

```plain text
[0] Draft a rough specification yourself
↓
[1] Refine the spec with Claude (+ generate prompts)
↓
[2] Delegate implementation to AI agents
↓
[3] Review generated code (test/debug)
↓
[4] If OK, merge PR / commit
↓
Return to [0] and define the next requirement → repeat until complete




---

## [0] Create a Rough Specification

Start by writing down what you want to build in bullet points:



```plain text
- When the user presses a button, the score increases by +1
- The score is displayed at the top of the screen
- When the score reaches 10, transition to a game over screen

Perfection is not required at this stage. As long as you’ve clarified what you want to build, that’s enough.

Writing this on paper can help organize your thoughts. It’s even better if you brainstorm ideas interactively with free AI tools.

[1] Refine the Specification with Claude

Take the rough spec from [0] and pass it to Claude Sonnet / Opus to refine it into a more concrete specification. At the same time, have it generate a prompt for the AI coding agent.

Effective Prompt Template

```plain text
Based on the following specification, create a more detailed specification
and a prompt suitable for an AI coding agent.
If anything is unclear, ask me before implementation.

(Paste your rough specification from [0])




**Important:** Explicitly state “ask me if anything is unclear.”

Otherwise, ambiguity increases the failure rate in later steps.

### Using Claude Code (CLI)

If you’re using Claude Code, open your target repository/folder at this stage. Claude can refine the spec while referencing your codebase.



```plain text
cd <repository path>
claude

Token-Saving Tips

Opus is powerful but consumes more tokens; Sonnet is often sufficient
Claude usage depends on output token volume, not request count
Usage resets every 5 hours → avoid burning through everything at once

- Weekly limits (introduced after August 2025) may apply for heavy users

[2] Delegate Implementation to AI Agents

Use the refined prompt from [1] and send it to agents in this priority order:

Priority

① GitHub Copilot Agent → ② Antigravity → ③ Google Jules → ④ Gemini CLI

① GitHub Copilot Agent

Type: Cloud (asynchronous)
Cost: 1 task = 1 Premium Request
Limit: 300/month (free for students via Copilot Student)
Success Rate: High

- 특징: Async workflow—submit and wait. Use requests carefully.

② Antigravity

Type: Cloud-based agent-first IDE
Cost: Free (preview)
Features:
- Access to multiple models (Claude Opus 4.6 / Sonnet 4.6 / Gemini 3.1 Pro)
- Planning mode adds a confirmation step before execution
- Manager View allows up to 5 parallel agents
Notes:
- Rate limits are unstable
- Not a local tool

③ Google Jules

Type: Cloud (asynchronous)
Cost: Free (15 tasks/day, max 3 concurrent)
Model: Gemini 2.5 Pro
Success Rate: Moderate (~40–50%)
Features:
- Interactive (Plan) mode allows agent questions
- Good alternative to Copilot Agent
- Supports scheduled tasks (e.g., refactoring, security checks)

④ Gemini CLI

Type: Local
Cost: Free (usage-based, replenished daily)
Success Rate: Moderate
Features:
- Generous usage limits
- Nano model has low reliability → avoid it
- Prefer Gemini 3 Flash or 2.5 Pro

[3] Review Generated Code

Run and verify the generated code.

If Errors Occur

Copy the error message and send it back to the same agent:

```plain text
The following error occurred. Please fix it.

(Paste error message)




---

### If Behavior Is Incorrect

**Close the PR or discard changes, then return to [2].**

Why not request incremental fixes?

Because repeated patching often breaks other working logic. Resetting and improving the prompt is usually faster and more reliable.

If issues persist, go back to [1] and refine the prompt.

---

### When Manual Fixing Is Faster

If you understand the language, small fixes (e.g., constants) are often quicker to do yourself.

Delegating minor fixes to agents:

- Takes time
- Risks breaking other logic
---

## [4] Merge → Return to [0]

Once everything works, merge or commit and return to [0] for the next requirement.

Repeat this loop until completion.

---

## Tool Comparison Summary

---

## PRO TIPS

### Insert Deep Research Between [1] and [2]

If you get stuck during spec drafting, use Deep Research (Gemini / Copilot / ChatGPT) to explore prior work.

**Steps:**

1. Ask Claude to generate a research prompt
2. Run Deep Research
3. Attach the report to your agent prompt in [2]
This improves coverage and success rates.

---

### Copilot Is Free for Students

GitHub Copilot is available **for free (Copilot Student plan)** via GitHub Education.

You get 300 Premium Requests/month—use it.

---

## Summary

- Use Claude for refining specifications—not implementation
- Delegate coding to free agents (Copilot → Antigravity → Jules → Gemini CLI)
- Reset and retry instead of stacking fixes
- Use Deep Research to improve prompt quality
- Antigravity is a cloud IDE, not local—prepare backups
By using AI tools strategically, you can significantly increase development speed while keeping costs low.

---

*This article was automatically cross-posted from [norinori1's portfolio](https://norinori1-web-site.vercel.app/news/vibe-codings-save-tokens-2026)*

A Role-Based Workflow to Supercharge AI Coding — A Tool-Agnostic Design Philosophy

norinori1 — Mon, 13 Apr 2026 13:22:15 +0000

Core Concept: Classify AI by “Roles”

The starting point is to classify AI coding tools into three roles:

The essence of cost saving is: “Don’t let the Thinker do the implementation.”

High-quality models excel at “thinking,” which is worth paying for. However, if you also let them handle simple code generation, costs will balloon. Separating “thinking” and “writing” is the foundation of this entire workflow.

Overall Workflow

```plain text
[0] Draft a rough specification yourself
↓
[1] Refine the spec with a Thinker AI (and generate implementation prompts)
↓
(Optional: use a Researcher AI to investigate prior art)
↓
[2] Hand it off to an Executor AI
↓
[3] Check the generated code (test / debug)
↓
[4] If no issues, merge → return to [0]




By repeating this loop, you complete one feature at a time.

---

## [0] Write the Spec in Your Own Words

Before handing things over to AI, start by **writing down what you want to implement in bullet points**.



```plain text
- When the user presses a button, the score increases by +1
- The score is displayed at the top of the screen
- When the score reaches 10, transition to a game over screen

Perfection is not required. The goal here is simply to organize your own thoughts.

[1] Refine the Spec with a Thinker AI

This is the most valuable step to invest cost in. Provide your rough spec to a high-quality model.

Prompt Template

```plain text
Based on the following specification, create a more detailed specification
and an implementation prompt for an AI coding agent.
If anything is unclear, ask me before proceeding with implementation.

(Paste the spec from [0])




### Why say “ask if unclear”?

If you pass an ambiguous spec to the implementation AI, **it will interpret things on its own**, increasing the chance of unintended behavior. Eliminating ambiguity through dialogue with the Thinker AI greatly improves downstream success rates.

### Cost-saving principles for Thinker AI

- **Mid-tier models are often sufficient.** Save top-tier models for complex reasoning.
- **Usage depends on output size and complexity, not just the number of calls.** Longer conversations increase per-call cost.
- **Usage limits reset over time (time windows or weekly).** Spread usage strategically instead of consuming it all at once.
---

## [1.5] Use a Researcher AI for Prior Art (Optional)

If you get stuck wondering “how should this be implemented?” while writing the spec, insert a step to **research prior art, libraries, and design patterns using a Deep Research tool**.

**Steps:**

1. Ask the Thinker AI: “Create a prompt to research prior art related to this spec.”
2. Run Deep Research using that prompt
3. Attach the results to your spec and include them in the implementation prompt for [2]
This helps the implementation AI generate code with awareness of **common practices and established approaches**, improving success rates.

---

## [2] Hand Off to the Executor AI

Provide the refined prompt from [1] to the implementation AI.

### How to choose an Executor AI

The Executor should be **low-cost (or free) while maintaining a reasonable success rate**. While specific tools may change, the evaluation criteria remain consistent:

- **Cost**: Is there a free tier? Is it usage-based pricing?
- **Success rate**: Can it handle simple feature additions and bug fixes?
- **Asynchronicity**: Can you submit and wait (async), or must you stay engaged (sync)?
- **Limit reset timing**: Daily, weekly, or monthly resets?
### Keep multiple agents ready

Always have **2–3 candidate agents** available so you can switch immediately if one hits limits or fails.

“The best free agent today” might not be the best tomorrow. Keeping alternatives ready ensures long-term development stability.

---

## [3] Check the Generated Code

Run and verify the code generated by the agent.

### ① If errors occur

Copy the error message and ask the same agent to fix it:



```plain text
The following error occurred. Please fix it.

---
(Paste the error message)

② If behavior is not as intended

Close the PR or discard changes and return to [2].

Why avoid repeated patching?

Repeated fixes often break previously working logic or result in partial, unstable solutions. The root problem is usually insufficient prompt quality, so it’s faster overall to reset, improve the prompt, and retry.
If issues persist, go back to [1] and revise the prompt itself.

③ When it’s faster to fix manually

If you understand the code, it may be faster to fix it yourself rather than going back and forth with the agent. For small fixes (a few lines), manual correction is often more efficient.

[4] Merge if Successful → Back to [0]

Once everything works, merge the PR or commit the changes, then return to [0] to define the next requirement.

Three Benefits of This Workflow

1. Stable Costs

By using the Thinker (high-cost) only for thinking, and delegating implementation (token-heavy tasks) to low-cost agents, monthly costs become more predictable.

2. Tool Independence

The roles—Thinker, Executor, Researcher—remain constant. Even if services change, you can adapt by simply plugging in new tools that fit each role.

3. Higher Success Rate

The better the prompt quality, the better the output. By eliminating ambiguity beforehand, you reduce retries and accelerate development overall.

Practical Checklist

[ ] Have you chosen a Thinker AI (and understood its usage limits and reset timing)?
[ ] Do you have 2–3 Executor agents as backups?
[ ] Do you have access to a Researcher AI (with Deep Research capability)?
[ ] Do you have a strategy to improve prompts when [2]→[3] fails?

- [ ] Do you review tool plans and limitations monthly?

Summary

Separating AI into Thinker, Executor, and Researcher optimizes cost and quality
Not letting the Thinker handle implementation is the biggest cost saver
Keep multiple implementation agents and reset/retry when needed
Tools will change—having a framework lets you adapt easily In a rapidly evolving AI landscape, relying on specific tools is fragile. Having a solid “framework” is what gives you a long-term advantage.

This article was automatically cross-posted from norinori1's portfolio

The Complete Guide to Using Claude / Copilot / Antigravity / Jules / Gemini CLI Effectively[2026]

norinori1 — Mon, 13 Apr 2026 00:00:54 +0000

Overview

In this article, we’ll introduce a workflow that accelerates development by combining free AI agents while minimizing the consumption of tokens from paid tools like Claude and GitHub Copilot.

Introduction

“I’m paying for Claude Pro, but I keep hitting the usage limit…”

“I want AI to write code for me, but I don’t know which tool to use…”

Do you have these kinds of concerns?

In this article, we’ll introduce a workflow that accelerates development by combining free AI agents while minimizing the consumption of tokens from paid tools like Claude and GitHub Copilot.

What You’ll Learn

A workflow design that avoids wasting paid AI tokens
How to effectively delegate tasks to free AI agents (Jules / Antigravity / Gemini CLI)

- The real characteristics, success rates, and limitations of each tool

Prerequisites: Tool List

1 As of March 12, 2026, the student plan changed from “GitHub Copilot Pro” to GitHub Copilot Student*. The 300 Premium Requests/month limit remains, but models like Claude Opus/Sonnet are now only available via Auto mode.

Key Point: Use Claude as a “smart advisor” focused on refining specifications, and delegate implementation to free agents.

Overall Coding Workflow




---

## [0] Create a Rough Specification

Start by writing down what you want to build in bullet points:



```plain text
- When the user presses a button, the score increases by +1
- The score is displayed at the top of the screen
- When the score reaches 10, transition to a game over screen

Perfection is not required at this stage. As long as you’ve clarified what you want to build, that’s enough.

Writing this on paper can help organize your thoughts. It’s even better if you brainstorm ideas interactively with free AI tools.

[1] Refine the Specification with Claude

Take the rough spec from [0] and pass it to Claude Sonnet / Opus to refine it into a more concrete specification. At the same time, have it generate a prompt for the AI coding agent.

Effective Prompt Template

```plain text
Based on the following specification, create a more detailed specification
and a prompt suitable for an AI coding agent.
If anything is unclear, ask me before implementation.

(Paste your rough specification from [0])




**Important:** Explicitly state “ask me if anything is unclear.”

Otherwise, ambiguity increases the failure rate in later steps.

### Using Claude Code (CLI)

If you’re using Claude Code, open your target repository/folder at this stage. Claude can refine the spec while referencing your codebase.



```plain text
cd <repository path>
claude

Token-Saving Tips

Opus is powerful but consumes more tokens; Sonnet is often sufficient
Claude usage depends on output token volume, not request count
Usage resets every 5 hours → avoid burning through everything at once

- Weekly limits (introduced after August 2025) may apply for heavy users

[2] Delegate Implementation to AI Agents

Use the refined prompt from [1] and send it to agents in this priority order:

Priority

① GitHub Copilot Agent → ② Antigravity → ③ Google Jules → ④ Gemini CLI

① GitHub Copilot Agent

Type: Cloud (asynchronous)
Cost: 1 task = 1 Premium Request
Limit: 300/month (free for students via Copilot Student)
Success Rate: High

- 특징: Async workflow—submit and wait. Use requests carefully.

② Antigravity

Type: Cloud-based agent-first IDE
Cost: Free (preview)
Features:

- Notes:

③ Google Jules

Type: Cloud (asynchronous)
Cost: Free (15 tasks/day, max 3 concurrent)
Model: Gemini 2.5 Pro
Success Rate: Moderate (~40–50%)

- Features:

④ Gemini CLI

Type: Local
Cost: Free (usage-based, replenished daily)
Success Rate: Moderate

- Features:

[3] Review Generated Code

Run and verify the generated code.

If Errors Occur

Copy the error message and send it back to the same agent:

```plain text
The following error occurred. Please fix it.

(Paste error message)




---

### If Behavior Is Incorrect

**Close the PR or discard changes, then return to [2].**

Why not request incremental fixes?

Because repeated patching often breaks other working logic. Resetting and improving the prompt is usually faster and more reliable.

If issues persist, go back to [1] and refine the prompt.

---

### When Manual Fixing Is Faster

If you understand the language, small fixes (e.g., constants) are often quicker to do yourself.

Delegating minor fixes to agents:

- Takes time
- Risks breaking other logic
---

## [4] Merge → Return to [0]

Once everything works, merge or commit and return to [0] for the next requirement.

Repeat this loop until completion.

---

## Tool Comparison Summary

---

## PRO TIPS

### Insert Deep Research Between [1] and [2]

If you get stuck during spec drafting, use Deep Research (Gemini / Copilot / ChatGPT) to explore prior work.

**Steps:**

1. Ask Claude to generate a research prompt
2. Run Deep Research
3. Attach the report to your agent prompt in [2]
This improves coverage and success rates.

---

### Copilot Is Free for Students

GitHub Copilot is available **for free (Copilot Student plan)** via GitHub Education.

You get 300 Premium Requests/month—use it.

---

## Summary

- Use Claude for refining specifications—not implementation
- Delegate coding to free agents (Copilot → Antigravity → Jules → Gemini CLI)
- Reset and retry instead of stacking fixes
- Use Deep Research to improve prompt quality
- Antigravity is a cloud IDE, not local—prepare backups
By using AI tools strategically, you can significantly increase development speed while keeping costs low.

---

*This article was automatically cross-posted from [norinori1's portfolio](https://norinori1-web-site.vercel.app/news/vibe-codings-save-tokens-2026)*

A Role-Based Workflow to Supercharge AI Coding — A Tool-Agnostic Design Philosophy

norinori1 — Mon, 13 Apr 2026 00:00:51 +0000

Overview

In this article, we introduce a

Introduction

The world of AI coding tools is changing rapidly.

Services that were free yesterday become paid, models you relied on get restricted, and plan names keep changing. Do you find yourself having to “research everything all over again” each time?

In this article, we introduce a universal AI coding workflow that does not depend on any specific service or plan. Even if tools change, as long as you have this “framework,” you can quickly rebuild your setup.

Core Concept: Classify AI by “Roles”

The starting point is to classify AI coding tools into three roles:

The essence of cost saving is: “Don’t let the Thinker do the implementation.”

Overall Workflow




By repeating this loop, you complete one feature at a time.

---

## [0] Write the Spec in Your Own Words

Before handing things over to AI, start by **writing down what you want to implement in bullet points**.



```plain text
- When the user presses a button, the score increases by +1
- The score is displayed at the top of the screen
- When the score reaches 10, transition to a game over screen

Perfection is not required. The goal here is simply to organize your own thoughts.

[1] Refine the Spec with a Thinker AI

This is the most valuable step to invest cost in. Provide your rough spec to a high-quality model.

Prompt Template

(Paste the spec from [0])




### Why say “ask if unclear”?

If you pass an ambiguous spec to the implementation AI, **it will interpret things on its own**, increasing the chance of unintended behavior. Eliminating ambiguity through dialogue with the Thinker AI greatly improves downstream success rates.

### Cost-saving principles for Thinker AI

- **Mid-tier models are often sufficient.** Save top-tier models for complex reasoning.
- **Usage depends on output size and complexity, not just the number of calls.** Longer conversations increase per-call cost.
- **Usage limits reset over time (time windows or weekly).** Spread usage strategically instead of consuming it all at once.
---

## [1.5] Use a Researcher AI for Prior Art (Optional)

If you get stuck wondering “how should this be implemented?” while writing the spec, insert a step to **research prior art, libraries, and design patterns using a Deep Research tool**.

**Steps:**

1. Ask the Thinker AI: “Create a prompt to research prior art related to this spec.”
2. Run Deep Research using that prompt
3. Attach the results to your spec and include them in the implementation prompt for [2]
This helps the implementation AI generate code with awareness of **common practices and established approaches**, improving success rates.

---

## [2] Hand Off to the Executor AI

Provide the refined prompt from [1] to the implementation AI.

### How to choose an Executor AI

The Executor should be **low-cost (or free) while maintaining a reasonable success rate**. While specific tools may change, the evaluation criteria remain consistent:

- **Cost**: Is there a free tier? Is it usage-based pricing?
- **Success rate**: Can it handle simple feature additions and bug fixes?
- **Asynchronicity**: Can you submit and wait (async), or must you stay engaged (sync)?
- **Limit reset timing**: Daily, weekly, or monthly resets?
### Keep multiple agents ready

Always have **2–3 candidate agents** available so you can switch immediately if one hits limits or fails.

“The best free agent today” might not be the best tomorrow. Keeping alternatives ready ensures long-term development stability.

---

## [3] Check the Generated Code

Run and verify the code generated by the agent.

### ① If errors occur

Copy the error message and ask the same agent to fix it:



```plain text
The following error occurred. Please fix it.

---
(Paste the error message)

② If behavior is not as intended

Close the PR or discard changes and return to [2].

Why avoid repeated patching?

If issues persist, go back to [1] and revise the prompt itself.

③ When it’s faster to fix manually

If you understand the code, it may be faster to fix it yourself rather than going back and forth with the agent. For small fixes (a few lines), manual correction is often more efficient.

[4] Merge if Successful → Back to [0]

Once everything works, merge the PR or commit the changes, then return to [0] to define the next requirement.

Three Benefits of This Workflow

1. Stable Costs

By using the Thinker (high-cost) only for thinking, and delegating implementation (token-heavy tasks) to low-cost agents, monthly costs become more predictable.

2. Tool Independence

The roles—Thinker, Executor, Researcher—remain constant. Even if services change, you can adapt by simply plugging in new tools that fit each role.

3. Higher Success Rate

The better the prompt quality, the better the output. By eliminating ambiguity beforehand, you reduce retries and accelerate development overall.

Practical Checklist

[ ] Have you chosen a Thinker AI (and understood its usage limits and reset timing)?
[ ] Do you have 2–3 Executor agents as backups?
[ ] Do you have access to a Researcher AI (with Deep Research capability)?
[ ] Do you have a strategy to improve prompts when [2]→[3] fails?

- [ ] Do you review tool plans and limitations monthly?

Summary

Separating AI into Thinker, Executor, and Researcher optimizes cost and quality
Not letting the Thinker handle implementation is the biggest cost saver
Keep multiple implementation agents and reset/retry when needed
Tools will change—having a framework lets you adapt easily In a rapidly evolving AI landscape, relying on specific tools is fragile. Having a solid “framework” is what gives you a long-term advantage.

This article was automatically cross-posted from norinori1's portfolio

[Boost]

norinori1 — Tue, 31 Mar 2026 04:43:33 +0000

norinori1

Mar 30

I Built an Auto-Publishing Pipeline from Notion to Qiita, Zenn, and My Portfolio

Comments

3 min read

6 UI/UX Techniques from ZINTOROAD

norinori1 — Mon, 30 Mar 2026 11:22:27 +0000

Overview

A breakdown of 6 UI/UX lessons learned while developing ZINTOROAD — from fixing broken button interactions to repositioning HUD elements based on where players actually look.

Excerpting my own article from the jack blog.

Hey there, I’m norinori1, jack’s ghost.

Today I’d like to share some of my own UI/UX design techniques and advice for game development, based on my experience developing “ZINTOROAD,” a game I brought to beta this year.

For more about “ZINTOROAD,” check here (I entered it into “Game Creator Koshien”) ↓

ZINTOROAD (Minna no Game Parade)

You might get a better understanding by viewing the “Work Introduction PDF” from there.

From here, I’ll talk about the improvements I made based on alpha and beta survey results for ZINTOROAD, and the UI/UX techniques I learned from them.

First, let me express my gratitude to everyone who played the ZINTOROAD alpha and beta versions, and to everyone who participated in the surveys.

(a) Title Screen

Alpha version → Beta version

In the alpha version, the game would only advance to the next scene by holding down Z — clicking “▶ Start” with the mouse actually did nothing.

This was flagged by quite a few survey respondents, so I updated it so clicking the start UI also starts the game.

Takeaway: UI should match the behavior users naturally expect.

Also in the beta: pressing [Esc] on the title screen now shows a confirmation dialog with an “Exit” button. Always give players a way to quit from within the game itself.

(b) Play Screen

Alpha version → Beta version

Feedback from surveys and friends on the alpha:

“Why is Pause mapped to ‘C’? (Shouldn’t it be ‘Esc’?)”
“Clicking the Pause UI doesn’t do anything”
“There’s an HP bar in the bottom-right but I never look there during gameplay”
“I can’t tell how many anchors are on the board” Points 1 and 2 come back to the same principle from (a): follow control conventions players already know from other games.

(Pause ended up on ‘C’ because two scripts were handling key input simultaneously and ‘Esc’ caused conflicts. Fixed in beta.)

Fix: moved the HP gauge and AP gauge (as a percentage of max) to the center of the screen. Players can now register damage immediately from the visual.

Fix: added a UI indicator next to the anchor placement display showing how many anchors on the board can currently form a triangle.

Takeaway: Show all information that matters to the player, and position the most critical elements where their eyes actually go.

(c) Boost Selection Screen

Alpha version → Beta version

After defeating enough enemies, the game levels you up and lets you pick a “boost” — a special ability (think the level-up screen in Vampire Survivors).

In the alpha, selecting a boost required holding down Z. Survey respondents found this confusing.

(Happened because I lazily reused the anchor-placement code.)

In the beta: single press of Z, plus mouse click support added.

On fonts: the alpha used a blocky, angular typeface called “Makinas” to match the game’s aesthetic. Surveys said it was hard to read, so I switched to “Smart Font UI.”

Takeaway: For any UI that explains or instructs, legibility beats style.

Takeaway: Enclose or clearly space UI groups so it’s unambiguous what belongs to what.

(d) Summary

Align controls with conventions from other games; make UI behavior match what it implies
Provide a way to quit from within the game
Ensure UI communicates all information the player needs
Place critical UI where the player’s eyes actually go
Use legible fonts for any explanatory text
Enclose control groups so there’s no ambiguity about what applies to what ### Closing

Thanks for reading!

If you’d like, I’d love it if you hit the “Cheer for this!” button on Minna no Game Parade:

ZINTOROAD (Minna no Game Parade)

See you next time!

This article was automatically cross-posted from norinori1's portfolio

I Built an Auto-Publishing Pipeline from Notion to Qiita, Zenn, and My Portfolio

norinori1 — Mon, 30 Mar 2026 11:22:26 +0000

Overview

Tired of manually cross-posting to three platforms every time I write something, I built a pipeline that uses Notion as the single source of truth and auto-publishes to my portfolio site, Qiita, and Zenn via GitHub Actions.

Introduction

Manually posting the same content to three different services every time I write an article — that’s quietly exhausting.

My portfolio site, Qiita, Zenn. Each has a different editor, different tagging conventions, and the work of copy-pasting and lightly reformatting was accumulating every single time.

And honestly — you know how AI tools have usage limits these days? It feels like a social game stamina bar, and I hate leaving it unused. I want to max out both Copilot and Claude Code.

Those frustrations overlapped, and I ended up building an article auto-publishing pipeline with Notion as the data source.

Architecture Overview




The key design principle: **“Notion is the single source of truth.”** You only ever need to write in Notion.

---

## Notion Property Design

DB properties control where each article gets published:

Checking or unchecking per article gives flexible control over publish destinations.

---

## Portfolio Site (Next.js)

I **call the Notion API directly** from Next.js and display articles with SSG/ISR. Only pages where `status` is Published are fetched.

Notion’s rich text blocks are converted from the API response directly to Markdown for rendering.

---

## Auto-Publishing to Qiita

A script runs via **GitHub Actions cron** and posts using the **Qiita API**.



```yaml
on:
schedule:
-cron:'0 0 * * *'  # daily at midnight

Fetch articles with publish_qiita checked → convert Notion blocks to Markdown → create or update via Qiita API.

Watch out: rate limit errors

The Qiita API has rate limits. Posting multiple articles at once will error out. As your article count grows, add delays between requests or switch to a diff-only approach.

Auto-Publishing to Zenn

Zenn has no public API, so I use the zenn-cli + dedicated repo approach:

Create a separate GitHub repository for Zenn articles
GitHub Actions fetches from Notion → generates Markdown files
Push to that repo using a PAT (Personal Access Token)
Zenn auto-syncs from the linked GitHub repo

```plain text
your-name/zenn-articles ← Actions pushes here




---

## The Biggest Headache: Notion Image URL Expiration

Notion image URLs **expire after a certain time**.

I initially embedded them directly in Markdown, but images would stop displaying after a while.

**Fix: fetch URLs fresh on every request**

I changed the image block converter to always call the API for the latest URL. It’s slower per request, but images reliably display — good enough.

---

## AI-Driven Development

I delegated almost all the coding to **GitHub Copilot and Claude Code**.

For API-related implementations, telling them “I want to do X” gets most of the code written. Where I got stuck was on things AI couldn’t know: **Notion’s image URL behavior** and **Qiita’s rate limits** — the “you can’t know until you run it” class of problems.

My real takeaway: **spec research and behavior verification now takes more time than writing logic**.

---

## Summary

The “annoying to post to 3 sites separately” problem is genuinely solved.

That said, plenty of people have built something similar, so look at other articles too if you want a more polished implementation. I had personal context — “I want everything in Notion” and “I want this alongside my portfolio” — which made building it myself worthwhile.

---

## References

- [Notion API Official Docs](https://developers.notion.com/)
- [Qiita API v2 Docs](https://qiita.com/api/v2/docs)
- [zenn-cli Guide](https://zenn.dev/zenn/articles/zenn-cli-guide)

---

*This article was automatically cross-posted from [norinori1's portfolio](https://norinori1-web-site.vercel.app/news/notion-auto-publish)*

How I Recreated Unity's TextMeshPro Font Asset Creator in Scratch

norinori1 — Mon, 30 Mar 2026 11:17:14 +0000

Overview

I built a web tool that generates .sb3 files containing sprites for rendering custom fonts in vanilla Scratch — inspired by Unity's TextMeshPro Font Asset Creator and built in 3 days with AI.

“Doesn’t the default variable display in Scratch look terrible?” That one thought started everything.

Introduction: I Want to Display Text “Properly” in Scratch

Anyone who’s built games in Scratch has hit this wall.

You want to display scores and dialogue, but the default variable display is ugly.

Showing lists and variables directly on screen gives you that unmistakably clunky Scratch look. I wanted something more game-like — any font I choose, text rendered cleanly from code.

So I previously published a Scratch project called “Text Display” — a system that renders characters using sprite clones. It had its audience.

— But it was slow. And it ended up mostly unused.

For years I kept thinking “I want to remake this someday.”

And finally, I acted. Let’s try building this with AI.

What I Built

Scratch Font Asset Creator (SFAC) is a web tool that generates **.sb3 files containing sprites capable of displaying text in any font within Scratch**.

Works on vanilla Scratch — no extensions required. Runs in the browser via GitHub Pages, no install needed.

🔗 Repository: GitHub - norinori1/Scratch-Text-Asset-Creator

🔗 Tool: https://norinori1.github.io/Scratch-Text-Asset-Creator/

Bringing Unity’s TextMeshPro into Scratch

The design model was Unity’s TextMeshPro (TMP) Font Asset Creator.

TMP’s Font Asset Creator generates a texture atlas from a font file for use in games. I reinterpreted its core UX — “drop in a font, get a ready-to-use asset” — for the Scratch ecosystem.

The key difference: the user base spans from elementary school kids to experienced developers. So SFAC offers three input modes at different skill levels.

Three Text Input Modes

🟢 Parameter Block Mode (Beginner)

```plain text
Display text [Hello!] x: [0] y: [0] size: [100] color: [0]




Pass color, size, and position as arguments to a custom block. Intuitive enough for a complete beginner.

---

### 🟡 Rich Text Inline Mode (Intermediate)



```plain text
<c=100>Red text</c> with <b>bold</b> too

TMP-style tags embedded directly in the text string. Works well for dynamic text like scores and dialogue — fine-grained visual control without extra complexity.

🔴 Console Script Mode (Advanced)

Write CSS/YAML-style scripts into a “text display console” list and execute them. The most flexible mode — handles complex text presentations and effects.

Three modes means the tool is accessible to beginners without being too simple for experienced developers.

Technical Overview

SFAC is a Node.js web app running on GitHub Pages.




### Improvements Over the Old “Text Display”

---

## The Hardest Part: Implementing Rich Text

I’ll be honest — writing the rich text parser was **like writing half a compiler**.

Tag detection, stack management, nesting interpretation, conversion to Scratch blocks — designing all of that by hand is genuinely painful.

**AI was struggling too.** Multiple rounds of “please fix this” before it finally worked.

But I also think **this is a feature that only became possible because AI was there**. Rich text and YAML-style script input — without AI support, they wouldn’t have made it into scope.

---

## Developing with AI

From the start, I used AI as a development partner:

- Sounding out the spec
- Coding complex parsers
- Debugging and root cause analysis
The moment that genuinely surprised me was when I gave the instruction “implement rich text” and AI actually produced a working parser — in Scratch.

> **“It implemented rich text. In Scratch. What the heck.”**

Total development time: **3 days**. Not possible at this speed without AI.

---

## What’s Next

The feature set is solid, but **the in-Scratch UX is still complex**. First-time users loading the `.sb3` often hit “how do I use these blocks?” I want to reduce the number of parameters in custom block definitions and keep improving the Scratch-side experience.

Personally, I also think SFAC has real potential as a novel game engine of sorts — I’d love to see it used for that.

---

## Summary

If you want serious text presentation in Scratch, give it a try.

And to any Scratchers thinking “I’d like to try building with AI” —

**AI is incredible. For real.**

---

*#Scratch #GameDev #IndieGame #AI #NodeJS*

---

*This article was automatically cross-posted from [norinori1's portfolio](https://norinori1-web-site.vercel.app/news/scratch-font-asset-creator)*

DEV Community: norinori1

6 UI/UX Techniques from ZINTOROAD

(a) Title Screen

(b) Play Screen

(c) Boost Selection Screen

(d) Summary

I Built an Auto-Publishing Pipeline from Notion to Qiita, Zenn, and My Portfolio

Introduction

Architecture Overview

Watch out: rate limit errors

Auto-Publishing to Zenn

How I Recreated Unity's TextMeshPro Font Asset Creator in Scratch

Introduction: I Want to Display Text “Properly” in Scratch

What I Built

Bringing Unity’s TextMeshPro into Scratch

Three Text Input Modes

🟢 Parameter Block Mode (Beginner)

🔴 Console Script Mode (Advanced)

Technical Overview

How ZINTOROAD Made It to the Game Creator Koshien Semifinal

An Idea Four Years in the Making

The Game’s Design

Visitor Feedback

What I Noticed Watching People Play

Improvements Based on Feedback

Reworking the Tutorial

Balance Adjustments

Anchor Reinforcement

The Philosophy in One Line

“You Can’t Stay in Your Own World”

ZINTOROAD Now

Finally

The Complete Guide to Using Claude / Copilot / Antigravity / Jules / Gemini CLI Effectively[2026]

Introduction

What You’ll Learn

- The real characteristics, success rates, and limitations of each tool

Prerequisites: Tool List

Overall Coding Workflow

[1] Refine the Specification with Claude

Effective Prompt Template

Token-Saving Tips

- Weekly limits (introduced after August 2025) may apply for heavy users

[2] Delegate Implementation to AI Agents

Priority

① GitHub Copilot Agent

- 특징: Async workflow—submit and wait. Use requests carefully.

② Antigravity

- Not a local tool

③ Google Jules

- Supports scheduled tasks (e.g., refactoring, security checks)

④ Gemini CLI

- Prefer Gemini 3 Flash or 2.5 Pro

[3] Review Generated Code

If Errors Occur

A Role-Based Workflow to Supercharge AI Coding — A Tool-Agnostic Design Philosophy

Core Concept: Classify AI by “Roles”

High-quality models excel at “thinking,” which is worth paying for. However, if you also let them handle simple code generation, costs will balloon. Separating “thinking” and “writing” is the foundation of this entire workflow.

Overall Workflow

[1] Refine the Spec with a Thinker AI

Prompt Template

② If behavior is not as intended

③ When it’s faster to fix manually

[4] Merge if Successful → Back to [0]

Three Benefits of This Workflow

1. Stable Costs

2. Tool Independence

3. Higher Success Rate

Practical Checklist

- [ ] Do you review tool plans and limitations monthly?

Summary

The Complete Guide to Using Claude / Copilot / Antigravity / Jules / Gemini CLI Effectively[2026]

Overview

Introduction

What You’ll Learn

- The real characteristics, success rates, and limitations of each tool

Prerequisites: Tool List

Overall Coding Workflow

[1] Refine the Specification with Claude

Effective Prompt Template

Token-Saving Tips