#crazyrouter

Building an Interactive Fiction Tool with Claude Code and Crazyrouter

Interactive fiction is a strong practical example for LLM application design. It is small enough to prototype quickly, but complex enough to expose real product problems: state management, branching, context drift, editing, retries, and user control.

The basic workflow is simple. A writer enters a title and a short opening. The app sends that context to a model through Crazyrouter and asks for several possible next branches. The writer chooses one branch, and the app expands it into a full scene. The selected scene becomes part of the active story path, and the process repeats.

The important design choice is to keep the story state in the application, not only in the prompt. Each story node should have an id, parent id, summary, full text, selected branch, timestamp, and model metadata. That gives the app a reliable timeline or tree view, and it lets the writer resume, edit, or regenerate specific parts of the story.

Claude Code is useful because this is not just a single API call. It can help implement the data model, API wrapper, UI states, local persistence, and error handling across multiple files. A structured prompt works better than a vague request: describe the screens, the branch behavior, the model calls, and how generated text should be edited before the next continuation.

Crazyrouter endpoint configuration also matters. Claude Code and Anthropic-native clients should use https://cn.crazyrouter.com. OpenAI-compatible SDKs and regular HTTP applications should use https://cn.crazyrouter.com/v1. Keeping those separate avoids the common /v1/v1/... mistake.

A first version can store stories and settings locally. A production version should move API key handling to a backend, add rate limits, and preserve model metadata for debugging. Streaming output is useful, but the UI should handle cancellation and partial results cleanly.

A common problem in AI-assisted product work is not that Claude gives weak answers. It is that the work is scattered across too many conversations.

You might discuss a membership points system in three separate Claude windows: one for ROI and redemption cost, one for competitor analysis, and one for refund logic and edge cases. Then you open a new writing session and ask for a PRD outline. The model asks the same basic questions again: What is the exchange ratio? Which competitors matter? What happens when an order is refunded?

At that point, the product manager has become a context courier.

The better pattern is to stop treating chat history as the project memory. Put the work into local Markdown files that both you and Claude can read. Obsidian works well for this not because it is special, but because it stores plain files. A project folder can contain research notes, business rules, PRD drafts, architecture notes, checklists, and a decision log.

Once that folder becomes the source of truth, Claude can work by role. A product manager role reads research and writes the PRD. An architect role reads the PRD and writes the technical plan. Frontend and backend roles read the relevant files and produce implementation notes. A QA role reads the rules and edge cases, then creates test scenarios.

The important rule is boundaries. Each role needs a clear input scope, output file, checklist, and policy for missing information. Otherwise, multi-role AI work becomes another pile of unstructured text.

A useful habit is to turn every important conversation into a minimum viable document. It does not need to be polished. It only needs to preserve goals, decisions, alternatives, constraints, open questions, and edge cases. Then turn AI questions into a project checklist instead of letting them disappear in chat.

For teams using Crazyrouter, keep endpoints clean. Claude Code and Anthropic-native clients use https://cn.crazyrouter.com. OpenAI-compatible SDKs use https://cn.crazyrouter.com/v1. Do not attach UTM parameters to API endpoints, and avoid doubled paths such as /v1/v1/....

Pencil is useful in an AI coding workflow because it gives Claude Code a real design surface to operate on. Instead of asking an agent to imagine a UI and produce a rough HTML version, you can let it create and edit a structured Pencil design through MCP, inspect the result, and then export implementation code.

The workflow is straightforward. Install the Pencil desktop app, verify its MCP server inside Claude Code with /mcp, and allow the mcp__pencil permission if you do not want repeated confirmation prompts. From there, Claude Code can use Pencil tools such as get_editor_state, get_screenshot, batch_get, get_variables, and especially batch_design.

The important capability is batch_design. It lets the agent insert, copy, update, replace, move, and delete design nodes. That means Claude Code can make concrete changes to the design file rather than only giving written suggestions.

A practical prompt should describe the product surface, not just the visual style. For example: create a sign-in screen for an internal API management console, including email/password login, SSO, error state, loading state, and an environment selector. Claude can create the design, check it through a screenshot, and then respond to targeted edits such as changing spacing, translating labels, or updating all cards.

When the structure is ready, the design can be exported into a React project using Tailwind CSS and shadcn/ui-style components. The generated project can be installed and run locally, then refined like normal application code.

One underrated benefit is version control. Pencil’s .pen file is JSON, so it can live in Git beside the code. That makes it easier to review design changes, track prototype evolution, and keep specs, design files, and implementation in the same repository.

For Crazyrouter users, keep endpoint usage clean. Claude Code and Anthropic-native clients use https://cn.crazyrouter.com; OpenAI-compatible SDKs and HTTP applications use https://cn.crazyrouter.com/v1. Do not add tracking parameters to API endpoints.

Diagrams are useful until they become stale. In many teams, the README changes, the service boundaries change, and the deployment model changes, but the system diagram remains untouched because opening a design tool is outside the normal development workflow.

Claude Code can make diagram maintenance more practical when you treat diagrams as repository artifacts instead of one-off images. The most useful approach is to generate editable Markdown diagrams from real project context: feature documents, architecture notes, README files, service folders, deployment configuration, and API descriptions.

There are two diagram types worth separating.

A functional module diagram explains what the system does. It is organized around business capabilities and user-facing modules: authentication, user management, order management, billing, notifications, reporting, admin workflows, and similar areas.

A system architecture diagram explains how the system is built and operated. It should show technical components such as frontend applications, API gateways, backend services, databases, caches, queues, background workers, external APIs, and observability tools.

Keeping these separate prevents the common problem where one diagram mixes “Order Center” with “PostgreSQL” and “Redis” without making clear whether the reader is looking at product capability, runtime structure, or infrastructure.

A practical Claude Code workflow is simple:

1. If visual consistency matters, provide a reference diagram and ask Claude Code to extract layout, grouping, colors, node styles, connector styles, and label density.

2. Provide the functional module document and generate a Mermaid-based functional module diagram.

3. Provide technical context from the repository and generate a Mermaid-based architecture diagram.

4. Review the output like code-adjacent documentation: check naming, boundaries, arrows, external systems, and whether the diagram is editable.

When routing Claude Code through Crazyrouter, keep endpoint usage precise. Claude Code and Anthropic-native clients use https://cn.crazyrouter.com. OpenAI-compatible SDKs and HTTP requests use https://cn.crazyrouter.com/v1. Do not add tracking parameters to API endpoints.

From Requirements to UI Prototype with Claude Code and Crazyrouter

A better AI-assisted UI workflow does not begin by asking a model to “make a beautiful screen.” That usually leads to inconsistent colors, spacing, shadows, and components. The more reliable approach is to move through the same artifacts a product team would normally review: requirements, design system, low-fidelity wireframes, and high-fidelity prototype.

The first step is to ask Claude Code to generate a design system document from the product requirement. Give it the audience, product tone, core features, and base color palette. Then require a structured Markdown output with design tokens for colors, typography, spacing, radius, shadows, and semantic states. Also ask it to define reusable components such as Button, Input, Card, Modal, Tabs, and Bottom Navigation, including props and state behavior.

The second step is to generate low-fidelity wireframes from that design system. At this stage, the goal is structure, not polish. A useful prompt asks Claude Code to produce a single HTML file with multiple mobile artboards, a simulated status bar, fixed bottom navigation, and independently scrollable content areas. All visual values should come from CSS custom properties derived from the design tokens.

The third step is high-fidelity styling. Provide visual references only after the wireframe is structurally correct. The instruction should preserve the existing page structure and token system while applying the reference style. Iteration works best when feedback is precise: reduce a specific card shadow, align a tab label, use a named token for the primary button, or improve contrast on one component.

For Crazyrouter, keep endpoint usage clean. Claude Code and Anthropic-native clients use https://cn.crazyrouter.com. OpenAI-compatible SDKs and HTTP clients use https://cn.crazyrouter.com/v1. Avoid the common /v1/v1 mistake.

Mermaid is a practical format for developer documentation because it turns diagrams into text. That means architecture diagrams, sequence diagrams, flowcharts, and state machines can live in the same repository as the code they explain. They can be reviewed in pull requests, updated with normal editor tools, and rendered in GitHub, Mermaid Live Editor, draw.io, or ProcessOn.

Claude Code makes the workflow more useful because it can inspect a codebase before drafting the diagram. The key is to avoid vague prompts like “make a nice architecture diagram.” A better prompt defines the audience, scope, diagram type, and level of detail. For example, ask it to inspect the checkout flow, summarize the relevant components first, and then output a valid Mermaid flowchart LR diagram for backend onboarding.

A reliable process is:

1. Choose one diagram type and one audience.

2. Point Claude Code at the relevant files or directories.

3. Ask for a short system summary first.

4. Correct any wrong assumptions.

5. Generate Mermaid.

6. Render and adjust the diagram.

7. Commit the Mermaid source.

Architecture diagrams should show stable boundaries such as clients, APIs, services, databases, queues, workers, and external providers. Sequence diagrams are better for ordered interactions such as login, payments, uploads, notifications, and webhooks. Flowcharts are best for decision-heavy logic such as eligibility checks, approval flows, validation pipelines, and feature flag behavior.

If you are using Crazyrouter as the routing layer, keep the endpoint rules clear. Claude Code and Anthropic-native clients use https://cn.crazyrouter.com. OpenAI-compatible SDKs, HTTP calls, and apps that expect an OpenAI-style base URL use https://cn.crazyrouter.com/v1. Do not append /v1 twice.

Claude Code + Figma MCP: a practical design-to-code workflow

Claude Code is most useful when it can work with real project context. For frontend work, that context often lives in two places: the codebase and Figma. Connecting Claude Code to Figma through MCP gives you a cleaner handoff loop: point Claude Code at a Figma file or selection, ask for a targeted implementation, then review the generated code like any other change.

This setup is useful for portfolio pages, product screens, component updates, and design revisions where the visual intent already exists. It is less useful when the design is still vague. In that case, you are asking the model to do product design and implementation at the same time, which can be fine for exploration but should not be treated as production-ready output.

The key setup steps are straightforward. Install Claude Code, configure model access, add the Figma MCP server, authenticate with Figma, and install the official Figma plugin inside Claude Code. If you use Crazyrouter, keep the endpoint rules clear:

Claude Code and Anthropic-native clients use https://cn.crazyrouter.com

OpenAI-compatible SDKs and app-side API calls use https://cn.crazyrouter.com/v1

That distinction matters because adding /v1 in the wrong place can lead to broken paths such as /v1/v1/....

A good prompt is specific. Instead of “make this Figma design into code,” ask Claude Code to implement a selected Figma frame as a React component, preserve the current prop API, reuse local CSS conventions, and avoid adding a new UI library. Smaller, more explicit prompts usually produce cleaner diffs.

For design changes, copy the Figma selection link rather than the whole file link. Then ask Claude Code to update only the relevant component. This keeps the change reviewable and reduces accidental rewrites.

The point is not to remove frontend judgment. Claude Code can infer layout and generate a useful first pass, but developers still need to check responsive behavior, accessibility, component boundaries, token usage, and unnecessary dependencies.

From Prompt to Prototype with Claude Code, Cursor, and Figma/MasterGo

A common mistake in AI prototyping is asking for the final UI too early. If the prompt is only “create a high-end car sales app,” the result may look polished, but it often lacks product structure, page coverage, reusable design tokens, and design-tool compatibility.

A more reliable workflow is staged:

1. Write a rough product request.

2. Ask the AI to rewrite it into a complete product/design/development prompt.

3. Use Claude Code to generate a single-file HTML prototype.

4. Refine the code in Cursor.

5. Import or rebuild the result in Figma or MasterGo.

For a premium automotive sales app, the prompt should define the product positioning, target users, required modules, and screen list. Useful screens include home, vehicle catalog, vehicle detail, 360-degree view, smart configuration, configuration comparison, test drive booking, finance calculator, order tracking, profile, membership center, settings, customer support, news list, and article detail.

The UI section should be specific. Instead of saying “make it high-end,” define the system: deep black, white, champagne gold, neutral gray, large whitespace, subtle shadows, premium typography, consistent spacing, rounded cards, realistic vehicle imagery, and minimal navigation.

The frontend section should ask for Tailwind CSS, open-source icons, mobile dimensions such as 390×844, semantic HTML, clear comments, status bar simulation, fixed bottom navigation, and all screens displayed in a reviewable grid.

For Figma/MasterGo, the prototype should include export expectations: SVG output per screen, semantic class names, downloadable design tokens, copyable CSS variables, and a short import guide. After importing, the design team should still ungroup, convert to frames, apply Auto Layout, and rebuild reusable components.

If using Crazyrouter with Claude Code, keep endpoint configuration exact. Claude Code and Anthropic-native clients use https://cn.crazyrouter.com. OpenAI-compatible SDKs and HTTP clients use https://cn.crazyrouter.com/v1. Do not add tracking parameters to API endpoints, and avoid accidental /v1/v1/... paths.