Coding

Act as an AI workflow-governance architect. Audit {workflow} and decide whether it should remain a one-off prompt, become a reusable Skill, or mature into a Plugin with tools, state, and permissions. Inputs include {users and audience}, {five to ten recent real runs}, {repeated explanations or corrections}, {data and tool dependencies}, {cost of error}, {rate of change}, {owner}, and {compliance and privacy boundaries}. Start with an evidence inventory: 1. Extract recurring goals, inputs, steps, judgment criteria, corrections, and failure modes from the run samples. Separate stable rules from volatile facts. 2. Identify judgment that exists only in experienced people's heads and the time, quality, or consistency cost of re-explaining it. If data is missing, state Insufficient evidence instead of inventing a savings estimate. 3. Identify secrets, personal data, paid data, external writes, high-impact decisions, and actions that require human approval. Score all three options from one to five on reuse frequency, context stability, judgment complexity, tool dependency, state needs, team-distribution value, maintenance cost, error risk, and observability. Use these boundaries: - Keep a prompt for low-frequency or one-off work that depends mainly on current context and needs no persistent state, tool orchestration, or team versioning. - Create a Skill when the method, judgment criteria, and output structure recur; most steps are stable; and explicit triggers, templates, examples, and validation can make the work reusable. - Create a Plugin when the workflow needs multiple tools or integrations, identity and permissions, persistent state, external events, team distribution, or an independent version lifecycle. Recommend one option and write its minimum asset specification: name and objective, trigger and non-trigger conditions, required inputs, steps, tools and permissions, validation, failure and stop conditions, human confirmation points, examples, counterexamples, version owner, and review cadence. Never put secrets in prompts or examples. Keep frequently changing facts in an updateable external source. Finish with the smallest migration plan: implement the minimum asset, test it read-only or in a sandbox on three representative cases and two boundary cases, compare completion time, rework, errors, and consistency, and define a rollback path. If evidence does not justify escalation, recommend the current form and list the next run data to collect. Return: evidence summary, re-explanation tax, three-option scorecard, recommendation and counterevidence, minimum asset specification, test and rollback plan, and maintenance checklist.

You are an AI platform architect. Design an explainable, testable, progressively deployable model-routing policy for the application below. Do not send every request to the largest model by default. Application and user scenarios: {application} Primary task classes and examples: {task examples} Candidate models and known capabilities: {model inventory} Context windows and tool support: {context and tools} Quality and safety thresholds: {quality thresholds} Latency objectives: {latency} Cost budget and billing units: {cost} Privacy, data-residency, and compliance requirements: {privacy and compliance} Availability, concurrency, and rate-limit information: {runtime constraints} Allowed telemetry and feedback signals: {telemetry} First audit every time-sensitive input. If model price, regional availability, rate limits, context size, or capability lacks a dated source, label it "verification required" rather than treating it as current fact. Then return: 1. A task-classification table defining complexity, context, tools, privacy, accuracy, latency, and cost needs for each class, with positive examples and confusing counterexamples. 2. A routing decision table that filters models by hard constraints before ranking eligible options by quality, latency, and cost. Explain every rule; do not substitute brand reputation or one benchmark for task evidence. 3. Escalation and degradation rules covering when to move up from a small model, when to fall back to a compatible model, and how to handle timeout, rate limit, empty response, tool failure, and low confidence. Never silently weaken safety or privacy to stay online. 4. Budget controls for request, session, and daily limits, including what the system returns when a limit is reached, which tasks may continue after user confirmation, and which must stop. 5. An evaluation set with representative cases, expected behavior, scoring rubric, maximum latency, and cost-recording fields for every task class. Include multilingual, long-context, and failure-injection cases. 6. A rollout plan covering offline replay, shadow routing, limited traffic, rollback thresholds, and monitoring. Do not change production configuration directly. Finish with machine-readable pseudoconfiguration and a short team-facing decision note. Distinguish conclusions supported by supplied data from assumptions that require measurement.

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 an agent workflow architect. Turn the project below into a safe spec-build-review delivery loop. Project goal: {goal} Repository and runtime: {environment} Available tools and permissions: {tools and permissions} Time or cost limit: {budget} Actions requiring human approval: {human gates} Forbidden actions: {prohibited actions} Ask no more than five high-value questions that could materially change the design. If I cannot answer, state your assumptions and continue. Then provide: 1. Specification packet: scope, non-goals, dependencies, risks, acceptance criteria, and rollback conditions. 2. Build loop: split work into the smallest verifiable increments; define the input, action, expected artifact, validation command, and state record for every step. 3. Review loop: cover static checks, types, tests, browser behavior, security, data changes, and accessibility while keeping review scoped to the increment. 4. Orchestration rules: trigger, cadence, logs, retry cap, backoff, timeout, idempotency requirements, and stop conditions. 5. Human gates: identify checkpoints before releases, deletion, permission changes, purchases, external messages, and irreversible mutations. 6. Handoff report: completed work, evidence, failures, residual risks, recovery instructions, and the next loop entry point. Finish by simulating one complete loop for a minimal increment. Clearly distinguish planned, executed, and verified work. Never claim that a command ran or an external system changed unless evidence is provided. Stop after the same failure occurs twice and return diagnostics instead of retrying forever.

You are a multi-agent systems adviser. Select a control flow for the task below and design an executor-critic loop. Task: {task} Inputs and outputs: {inputs and outputs} Available tools: {tools} Risk level: {risk} Latency and cost limits: {limits} Success criteria: {success criteria} First decide which pattern fits: - Sequential: steps are fixed and branching is rare. - Reactive: the next action depends on the latest observation. - Planning: dependencies require a plan before execution. Explain the decision using task dependencies, environmental change, failure cost, and observability. If a hybrid is appropriate, provide the state transitions and boundaries. Second, design two independent roles: 1. The executor produces a candidate result and supporting evidence but never grades itself. 2. The critic checks correctness, completeness, sources, constraints, safety, and recoverability against a predefined rubric. Fluent wording is not evidence of success. Third, define a revision protocol capped at three rounds. Every round must return the failed rubric items, reproducible evidence, the smallest proposed correction, whether execution must be repeated, and a pass or stop decision. Do not let the roles share a hidden conclusion. When the critic cannot verify a claim, label it insufficient evidence. Finish with the recommended architecture, role prompts, state machine, scoring rubric, retry and stop rules, human escalation conditions, and one demonstration using sample input. Never let two model opinions automatically authorize a high-risk action.