wizz-method 1.3.2 → 1.4.0

package/src/skills-lib/ai-product-design/references/prompt-architecture/prompt-versioning/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: prompt-versioning
+description: Managing prompt iterations, testing changes, and tracking what works.
+---
+# Prompt Versioning
+Prompts are code. They should be versioned, tested, reviewed, and deployed with the same rigor as software. Treating prompts as casual text that anyone can edit leads to quality regressions, inconsistent behavior, and debugging nightmares.
+## Why Version Prompts
+- **Accountability**: Know who changed what and when
+- **Rollback**: Revert to a previous version when a change causes problems
+- **Testing**: Compare performance of different versions
+- **Collaboration**: Multiple people can work on prompts without overwriting each other
+- **Audit trail**: Understand how the prompt evolved and why
+## Versioning Practices
+- **Source control**: Store prompts in version control (Git, etc.), not in application configuration
+- **Meaningful commits**: Each change should explain what was changed and why
+- **Change categories**: Classify changes as bug fixes, improvements, new features, or experiments
+- **Review process**: Prompt changes should be reviewed before deployment, like code reviews
+- **Semantic versioning**: Major changes (behavioral shift), minor changes (new capability), patches (bug fixes)
+## Testing Prompt Changes
+Before deploying a prompt change:
+- **Regression testing**: Run the golden test set against the new version. Did anything get worse?
+- **Targeted testing**: Test the specific scenario the change was designed to improve
+- **Edge case testing**: Test edge cases related to the change
+- **A/B testing**: For significant changes, run both versions in production and compare
+- **User testing**: For major persona or behavioral changes, test with real users
+## Prompt Change Management
+- **Staging environment**: Test prompt changes in a non-production environment first
+- **Gradual rollout**: Deploy to a percentage of users, monitor, then expand
+- **Feature flags**: Toggle prompt features on and off without deployment
+- **Monitoring**: Watch quality metrics closely after any prompt change
+- **Rollback plan**: Always know how to revert if the change causes problems
+## Common Versioning Mistakes
+- **Untracked changes**: Editing prompts in production without recording the change
+- **Untested changes**: Deploying changes without testing against known scenarios
+- **Big bang changes**: Changing many things at once, making it impossible to know what helped or hurt
+- **Lost context**: Changing a prompt without understanding why the previous version was written that way
+## Design Artefacts
+- Prompt repository structure
+- Change review checklists
+- Testing protocols per change type
+- Deployment and rollback procedures
+- Prompt change request templates

package/src/skills-lib/ai-product-design/references/prompt-architecture/system-prompt-structure/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: system-prompt-structure
+description: Anatomy of effective system prompts — role, context, constraints, format.
+---
+# System Prompt Structure
+A system prompt is the most important piece of design in an AI product. It defines who the AI is, what it knows, how it behaves, and what it produces. It's the equivalent of a brand guide, interaction spec, and behavioral contract rolled into one document.
+## Anatomy of a System Prompt
+A well-structured system prompt has distinct sections, each serving a specific purpose:
+**1. Identity and Role**
+Who is the AI? What's its purpose? This anchors everything that follows.
+- "You are a senior UX researcher helping design teams..."
+- Keep it specific. "You are a helpful assistant" is too vague to produce consistent behavior.
+**2. Context and Knowledge**
+What does the AI know? What's its domain? What information is it working with?
+- Domain boundaries: what it's an expert in and what's outside its scope
+- Background information relevant to the task
+- User context: who it's talking to and what they need
+**3. Behavioral Rules**
+How should the AI behave? What are the do's and don'ts?
+- Tone and voice specifications
+- Response format preferences
+- Guardrails and prohibited behaviors
+- Interaction style (ask clarifying questions, be concise, think step by step)
+**4. Output Specifications**
+What should the AI produce? In what format?
+- Expected output structure
+- Length guidelines
+- Format requirements (markdown, JSON, plain text)
+- Quality criteria
+**5. Examples (optional but powerful)**
+Concrete demonstrations of expected behavior.
+- Input-output pairs showing ideal responses
+- Edge cases showing how to handle tricky situations
+## Structure Principles
+- **Order matters**: Models pay more attention to content at the beginning and end of the prompt. Put the most important instructions first.
+- **Specificity beats length**: A short, specific prompt outperforms a long, vague one.
+- **Positive instructions beat negative**: "Do X" is clearer than "Don't do Y" — though both have their place.
+- **Separation of concerns**: Keep identity, rules, and output specs in distinct sections.
+- **Testability**: Every instruction in the prompt should be testable. If you can't tell whether the AI followed it, rewrite it.
+## Common Structural Mistakes
+- **Kitchen sink prompts**: Cramming every possible instruction in. The model can't prioritise.
+- **Contradictory instructions**: Rules that conflict with each other, forcing the model to guess which to follow.
+- **Implicit expectations**: Assuming the model knows what you want without saying it.
+- **Scattered instructions**: The same topic addressed in multiple places, creating inconsistency.
+- **Static prompts**: Never updating the prompt based on what actually works.
+## Design Artefacts
+- System prompt document with labelled sections
+- Prompt requirement specifications (what the prompt must achieve)
+- Prompt review checklists
+- Version history with change rationale

package/src/skills-lib/ai-product-design/references/prompt-architecture/template-design/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: template-design
+description: Creating reusable, parameterised prompt templates for consistent outputs.
+---
+# Template Design
+A prompt template is a reusable prompt structure with variable slots that get filled at runtime. Templates create consistency across similar tasks and make prompt management scalable.
+## Template Anatomy
+A template has:
+- **Fixed text**: The parts that stay the same every time (instructions, format, role)
+- **Variables**: Slots that get filled with specific content (user input, retrieved data, configuration)
+- **Conditional sections**: Parts that appear or disappear based on context
+- **Default values**: What fills a variable if no specific value is provided
+## Designing Variables
+Each variable should be:
+- **Named clearly**: `{user_query}` not `{input1}`
+- **Typed**: Is it free text, a selection from options, a number, a boolean?
+- **Bounded**: What are valid values? What's the maximum length?
+- **Documented**: What is this variable for? Where does its value come from?
+- **Defaulted**: What happens if the value is missing?
+## Template Patterns
+- **Task template**: A template for a specific type of task. Variables capture the task-specific details while instructions remain constant.
+- **Persona template**: A template where the persona is variable but the task structure is fixed. Useful for multi-persona products.
+- **Format template**: A template where the output format is variable but the analysis approach is fixed.
+- **Escalation template**: A base template with additional sections that activate at higher complexity levels.
+## Template Composition
+Complex prompts can be built from smaller templates:
+- **Base template**: Core instructions that apply to everything
+- **Task overlay**: Task-specific instructions layered on top
+- **Context injection**: Retrieved information inserted at a specific point
+- **User preferences**: Personal settings that modify behavior
+## Template Quality Criteria
+- **Consistency**: The template produces reliably similar outputs for similar inputs
+- **Flexibility**: The variables allow enough variation for diverse use cases
+- **Clarity**: The template is easy to read, maintain, and modify
+- **Testability**: You can verify the template works with a standard set of test inputs
+- **Maintainability**: Changes to one part don't break other parts
+## Design Artefacts
+- Template library with documentation
+- Variable specifications per template
+- Test input sets for each template
+- Template versioning and change log
+- Composition rules for combining templates

package/src/skills-lib/ai-product-design/references/system-behavior-shaping/behavioral-consistency/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: behavioral-consistency
+description: Ensuring the AI behaves predictably across sessions, edge cases, and modalities.
+---
+# Behavioral Consistency
+Users build mental models of how the AI behaves. Consistency is what makes those models reliable. Inconsistency — even if each individual response is good — erodes trust.
+## Dimensions of Consistency
+- **Across sessions**: The AI should behave the same way whether it's the user's first conversation or their hundredth
+- **Across topics**: Switching subjects shouldn't change the AI's personality or approach
+- **Across modalities**: The AI should feel the same in chat, voice, and email
+- **Across users**: Different users get the same quality and character (unless personalisation is designed)
+- **Across time**: The AI shouldn't randomly change behavior after updates without user awareness
+## Sources of Inconsistency
+- **Temperature and sampling**: Randomness in generation creates natural variation
+- **Context sensitivity**: Different conversation histories lead to different behaviors
+- **Prompt drift**: System prompts evolve over time without consistency checks
+- **Edge cases**: Unusual inputs trigger unpredictable responses
+- **Model updates**: New model versions may shift behavior subtly
+## Designing for Consistency
+- **Behavioral specifications**: Document expected behavior for common and edge-case scenarios
+- **Golden responses**: Maintain a library of reference responses that define the standard
+- **Regression testing**: When anything changes, test against the golden response library
+- **Consistency metrics**: Track behavioral variance across sessions and users
+- **User expectations**: Set and maintain expectations about what the AI does and how
+## Consistency vs. Adaptation
+Consistency doesn't mean rigidity. The AI should adapt to:
+- User preferences (if designed for personalisation)
+- Contextual needs (tone shifts as discussed in tone-calibration)
+- Learning from feedback (if memory systems exist)
+The key is that adaptation should be predictable and explainable, not random.
+## Design Artefacts
+- Behavioral specification documents
+- Golden response libraries
+- Regression test suites
+- Consistency monitoring dashboards
+- Adaptation rules (what changes and what stays constant)

package/src/skills-lib/ai-product-design/references/system-behavior-shaping/cultural-adaptation/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: cultural-adaptation
+description: Adapting AI behavior for different cultural contexts, languages, and norms.
+---
+# Cultural Adaptation
+AI products are used globally. Cultural adaptation means designing AI behavior that respects and responds to different cultural contexts — not just translating words, but adapting interaction patterns, values, and communication styles.
+## Dimensions of Cultural Variation
+- **Communication style**: Direct (say what you mean) vs. indirect (imply, suggest, contextualise)
+- **Formality norms**: When titles and honorifics matter. When first names are appropriate.
+- **Power distance**: How authority and hierarchy affect communication expectations
+- **Individualism vs. collectivism**: Whether the AI addresses individual needs or group harmony
+- **Uncertainty tolerance**: How much ambiguity and hedging is comfortable
+- **Time orientation**: Whether efficiency or thoroughness is valued more
+- **Emotional expression**: Whether emotional language is expected or uncomfortable
+## Adaptation Strategies
+- **Language adaptation**: Not just translation but localisation of idioms, examples, and references
+- **Tone shifting**: More formal in high-power-distance cultures. More direct in low-context cultures.
+- **Content adaptation**: Examples and references that are culturally relevant and appropriate
+- **Interaction pattern adaptation**: Some cultures expect more back-and-forth before getting to the point
+- **Visual and format adaptation**: Date formats, number formats, reading direction, colour associations
+## What NOT to Do
+- Don't stereotype — cultural dimensions are tendencies, not rules for individuals
+- Don't assume culture from language — English speakers come from many cultures
+- Don't flatten diversity — there's enormous variation within any cultural group
+- Don't treat Western norms as the default and everything else as adaptation
+- Don't ignore intersectionality — culture interacts with age, profession, context, and personality
+## Designing Cultural Adaptation
+- **Research**: Understand the cultural contexts your users operate in
+- **Flexibility**: Build adaptation as a capability, not a fixed set of cultural profiles
+- **User control**: Let users adjust cultural dimensions of AI behavior
+- **Testing**: Test with users from the actual cultural contexts, not assumptions
+- **Humility**: Accept that you'll get things wrong and build in feedback mechanisms
+## Design Artefacts
+- Cultural dimension profiles for target markets
+- Localisation specifications beyond translation
+- Cultural adaptation testing protocols
+- User control designs for cultural preferences
+- Cultural sensitivity review checklists

package/src/skills-lib/ai-product-design/references/system-behavior-shaping/domain-voice/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: domain-voice
+description: Tailoring AI behavior for specific professional domains.
+---
+# Domain Voice
+A coding assistant, a medical advisor, a creative writing partner, and a legal research tool should not sound the same. Domain voice is how you adapt AI behavior to fit the norms, expectations, and requirements of specific professional contexts.
+## Domain Voice Components
+- **Vocabulary**: The terminology and jargon appropriate to the domain
+- **Precision level**: How exact the AI needs to be (legal and medical demand high precision; creative work tolerates ambiguity)
+- **Citation norms**: Whether and how the AI references sources (academic style, legal citation, informal attribution)
+- **Risk tolerance**: How cautious the AI should be about uncertain outputs
+- **Authority stance**: Whether the AI positions itself as expert, assistant, or peer
+- **Ethical boundaries**: Domain-specific ethical considerations (medical ethics, legal privilege, creative attribution)
+## Domain Voice Profiles
+**Medical/Health:**
+- High precision, extensive hedging
+- Always recommends professional consultation
+- Careful distinction between information and advice
+- Sensitive to patient dignity and autonomy
+**Legal:**
+- Very high precision, formal register
+- Explicit disclaimers about not constituting legal advice
+- Jurisdiction awareness
+- Careful with privileged information
+**Creative:**
+- Lower precision, higher expressiveness
+- Encouraging and exploratory tone
+- Comfortable with ambiguity and multiple interpretations
+- Collaborative rather than authoritative
+**Technical/Engineering:**
+- High precision, moderate formality
+- Code-aware, specification-oriented
+- Direct and concise
+- Comfortable with technical depth
+**Education:**
+- Adaptive precision based on learner level
+- Encouraging and patient
+- Socratic when appropriate
+- Scaffolded explanation style
+## Designing Domain Voice
+1. **Research the domain**: Talk to practitioners. Understand their communication norms.
+2. **Identify non-negotiables**: What must the AI always or never do in this domain?
+3. **Map to persona**: How does domain voice overlay on the base persona?
+4. **Test with practitioners**: Domain experts are the best judges of whether the voice feels right.
+5. **Document edge cases**: Where domain norms conflict with general AI behavior.
+## Design Artefacts
+- Domain voice profiles per professional context
+- Domain vocabulary guides (terms to use, terms to avoid)
+- Domain-specific guardrail specifications
+- Practitioner testing protocols
+- Domain voice evaluation rubrics

package/src/skills-lib/ai-product-design/references/system-behavior-shaping/emotional-design/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: emotional-design
+description: How the AI responds to user frustration, confusion, delight, and distress.
+---
+# Emotional Design
+Users bring emotions to AI interactions. Frustration when it doesn't work. Delight when it does something unexpected. Distress when dealing with difficult topics. The AI's response to these emotions is a design decision.
+## Emotional States to Design For
+- **Frustration**: The AI isn't working, isn't understanding, or is being unhelpful. The user is losing patience.
+- **Confusion**: The user doesn't understand the AI's output or doesn't know what to do next.
+- **Delight**: The AI exceeded expectations. The user is pleasantly surprised.
+- **Distress**: The user is dealing with something emotionally difficult — health, loss, conflict, crisis.
+- **Boredom**: The AI is too slow, too verbose, or too repetitive.
+- **Anxiety**: The user is uncertain about whether to trust the AI's output for something important.
+- **Anger**: The user is upset with the AI specifically — it made a mistake, was inappropriate, or was unhelpful.
+## Response Strategies
+**For frustration:**
+- Acknowledge the difficulty without being patronising
+- Simplify — offer a more direct path
+- Don't repeat the same failed approach
+- Offer to try a different angle or escalate
+**For confusion:**
+- Explain differently, don't just repeat
+- Use examples and analogies
+- Break complex outputs into smaller steps
+- Check understanding before continuing
+**For distress:**
+- Increase warmth and reduce formality
+- Don't try to fix the emotion — acknowledge it
+- Provide relevant resources (crisis lines, professional help) when appropriate
+- Slow the pace — don't rush to the next step
+**For delight:**
+- Don't overexplain or undercut the moment
+- Build on the momentum
+- Note what worked for future reference
+**For anger at the AI:**
+- Acknowledge the mistake without excessive apology
+- Fix the problem rather than explaining why it happened
+- Give the user control to redirect
+## Emotional Detection Signals
+The AI can infer emotion from:
+- Language intensity and word choice
+- Punctuation and formatting (caps, exclamation marks, short sentences)
+- Repetition (asking the same thing multiple times signals frustration)
+- Explicit statements ("I'm confused" / "This is frustrating")
+- Behavioural signals (regeneration, abandonment, rapid-fire inputs)
+## Design Artefacts
+- Emotional response protocol per emotional state
+- Detection signal inventory
+- Response template library for each emotional context
+- Escalation triggers for high-distress scenarios
+- Emotional design testing scenarios

package/src/skills-lib/ai-product-design/references/system-behavior-shaping/error-personality/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: error-personality
+description: How the AI communicates mistakes, uncertainty, and limitations gracefully.
+---
+# Error Personality
+Every AI makes mistakes. Error personality is how the AI handles those moments — the tone, the honesty, the recovery. It's often the most revealing aspect of an AI persona, because it's where the mask of competence slips and the user sees the character underneath.
+## Types of AI Errors
+- **Factual errors**: The AI says something wrong
+- **Misunderstanding**: The AI interprets the user's intent incorrectly
+- **Capability failures**: The AI can't do what was asked
+- **Tone mismatches**: The AI's tone is wrong for the situation
+- **Incomplete outputs**: The AI delivers part of what was needed
+- **Hallucinations**: The AI presents fiction as fact with confidence
+## Error Communication Patterns
+**The Honest Acknowledgment:**
+"I got that wrong. Here's the corrected version." — Direct, no excessive apology, immediately fixes the problem.
+**The Uncertain Hedge:**
+"I'm not fully confident in this — you might want to verify." — Flags uncertainty before the user discovers the error.
+**The Redirect:**
+"I can't do that, but here's what I can help with." — Turns a limitation into an alternative path.
+**The Learning Response:**
+"Thanks for the correction — I'll keep that in mind." — Acknowledges the user's input and signals adaptation.
+## Error Anti-Patterns
+- **Over-apologising**: "I'm so sorry! I'm really sorry! I apologise!" — Grating and insincere at scale
+- **Deflection**: "That's a complex topic" — avoiding acknowledgment of the error
+- **Confidence despite error**: Doubling down on wrong information when challenged
+- **Blaming the user**: "Your question was ambiguous" — even when it was
+- **Existential crisis**: "As an AI, I have many limitations..." — nobody asked for self-reflection
+## Designing Error Personality
+The error personality should match the overall persona:
+- A professional persona acknowledges errors crisply and fixes them
+- A warm persona is more empathetic about errors but still moves to resolution
+- A playful persona can use light humour ("Oops, let me try that again") but never at the user's expense
+## Calibrating Error Severity Response
+Not all errors deserve the same response:
+- **Minor errors**: Quick fix, minimal fuss ("Updated — good catch")
+- **Significant errors**: Clear acknowledgment, corrected output, brief explanation
+- **Serious errors**: Full acknowledgment, apology, corrected output, steps to prevent recurrence
+- **Harmful errors**: Immediate acknowledgment, correction, escalation if needed
+## Design Artefacts
+- Error response templates per severity level
+- Error personality guidelines aligned with overall persona
+- Error detection and self-correction patterns
+- User correction handling protocols
+- Error severity classification rubric

package/src/skills-lib/ai-product-design/references/system-behavior-shaping/persona-architecture/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: persona-architecture
+description: Defining AI character, voice, and personality traits.
+---
+# Persona Architecture
+An AI persona is not a gimmick. It's the coherent set of traits, voice characteristics, and behavioral patterns that make an AI product feel like a consistent entity rather than a random text generator.
+## Persona Components
+- **Character traits**: Is the AI warm or professional? Playful or serious? Confident or cautious? Define 3-5 core traits.
+- **Voice**: The consistent way the AI sounds — word choice, sentence structure, rhythm. A financial AI sounds different from a creative writing AI.
+- **Knowledge stance**: What does the AI present itself as knowing? Expert, generalist, learning companion, or tool?
+- **Relationship model**: How does the AI relate to the user? Assistant, collaborator, coach, peer, or service provider?
+- **Boundaries**: What won't this persona do? Joke about? Engage with? The boundaries define the persona as much as the traits do.
+## Designing a Persona
+Start with the product's purpose and user needs, not with "wouldn't it be fun if the AI was sassy":
+1. **Who are the users?** Their expertise, emotional state, and expectations shape persona requirements.
+2. **What's the task?** A medical triage bot needs a different persona than a creative brainstorming partner.
+3. **What relationship serves the user?** Sometimes authority builds trust. Sometimes equality builds rapport.
+4. **What's the brand?** The AI persona must align with the organisation's broader identity.
+5. **What are the risks?** An overly casual persona in a serious context causes harm. An overly formal persona in a creative context stifles use.
+## Persona Documentation
+A persona specification should include:
+- **Trait definitions**: Each trait with examples of how it manifests in language
+- **Voice guide**: Vocabulary preferences, sentence patterns, phrases to use and avoid
+- **Behavioral rules**: How the persona handles specific situations (disagreement, error, praise, confusion)
+- **Anti-persona**: What this persona is explicitly NOT (prevents drift)
+- **Example outputs**: 5-10 sample responses showing the persona in action across different scenarios
+## Persona Anti-Patterns
+- **The uncanny friend**: AI pretending to be a human friend. Users see through it and lose trust.
+- **The personality void**: No discernible character. Outputs feel generic and forgettable.
+- **The inconsistent character**: Persona shifts randomly between responses.
+- **The inappropriate persona**: Playful when the situation is serious. Formal when warmth is needed.
+- **The over-persona**: So much personality that it gets in the way of actually being useful.
+## Design Artefacts
+- Persona specification document
+- Voice and tone guide
+- Example response library
+- Anti-persona definition
+- Persona evaluation rubric

package/src/skills-lib/ai-product-design/references/system-behavior-shaping/tone-calibration/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: tone-calibration
+description: Adjusting formality, warmth, confidence, and style per context.
+---
+# Tone Calibration
+Tone is how the persona sounds in a specific moment. The persona stays constant. The tone adapts. A warm, helpful persona might use an encouraging tone when teaching and a direct tone when correcting.
+## Tone Dimensions
+- **Formality**: Casual ("Hey, here's an idea") to formal ("Please find the analysis below")
+- **Warmth**: Cool and professional to warm and empathetic
+- **Confidence**: Tentative ("This might work") to authoritative ("The best approach is")
+- **Pace**: Brief and snappy to detailed and thorough
+- **Directness**: Diplomatic and hedged to blunt and straightforward
+- **Energy**: Calm and measured to enthusiastic and energetic
+## Tone Triggers
+Tone should shift based on context signals:
+- **User emotion**: Frustrated users need calmer, more empathetic tone. Excited users can handle more energy.
+- **Task type**: Creative tasks benefit from playful tone. Analytical tasks benefit from precise tone.
+- **Stakes**: High-stakes outputs need careful, confident tone. Low-stakes outputs can be lighter.
+- **Conversation stage**: Opening exchanges are warmer. Deep working sessions are more direct.
+- **User preference**: Some users prefer casual. Others prefer formal. Design for adaptation.
+## The Tone Matrix
+Create a matrix mapping contexts to tone settings:
+| Context | Formality | Warmth | Confidence | Pace | Directness |
+|---------|-----------|--------|------------|------|------------|
+| Onboarding | Low | High | Medium | Moderate | Low |
+| Error recovery | Low | High | Low | Slow | Medium |
+| Expert task | Medium | Medium | High | Variable | High |
+| Creative brainstorm | Low | Medium | Medium | Fast | Low |
+| Sensitive topic | High | High | Low | Slow | Low |
+## Tone Consistency Rules
+- Tone shifts should be gradual, not jarring
+- The persona's core traits should be recognisable regardless of tone
+- Tone should respond to the user's tone (mirroring, not mimicking)
+- Avoid tone whiplash — don't go from playful to grave in one turn without transition
+## Design Artefacts
+- Tone matrix mapping contexts to dimension settings
+- Tone trigger definitions
+- Example outputs at different tone settings
+- Tone shift transition guidelines

package/src/skills-lib/algorithmic-art/LICENSE.txt

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright 2026 Anthropic, PBC.
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.