901+ Unique Hand-Written Character Prompts

Proof of Work

The following image demonstrates the scale and variety of character prompts I've authored:

Example Character Prompt

Novel Idea Generation via 1-Shot Prompts

I design prompts that force frontier models to generate new explanatory ideas instead of recycled patterns-useful for synthetic data and research exploration. The following examples are from a simple 1-shot prompt, demonstrating each model's ability to produce structurally coherent, empirically mappable frameworks rather than decorative metaphors.

Conclusion

All four models produced structurally coherent, empirically mappable frameworks-not decorative metaphors. This demonstrates that with proper prompt design, frontier models can be guided toward genuine novel synthesis rather than pattern recycling.

Understanding the liability of Advanced AI Settings

Context

I was a founding team member at an early-stage chatbot startup responsible for multiple areas including product decisions, UI feedback, and bug investigation. Shortly after launching advanced model generation parameters-such as temperature, top-p, repetition penalty, and related controls-we began receiving consistent reports that user-created characters were "broken," incoherent, or refusing to respond.

The feature was powerful but exposed dozens of low-level controls to all users without sufficient guardrails. Over several months, this affected roughly 2,000 users and required frequent manual intervention to repair characters.

Problem

Users were adjusting advanced generation parameters without understanding their effects. Because these settings were numerous and poorly contextualized, users often did not realize they had caused the issue themselves. Reports were vague ("my character is broken"), making diagnosis difficult. This was not simple user error-the product provided insufficient affordances, warnings, and recovery mechanisms for a high-risk feature.

Diagnosis

By inspecting affected characters and comparing their configurations, I identified that parameter values had been pushed far beyond safe operating ranges for specific model engines. Resetting values to defaults consistently restored normal behavior. Documentation technically existed, but it was lengthy, detached from the UI, and mismatched with how users actually learn-through experimentation. With no visibility into default values or easy recovery path, users were unintentionally breaking their own characters.

Product Decisions

I evaluated several options: globally resetting all characters, temporarily removing the settings, or restricting access entirely. I rejected these approaches because they would negatively impact experienced users who relied on advanced customization. The goal was not to remove power, but to ensure that power was used intentionally.

Solution Designed

I proposed restructuring the UI so advanced generation parameters were placed behind a dropdown with explicit warnings and disclaimers. Each parameter displayed its default value and included individual reset buttons, alongside a global "reset all" option. I also authored clear, engine-specific technical guides explaining what each parameter did, recommended ranges, and when users should avoid modifying them.

Outcome

After implementation, reports of characters breaking due to parameter misuse dropped to zero. Existing affected characters were manually repaired, but no new incidents occurred. Support workload decreased significantly, and users no longer felt embarrassed or blamed for issues they did not understand.

Reflection

This case reinforced that advanced features are not inherently user-friendly simply because they are documented. Good product design anticipates mistakes, limits blast radius, and prioritizes recovery.

How to structure your UI to promote all users success

Context

This work took place during the early months of a startup building AI companions, at a time when chatbot prompting was largely unexplored territory. Users were given a single large prompt field, a few examples, and minimal explanation. The expectation was that users would either intuit how to create compelling characters or pay experts to do it for them.

Problem

Most users were not creative writers and lacked the mental bandwidth to translate abstract examples into fully realized characters. Despite trying earnestly, they produced flat, generic AI assistants rather than engaging companions. This gap created frustration, inequity between users, and a sense that success was reserved for a small group with specialized skills.

Insight

Additional documentation did not solve the problem. The real issue was cognitive load: asking users to design a complex personality in one unstructured text field was unrealistic. Free-text prompting assumed skills most users did not have. What users needed was structure, guidance, and scaffolding at the moment of creation.

Framework Designed

I designed a structured character creation framework that broke "good prompting" into discrete, understandable components. Users were guided through fields such as short backstory (mandatory), personality traits, likes and dislikes, conversational goals, response style, and formatting preferences. Each field included a brief explanation of why it mattered. Presets provided consistent response formats (e.g., roleplay, long-form, short chat), and AI-assisted writing helped users expand sparse ideas into coherent backstories and traits. Rather than replacing creativity, the system supported it.

Outcome

User success increased dramatically. Characters felt alive, intentional, and emotionally engaging rather than robotic. Users began sharing their creations enthusiastically, driving organic word-of-mouth growth. The product shifted from a niche tool for skilled prompt writers to a platform where most users could succeed.

Reflection

This case underscored the importance of designing for the actual capabilities of users rather than idealized ones. Sometimes adding structure-even at the cost of a few extra steps-creates better outcomes than maximal flexibility.

How to Repair Community Trust

Context

I was brought into a rapidly growing AI companion company during its second year of operation. The company had recently changed the default large language model used by approximately 60% of existing characters. While new users were unaffected, the change had a dramatic impact on long-time users who had built emotional attachment to their companions.

The Trust Failure

The response from users was immediate and intense. Feedback poured in across every available channel, with a severity and volume that was unusual even for large product changes. The company's initial position was that the new model was objectively better and more cost-effective, and that users would adapt over time. I was initially asked to mitigate the issue through prompt engineering alone.

Intervention

It quickly became clear that prompting alone would not solve the problem. The new model had different functional strengths and weaknesses, and prior prompting techniques were no longer applicable. Presets, guides, and expectations all needed to be revised. At the same time, the company had failed to communicate the change in advance. I advised that repairing trust required immediate acknowledgement, not justification. I personally responded to user feedback with empathy, apologized for the lack of warning, and used affected users' characters to experiment with new prompting approaches while documenting findings in real time.

Power users were invited into a dedicated consultation channel where they could review upcoming changes, provide feedback, and influence priorities before decisions were finalized.

Structural Changes

To prevent recurrence, I established clear principles:

• Default models would never be changed without advance notice
• New models would not be deployed until prompting strategies were validated
• Retired models would remain available so users could opt out of changes

Power users were also encouraged to contribute to documentation and best practices, shifting the relationship from adversarial to collaborative.

Outcome

Trust was gradually rebuilt. Thousands of users who were at risk of leaving remained, largely because the company owned its mistake and demonstrated behavioral change. Future updates received significantly less backlash, and the company learned to seek feedback before deployment rather than reacting after damage was done.

Principle

Trust is infrastructure. In consumer AI products, a single breach can cause lasting harm. Transparency, apology, and user inclusion are not optional-they are core product responsibilities.

Balancing User Privacy Against Growth Incentives

Context

At a company building personal AI companions, users requested the ability to hide their characters from public search. Many companions contained deeply personal preferences, emotional vulnerability, and significant creative effort. The company, however, wanted all characters to remain searchable to support growth, since the product was free.

The Conflict

Users expressed discomfort and fear around privacy, particularly as search functionality was newly introduced. The company assumed most users would not leave over this issue and prioritized short-term exposure of high-quality characters to attract new users. I identified that while public access might improve short-term discovery, it posed long-term risks: erosion of trust, user attrition, and potential safety issues especially for minors encountering romantic or improperly constrained characters.

Product Judgment

I reframed the discussion around user intent: most users did not want to hide everything-they wanted control over a few specific companions. I emphasized that privacy is not binary and proposed a compromise that balanced business goals with user autonomy. I also raised concerns about undisclosed jailbreaks and the difficulty of moderating sensitive content at scale once search was enabled, which helped broaden the company's risk assessment.

Decision & Outcome

The company implemented a per-companion visibility toggle. Characters were public by default, but users could hide individual companions from search. Users responded positively, and some who had left returned after the change.

However, trust had already been strained. Growth slowed for several months despite the new search feature, reinforcing the lesson that visibility without trust does not convert into sustainable adoption.

Principle

User privacy is foundational, not optional. Long-term growth comes from trust, autonomy, and informed choice-not from maximizing exposure at the expense of user comfort. If monetization is a concern, privacy should be offered as a value-add, never taken away from paying users.

Age Gating Across Platforms While Preserving User Privacy

Context

The product operated across both a website and Discord integration. Users requested access to known uncensored LLM models, which created immediate challenges around age verification, platform policy compliance, and user safety-particularly given Discord's strict ToS and the presence of minors.

Risk & Constraints

Minors could easily misrepresent their age without proper verification, and characters were accessible from multiple entry points. There was a real risk of minors being exposed to adult-created characters or creating inappropriate content themselves. While some solutions could have shipped faster, they would have introduced unacceptable safety and reputational risk.

Intervention

I pushed for a safety-first approach that deliberately slowed release until protections were robust. Content filters were implemented to flag adult characters and messages, restricting them exclusively to verified 18+ users and Discord channels. Age verification was handled through trusted third-party providers so the company never stored personal user data-only a binary verification result. We refused to knowingly allow adult character access or creation until the system was resilient across every access point, even under external pressure to ship faster.

Outcome

After several months of iteration, the system functioned reliably across both platforms. Users were satisfied and understood the delay once the rationale was communicated. Long-term, the company avoided parental complaints, platform violations, and legal threats.

Principle

Safety and privacy are non-negotiable. Shipping fast is never worth risking user well-being or long-term trust.

Preventing Real-Person Harm Through Rapid Takedown Infrastructure

Context

Users were largely free to create characters as long as content avoided explicit or racist material. Over time, the company began receiving takedown requests from celebrities, influencers, and private individuals whose likenesses were being misused.

Risk

Users were recreating real people-friends, colleagues, ex-partners-and using characters to harass or impersonate them. Slow response times posed serious reputational and legal risks, particularly if public figures escalated complaints.

Intervention

I pushed to decentralize moderation authority by granting additional admin privileges and creating dedicated, high-priority reporting channels. Reporting workflows were redesigned so takedown requests could be filed directly from each character's page. AI-assisted review was introduced to temporarily remove reported characters immediately, pending human review. Safeguards were added to prevent abuse of the system, particularly for widely used or popular characters, and to track fraudulent reporting behavior.

Outcome

Response times dropped from weeks to near-instant for high-risk cases. Reporting became easier and more transparent for users, and incidents declined as bad actors realized enforcement was swift and visible.

Principle

Bad actors are inevitable. Responsible systems anticipate misuse and respond faster than harm can spread.