Turn commitments, strategic priorities, unresolved decisions, risks, and available capacity into an evidence-grounded executive plan for the week.
Updated Aug 17, 2026
Create an executive reset for [Planning week] using only the information supplied below.
Planning inputs
- Executive commitments and calendar: [Executive commitments and calendar]
- Strategic priorities and deadlines: [Strategic priorities and deadlines]
- Decision and delegation inventory: [Decision and delegation inventory]
- Team and stakeholder context: [Team and stakeholder context]
- Capacity and constraints: [Capacity and constraints]
- Prior-week evidence: [Prior week evidence]
Input requirements
The minimum reliable inputs are the planning week, dated commitments, current strategic priorities, and realistic capacity constraints. Decision inventory, stakeholder context, and prior-week evidence improve the result but may be incomplete.
If a missing date, timezone, immovable commitment, approval boundary, or capacity constraint could materially change the plan, ask only the blocking questions before proceeding. If the missing information is not blocking, produce a bounded draft and mark the affected items as unknown or unverified. Do not silently resolve contradictory dates, owners, priorities, or status reports.
Evidence and status rules
- Treat pasted calendars, notes, metrics, status reports, and explicit user statements as supplied evidence, not independently verified facts.
- Label material statements as Supplied fact, Assumption, Inference, Conflict, or Unknown.
- Distinguish completed work supported by evidence from reported complete, planned, blocked, deferred, and unverified work.
- Never claim that a meeting was changed, a message was sent, a decision was approved, a task was delegated, or a calendar event was created or cancelled unless the user supplies evidence that it occurred.
- ChatGPT may analyze the supplied materials and propose a plan. It cannot inspect private calendars, email, project systems, or live organizational data unless their contents are provided in the conversation, and it must not imply that it performed external actions.
Reset workflow
1. Establish the planning frame: identify the date range, timezone, hard deadlines, fixed commitments, available working capacity, recovery needs, and any explicit instructions from authorized decision-makers.
2. Reconcile the prior week: classify each carried item as completed with evidence, reported complete, still active, blocked, deliberately deferred, obsolete, or unknown. Preserve unresolved ownership and status conflicts.
3. Build a demand-versus-capacity view. Estimate fixed meeting load, focus-time demand, operational overhead, and contingency buffer using the supplied information. Show the method and flag any estimate that lacks duration data. Do not create false precision.
4. Rank no more than three weekly outcomes. For each, assess strategic impact, deadline pressure, executive leverage, consequence of delay, dependency readiness, effort, and confidence. Explain why excluded or deferred work falls below the cutoff.
5. Review the calendar commitment by commitment. Recommend Keep, Shorten, Delegate, Decline, Move, Combine, or Needs review. For every proposed change, state the purpose, opportunity cost, affected stakeholders, preparation required, and approval or communication needed. Treat all changes as proposals only.
6. Create a decision agenda. Separate decisions the executive can make now, decisions awaiting evidence, decisions owned elsewhere, and irreversible or high-consequence decisions requiring additional review. Include a deadline and cost of delay where supported.
7. Design delegations without assuming acceptance. Specify the proposed owner, desired outcome, authority granted, definition of done, deadline, check-in point, dependencies, and escalation trigger. Flag overloaded, unavailable, or unauthorized owners.
8. Map dependencies and stakeholders across outcomes, meetings, decisions, and delegations. Identify sequencing conflicts, single points of failure, and commitments that depend on unconfirmed responses.
9. Build a risk radar covering deadline slippage, decision latency, stakeholder misalignment, capacity overload, sensitive personnel matters, financial or legal exposure, and insufficient recovery time only where relevant to the supplied material. Give an early-warning indicator, mitigation, owner, and escalation threshold for each material risk.
10. Produce a realistic weekly operating rhythm: protected focus blocks, decision windows, meeting preparation, communication windows, buffer, and recovery periods. Do not schedule overlapping work or allocate all available capacity; expose unresolved overload instead.
11. End with the smallest safe actions for the next 24 hours, identifying which actions the user may take directly and which require authorization, confirmation, or stakeholder communication.
Authority, privacy, and safety boundaries
- Do not send messages, alter calendars, assign work, approve spending, make personnel decisions, or represent that stakeholders agreed. Draft recommendations or communications for human review only.
- Do not override stated organizational authority, confidentiality rules, employment obligations, legal review, financial controls, or security policy.
- Minimize reproduction of sensitive personal, personnel, customer, legal, health, credential, and financial information. Recommend redaction when details are unnecessary for planning.
- Mark high-impact, irreversible, personnel, legal, financial, security, or public commitments for explicit human approval.
- Stop and request clarification when conflicting instructions, uncertain authority, absent critical dates, or sensitive information make prioritization unsafe. Otherwise continue with clearly bounded assumptions.
Required output
A. Planning basis
- Planning period and timezone
- Supplied sources
- Assumptions, unknowns, and conflicts
- Fixed constraints and available capacity
- Confidence assessment with reasons
B. Prior-week reconciliation table
Columns: Item; Intended result; Current status; Evidence supplied; Carry, close, defer, or drop; Owner; Reason; Unresolved issue.
C. Executive outcome stack
Provide no more than three outcomes. Columns: Rank; Outcome stated as an observable result; Strategic link; Deadline; Impact; Cost of delay; Effort or capacity demand; Dependencies; Confidence; Acceptance evidence.
Then list deliberately deferred items with the trade-off behind each deferral.
D. Capacity and calendar audit
First show estimated meeting load, focus demand, overhead, buffer, and remaining capacity. Then provide columns: Commitment; Purpose; Recommendation; Time recovered or required; Opportunity cost; Stakeholders affected; Preparation; Authorization or communication needed; Evidence status.
E. Decision register
Columns: Decision; Decision owner; Decision type and reversibility; Deadline; Evidence available; Evidence missing; Options and trade-offs; Cost of delay; Recommended disposition; Approval state.
F. Delegation register
Columns: Proposed outcome; Proposed owner; Authority boundary; Definition of done; Deadline; Check-in; Dependencies; Escalation trigger; Acceptance status. Use Proposed or Unconfirmed until acceptance evidence is supplied.
G. Dependency and risk radar
Columns: Outcome affected; Dependency or risk; Early-warning indicator; Likelihood and impact using qualitative ratings; Mitigation; Owner; Escalation threshold; Residual uncertainty.
H. Weekly operating rhythm
Present a day-by-day plan containing fixed commitments, protected focus blocks, decision windows, preparation, communication, buffer, and recovery. Identify overload, collisions, and items that remain unscheduled rather than forcing them into the calendar.
I. Verification and acceptance checklist
For each check, provide Expected condition; Actual observation from supplied evidence; Evidence reference; Status as Pass, Fail, Unverified, or Not applicable; Resolution owner.
Include checks that:
- every top outcome has an observable result, owner, deadline, capacity allocation, and acceptance evidence;
- total proposed workload fits stated capacity with a visible buffer;
- calendar recommendations support the ranked outcomes;
- every decision and delegation has a valid owner and authority boundary;
- dependencies, stakeholder communications, and escalation triggers are represented;
- prior-week items reconcile without unsupported completion claims;
- conflicting dates, statuses, or priorities remain visible until resolved;
- no external action is described as executed without supplied evidence.
J. Next-24-hours handoff
List the smallest safe actions in order, with owner, timing, prerequisite, approval requirement, and intended evidence of completion. Finish with a short list of actions that remain proposed, blocked, or unverified.
Use Claude to produce an evidence-traceable literature review that maps themes, study quality, agreements, contradictions, uncertainty, and unresolved questions across a supplied source corpus.
Updated Aug 17, 2026
Synthesize the supplied literature into a traceable review that answers the stated question without inventing evidence, citations, source access, or certainty.
Review specification
- Review question: [Review question]
- Source corpus: [Source corpus]
- Scope and eligibility criteria: [Scope and eligibility criteria]
- Research context and constraints: [Research context and constraints]
- Appraisal framework: [Appraisal framework]
- Citation and output requirements: [Citation and output requirements]
Input requirements and blocking conditions
The minimum inputs are a defined review question, an inspectable source corpus, and criteria establishing what belongs in scope. Useful additional context includes the intended audience, date range, disciplines, jurisdictions, study designs, required appraisal method, and citation style.
Ask concise clarification questions before synthesis if the review question is materially ambiguous, the source corpus is unavailable, eligibility rules would change which evidence is included, or conflicting instructions cannot be reconciled. If clarification is unavailable but bounded work remains safe, proceed only with an explicitly labeled provisional scope and preserve unresolved matters as unknowns. If full text is missing, distinguish abstract-only assessment from full-text assessment. If the corpus is too large for reliable analysis in one pass, propose batches, define a stable extraction schema, and do not imply that unread sources were reviewed.
Claude access and action boundaries
Analyze only content actually supplied in the conversation, attached files Claude can inspect, and any external material accessed through tools that are explicitly available and authorized. Do not claim to have opened a file, followed a citation, searched a database, checked a retraction, or verified a current status unless that action occurred and evidence is available. If authorized browsing is used, record the query or URL, access date, and result. Otherwise, mark external verification as not performed.
Do not purchase content, bypass access controls, contact authors, alter source files, submit registrations, publish the review, or make approval decisions. Treat publication, policy adoption, clinical application, legal reliance, and other consequential uses as requiring qualified human review. Minimize reproduction of copyrighted text, quote only when necessary and exact, and redact unnecessary personal, confidential, or sensitive information. Stop and request guidance if the materials appear unlawfully obtained, expose sensitive participant data, or require unsafe disclosure.
Evidence rules
1. Keep supplied facts, direct source findings, reviewer interpretations, assumptions, hypotheses, conflicts, and unknowns distinct.
2. Give every material factual statement a traceable source identifier and, when available, a page, section, table, figure, or paragraph locator. Never invent bibliographic fields or locators.
3. Preserve the difference between primary studies, reviews, protocols, commentaries, preprints, and other source types. Identify when multiple publications appear to report the same underlying study so they are not double-counted.
4. Extract the population or corpus, setting, design, sample, intervention or exposure, comparator, outcomes, measures, follow-up, and relevant numerical results when applicable. Preserve effect direction, effect size, uncertainty interval, denominator, and adjustment status rather than reporting significance alone.
5. Separate statistical significance, practical significance, methodological quality, and confidence in a conclusion. Do not infer causation from observational association or treat an absence of evidence as evidence of no effect.
6. Apply the specified appraisal framework consistently. If none is specified, recommend a framework suited to the included study designs and obtain confirmation when framework choice could materially affect conclusions. Do not fabricate scores for unreported information.
7. Explain heterogeneity before combining findings. Do not pool estimates or perform a meta-analysis unless compatible data and an authorized, defensible method are available. Label any informal comparison as narrative synthesis.
8. Present credible disagreements rather than forcing consensus. Examine design, population, setting, measurement, comparator, timing, analytic choices, funding, conflicts of interest, publication status, and risk of bias as possible explanations.
9. Flag inaccessible full text, missing data, suspected duplicates, corrections, retractions, inconsistent citations, selective reporting, and sources whose status could not be checked.
Synthesis workflow
1. Translate the review question into operational concepts, boundaries, and decision-relevant subquestions. Record any provisional interpretation.
2. Build a source inventory with a stable source ID for every supplied item. Capture source type, year, access level, eligibility decision, exclusion reason, duplicate or companion-report relationship, and verification status.
3. Apply the eligibility criteria consistently. Do not silently discard unfavorable, null, contradictory, low-quality, or inconvenient findings.
4. Extract evidence at the study-and-outcome level into a structured matrix. Use “not reported” or “not assessed” rather than guessing.
5. Appraise each included source using the chosen framework or a clearly described domain-based assessment. Show the evidence supporting each judgment and distinguish study limitations from reporting omissions.
6. Group findings into themes derived from the review question and corpus. For each theme, state the claim, supporting and opposing evidence, relevant populations and settings, consistency, methodological limitations, and confidence.
7. Analyze agreements and disagreements. Determine whether apparent conflict may reflect genuinely opposing results, different constructs, incomparable outcomes, subgroup effects, time periods, settings, methods, or precision.
8. Assess transferability and evidence gaps. Identify populations, outcomes, time horizons, geographies, study designs, and mechanisms that are missing or underrepresented.
9. Test the synthesis against plausible alternative interpretations and influential sources. Explain whether excluding high-risk, abstract-only, preprint, duplicate, or outlier evidence would materially change a conclusion; if this cannot be assessed, say so.
10. Reconcile the final narrative against the source inventory and evidence matrix before presenting conclusions.
Required deliverable
A. Review scope and status
- Operational review question and subquestions
- Scope, eligibility rules, assumptions, deviations, and unresolved ambiguities
- Corpus coverage: supplied, inspected, included, excluded, duplicate or companion records, and unreadable or incomplete records
- Synthesis status: complete for the supplied corpus, provisional, partially blocked, or blocked, with reasons
B. Source disposition table
Include source ID, short citation, source type, full-text or abstract-only status, eligibility decision, exclusion reason, duplicate or companion relationship, correction or retraction status if actually checked, and access or verification notes.
C. Evidence matrix
For each included source, include source ID; research aim; design; population or material; setting; sample size; intervention or exposure; comparator; outcomes and measures; key qualitative or quantitative results; uncertainty information; limitations; funding or conflicts when reported; appraisal judgments; and exact evidence locators. Mark non-applicable and unreported fields explicitly.
D. Thematic synthesis
For each theme, provide:
- A precise synthesis claim
- Supporting, null, and opposing evidence with source IDs
- The populations, settings, outcomes, and time horizons to which the claim applies
- Consistency and heterogeneity analysis
- Methodological and reporting limitations
- Confidence rating using the specified framework, or a transparent descriptive rating if authorized
- A calibrated conclusion that does not exceed the evidence
E. Agreement and contradiction register
List each material agreement or conflict, the sources involved, whether comparison is valid, plausible explanations, evidence that favors an explanation, unresolved uncertainty, and what additional evidence would discriminate between interpretations.
F. Bias, credibility, and applicability assessment
Address selection and publication bias where assessable; study-level risk of bias; selective reporting; measurement validity; confounding; funding and declared conflicts; publication status; corpus limitations; and transferability to the intended context. Do not claim that bias is absent merely because it was not reported.
G. Evidence gaps and open questions
Rank unanswered questions by decision relevance and evidentiary importance. For each, identify the missing evidence, why existing sources cannot answer it, and an appropriate study type or data source that could reduce uncertainty.
H. Verification and acceptance record
Report each check as passed, failed, blocked, or not applicable, with the actual observation and supporting evidence:
- Inventory reconciliation: every supplied record has one documented disposition, and record totals reconcile
- Coverage: every included source appears in the evidence matrix and every excluded source has a reason
- Traceability: every material synthesis claim maps to one or more source IDs and available locators
- Fidelity: quoted text and numerical values match the inspected source, including units, denominators, direction, and uncertainty
- Duplicate control: companion reports are linked and underlying studies are not counted repeatedly as independent evidence
- Appraisal consistency: equivalent evidence receives equivalent judgments, with departures explained
- Contradiction preservation: material null and opposing findings remain visible
- Scope control: conclusions do not extend beyond studied populations, settings, outcomes, or designs without an explicit transferability caveat
- Status integrity: unread, inaccessible, or externally unverified material is not described as reviewed or verified
- Requirement compliance: citation style, appraisal method, length, and audience requirements are satisfied or listed as unresolved
I. Human-review handoff
List the conclusions requiring subject-matter review, unresolved citation or source-status checks, sensitive-data concerns, decisions needing approval, and the smallest safe next step. Describe the work as completed or verified only to the extent demonstrated by the acceptance record.
Design an evidence-informed lesson that adapts instruction, pacing, practice, and assessment to learner readiness, misconceptions, and required accommodations.
Updated Aug 17, 2026
Create an adaptive lesson plan from the inputs below. The plan must show how evidence gathered before and during instruction changes pacing, explanation, grouping, practice, support, or extension.
Inputs
- Learning goal: [Learning goal]
- Learner profile: [Learner profile]
- Instructional context: [Instructional context]
- Time and resources: [Time and resources]
- Curriculum and assessment requirements: [Curriculum and assessment requirements]
- Source materials and evidence: [Source materials and evidence]
- Required accommodations: [Required accommodations]
- Definition of success: [Definition of success]
Input and evidence rules
1. Treat the learning goal, learner stage, instructional setting, and available duration as blocking prerequisites. If any is absent or too ambiguous to support a coherent plan, ask no more than five focused questions and stop before drafting the full lesson.
2. Continue with bounded assumptions only when missing details are low risk. Label each assumption and explain how it affects the plan. Preserve unresolved conflicts instead of silently choosing one interpretation.
3. Separate supplied facts, evidence from learner work or assessment data, reasonable inferences, assumptions, unknowns, and conflicts. Do not invent learner performance, curriculum requirements, citations, standards, accommodations, or resource availability.
4. Use learner evidence such as prior responses, error patterns, reading or language demands, prerequisite mastery, and formative checks. Do not infer ability, disability, motivation, identity, or diagnosis from demographic information or limited performance data.
5. If curriculum standards are supplied, retain their identifiers and wording accurately. If they are not supplied, describe the intended competency without claiming formal standards alignment.
Planning workflow
1. Translate the learning goal into measurable lesson objectives. Identify prerequisite knowledge, essential vocabulary, likely cognitive demands, and what acceptable evidence of learning would look like.
2. Review the supplied learner evidence. Identify demonstrated strengths, unfinished learning, likely misconceptions, accessibility needs, and unknowns. For every inferred misconception, state the evidence or mark it as a hypothesis to test.
3. Design a brief entry diagnostic that reveals prerequisite readiness without consuming disproportionate lesson time. Provide the questions or tasks, expected responses, common error signals, and interpretation rules.
4. Build a timed instructional sequence with an opening, explicit instruction or modeling, guided practice, independent or collaborative application, formative checks, and closure. Ensure the minutes reconcile with the available duration and include realistic transition time.
5. Create adaptive decision rules. Each rule must include an observable trigger, a threshold where appropriate, the instructional response, the time impact, and a follow-up check. Include at least these pathways when relevant:
- prerequisite gap or widespread misconception;
- partial understanding requiring another representation or scaffold;
- expected progress allowing the core sequence to continue;
- early mastery requiring meaningful extension rather than extra routine work;
- insufficient or contradictory evidence requiring another check instead of a conclusion.
6. Sequence practice from supported to independent performance. Vary representations and response modes where useful while preserving the intended rigor. Distinguish scaffolds that can fade from accommodations that must remain available.
7. Design formative checks at decision points and an end-of-lesson assessment aligned to each objective. Supply prompts or tasks, expected answers or performance indicators, scoring criteria, likely error patterns, and feedback moves. Avoid assessing content or skills that the lesson does not teach or intentionally activate as prior knowledge.
8. Address required accommodations and accessibility without changing the target construct unless the supplied requirements authorize a modification. Check language load, readability, sensory access, assistive-technology compatibility, response options, cultural assumptions, and unnecessary barriers.
9. Identify implementation risks such as overpacked timing, weak prerequisite evidence, stigmatizing grouping, inaccessible materials, technology failure, answer leakage, or an adaptation that lowers rigor. Give a practical mitigation and fallback for each material risk.
10. Audit the completed design against the acceptance checks below and reconcile it with the stated definition of success.
Authority, safety, and tool boundaries
- ChatGPT may analyze only the information provided in the conversation and may draft lesson materials, decision rules, assessments, and review checks. It cannot observe learners, access school systems or files that were not supplied, administer the lesson, verify classroom results, contact learners, assign grades, approve accommodations, or publish materials.
- Treat the result as a draft for educator review. A qualified educator must approve curriculum alignment, assessment use, grouping decisions, accommodations, and any consequential learner decision.
- Do not include personally identifying learner information in the output. Refer to individuals or groups with neutral, de-identified labels. If sensitive data is supplied unnecessarily, recommend replacing it with the minimum relevant educational evidence.
- Do not diagnose learning needs or override an individualized education plan, accessibility plan, safeguarding rule, or institutional policy. If requirements conflict, identify the conflict and mark the affected decision as blocked pending authorized review.
- Flag lessons involving laboratories, physical activity, sensitive topics, external media, or regulated assessment for the appropriate safety, safeguarding, copyright, or assessment-security review. Do not invent local procedures.
- Describe lesson delivery and learner outcomes as proposed or predicted unless actual observations are supplied. Never claim the lesson was taught, tested, verified, approved, or successful without corresponding evidence.
Required output
A. Planning basis
- Lesson topic and measurable objectives
- Blocking questions, if any
- Evidence register with columns: item, classification, source, planning implication, confidence, and unresolved issue
- Prerequisite map and key vocabulary
B. Learner-readiness analysis
- Demonstrated strengths
- Unfinished learning or prerequisite gaps supported by evidence
- Misconception hypotheses and how each will be tested
- Accessibility and accommodation requirements
- Unknowns that limit personalization
C. Alignment map
Provide a table with columns: objective, learning activity, formative evidence, end-of-lesson evidence, success criterion, and curriculum requirement. Every objective must have both instruction and assessment evidence.
D. Timed lesson sequence
Provide a table with columns: minutes, phase, educator move, learner action, materials, evidence collected, adaptive decision, and accessibility support. Show the planned total and confirm whether it matches the available duration.
E. Adaptive decision matrix
Provide a table with columns: decision point, observable trigger, threshold or interpretation rule, response, pacing impact, follow-up check, and escalation condition. Include concrete reteaching, alternate-representation, scaffold, continuation, and extension options where relevant.
F. Assessment and practice pack
- Entry diagnostic with interpretation guide
- Guided-practice tasks
- Independent or collaborative application task
- Formative-check prompts at each decision point
- End-of-lesson assessment
- Teacher answer key or performance indicators
- Scoring criteria and feedback moves
Clearly identify which objective each item measures.
G. Accessibility, differentiation, and grouping plan
- Required accommodations that remain in force
- Optional scaffolds and criteria for fading them
- Extension that increases depth or transfer without introducing unrelated work
- Flexible grouping purpose, evidence basis, regrouping trigger, and anti-stigma safeguard
- Accessible fallback for any technology-dependent activity
H. Risk and contingency register
Provide a table with columns: risk, warning sign, likely consequence, prevention, in-lesson fallback, and human approval needed.
I. Verification and handoff
Evaluate each acceptance check as Pass, Needs review, or Blocked, and cite the relevant section as evidence:
- Every objective is taught, practiced, and assessed.
- The planned minutes, including transitions and checks, equal the available duration.
- Every claimed misconception is supported by evidence or explicitly treated as a hypothesis.
- Every adaptive pathway has an observable trigger and a follow-up check.
- Assessment items measure the intended objective and have usable scoring criteria.
- Required accommodations are preserved, and optional scaffolds do not unintentionally reduce rigor.
- Grouping and differentiation decisions avoid unsupported learner labels.
- Material and technology dependencies have feasible fallbacks.
- The lesson satisfies the stated definition of success, or any mismatch is recorded.
- No classroom outcome, approval, or completed action is claimed without evidence.
Finish with a post-lesson evidence log containing fields for expected observation, actual observation, evidence source, discrepancy, interpretation, and revision decision. Set actual observations to “Not observed” unless real post-lesson evidence was supplied.
Design an implementation-ready no-code automation covering triggers, actions, data mappings, API contracts, controls, failure recovery, alerts, ownership, testing, and release gates.
Updated Aug 17, 2026
Create an implementation-ready blueprint for the following no-code automation. Analyze only the information supplied in this conversation. ChatGPT may structure requirements, inspect pasted evidence, identify conflicts, and propose a design; it cannot access external systems, validate live endpoints, configure integrations, run tests, deploy workflows, or approve a release unless direct evidence of those actions is supplied.
Inputs
- Workflow objective: [Workflow objective]
- Systems and owners: [Systems and owners]
- Trigger and scope: [Trigger and scope]
- Data and API evidence: [Data and API evidence]
- Constraints and controls: [Constraints and controls]
- Failure and recovery requirements: [Failure and recovery requirements]
- Acceptance criteria: [Acceptance criteria]
Input gate
Treat the objective, initiating event or schedule, participating systems, intended outcome, accountable owner, and material constraints as blocking prerequisites. Treat sample payloads, field schemas, API documentation, authentication method, volume estimates, rate limits, historical errors, and platform preferences as optional only when they are not needed to make a safe design decision.
If a blocking prerequisite is missing, ambiguous, or contradictory, ask concise questions before presenting a final blueprint. You may still provide a clearly labeled bounded draft for confirmed portions. Preserve unresolved details as unknowns; do not invent endpoints, fields, credentials, platform capabilities, limits, test results, approvals, or business rules.
Evidence and claim rules
1. Classify material statements as supplied fact, observation from supplied evidence, assumption, hypothesis, conflict, or unknown.
2. Cite the relevant supplied artifact, excerpt, example payload, log entry, or requirement when making a consequential design decision. If no evidence identifier exists, assign a simple source label such as Input 1 or Payload A.
3. Separate proposed behavior from existing behavior and from behavior demonstrated by execution evidence.
4. Use verified only when supplied evidence demonstrates the check and its result. Mark tests without execution evidence as Not run. Never claim that a workflow was built, fixed, tested, deployed, approved, sent, deleted, or completed based solely on this blueprint.
Blueprint method
1. Define the workflow boundary: business event, start condition, included and excluded records, expected outcome, frequency or volume, latency target, duplicate-event policy, and completion condition.
2. Model the trigger. Specify whether it is a webhook, polling trigger, schedule, manual event, or application event; document filters, cursor or checkpoint behavior, payload validation, authentication, replay behavior, ordering assumptions, and the effect of delayed or duplicated delivery.
3. Map the end-to-end path from trigger through lookups, transformations, branches, approvals, writes, notifications, and terminal states. Give each step a stable identifier. For every step, identify its system, operation, input, output, precondition, success condition, timeout, and owner.
4. Review each integration contract using the supplied evidence. Capture endpoint or connector operation, method where applicable, authentication, required parameters, request and response schema, status or error behavior, pagination, rate limits, versioning, webhook signature checks, and relevant platform limitations. Do not infer undocumented API behavior as fact.
5. Build a field-level data map. Include source path, source type, required or optional status, transformation, validation, destination field, destination type, default or null behavior, sensitivity classification, retention concern, and invalid-value handling. Identify lossy conversions, locale and time-zone risks, identifier mismatches, and schema drift.
6. Design control flow for filters, routers, loops, batching, concurrency, human approvals, and partial success. Make branch precedence and terminal outcomes explicit. Flag any path that can create unintended repeated actions or bypass an approval.
7. Design reliability controls. Address idempotency keys, deduplication windows, retries, exponential backoff, maximum attempts, timeouts, rate-limit handling, checkpointing, dead-letter or exception queues, replay procedures, ordering, compensating actions, and reconciliation after partial writes. Explain trade-offs such as latency versus batching, strict ordering versus throughput, and retrying versus duplicate side effects.
8. Define failure handling by failure class: invalid input, authentication failure, authorization failure, rate limiting, timeout, provider outage, malformed response, mapping failure, duplicate event, downstream rejection, and partial completion. For each, state detection signal, automatic response, retry eligibility, escalation threshold, record state, recovery action, and accountable owner.
9. Define observability and ownership. Specify run identifiers, correlation identifiers, safe logs, metrics, dashboards or run-history views, alert severity, alert channel, routing owner, acknowledgement target, escalation path, support handoff, and audit evidence. Exclude secrets and minimize personal or sensitive data in logs and alerts.
10. Apply security and operational controls: least-privilege connections, secret storage outside prompt text, data minimization, environment separation, sandbox fixtures, access review, change approval, kill switch or pause procedure, rollback or disablement plan, retention rules, and audit trail. Flag legal, privacy, financial, or contractual questions for qualified human review rather than resolving them without evidence.
11. Identify consequential steps requiring explicit human authorization, including production enablement, credential creation or rotation, destructive writes, bulk updates, payments, customer communications, permission changes, or transfer of regulated data. Do not instruct ChatGPT to perform these actions. Require dry runs, scoped test records, backups or compensating controls, and named approval evidence where proportionate.
12. Create a verification matrix covering at least: valid event, missing required field, invalid type or format, duplicate event, delayed or out-of-order event, branch boundaries, authentication failure, rate limit, timeout, retry exhaustion, malformed response, partial downstream success, alert delivery, replay, rollback or disablement, reconciliation, and expected-volume behavior. Add workflow-specific cases from the supplied risks.
13. Reconcile the proposed design against every supplied acceptance criterion. Mark each criterion Pass only when execution evidence exists, Fail when evidence contradicts it, Not run when testing has not occurred, or Blocked when a prerequisite is unavailable. State the smallest safe next action and the human role authorized to take it.
Stop conditions
Stop short of a release recommendation when required contracts are unknown, sensitive data handling is unresolved, destructive behavior lacks recovery controls, credentials or production access would be exposed, ownership is unassigned, acceptance criteria are absent, or critical tests are failed, blocked, or not run. Recommend a sandbox or read-only validation step instead.
Required output
Produce the following task-specific deliverable in Markdown:
1. Blueprint status
- State: Ready for implementation review, Bounded draft, or Blocked
- One-paragraph workflow outcome and boundary
- Blocking questions and unresolved conflicts
2. Evidence and assumptions register
A table with ID, statement, classification, source evidence, confidence, design impact, and validation owner.
3. Workflow specification
A table with step ID, trigger or action, system, operation, inputs, outputs, preconditions, branch rule, success condition, timeout, failure route, and owner. Follow it with a compact numbered flow showing all terminal states.
4. Trigger and integration contract review
Separate tables for trigger semantics and connector or API contracts. Include undocumented behavior, compatibility concerns, rate limits, pagination, authentication, versioning, and contract decisions.
5. Data mapping and validation dictionary
A field-level table with source path and type, required status, transformation, validation, destination path and type, null or default behavior, sensitivity, and invalid-data disposition.
6. Reliability and recovery design
Document idempotency, duplicate suppression, retry policy, checkpointing, replay, partial-write handling, reconciliation, rollback or disablement, recovery ownership, and key trade-offs.
7. Failure, alert, and ownership matrix
A table with failure class, detection evidence, record state, automated response, escalation threshold, alert destination, acknowledgement target, recovery procedure, and accountable owner.
8. Security and approval gates
List data protections, least-privilege requirements, logging restrictions, environment controls, consequential actions, required approver, required approval evidence, stop conditions, and residual risks.
9. Verification matrix
A table with test ID, scenario, fixture or precondition, execution steps, expected observation, actual observation, status, evidence reference, cleanup or recovery, and owner. Unless supplied execution evidence exists, keep actual observation unavailable and status Not run or Blocked.
10. Acceptance and release handoff
Map each acceptance criterion to evidence and status; list implementation dependencies, platform configuration decisions, open risks, required reviewers, release gate, rollback readiness, and the smallest safe next action. Distinguish explicitly among proposed, configured, executed, verified, approved, and deployed states.
Design an evidence-based founder content engine that turns authentic insights, customer stories, lessons, and business priorities into governed, measurable social content.
Updated Aug 16, 2026
Build a founder-led content system from the inputs below. The system must preserve the founder’s authentic point of view, connect content to business priorities, and be practical for the available publishing capacity.
Inputs
- Founder and business context: [Founder and business context]
- Content goals and business priorities: [Content goals and business priorities]
- Audience and channels: [Audience and channels]
- Founder source materials: [Founder source materials]
- Brand voice and boundaries: [Brand voice and boundaries]
- Publishing capacity and workflow: [Publishing capacity and workflow]
- Measurement window and baseline: [Measurement window and baseline]
Input and tool rules
1. Treat the founder and business context, intended audience, target channels, at least one business priority, and some authentic founder source material as minimum inputs. Useful optional context includes past posts, performance data, customer research, competitor examples, campaign dates, offers, and approval owners.
2. Use only information supplied in the conversation or made accessible through explicitly enabled ChatGPT tools. Do not claim to have opened a link, reviewed an account, queried analytics, scheduled a post, contacted anyone, or published content unless that action actually occurred and evidence is available.
3. Ask concise clarification questions only when missing information would prevent a credible strategy, create a material brand or legal risk, or make the proposed cadence infeasible. If answers are unavailable, produce a clearly marked provisional system, preserve unknowns, and explain what cannot yet be finalized.
4. Classify material statements as supplied fact, source-backed observation, assumption, hypothesis, conflict, or unknown. Do not convert assumptions into founder opinions, customer facts, performance results, or market evidence.
5. When sources conflict, display the conflict and its implications instead of silently choosing one version. Reference the supplied source supporting each proposed story, opinion, lesson, or factual claim.
Authority, privacy, and editorial controls
- Produce analysis, recommendations, workflows, templates, and ready-for-human-review drafts. Do not publish, schedule, approve, send, or represent that the founder has endorsed any draft.
- Require named human approval before publication, material claim approval where relevant, and explicit permission before using identifiable customer or employee stories, quotations, private communications, testimonials, or sensitive business information.
- Never fabricate quotes, customer outcomes, founder experiences, credentials, partnerships, product capabilities, statistics, or audience reactions. Use a clearly marked verification placeholder in draft copy when a claim lacks support.
- Minimize personal and confidential data. Recommend anonymization or composite-free reframing where a story can be told without identifying a person. Do not create fictional composite testimonials.
- Flag legal, regulatory, reputational, employment, intellectual-property, confidentiality, and platform-policy concerns. Stop the affected content item and request qualified human review when it involves allegations, undisclosed endorsements, regulated claims, pending litigation, confidential events, vulnerable individuals, or uncertain publication rights.
- Separate proposed metrics from measured results. Do not describe content as tested, approved, published, successful, or verified without corresponding execution evidence.
Workflow
1. Diagnose the operating context. Translate the goals into explicit content outcomes, audience actions, channel roles, constraints, approval needs, and capacity limits. Identify blockers, useful unknowns, and any incompatible goals.
2. Build a source and evidence register. Extract founder opinions, recurring lessons, original frameworks, customer problems, customer stories, operating decisions, mistakes, contrarian views, and business priorities. Record the source, confidence, permission status, sensitivity, potential claim risk, and whether the item is usable, needs verification, needs consent, or must be excluded.
3. Define the founder narrative. Formulate the core audience promise, three to five defensible points of view, relevant credibility signals, topics the founder should own, topics to avoid, voice characteristics, and boundaries against generic thought leadership. Distinguish documented founder views from suggested positions requiring confirmation.
4. Create the content architecture. Develop three to six content pillars tied to audience needs and business priorities. For each pillar, define its purpose, source types, suitable formats, funnel role, intended audience response, proof requirements, call-to-action options, risks, and indicators of overuse.
5. Design the idea-generation method. Convert source material into a traceable idea bank using formats such as lesson, customer problem, operating story, decision breakdown, myth correction, framework, informed opinion, behind-the-scenes process, and business-priority narrative. Avoid unsupported trend commentary and superficial topic variations.
6. Define channel adaptation. Assign a distinct role to each selected channel and explain how hooks, length, structure, media, calls to action, frequency, and conversation handling should change by channel. Do not duplicate identical copy across channels unless a reason is documented.
7. Build the editorial queue. Create a realistic four-week queue or a shorter capacity-appropriate period. Balance pillars, audience stages, formats, founder effort, promotional intensity, and timely business priorities. Every item must link to a source-register entry and include its objective, channel, format, hook, key point, evidence needs, call to action, owner, approval state, and target timing.
8. Design capture and production operations. Specify how raw founder material is collected through interviews, voice notes, meetings, customer conversations, or written notes; how it becomes briefs and drafts; and how review, fact-checking, consent, revision, approval, publication, community response, reuse, and archiving are handled. Include owners, handoffs, service expectations, and a route for blocked items.
9. Produce reusable editorial assets. Create interview prompts, a source-note template, a post brief, a voice review rubric, a claim-check procedure, and channel-specific drafting patterns. Also provide three representative draft posts when the evidence is sufficient; otherwise provide structured outlines showing exactly what evidence or founder input is missing.
10. Establish measurement and learning. Define leading and lagging indicators aligned with the stated goals, including calculation method, data source, baseline status, review frequency, attribution limits, and decision thresholds. Propose controlled editorial experiments that change one meaningful variable at a time where practical.
11. Verify the complete system. Reconcile the proposed cadence with capacity, each idea with an authentic source, each factual claim with evidence, each customer story with permission status, each call to action with a business priority, and each metric with an available data source. Leave failed checks unresolved rather than implying completion.
Required deliverable
A. Decision brief
- Business outcome, audience, selected channels, capacity, constraints, approval authority, blocking questions, assumptions, conflicts, and unresolved unknowns.
B. Source and evidence register
- Table columns: source ID, source description, extracted insight or story, classification, confidence, permission status, sensitivity, claim support, permitted use, and required follow-up.
C. Founder narrative and voice specification
- Audience promise, confirmed points of view, proposed points of view awaiting confirmation, credibility basis, differentiators, voice rules, prohibited patterns, sensitive topics, and examples of on-voice versus off-voice phrasing.
D. Content-pillar matrix
- Pillar, audience need, business connection, source pool, suitable formats, funnel role, proof standard, call-to-action options, risk, and success signal.
E. Traceable idea bank
- At least 12 ideas when source depth supports them; otherwise provide the defensible number. Include idea ID, source ID, angle, intended reader, channel, format, hook, key takeaway, evidence requirement, call to action, and readiness state.
F. Channel and repurposing map
- Channel role, native format rules, adaptation requirements, publishing frequency, engagement approach, and rules for transforming one source into multiple non-duplicative assets.
G. Capacity-aware editorial queue
- A four-week or justified shorter schedule with item ID, pillar, source ID, objective, channel, format, hook, evidence status, permission status, owner, approver, target timing, and workflow state.
H. Production and governance playbook
- Capture process, interview prompts, brief template, drafting procedure, fact check, consent check, voice review, approval gate, publication handoff, response protocol, reuse rules, archive method, escalation path, and responsibility matrix.
I. Draft assets
- Three source-grounded drafts or evidence-gap outlines. Annotate any unverified claim, consent dependency, founder-confirmation point, and channel-specific adaptation decision. Keep drafts in ready-for-review rather than approved status.
J. Measurement and experiment plan
- Goal-to-metric map with metric definition, formula, source, baseline, review interval, interpretation limits, and threshold for continue, revise, or stop. Include an experiment backlog with hypothesis, single primary variable, comparison method, minimum observation window, confounders, and decision rule.
K. Verification and acceptance record
- For each check, report expected condition, actual observation based on supplied material, evidence reference, status, and remediation owner. Check source traceability, voice fidelity, factual support, permissions, privacy, channel fit, pillar balance, promotional balance, cadence feasibility, approval coverage, metric availability, and business-goal alignment.
- Use only these handoff states: ready for human review, provisional, blocked, or excluded. Explain every provisional, blocked, or excluded state.
Finish with the smallest safe next action that moves the system toward human-approved operation without implying that publication or measurement has occurred.
Run an evidence-led workshop to define an offer’s priority buyer, urgent problem, promise, proof, differentiation, objections, and validation plan.
Updated Aug 18, 2026
Run an evidence-led offer positioning workshop using the following inputs.
Inputs
- Offer description: [Offer description]
- Business objective: [Business objective]
- Target market evidence: [Target market evidence]
- Customer research: [Customer research]
- Competitive alternatives: [Competitive alternatives]
- Proof assets: [Proof assets]
- Commercial constraints: [Commercial constraints]
- Brand and compliance constraints: [Brand and compliance constraints]
- Success criteria: [Success criteria]
Input gate
The minimum prerequisites are a sufficiently specific offer description, the business decision this positioning must support, and some basis for identifying a potential buyer or market. Useful supporting material includes interview transcripts, survey results, sales-call notes, win-loss findings, reviews, funnel data, pricing, testimonials, case studies, competitor pages, brand guidance, and applicable claim restrictions.
If a prerequisite is missing or contradictory, ask no more than five blocking questions and do not issue a final positioning recommendation. If optional evidence is absent, continue only with bounded hypotheses, identify what remains unknown, and reduce the confidence assigned to affected conclusions. Never fill an evidence gap with invented customer behavior, competitor facts, market statistics, testimonials, or performance results.
Tool and action boundaries
Use ChatGPT to organize the supplied material, identify patterns, facilitate positioning decisions, compare alternatives, draft options, and design validation tests. Do not imply that ChatGPT has interviewed customers, inspected private systems, accessed links, browsed current market information, or run experiments unless that capability was explicitly available and the resulting evidence is present. When browsing is explicitly enabled, cite the page URL, publisher, access date, and relevant observation; distinguish third-party claims from verified facts.
This workshop produces recommendations and draft marketing language only. Do not publish, contact customers, change campaigns, alter pricing, approve regulated claims, or represent the positioning as organizationally approved. Flag claims involving health, finance, legal outcomes, safety, guaranteed results, comparative superiority, sensitive traits, or named competitors for qualified human review. Exclude unnecessary personal or confidential data. Refuse deceptive positioning, fabricated scarcity, fake social proof, or messaging that disguises material limitations.
Evidence rules
1. Create stable evidence identifiers such as E1 and E2 for material used in the analysis.
2. Classify each material proposition as supplied fact, direct observation, reported customer statement, assumption, hypothesis, unknown, conflict, or unsupported claim.
3. Record the source, recency, segment relevance, and confidence for each important proposition. Do not convert repeated opinions into measured facts.
4. Preserve conflicting signals. Explain whether a conflict may result from segment, buying stage, customer maturity, geography, channel, sample bias, or stale evidence.
5. Tie every recommended promise, differentiator, objection response, and proof point to evidence identifiers or mark it explicitly as a hypothesis requiring validation.
6. Use words such as validated, proven, measured, approved, tested, or completed only when the supplied record shows the relevant action, method, result, and approval. Otherwise use proposed, drafted, unverified, unavailable, or blocked.
Workshop workflow
1. Frame the decision. Restate the offer, intended commercial outcome, decision deadline if supplied, non-negotiable constraints, stakeholders whose approval is required, and what this workshop will not decide.
2. Assess readiness. Determine whether the evidence supports a positioning recommendation, only provisional options, or discovery planning. Report the limiting gaps before continuing.
3. Segment the market by meaningful buying conditions rather than demographics alone. Compare buyer role, user role, triggering event, job to be done, current workaround, urgency, ability to buy, desired outcome, switching friction, and disqualifying conditions. Recommend one primary segment only when the evidence supports prioritization.
4. Model the problem. Separate symptoms from the underlying problem, quantify consequences only where evidence permits, identify emotional and operational stakes, and test whether the pain is urgent, costly, frequent, recognized, and addressable by this offer.
5. Map the competitive frame. Include direct competitors, internal solutions, manual workarounds, delay, and doing nothing. For each alternative, identify why buyers choose it, its strengths, its trade-offs, and the credible reason to switch. Do not manufacture competitor weaknesses.
6. Build the value logic. Connect offer capabilities to buyer outcomes through an explicit capability-to-benefit-to-outcome chain. Identify the mechanism that makes the promise plausible, expected time to value, dependencies, customer effort, exclusions, and conditions under which the offer is a poor fit.
7. Audit proof and claims. Match each potential claim to available proof such as demonstrations, product data, case studies, testimonials, credentials, methodology, guarantees, or third-party evidence. Flag weak attribution, tiny samples, outdated results, atypical outcomes, missing consent, and claims that require legal or compliance review.
8. Generate three materially different positioning territories. Each must specify the primary buyer, category or frame of reference, urgent problem, promised outcome, mechanism, differentiation, proof, principal trade-off, likely objection, and situations where the territory should not be used.
9. Score the territories from one to five on buyer relevance, urgency, distinctiveness, believability, evidence strength, defensibility, commercial fit, delivery fit, and compliance risk. Show the rationale and evidence identifiers behind each score. Keep score precision separate from evidence confidence and do not let an unsupported total determine the recommendation.
10. Make the decision. Recommend one territory, or state that no territory is supportable. Explain rejected alternatives, strategic trade-offs, dependencies, dissent or unresolved conflicts, and the human approval required before adoption.
11. Draft the positioning system. Produce a concise internal positioning statement, value proposition, short offer description, three message pillars, supporting proof, objection responses, disqualifier language, and claim caveats. Keep internal strategic language distinct from customer-facing copy.
12. Design validation. Convert the riskiest assumptions into prioritized tests using customer interviews, message testing, landing-page experiments, sales-call tagging, win-loss review, willingness-to-pay research, or campaign tests as appropriate. Specify the hypothesis, target segment, method, sample limitations, metric, decision threshold, duration or stopping rule, owner, required approval, and interpretation risks. Do not report tests as run.
13. Prepare the handoff. Identify which website, sales, product-marketing, enablement, advertising, and onboarding artifacts would need revision if the recommendation is approved. Separate draft work from authorized implementation and name the smallest reversible next step.
Required output
A. Decision frame and readiness status
- Decision to be made
- Commercial objective
- Scope and exclusions
- Required approvers
- Readiness: recommendation-ready, provisional, or blocked
- Blocking gaps and non-blocking limitations
B. Evidence and uncertainty register
Provide a table with: evidence ID, proposition or observation, classification, source, recency, segment relevance, confidence, conflict or limitation, and where it is used.
C. Buyer and problem model
Provide a segment comparison table and a primary-segment decision. Include buyer, user, trigger, job to be done, problem, consequence, desired outcome, purchase barriers, switching friction, and poor-fit criteria.
D. Competitive frame
Provide a table covering each alternative, why it wins, its credible strengths, trade-offs, switching trigger, and evidence status.
E. Claim and proof matrix
Provide: proposed claim, capability or mechanism, buyer outcome, evidence IDs, substantiation strength, caveat, prohibited or risky wording, and review owner.
F. Positioning territory scorecard
Compare three territories across all specified criteria. Show individual scores, evidence confidence, rationale, risks, and the meaningful strategic trade-off represented by each option.
G. Positioning decision
State the recommended territory or no-supportable-decision outcome. Include the internal positioning statement, value proposition, category frame, differentiation, reasons to believe, exclusions, rejected alternatives, unresolved dissent, confidence level, and approval status.
H. Messaging and objection framework
Provide three message pillars with supporting proof, a short offer description, the five most consequential objections with evidence-based responses, claim caveats, and language that identifies poor-fit buyers. Mark every item as draft.
I. Validation backlog
Provide a prioritized table with: assumption, risk if wrong, hypothesis, target segment, method, metric, acceptance threshold, stopping rule, owner, required approval, privacy or compliance control, current state, and interpretation risk.
J. Acceptance and verification record
Evaluate each success criterion using: criterion, expected evidence, actual supplied observation, evidence IDs, status as met, unmet, unknown, or conflicting, and action needed. Also verify that the recommendation names one priority buyer, addresses a recognized problem, distinguishes the offer from the full alternative set, uses supportable claims, acknowledges trade-offs, states poor-fit conditions, and can be tested. Do not mark acceptance complete without corresponding evidence.
K. Approval and implementation handoff
List proposed artifact changes, responsible owner, dependencies, review gates, reversible first action, and current state. End with the smallest safe next action; do not characterize any change as published, approved, tested, or implemented unless supplied evidence demonstrates that state.
Build an evidence-aware SEO content map that organizes entities, topics, search intent, content clusters, citations, and internal links into a prioritized publishing plan.
Updated Aug 17, 2026
Create a topical authority content map for the following scope.
Inputs
- Business, site, and scope: [Business, site, and scope]
- Target audiences and markets: [Target audiences and markets]
- Seed topics and entities: [Seed topics and entities]
- Existing content inventory and performance data: [Existing content inventory and performance data]
- Search, competitor, and source evidence: [Search, competitor, and source evidence]
- Editorial, legal, technical, and resource constraints: [Editorial, legal, technical, and resource constraints]
- Success criteria and planning horizon: [Success criteria and planning horizon]
Input requirements
Treat the business or site scope, target audiences or markets, and seed topics or entities as blocking prerequisites. A reliable inventory must identify at least URL, title, status, and primary subject for each known page. Performance exports should identify metric definitions, date ranges, filters, and market or device scope. Search evidence should identify its source and collection date.
If a blocking prerequisite is absent or materially contradictory, ask only the questions needed to resolve it before building the final map. If optional performance, backlink, crawl, competitor, or live search evidence is unavailable, continue with a bounded strategic draft, mark affected judgments as unverified, and state what evidence would validate them. Preserve conflicting inputs rather than silently choosing one.
ChatGPT operating boundaries
- Use ChatGPT to normalize supplied inventories, identify entity and topic relationships, classify intent, detect likely overlap, design clusters, propose internal links, specify evidence needs, and prioritize work.
- Do not imply access to analytics, search consoles, crawlers, CMS data, live rankings, competitor systems, or URLs unless their contents were supplied in the conversation or an enabled tool actually retrieved them.
- If browsing or another retrieval tool is available and the user authorizes its use, record each consulted URL, publisher, retrieval date, market context, and the observation it supports. Otherwise, treat live SERP composition, rankings, indexation, backlinks, and page contents as unknown.
- Do not publish, edit, redirect, delete, merge, contact publishers, change internal links, or approve content. Present these as recommendations requiring an authorized human owner.
- Never claim that a page was crawled, a query was checked, a link was added, or a result was verified unless that action occurred and evidence is available in the conversation.
Evidence rules
Maintain these states throughout the analysis:
- Supplied fact: directly present in an input or provided artifact.
- Observed evidence: directly visible in supplied or tool-retrieved material, with source and date.
- Assumption: a low-risk working premise needed to proceed.
- Hypothesis: a proposition requiring search, customer, or performance validation.
- Unknown: information not available.
- Conflict: credible inputs that disagree.
Attach an evidence state and source reference to consequential findings. Do not invent search volume, traffic, ranking difficulty, competitor coverage, customer demand, entity relationships, citations, or performance. Use qualitative demand or priority labels when numerical evidence is absent. Separate semantic relevance from demonstrated search demand, and separate topical breadth from proven authority.
Method
1. Define the authority boundary.
Translate the business scope into included topics, adjacent topics, and exclusions. Identify target audiences, markets, customer problems, funnel or journey stages, conversion paths, products or services, and regulated or high-risk subject areas. Flag scope that is too broad to support credible expertise.
2. Normalize the current inventory.
Create one record per known URL or planned asset. Standardize canonical URL, page type, status, primary subject, target audience, apparent intent, entities, funnel stage, performance evidence, freshness, and conversion role. Preserve missing values. Flag duplicate records, redirect chains reported by the inputs, stale pages, thin coverage, orphan candidates, and pages with unclear ownership; do not infer technical states that were not observed.
3. Build the entity and topic model.
Identify the central entity, supporting entities, attributes, problems, solutions, processes, comparisons, standards, and adjacent concepts. For every relationship, state whether it is evidenced, inferred, or uncertain. Define cluster boundaries so that the map reflects the business and audience rather than expanding indiscriminately around keyword similarity.
4. Model search intent and journeys.
Classify each topic by primary intent, secondary intent, audience, journey stage, expected answer format, and likely conversion path. Use mixed or ambiguous intent when appropriate instead of forcing a single label. Where current search-result evidence exists, summarize recurring result types, formats, and dominant interpretations without copying competitors. Mark intent as provisional when no current, market-specific evidence is available.
5. Design hubs and clusters.
Group topics into pillar or hub pages and supporting assets. Give each proposed page one defensible primary purpose, a distinct information gain, and a relationship to existing pages. Include definitions, comparisons, workflows, use cases, decision support, and evidence-led resources only where they fit observed audience needs. Avoid doorway pages, near-duplicate location or modifier pages, artificial keyword fragmentation, and clusters created solely to maximize page count.
6. Resolve overlap and cannibalization risk.
Compare proposed assets with the inventory using audience, intent, query theme, entity focus, format, and conversion role. Recommend keep, refresh, expand, consolidate, redirect for review, differentiate, create, or defer. Treat cannibalization as a hypothesis unless query-level or search-result evidence demonstrates competing URLs. Any redirect, deletion, canonical, or consolidation recommendation must include dependency checks, likely value at risk, an approval owner, and a rollback or recovery note.
7. Plan internal linking.
Create contextual links that explain the relationship between source and destination pages. Prioritize hub-to-spoke, spoke-to-hub, sibling, journey-progressing, and conversion-support links. Specify suggested anchor concept rather than prescribing repetitive exact-match anchors. Distinguish links that can use existing destinations from links blocked by unpublished pages. Flag orphaned priority pages, excessive depth, circular navigation without a useful path, and recommendations that rely on inaccessible or unknown pages.
8. Define citation and source readiness.
For claims likely to affect trust or decisions, specify the evidence needed: first-party documentation, primary research, official statistics, standards, regulatory guidance, qualified expert review, or reputable secondary synthesis. Record source ownership, publication or update date when known, geographic applicability, claim supported, and limitations. Flag unsupported statistics, outdated sources, circular citations, copied claims, commercial conflicts, and claims requiring legal, medical, financial, or other qualified review.
9. Assess AI-search readiness without promising visibility.
For priority assets, recommend clear entity naming, direct answer passages, scoped definitions, supporting evidence, author or organization transparency, update signals, and internally consistent facts. Identify passages suitable for concise extraction only when they remain accurate outside their surrounding text. Do not claim that formatting, schema, or topical coverage guarantees citation, ranking, inclusion, or traffic in an AI-generated response.
10. Prioritize the roadmap.
Score each recommendation using the supplied success criteria. If no scoring model is supplied, use transparent ordinal ratings for audience value, business alignment, evidence strength, coverage gap, dependency burden, effort, and risk. Explain ties and trade-offs. Sequence foundational hubs, supporting assets, refreshes, consolidations, links, and source acquisition according to dependencies and the planning horizon.
11. Validate and hand off.
Reconcile the map against the inventory and authority boundary. Identify unresolved unknowns, conflicts, approval points, and evidence-gathering tasks. Distinguish proposed work, work supported by observed evidence, blocked work, and work requiring human authorization.
Required deliverable
Produce the following sections in this order:
A. Scope and evidence ledger
- Authority boundary, audiences, markets, goals, exclusions, constraints, and planning horizon.
- A table with item or claim, evidence state, source reference, date or date range, scope, confidence, conflict or limitation, and validation need.
B. Existing-content diagnostic
- A table with URL or asset ID, current title, page type, primary topic, intent, entities, audience or journey stage, observed performance, freshness, overlap risk, link role, recommended disposition, rationale, evidence state, and approval dependency.
- State inventory totals, duplicates, and missing fields. Do not present totals as complete if the inventory is partial.
C. Entity and topical coverage model
- Central entity, supporting entities, key attributes and relationships, included and excluded topic boundaries, current coverage, missing coverage, and evidence status.
- Explain which gaps are strategically relevant and which adjacent topics should be excluded or deferred.
D. Content cluster map
Provide one row per existing or proposed asset with:
- Cluster ID and cluster name
- Hub or supporting role
- Existing URL or proposed slug concept
- Working title and page purpose
- Primary topic and entities
- Audience, journey stage, primary intent, and secondary intent
- Information gain or differentiator
- Recommended format and essential sections
- Existing, refresh, consolidate, differentiate, create, or defer state
- Parent hub and related assets
- Conversion or next-step path
- Evidence required and evidence state
- Priority, effort, risk, dependencies, owner or approver, and acceptance condition
E. Overlap and consolidation register
For each suspected collision, show affected assets, overlapping intent or entities, evidence, confidence, proposed resolution, value at risk, redirect or canonical review needs, approval owner, rollback consideration, and unresolved questions.
F. Internal-link architecture
Provide a table with source asset, destination asset, relationship, reader purpose, suggested anchor concept, contextual placement, destination status, priority, dependency, and verification method. Summarize hub coverage, orphan risks, depth concerns, and links blocked by proposed assets.
G. Citation and trust plan
Provide a table with asset or cluster, consequential claim type, required source tier, candidate supplied source, publisher or owner, date, geographic scope, limitation or conflict, expert-review need, and readiness status. Clearly distinguish an identified source need from a verified citation.
H. AI-search readiness notes
For priority assets, list the entity clarity, answer structure, factual consistency, provenance, authorship, freshness, and extractability improvements supported by the available evidence. Label all visibility outcomes as hypotheses to be measured after publication.
I. Prioritized implementation roadmap
Group work into dependency-aware phases. For each item include rationale, scoring inputs, expected value, effort, risk, prerequisite, accountable owner, required approval, deliverable, and completion evidence. Do not assign invented calendar dates or resources.
J. Verification and acceptance matrix
Use columns for check, expected condition, actual observation, evidence reference, status, and remediation. At minimum verify:
- Every priority topic falls inside the authority boundary and maps to a defined audience need.
- Every proposed asset has a distinct primary purpose or an explicit consolidation decision.
- Existing URLs are not mislabeled as inspected when their contents were unavailable.
- Inventory totals and mapped records reconcile, with partial coverage disclosed.
- Each priority cluster has a hub path, supporting relationships, and no unexplained orphan asset.
- Internal-link destinations exist or are clearly marked as proposed dependencies.
- Consequential claims have an appropriate source requirement and review path.
- Search volume, rankings, traffic, indexation, backlinks, and AI citations are not asserted without dated evidence.
- High-risk content and destructive SEO changes have named human approvals.
- The roadmap reflects constraints, dependencies, and the stated success criteria.
Use Pass only when the expected condition is supported by cited evidence. Otherwise use Fail, Partial, Blocked, or Not verified and explain the gap.
K. Decision and handoff register
List decisions ready for human review, blocked decisions, open questions, evidence to collect, approval owners, and the smallest safe next action. End by stating explicitly that the map is advisory and unexecuted unless the conversation contains evidence of authorized implementation.
Turn a consequential business decision into an evidence-grounded executive brief with comparable options, explicit trade-offs, risk controls, measurable outcomes, and a recommendation.
Updated Aug 17, 2026
Prepare an executive decision brief for the following decision.
Decision inputs
- Decision question: [Decision question]
- Decision owner and approval authority: [Decision owner and approval authority]
- Decision deadline: [Decision deadline]
- Business context: [Business context]
- Options already under consideration: [Options under consideration]
- Evidence pack: [Evidence pack]
- Constraints and non-negotiables: [Constraints and non-negotiables]
- Decision criteria and priorities: [Decision criteria and priorities]
- Affected stakeholders: [Affected stakeholders]
- Risk, authority, and escalation limits: [Risk, authority, and escalation limits]
- Definition of a decision-ready brief: [Definition of done]
Input requirements
Treat the decision question, accountable owner, deadline, known constraints, and at least one credible source describing the current situation as minimum inputs. Financial baselines, operating metrics, forecasts, customer evidence, contracts, policies, prior decisions, stakeholder positions, and option estimates are useful supporting inputs.
If the decision question, authority, material constraints, or baseline evidence is missing or contradictory, ask only the questions that block responsible comparison or recommendation. If answers are unavailable, continue only where bounded analysis is safe. Preserve each unresolved item as an unknown, conflict, or assumption; do not manufacture figures, stakeholder agreement, approvals, or evidence.
Evidence and tool rules
1. Use ChatGPT to organize supplied material, test reasoning, compare options, calculate only from provided figures, and draft the brief. State any calculation method and show enough working for review.
2. Do not imply access to internal systems, live dashboards, private links, meetings, or external sources unless their contents are actually available in the conversation. A URL alone is not evidence if its relevant content cannot be inspected.
3. Classify material claims as one of: supplied fact, direct observation from supplied material, calculation, stakeholder assertion, assumption, hypothesis, forecast, unknown, or conflict. Cite the file, excerpt, table, date, or source label supplied by the user whenever available.
4. Separate historical results from forecasts and correlation from demonstrated causation. Flag stale data, mismatched periods, inconsistent definitions, selection bias, omitted costs, optimistic adoption assumptions, and unsupported precision.
5. Never describe an option as approved, funded, validated, compliant, tested, launched, communicated, or completed unless the supplied evidence proves that state. Keep proposed, pending approval, blocked, unverified, and executed states distinct.
Decision analysis workflow
1. Frame the decision: Rewrite the question as a specific choice to be made by the named owner by the deadline. Define what is in scope, what is excluded, why a decision is needed now, and the consequences of delay or no decision.
2. Establish the baseline: Summarize the current operating and financial position using the most decision-relevant metrics. Record metric definitions, periods, sources, and known data-quality limitations. Distinguish verified baseline values from estimates.
3. Confirm decision rights: Identify the recommender, approver, consulted parties, implementers, and parties who must be informed. Flag conflicting mandates or any action exceeding the stated authority limits.
4. Define evaluation criteria: Convert the supplied priorities into clear criteria such as strategic fit, customer impact, expected value, cash requirement, time to value, operational feasibility, reversibility, compliance exposure, security or privacy impact, workforce impact, and execution risk. Assign weights only when supplied or transparently proposed; do not present invented weights as executive preferences.
5. Build a complete option set: Analyze the supplied options and add a status quo, defer, pilot, staged commitment, or reversible alternative when materially relevant. Do not add artificial options merely to create symmetry. Define scope, prerequisites, dependencies, timing, resource demand, and opportunity cost for each credible option.
6. Normalize the comparison: Use consistent time horizons, units, cost boundaries, discounting assumptions, and metric definitions. Reconcile one-time and recurring costs, benefits, downside exposure, implementation capacity, and displaced work. Identify values that cannot be compared reliably.
7. Test economics and outcomes: Where evidence permits, show formulas and inputs for relevant measures such as incremental revenue, avoided cost, total cost of ownership, contribution margin, payback period, break-even point, or expected value. Use ranges or scenarios rather than false precision. Never invent a return estimate when required inputs are absent.
8. Stress-test the options: Evaluate base, upside, and downside cases; key sensitivities; adoption or demand shortfalls; schedule slippage; cost overruns; dependency failure; vendor or concentration risk; regulatory, legal, privacy, security, reputational, and workforce effects where applicable. Identify assumptions capable of reversing the ranking.
9. Account for stakeholder effects: State who benefits, who bears cost or disruption, likely objections, distributional effects, change-management needs, and unresolved dissent. Do not infer stakeholder consent from silence.
10. Form the recommendation: Recommend one option only when the evidence supports a defensible preference. Explain why it wins against the criteria, what trade-offs are accepted, confidence level, and what new evidence would change the recommendation. If evidence is insufficient, issue a conditional recommendation or a clearly bounded no-recommendation finding.
11. Design execution gates: Translate the recommendation into decision gates, accountable owners, dependencies, resources, approval points, leading and lagging indicators, review cadence, stop-loss thresholds, and rollback or exit conditions. Treat all owners and dates not explicitly confirmed as proposed.
12. Verify decision readiness: Reconcile important claims to sources, arithmetic to inputs, option scores to rationale, recommendation to criteria, risks to controls, and implementation gates to named authority. Report every failed or unperformed check rather than claiming verification.
Authority and safety boundaries
- Produce analysis and a recommendation, not an approval. Do not authorize spending, sign contracts, change policy, contact stakeholders, publish communications, move data, alter systems, or initiate implementation.
- Require explicit human authorization for commitments involving funds, personnel, customers, regulated activity, contracts, production operations, security, privacy, legal positions, or external communications.
- Minimize exposure of personal, confidential, privileged, security-sensitive, or commercially restricted information. Recommend redaction or aggregation when detailed data is unnecessary. Do not reproduce secrets or credentials.
- Flag where qualified finance, legal, compliance, security, privacy, HR, procurement, or operational review is required. Do not represent the brief as a substitute for those approvals.
- Stop at analysis and escalate when evidence suggests unlawful conduct, material safety danger, unauthorized access, sanctions exposure, serious privacy or security risk, an unbounded financial commitment, or a decision outside the named owner's authority.
- For difficult-to-reverse actions, prefer staged commitment, pilot controls, backups, rollback planning, and explicit kill criteria where practical.
Required output
A. Decision header
- Decision statement
- Accountable decision owner and required approvers
- Decision deadline and urgency
- Scope and exclusions
- Current state of the decision: exploratory, under review, recommended, pending approval, or another evidence-supported state
B. Executive position
- Recommended option or no-recommendation finding
- Three to five reasons tied to evidence and criteria
- Material trade-offs being accepted
- Confidence level with rationale
- Immediate decision requested from the owner
C. Baseline and decision trigger
Provide the relevant operating, customer, market, workforce, and financial baseline; why action is being considered now; cost of delay; and status quo trajectory. Include source, period, metric definition, and limitation for each pivotal baseline claim.
D. Evidence ledger
Create a table with columns: ID; material claim; classification; source or calculation; source date or period; reliability or limitation; confidence; and implication. Include contradictory evidence rather than silently resolving it.
E. Decision criteria
Create a table with columns: criterion; definition; weight or priority; measurement method; threshold; source of priority; and uncertainty. Clearly mark proposed weights.
F. Options and trade-off matrix
Create a table with one row per credible option and columns: option; scope; strategic fit; expected benefits; full costs; time to value; feasibility; key dependencies; reversibility; principal risks; stakeholder effects; evidence gaps; and criterion-based result. Include status quo or defer when materially relevant. Follow the table with concise explanations for any scoring or ranking.
G. Economics and scenario analysis
Show applicable formulas, inputs, units, time horizon, and results. Compare base, upside, and downside cases. Identify the variables with the greatest effect on the outcome and any break-even threshold. If economics cannot be calculated, list the missing inputs and avoid numeric conclusions.
H. Recommendation rationale
Explain why the preferred option is superior to each viable alternative, which disadvantages remain, why they are tolerable, what assumptions the recommendation depends on, and the evidence or event that would reverse it. State meaningful dissent or unresolved objections.
I. Risk and control register
Create a table with columns: risk; cause; affected objective; likelihood; impact; exposure; early warning indicator; preventive control; contingency or recovery action; proposed owner; escalation threshold; and residual risk. Distinguish existing controls from proposed controls.
J. Approval-gated implementation outline
Create a table with columns: phase or gate; intended outcome; proposed owner; prerequisites; resources; approval required; target timing; acceptance evidence; stop condition; and rollback or exit path. Do not imply that any phase has begun unless execution evidence was supplied.
K. Measurement and review plan
Define the baseline, target, metric owner, data source, measurement frequency, leading indicators, lagging outcomes, guardrail metrics, review dates, and trigger for continue, adjust, pause, scale, or stop decisions. Note whether each target is supplied or proposed.
L. Verification and acceptance record
Create a table with columns: check; expected condition; actual observation from supplied material; evidence reference; result as passed, failed, unperformed, or blocked; and required resolution. At minimum check:
- the decision owner and approval path are explicit;
- options use consistent scope, units, and time horizons;
- pivotal claims trace to evidence;
- calculations reconcile to source inputs;
- assumptions and forecasts are labeled;
- status quo and delay consequences were considered;
- recommendation follows the stated criteria;
- material downside and affected stakeholders are represented;
- authority, specialist-review, privacy, and compliance limits are addressed;
- implementation gates have acceptance evidence and stop or exit conditions;
- no completion or approval claim exceeds available evidence.
M. Open issues and handoff
List blocking questions, non-blocking unknowns, evidence conflicts, required specialist reviews, decisions reserved for humans, and the smallest safe next action. End with a concise decision-owner checklist separating: decide now, obtain evidence, seek approval, and defer.
Use Codex to inspect application code for authentication, authorization, injection, unsafe input handling, secret exposure, file-access flaws, and release-blocking security risks.
Updated Aug 15, 2026
Conduct a code-level security review in Codex using the following inputs.
Review objective: [Review objective]
Repository materials: [Repository materials]
System context: [System context]
Security requirements: [Security requirements]
Execution permissions: [Execution permissions]
Validation commands: [Validation commands]
Definition of done: [Definition of done]
Input and access rules
- Treat the review objective and inspectable repository materials as minimum prerequisites. The materials should include the relevant source files or repository, dependency manifests and lockfiles, configuration examples, database or API boundaries, and tests when available.
- System architecture, trust boundaries, data classifications, deployment configuration, known threats, prior findings, and applicable security requirements are useful context. Mark them unknown when they are not supplied.
- If no relevant code or configuration is accessible, stop the code-level assessment. Return a blocking-input list and review plan rather than security conclusions.
- Ask a clarification question only when an ambiguity prevents safe scoping, severity assignment, or interpretation of an access-control rule. Otherwise, proceed with a bounded review and record the limitation.
- If supplied materials conflict, identify the conflict, cite both sources, and do not silently choose one.
Codex operating boundaries
- Use Codex to inspect only the files and repository context actually available in the session. Do not imply access to services, branches, secrets, logs, infrastructure, tickets, or production environments that Codex cannot access.
- Read and analyze within the granted scope. Run only the validation commands explicitly authorized by the execution permissions and only in an approved non-production environment.
- Do not deploy, merge, commit, push, rotate or reveal secrets, alter accounts or permissions, modify production data, contact third parties, or approve a release.
- Do not perform destructive tests, denial-of-service tests, credential attacks, persistence, data exfiltration, or exploitation beyond the minimum safe proof needed to establish a finding. Stop if a command could expose sensitive data, affect production, cross an authorization boundary, or cause irreversible changes.
- Redact credentials, tokens, personal data, private keys, and sensitive business data from the report. Refer to secret locations without reproducing secret values.
- Code changes are proposals unless the execution permissions explicitly authorize edits. Before any authorized edit, describe the files affected, security intent, compatibility risk, validation plan, and rollback method. Keep human approval as the gate for consequential changes and release decisions.
Evidence model
Maintain these distinctions throughout the review:
- Supplied fact: context stated by the user but not independently demonstrated in the available materials.
- Observation: behavior or code directly visible in an accessible file, with file path and line or symbol reference.
- Execution evidence: a command actually run in this session, including command, environment, exit status, and relevant redacted output.
- Assumption: a bounded interpretation required to continue.
- Hypothesis: a plausible security issue that still requires evidence.
- Unknown: information unavailable from the supplied scope.
- Conflict: incompatible evidence or requirements that require reconciliation.
Never present a hypothesis, scanner alert, pattern match, or dependency advisory as a confirmed exploitable vulnerability without tracing the relevant data flow, control flow, configuration, affected version, or reachable call path. State when line numbers are approximate or generated files reduce traceability.
Review procedure
1. Establish scope and attack surface
- Inventory the inspected files, languages, frameworks, dependency manifests, externally reachable endpoints, background jobs, administrative functions, file-processing paths, data stores, and third-party integrations visible in scope.
- Map trust boundaries and principal types such as anonymous users, authenticated users, tenants, administrators, services, and webhook senders.
- Record excluded components and explain how each exclusion limits assurance.
2. Trace identity and session controls
- Inspect login, registration, password reset, account recovery, multifactor flows, API-key handling, token creation and validation, session rotation, logout invalidation, cookie attributes, token expiry, and replay resistance where present.
- Check for authentication bypasses, user enumeration, insecure default credentials, weak token validation, confused identity sources, and inconsistent enforcement between web, API, job, and internal routes.
3. Test authorization logic by resource and action
- Trace how each sensitive endpoint or operation establishes the acting principal, requested resource, tenant ownership, role, and permitted action.
- Look for missing object-level and function-level authorization, insecure direct object references, tenant-boundary failures, privilege escalation, mass assignment, hidden-field trust, administrative route exposure, and checks performed only in the client.
- Distinguish authentication from authorization; the presence of a logged-in user is not evidence that access is permitted.
4. Follow untrusted input to security-sensitive sinks
- Identify request fields, headers, cookies, uploaded files, webhook payloads, queue messages, imported records, and third-party responses that cross trust boundaries.
- Trace validation, normalization, canonicalization, encoding, and type enforcement to SQL, NoSQL, shell, template, HTML, URL fetch, deserialization, logging, filesystem, redirect, and dynamic evaluation sinks.
- Evaluate injection, cross-site scripting, server-side request forgery, path traversal, open redirect, request smuggling assumptions, unsafe deserialization, command execution, and log-forging risks as applicable to the actual stack.
- Prefer parameterization and context-specific output encoding. Do not treat blocklists or client-side validation as sufficient controls.
5. Review secrets, cryptography, and sensitive data handling
- Check source, configuration, fixtures, logs, error paths, build files, and client bundles for embedded credentials or unintended sensitive-data disclosure without reproducing any discovered value.
- Inspect key and token storage, randomness, password hashing, encryption modes, signature verification, certificate validation, key separation, rotation support, and fail-open behavior where relevant.
- Verify that sensitive fields are minimized and protected in logs, caches, analytics, backups, URLs, error messages, and API responses.
6. Review database, file, and network boundaries
- Inspect query construction, row or tenant scoping, transaction boundaries, race conditions, unsafe raw queries, and excessive database privileges visible in configuration.
- For uploads and downloads, check filename canonicalization, extension and content validation, size limits, storage location, execution permissions, archive extraction, access checks, content disposition, malware-scanning hooks, and cleanup behavior.
- For outbound requests and webhooks, inspect destination allowlisting, redirect handling, DNS and private-network protections, timeouts, response limits, signature validation, replay controls, and error handling.
7. Review security configuration and dependency exposure
- Examine debug modes, verbose errors, CORS, CSRF protections, security headers, cookie settings, rate limits, proxy trust, environment separation, default routes, feature flags, and fail-open defaults.
- Compare dependency versions against supplied lockfiles and available advisory evidence. Account for reachability, affected version ranges, mitigations, and uncertainty; do not infer compromise from version presence alone.
8. Analyze abuse cases and operational failure modes
- Consider brute force, replay, duplicate requests, concurrency, stale authorization, cache confusion, race conditions, partial failures, retries, queue redelivery, oversized inputs, malformed encodings, and cross-tenant access.
- Identify controls that exist but can be bypassed through alternate endpoints, asynchronous workers, internal APIs, legacy paths, or inconsistent middleware ordering.
9. Triage and recommend remediation
- Assign each confirmed finding a unique identifier and severity of Critical, High, Medium, Low, or Informational.
- Explain severity using exploit preconditions, required privileges, reachability, affected assets, confidentiality/integrity/availability impact, tenant or user scope, detectability, and compensating controls. If these factors are unknown, lower confidence rather than inventing them.
- Separate confirmed findings from hypotheses and hardening opportunities. Avoid duplicate findings that share one root cause.
- Propose the smallest robust fix at the correct enforcement layer. Include compatibility, migration, performance, usability, observability, and rollback considerations.
10. Verify safely
- For each finding, define a reproducible validation procedure with prerequisites, a benign test input or unit/integration test design, expected secure behavior, expected vulnerable behavior when safe to describe, and required evidence.
- Run a procedure only when access and execution permissions allow it. Record the exact command, environment, exit status, and redacted result. Otherwise mark it Not run and state why.
- Include positive tests, negative tests, authorization tests across relevant roles or tenants, regression tests for the root cause, and checks that the remediation does not create a fail-open path.
- Reconcile static observations with execution results. Preserve discrepancies as unresolved instead of choosing the preferred result.
11. Determine handoff state
- Identify release blockers, accepted residual risks requiring owner approval, unresolved hypotheses, missing evidence, and dependencies on infrastructure or operational controls outside the repository.
- Recommend one of: Hold for remediation, Conditional review required, or No release-blocking issue identified in reviewed scope. The last state is not a declaration that the system is secure.
- A human security or engineering owner must approve remediation, risk acceptance, and release decisions.
Required deliverable
A. Scope and assurance statement
- Review objective and definition of done
- Materials inspected, including commit or revision when available
- Components, environments, and threat actors considered
- Exclusions, unknowns, conflicts, assumptions, and their effect on assurance
- Commands authorized, commands executed, and tools or data unavailable
B. Attack-surface and control map
Provide a table with: component or entry point; principal; trust boundary; sensitive asset or operation; authentication control; authorization control; untrusted inputs; sensitive sinks; relevant security requirement; evidence reference.
C. Confirmed finding register
For every confirmed finding provide:
- Finding ID and concise title
- Severity and confidence
- Affected component, file path, line or symbol, endpoint or operation
- Security property violated and plausible abuse scenario
- Preconditions, required privileges, reachability, and affected scope
- Evidence trace from source to control or sink
- Existing and missing controls
- Impact and severity rationale
- Minimal safe reproduction or test design
- Remediation at the root enforcement point
- Trade-offs, compatibility concerns, migration needs, and rollback approach
- Verification procedure, expected result, actual result if executed, and evidence reference
- Status: Confirmed-unfixed, Proposed remediation, Edited-not-tested, Tested-not-remediated, Verified-remediated, Blocked, or Risk-accepted with named human approval evidence
D. Hypotheses and hardening register
List unconfirmed concerns and defense-in-depth improvements separately. For each include the triggering observation, missing evidence, potential impact, and the next evidence needed. Do not assign confirmed-vulnerability language to this section.
E. Validation matrix
Provide a table with: finding ID; test type; authorized environment; command or procedure; expected secure observation; actual observation; evidence; result of Pass, Fail, Not run, or Inconclusive; follow-up owner.
A Pass requires an executed test whose actual observation matches the expected secure behavior. Code inspection alone may support a finding but must not be described as an executed test. If edits were made but tests were unavailable or failed to run, report Edited-not-tested rather than fixed or verified.
F. Release and remediation handoff
- Prioritized remediation order based on exploitability and impact
- Release blockers and rationale
- Required human approvals and risk owners
- Residual risks, monitoring or detection recommendations, and rollback triggers
- Final recommendation using one permitted handoff state
- Smallest safe next action
Completion language
- Use fixed, remediated, tested, verified, approved, deployed, or completed only when the corresponding action occurred and supporting evidence is cited.
- Never claim that an unexecuted command passed, a proposed patch was applied, an unavailable environment was inspected, or a release was approved.
- If no confirmed findings are identified, say only that no confirmed findings were identified within the reviewed scope and evidence; do not claim the application is secure.
Design and review production database migrations with evidence-based rollout, data protection, rollback or recovery controls, and concrete verification gates.
Updated Aug 15, 2026
Plan and assess the database migration described below using Codex.
Inputs
- Migration goal: [Migration goal]
- Database platform and version: [Database platform and version]
- Current schema and migration artifacts: [Current schema and migration artifacts]
- Application and deployment context: [Application and deployment context]
- Data profile and workload: [Data profile and workload]
- Operational constraints: [Operational constraints]
- Success criteria: [Success criteria]
- Available evidence and commands: [Available evidence and commands]
- Authorization scope: [Authorization scope]
Input requirements
Treat the database platform and version, current schema or migration artifacts, deployment context, operational constraints, and authorization scope as blocking prerequisites when their absence could change DDL behavior, lock risk, compatibility, or recovery strategy. Ask focused clarification questions before recommending execution if any of these are materially unknown.
Useful non-blocking context includes representative query plans, table sizes, row-growth rates, peak traffic periods, replica topology and lag, maintenance windows, backup history, observability links, prior migration timings, and staging results. If optional evidence is unavailable, continue with a bounded review, preserve the unknown explicitly, and state what must be measured before approval.
Codex access and action boundaries
- Inspect only the files, repository context, diffs, logs, schemas, configuration, and command output actually provided or accessible in the current Codex session.
- You may propose patches and, when explicitly permitted by the authorization scope, edit files or run non-destructive commands in an isolated development or test environment.
- Do not connect to, modify, migrate, restart, deploy to, or run write operations against production or any shared database unless explicit authorization and environment access are both supplied. Planning permission is not execution permission.
- Never expose credentials, connection strings, secrets, or unnecessary personal data. Prefer schema metadata, aggregates, redacted samples, and synthetic fixtures.
- Require human approval before destructive DDL, irreversible data transformations, production backfills, traffic switching, failover, restore operations, or deployment.
- Do not claim that a migration was run, tested, approved, deployed, rolled back, or verified unless the corresponding action occurred and its evidence is present. Otherwise label it proposed, not run, unavailable, blocked, or unverified.
Evidence rules
For every important conclusion, distinguish among supplied fact, inspected observation, command-produced evidence, assumption, hypothesis, unknown, and conflict. Cite the relevant file path, migration name, schema object, log excerpt, command, or metric when available. Do not invent row counts, lock duration, query plans, backup validity, replication behavior, test results, or database capabilities. When evidence conflicts, show the conflict and explain what must resolve it.
Migration analysis and design
1. Establish the change boundary.
- Identify affected tables, columns, indexes, constraints, triggers, views, stored routines, foreign keys, jobs, application models, queries, caches, analytics consumers, and replicas.
- Classify the work as schema DDL, data migration or backfill, application compatibility change, or a coordinated combination.
- For Laravel projects, inspect relevant migration classes, models, casts, validation, query usage, queue workers, scheduler jobs, deployment scripts, and framework or database-version constraints.
2. Inspect the current and target states.
- Reconstruct the current schema from authoritative artifacts where possible and describe the intended target schema.
- Detect drift between migration history, schema dumps, ORM definitions, and observed database metadata. Do not silently choose a source of truth when they disagree.
- Identify nullability, defaults, collation, character set, precision, generated values, identity or sequence behavior, uniqueness, referential integrity, and existing invalid or duplicate data that could block the change.
3. Analyze engine-specific operational risk.
- Determine whether each DDL operation is transactional, metadata-only, table-rewriting, lock-acquiring, online, concurrent, or version-dependent for the named database.
- Assess lock modes and duration, transaction-log or WAL growth, disk headroom, temporary space, replication lag, replica compatibility, connection-pool pressure, long-running transactions, statement timeouts, deadlocks, and impact on hot queries.
- Flag unsafe assumptions about operations such as adding a non-null column, changing a type, building or validating an index, adding a foreign key, renaming or dropping an object, or rewriting a large table.
4. Choose the safest migration pattern.
- Prefer expand-and-contract when old and new application versions may overlap: add compatible structures, deploy compatible code, backfill in bounded batches, validate, switch reads or writes, observe, and remove legacy structures only in a later approved release.
- Separate schema changes, application releases, backfills, and cleanup when combining them would enlarge the failure domain.
- Define batch keys, batch size assumptions, ordering, throttling, retry behavior, idempotency, resume checkpoints, transaction boundaries, and pause criteria for backfills.
- Address dual-write consistency, race conditions, stale workers, queued jobs, cache behavior, and mixed-version deployments where applicable.
- Compare credible alternatives, including downtime, online DDL, shadow-table approaches, phased constraints, or application-level compatibility. Explain safety, complexity, duration, and cost trade-offs.
5. Design recovery rather than assuming a down migration is safe.
- State whether reversal is logically and operationally safe after new writes begin.
- Select the appropriate response for each failure point: pause and resume, roll back application code while retaining expanded schema, run a compensating forward migration, restore from a tested backup, or fail over under an approved runbook.
- Define recovery point and recovery time expectations, backup or snapshot prerequisites, restore-test evidence, data reconciliation needs, and the point after which rollback becomes destructive or impractical.
- Never present a destructive down method as sufficient recovery for dropped or transformed data without validated restoration evidence.
6. Build rollout controls.
- Provide ordered pre-deployment, deployment, backfill, cutover, observation, and cleanup stages with owners or approval points.
- Include CI/CD gates appropriate to the artifacts: migration linting or static checks, clean-database application, upgrade from a representative prior schema, application tests against the target database version, backward-compatibility checks, and prevention of automatic destructive production execution.
- Define canary or staged rollout options, maintenance-window needs, concurrency controls, feature flags, timeout settings, monitoring coverage, and communications or incident escalation requirements.
7. Define stop conditions.
Stop and require human review if the target environment is ambiguous; production authority is absent; the current schema cannot be established; destructive or lossy behavior is unexplained; backup restoration is required but unvalidated; disk capacity is insufficient or unknown for a likely rewrite; lock, lag, error-rate, latency, or data-integrity thresholds are breached; mixed application versions are incompatible; or observed results materially differ from the plan.
8. Verify with expected and actual evidence.
- Specify preflight queries or commands, expected observations, acceptance thresholds, and the evidence to retain.
- Verify schema shape and migration-history consistency; row counts or scoped reconciliation totals; null, duplicate, orphan, checksum, or domain invariants; index presence and validity; critical query plans and latency; application read/write behavior; queue and job compatibility; error rates; locks; database load; replication lag; and backfill checkpoint completeness as relevant.
- Include tests for fresh installation and upgrade paths when both are supported.
- Record actual observations only from supplied or executed evidence. If commands were not run, leave actual results as not run and do not infer acceptance.
- Treat cleanup or destructive contraction as a separate decision after an observation period and explicit approval.
Required deliverable
Produce the following task-specific report:
A. Decision brief
State the recommended migration pattern, risk rating with rationale, execution readiness status, blocking issues, required approvals, and the smallest safe next action.
B. Evidence and uncertainty register
Use columns: ID; statement; classification; source or command; confidence; conflict or limitation; effect on decision.
C. Change inventory
Use columns: object or component; current state; target state; operation; application dependency; compatibility window; data-loss potential.
D. Operation risk matrix
Use columns: migration step; database behavior; expected lock or rewrite; workload impact; replica or storage impact; reversibility; mitigation; evidence needed.
E. Ordered migration runbook
For every phase, give prerequisites, exact artifact or proposed command, environment, permitted actor, expected observation, timeout or threshold, stop condition, recovery action, and retained evidence. Clearly distinguish proposed commands from commands actually executed. Avoid production credentials and use explicit environment checks before any runnable command.
F. Backfill specification
When applicable, document selection predicate, stable batch key, batch sizing, transaction scope, idempotency, concurrency, throttling, checkpoints, retries, data reconciliation, completion rule, and pause or abort thresholds. If no backfill is needed, explain why.
G. Rollback and recovery matrix
Use columns: failure stage; symptom; safe response; data consequences; required backup or checkpoint; authorization; validation after recovery. Identify the point of no safe rollback.
H. CI/CD and release gates
List each gate, where it runs, pass condition, evidence produced, failure behavior, and whether it blocks merge, deployment, cutover, or cleanup.
I. Verification ledger
Use columns: check; method or command; expected result; actual result; evidence reference; status; owner. Allowed statuses are passed with evidence, failed, not run, blocked, or not applicable with rationale.
J. Unresolved decisions and handoff
List open questions, responsible decision-maker, required evidence, deadline or sequencing dependency, residual risks accepted by whom, and the next authorized action.
Do not convert unknowns into reassuring assumptions. A migration is ready only when blocking evidence exists, required gates pass, recovery is credible, and the authorized human decision-maker approves execution.
Diagnose API integration failures using request traces, contracts, authentication evidence, logs, controlled tests, and verifiable fixes.
Updated Aug 15, 2026
Debug the API integration described below using Codex and produce an evidence-backed diagnosis, a safe remediation proposal, and concrete verification results.
Inputs
- Debugging objective: [Debugging objective]
- System and API context: [System and API context]
- Failure evidence: [Failure evidence]
- API contract and provider documentation: [API contract and provider documentation]
- Relevant code and configuration: [Relevant code and configuration]
- Authorized actions and constraints: [Authorized actions and constraints]
- Test environment and commands: [Test environment and commands]
- Acceptance criteria: [Acceptance criteria]
Input requirements
Treat the following as blocking prerequisites for a confirmed diagnosis: the failing endpoint or operation, expected behavior, an observed symptom such as an error response or timeout, and the boundaries of authorized inspection or execution. Request clarification when any of these are absent, when evidence conflicts materially, or when a test could affect production data or external users. If clarification is unavailable, continue only with bounded static analysis and label the result `provisional` or `blocked` rather than inventing details.
Useful but non-blocking context includes a sanitized request and response pair, timestamps and correlation IDs, API version, SDK version, recent changes, network path, retry policy, rate-limit headers, webhook delivery records, and a known-good comparison. Never request or reproduce raw secrets, private keys, bearer tokens, session cookies, personal data, or unredacted production payloads.
Codex operating boundaries
- Use Codex to inspect only the files, logs, fixtures, schemas, and documentation supplied or available in the authorized workspace.
- Run commands or tests only when the environment permits execution and the supplied authority explicitly covers them. Record the exact command, scope, exit status, and relevant sanitized output.
- Prefer read-only inspection and local, mocked, sandbox, staging, or replay tests. Do not send traffic to production, mutate external records, rotate credentials, change access policies, disable certificate validation, weaken authentication, deploy code, or delete data without explicit human authorization.
- Do not claim access to provider dashboards, network captures, repositories, runtime logs, or external systems unless that access is actually available through the current Codex environment.
- Stop and request approval if a proposed test may incur charges, trigger side effects, expose sensitive data, exceed rate limits, alter production state, or contact a real customer or third party.
Evidence rules
Maintain a strict distinction between:
- `supplied fact`: information present in the inputs;
- `observed`: something directly found in an inspected artifact;
- `executed`: a command or test actually run, with its result;
- `assumption`: a low-risk premise needed to proceed;
- `hypothesis`: a possible cause awaiting a discriminating check;
- `unknown`: information not available;
- `conflict`: evidence sources that disagree.
Cite evidence by file and line range, sanitized log timestamp or correlation ID, request fixture, response status and headers, documentation section, or executed command. Do not infer causation from temporal correlation alone. Never describe a fix as tested, verified, deployed, approved, or complete unless the corresponding action occurred and its evidence is recorded.
Debugging workflow
1. Establish the failing transaction
- Normalize the method, base URL, path, query parameters, headers, content type, body shape, timeout, API version, client or SDK version, and expected response.
- Build a sanitized request timeline across caller, gateway or proxy, provider, callback, queue, and persistence layers where applicable.
- Identify whether the failure is deterministic, intermittent, environment-specific, tenant-specific, payload-specific, or load-dependent.
2. Reconcile the API contract
- Compare the implementation and captured request with the authoritative OpenAPI schema, provider documentation, SDK types, examples, and version or deprecation notices.
- Check required and nullable fields, data types, enum values, date and number formats, character encoding, multipart boundaries, content negotiation, query serialization, pagination, response schema, and backward-incompatible version drift.
- Record conflicts between documentation, generated clients, tests, and observed provider behavior rather than silently choosing one.
3. Trace transport and routing
- Examine URL construction, DNS resolution evidence, TLS and certificate behavior, proxy settings, redirects, firewall or egress restrictions, connection pooling, compression, protocol negotiation, timeouts, and cancellation propagation.
- Separate connection failures, read timeouts, upstream gateway errors, client cancellations, and provider application errors. Do not recommend disabling TLS verification as a fix.
4. Validate authentication and authorization safely
- Check credential selection without exposing its value, token audience and issuer, expiry, scopes or roles, signature canonicalization, timestamp and nonce handling, clock skew, key identifier, environment mismatch, and header formatting.
- Distinguish unauthenticated failures from authenticated-but-forbidden failures. Treat credential rotation and permission changes as approval-gated actions.
5. Inspect payload and response handling
- Compare the serialized bytes or sanitized fixture with the intended object, including omitted versus null fields, casing, precision, escaping, duplicate keys, body hashing, and compression.
- Verify status-code handling, error-envelope parsing, empty-body behavior, partial success, pagination cursors, streaming, and malformed or unexpected responses.
6. Evaluate resilience behavior
- Inspect retry eligibility, attempt limits, exponential backoff, jitter, timeout budgets, circuit breakers, concurrency, connection reuse, and rate-limit header handling.
- Check idempotency keys and operation semantics before recommending retries. Identify retry amplification, duplicate writes, thundering-herd behavior, swallowed errors, and ambiguous outcomes after a timeout.
- For webhooks, examine signature verification, replay protection, event ordering, deduplication, acknowledgement timing, redelivery behavior, and dead-letter handling.
7. Rank root-cause hypotheses
- For each hypothesis, state supporting evidence, contradictory evidence, confidence, impact, and the smallest safe discriminating test.
- Prioritize causes that explain all observed symptoms with the fewest unsupported assumptions. Keep unresolved alternatives visible.
8. Propose the smallest safe correction
- Provide a minimal patch or configuration change when the evidence supports one. Include affected files or components, compatibility implications, security effects, migration concerns, observability changes, and rollback steps.
- Preserve existing public contracts unless a breaking change is explicitly authorized. Avoid broad dependency upgrades when a narrower correction is available.
- If evidence is insufficient, provide instrumentation or a diagnostic patch instead of presenting a speculative production fix.
9. Verify within authorized scope
- Define or run focused reproduction tests, contract or schema tests, authentication-negative tests, malformed-payload tests, timeout and retry tests, idempotency tests, rate-limit simulations, response-parser tests, and regression tests as relevant.
- For every check, record the precondition, command or procedure, expected observation, actual sanitized observation, and status as `pass`, `fail`, `blocked`, or `not run`.
- Reconcile results against the acceptance criteria. A passing happy-path test alone is insufficient when the proposed change affects retries, authorization, writes, or error handling.
10. Prepare the handoff
- Identify approvals required before credential changes, external traffic, production testing, deployment, or provider escalation.
- End with the smallest safe next action and the evidence it is expected to produce.
Required output
1. Failure signature
- Operation and environment
- Expected behavior
- Actual behavior
- First known occurrence and reproducibility
- User or system impact
- Current investigation state: `confirmed`, `provisional`, or `blocked`
2. Evidence ledger
Provide a table with: evidence ID, classification, source or location, sanitized observation, relevance, and limitations. Explicitly list unknowns and conflicting evidence.
3. Transaction and contract comparison
Provide a table with: request or response element, contract expectation, observed implementation or trace, match status, and consequence. Include method, route, API version, authentication mechanism, headers, query serialization, body schema, status handling, and relevant provider limits.
4. Hypothesis register
Provide a ranked table with: hypothesis, supporting evidence IDs, contradictory evidence IDs, confidence, discriminating test, test risk, and disposition.
5. Root-cause determination
State the confirmed root cause only if discriminating evidence supports it. Otherwise report the leading hypothesis and precisely what remains unverified. Explain the failure mechanism from initiating condition to observed symptom.
6. Remediation package
Include the minimal proposed code or configuration change, affected artifacts, patch or pseudodiff where possible, security and compatibility implications, retry or idempotency consequences, observability updates, rollback procedure, and required approvals. Clearly mark each item as `proposed` or `executed`.
7. Verification matrix
Provide a table with: check ID, scenario, preconditions, command or procedure, expected observation, actual observation, evidence ID, status, and residual concern. Include happy path, original failure reproduction, relevant negative cases, and regression coverage.
8. Acceptance assessment
Map every supplied acceptance criterion to its evidence and status. State whether the result is `accepted`, `not accepted`, or `blocked`. Do not use `accepted` when required checks were not run or evidence is missing.
9. Residual risks and handoff
List unresolved unknowns, production-specific risks, monitoring signals, rollback triggers, provider-escalation evidence, approval gates, and the smallest safe next action.
If no commands were run or no files were changed, say so explicitly. If a patch is produced but not applied, call it a proposed patch. If tests cannot run, preserve the planned commands and mark their results `not run`; never fabricate output.
Design, implement, review, and verify a production-ready WordPress plugin with explicit architecture, security, compatibility, testing, and release controls.
Updated Aug 17, 2026
Develop a production-ready WordPress plugin deliverable from the following inputs.
Required inputs:
- Plugin objective: [Plugin goal]
- Existing implementation, lifecycle stage, and known defects: [Current plugin state]
- Functional requirements and measurable acceptance criteria: [Functional requirements and acceptance criteria]
- Supported WordPress, PHP, multisite, and relevant browser versions: [WordPress and PHP compatibility targets]
Supporting inputs:
- Repository tree, relevant file contents, coding conventions, dependencies, and architecture notes: [Repository files and architecture]
- Performance, accessibility, privacy, licensing, hosting, packaging, and scope constraints: [Constraints and prohibited changes]
- Errors, logs, screenshots, reproduction steps, static-analysis reports, test results, and available commands: [Evidence, logs, and test commands]
- Permitted environments, authorized actions, required reviewers, deployment owner, and approval gates: [Deployment and approval boundaries]
Input and evidence rules:
1. Treat repository files, logs, command output, and test results supplied in this conversation as evidence. Identify their source and relevant version or timestamp when available.
2. Separate supplied facts, direct code observations, assumptions, hypotheses, conflicts, and unknowns. Do not resolve conflicting evidence silently.
3. Ask concise clarification questions only when a missing answer blocks safe architecture, implementation, data handling, authorization, or acceptance testing. If progress is still safe, proceed with bounded assumptions and identify what must later be confirmed.
4. Do not claim knowledge of files, runtime behavior, installed versions, external services, or current WordPress guidance that was not supplied or verifiably accessible in the session.
5. ChatGPT may analyze provided materials and draft plans, code, diffs, tests, commands, and release documentation. Unless an authorized execution environment is explicitly available, it cannot inspect an unprovided repository, run WordPress, execute tests, alter data, deploy, publish, or approve a release.
Authority and safety boundaries:
- Default to analysis and proposed changes. Do not modify a repository, install dependencies, run commands, access external systems, migrate data, deploy, publish, or delete anything unless that capability is available and the user has explicitly authorized the action and environment.
- Never treat staging authorization as production authorization. Require human approval before destructive operations, schema migrations, bulk updates, uninstall cleanup, credential changes, production deployment, or rollback execution.
- Do not expose secrets, authentication cookies, personal data, private keys, or production database content. Recommend redaction and synthetic fixtures where practical.
- Stop and request direction if requirements would bypass WordPress authorization, weaken nonce or capability checks, introduce undisclosed tracking, use incompatible licensing, perform an irreversible migration without backup and rollback controls, or require unsafe production-only experimentation.
- Prefer reversible changes, versioned migrations, least privilege, backups, dry runs, idempotent operations, and feature flags when justified. Preserve existing data unless deletion is an explicit, approved requirement.
Development workflow:
1. Establish scope and traceability
- Translate each requirement into a uniquely identified behavior and acceptance condition.
- Record exclusions, affected user roles, admin and front-end surfaces, data sensitivity, external integrations, and compatibility targets.
- Identify blocking gaps and define the safest bounded deliverable if source files or runtime evidence are incomplete.
2. Inspect the plugin context
- Map the plugin bootstrap, namespaces or prefixes, autoloading, hooks, shortcodes, blocks, REST routes, AJAX handlers, WP-CLI commands, cron events, admin pages, assets, templates, dependencies, and tests that are present or proposed.
- Trace activation, deactivation, upgrade, and uninstall behavior. Identify collisions, load-order assumptions, global state, missing cleanup, and backward-compatibility risks.
- For an existing plugin, cite file paths and symbols for material observations. For a greenfield plugin, mark the structure as proposed rather than observed.
3. Make architecture and data decisions
- Select hooks and extension points with their timing, callback signatures, priorities, and registration locations.
- Choose among options, transients, post or user metadata, custom post types, taxonomies, or custom tables based on query patterns, volume, indexing, lifecycle, portability, and multisite behavior.
- If custom tables or stored formats are needed, define schema versions, dbDelta-compatible creation where appropriate, migration sequencing, retry and idempotency behavior, failure recovery, and rollback limitations.
- Define service boundaries, dependency injection where useful, public APIs, error handling, caching and invalidation, cron concurrency controls, and behavior when dependencies or remote services fail.
- Explain important trade-offs and rejected alternatives, including compatibility and maintenance consequences.
4. Design security, privacy, and platform controls
- Apply capability checks and least privilege independently of nonce checks. Define permissions for admin pages, REST endpoints, AJAX actions, scheduled jobs, and destructive operations.
- Specify nonce creation and verification for state-changing browser requests. Do not present nonces as authorization.
- Validate input against allowed types and values, sanitize at ingestion where appropriate, use prepared database queries, and escape late for the exact HTML, attribute, URL, JavaScript, or translation context.
- Assess stored and reflected XSS, SQL injection, CSRF, privilege escalation, insecure direct object references, unsafe deserialization, path traversal, file upload abuse, SSRF, open redirects, and information leakage according to the feature surface.
- Define REST permission callbacks, response exposure, rate or abuse controls where needed, and secure handling of remote requests, redirects, timeouts, certificates, and failures.
- Identify personal data, retention, consent or notice implications, export and erasure integration, telemetry behavior, and secret storage. Flag legal or policy questions for human review rather than inventing conclusions.
5. Produce the implementation package
- Follow WordPress coding conventions, use collision-resistant names, internationalize user-facing text, and preserve backward compatibility unless a documented breaking change is approved.
- For new files, provide paths and complete contents when practical. For existing files, provide focused unified diffs or clearly delimited replacements anchored to supplied code. Do not fabricate unchanged context.
- Include plugin headers, hook registration, admin or front-end interfaces, data access, migrations, error handling, cleanup, and tests required by the accepted scope.
- For admin interfaces, include capability enforcement, nonce-protected state changes, settings registration, field validation, notices, keyboard use, semantic labels, and appropriate escaping.
- Keep generated assets, third-party packages, build artifacts, and dependency lock files distinct. Identify licensing, maintenance, and supply-chain implications of added dependencies.
6. Plan diagnosis and failure handling
- For reported defects, build a causal chain from reproduction evidence to the implicated code path. Distinguish confirmed cause from plausible hypotheses.
- Cover malformed input, unauthorized requests, duplicate submissions, partial writes, migration interruption, timeout, unavailable remote APIs, stale cache, cron overlap, multisite activation, localization, large datasets, and downgrade behavior when relevant.
- Define logging that is useful but does not expose secrets or personal data. Include user-safe error behavior and operator recovery steps.
7. Define verification and acceptance
- Map every requirement and significant risk to a concrete test: unit, integration, WordPress test suite, static analysis, coding-standards check, security test, accessibility review, manual scenario, or compatibility matrix entry.
- Give prerequisites, fixtures, exact commands when known, expected observations, and the evidence needed to record an actual result.
- Include authorization-negative tests, invalid and boundary inputs, nonce failure, escaping checks, REST permission tests, migration reruns, uninstall retention behavior, multisite cases, external-service failure, and regression coverage as applicable.
- Reconcile failed or missing results against acceptance criteria. A proposed test is not a passed test, and code inspection alone is not runtime verification.
8. Prepare release and recovery handoff
- Check version consistency across plugin headers, constants, readme, changelog, assets, schema version, and package name.
- Define supported upgrade paths, backup prerequisites, staging validation, package exclusions, dependency builds, smoke tests, observability, rollback triggers, rollback procedure, and any data changes that cannot be reversed automatically.
- Identify the human approvals required for security, privacy, accessibility, migration, and production release decisions.
Completion-claim rules:
- Label artifacts and checks as proposed, drafted, inspected, executed, passed, failed, blocked, or unavailable.
- Use executed, tested, fixed, verified, deployed, or approved only when the corresponding action occurred and supporting evidence is present. Cite the command, environment, result, or approver when available.
- If execution is unavailable, provide runnable commands and expected outcomes but report the results as unverified.
- Never infer deployment, publication, approval, deletion, migration success, or production safety from generated code alone.
Required output contract:
1. Scope and evidence ledger
- Requirement IDs, supplied evidence, observations, assumptions, conflicts, unknowns, exclusions, and blocking questions.
2. Plugin architecture specification
- File and component map; hooks and priorities; request and data flows; roles and capabilities; storage choice; schema or option definitions; lifecycle behavior; dependencies; compatibility decisions; rejected alternatives.
3. Implementation package
- File manifest with status, complete new files or anchored patches, configuration or build changes, migration logic, and concise integration instructions.
4. Security, privacy, and operational control register
- Surface or asset, threat or failure mode, affected role or data, control, implementation location, residual risk, required reviewer, and evidence status.
5. Requirement-to-verification matrix
- Requirement or risk ID, test level, prerequisites and fixture, command or procedure, expected observation, actual observation, evidence reference, and status.
6. Release and rollback handoff
- Compatibility matrix, upgrade path, packaging checklist, staging gates, monitoring signals, rollback triggers and procedure, irreversible effects, approvals, and release blockers.
7. Final status statement
- Separate completed and evidenced work from drafted, unverified, blocked, and out-of-scope work. End with the smallest safe action that advances the plugin toward acceptance.
