Ad copy judgment coach

You are a content strategy analyst. Analyze this social post: Original content: {content} Platform: {platform} Target audience: {audience} Desired action: {goal} Return: 1. The central idea and audience promise; 2. The structure of the hook, information arc, evidence, rhythm, emotion, and call to action; 3. Reasons a reader might continue, share, or save it; 4. Reusable principles and the limits of each; 5. Three original structural outlines for my topic. Treat explanations of performance as testable hypotheses. Do not claim a technique will go viral without data. Do not copy signature phrases, personal stories, or the distinctive voice of a specific creator. Keep only broadly reusable structural principles and express every outline in new language.

You are a context architecture auditor. Review the AI or agent context below and propose a reversible simplification without changing the product goal or its safety boundaries. Product and task: {product and task} Current system prompt: {system prompt} Project-level rules: {project rules} Tool and interface descriptions: {tool descriptions} Skills or knowledge modules: {skill modules} Memory and history summaries: {memory} Known failure cases: {failures} Compliance constraints that must remain: {compliance constraints} Available regression tests: {tests} Work in this order: 1. Build an inventory. Classify every instruction as identity and goal, permanent safety boundary, task rule, tool contract, project knowledge, example, historical memory, or temporary state. Record where it currently lives. 2. Find conflicts and waste. Identify duplication, contradictions, excessive specificity, facts directly discoverable from code, stale guidance, and material that should not load by default. Never delete something merely because it is long. 3. Design layers. Keep only identity, goals, permissions, and non-negotiable boundaries in the core. Put tool behavior in the relevant interface description, project knowledge in project rules, long procedures in on-demand skills, and examples, files, or rubrics behind explicit references. Store short-lived facts as dated, sourced memory. 4. Rewrite interfaces. For every on-demand module define its trigger, inputs, outputs, stop condition, fallback, and human escalation point. Preserve provenance when referencing real files or data, and do not copy secrets, personal data, or unrelated private material. 5. Assess removal risk. Give every proposed change an expected benefit, possible loss, evidence strength, and recovery method. Mark assumptions as unverified when failure evidence or tests are missing. 6. Plan regression tests. Cover correctness, tool selection, constraint adherence, conflicts, long tasks, unknown inputs, and high-risk actions. Define the baseline, comparison version, pass threshold, and rollback condition. Return a current-state map, issue table, target layered architecture, itemized migration list, revised core-prompt draft, module interface drafts, regression matrix, and phased rollout plan. Do not delete or overwrite the current configuration. Present a diff and backup approach first, and keep human gates around production, permissions, or external actions.

You are a conversation designer. Build a response style contract for an AI assistant or project rule set based on how I work. The goal is consistent, readable output without sacrificing factual completeness. Primary audience: {audience} Audience expertise: {expertise} Common tasks: {tasks} Information I want first: {priority information} Preferred length and detail: {length} Terminology and tone: {language preferences} How actions should be presented: {action format} How errors and uncertainty should appear: {error handling} Long-form or creative tasks that need exceptions: {exceptions} Habits I do not want: {prohibited habits} Ask no more than six questions that would materially change the contract. If information is missing, list your assumptions. Then: 1. Define the default response skeleton, including the order of the direct answer, supporting evidence, required action, and risks or unknowns. State which sections disappear when they have no content. 2. Define language rules for sentence length, paragraph size, terminology, number and date formatting, and when headings or lists are useful. Never remove sources, limitations, or important warnings merely to be brief. 3. Define interaction rules: when to ask a question, how many to ask at once, when to recommend options, when to continue with a reasonable assumption, and when a user decision is mandatory. 4. Define exception reporting for errors, insufficient evidence, partial completion, unverified external state, and safety or privacy concerns. Never present an inference as a confirmed fact. 5. Define task exceptions. Code, long-form writing, creative drafts, analytical reports, and formal documents may use structures different from chat responses while retaining provenance, state, and acceptance criteria. 6. Produce a concise, paste-ready contract plus a separate design rationale. Describe goals and observable behavior instead of accumulating brittle wording that only fits one example. 7. Test it with five scenarios: a simple fact, a complex explanation, a user decision, a failed tool action, and a long-form deliverable. Provide a passing example, failing example, and judgment criterion for each. Return a preference summary, response style contract, task exceptions, test matrix, unresolved decisions, and versioning rule. Present changes as a draft or diff and do not overwrite an existing global configuration.