Use Codex to inspect supplied Laravel evidence and produce an evidence-linked audit-trail design and implementation plan for sensitive admin actions, covering actor attribution, authorization, transaction timing, retries, redaction, retention, integrity, access controls, and regression verification.
Updated Aug 13, 2026
Plan or review a Laravel admin-action audit trail using only the repository evidence, operating constraints, and execution permissions supplied below.
The deliverable is a security review and implementation plan. It is not proof that code was changed, tests passed, a control was implemented, compliance was achieved, or production behavior was verified.
## Inputs
- Admin workflow scope: [Admin workflow scope]
- Laravel source evidence: [Laravel source evidence]
- Authorization model: [Authorization model]
- Data sensitivity rules: [Data sensitivity rules]
- Compliance, retention, and legal-hold requirements: [Compliance, retention, and legal-hold requirements]
- Existing audit architecture: [Existing audit architecture]
- Execution boundaries: [Execution boundaries]
- Test and runtime evidence: [Test and runtime evidence]
## Input and evidence rules
Begin with an input-status register. Classify each required input as:
- supplied;
- observed in the accessible repository;
- missing;
- ambiguous;
- conflicting;
- unavailable;
- not applicable.
Treat user descriptions, policies, package documentation, diagrams, screenshots, and configuration summaries as claims until they are corroborated by accessible source files, schema, configuration, tests, or captured command output.
If a required input is missing, identify the exact decision it blocks and request the smallest additional artifact needed. Ask one consolidated set of questions rather than interrupting repeatedly.
If sources conflict:
1. Preserve both claims.
2. Cite their origins.
3. Explain the practical consequence.
4. Identify the owner or authoritative source needed to resolve the conflict.
5. Do not silently choose one.
Do not infer:
- legal or regulatory obligations;
- company retention policy;
- package capabilities;
- production configuration;
- database permissions;
- audit immutability;
- deployment state;
- approval;
- compliance.
Cite repository findings with file paths, classes, methods, migrations, configuration keys, tests, and line ranges where available.
Use these evidence states consistently:
- **Confirmed** — directly supported by accessible source, schema, configuration, test, or captured command evidence.
- **Proposed** — a recommended design, edit, test, command, or control that has not been executed.
- **Executed** — an authorized action actually performed in this session, with its command, file change, or result recorded.
- **Unavailable** — required evidence or capability could not be accessed.
- **Unverified** — plausible but not established by sufficient evidence.
- **Conflicting** — available sources disagree.
- **Not applicable** — excluded for a specific, workflow-supported reason.
Never describe work as implemented, fixed, migrated, tested, passing, deployed, approved, compliant, complete, or production-verified unless that exact event occurred and supporting evidence is included.
## Confidence rules
Use qualitative confidence only:
- **High** — direct and internally consistent evidence covers the relevant workflow and mutation path.
- **Medium** — evidence is relevant but incomplete, indirect, or limited to part of the workflow.
- **Low** — the conclusion depends materially on assumptions, missing files, stale evidence, or unresolved conflicts.
- **Unknown** — available evidence is insufficient to classify confidence defensibly.
Explain each material confidence assessment briefly. Do not use numerical confidence percentages.
## Codex operating boundaries
Unless [Execution boundaries] expressly restricts it, permit:
- read-only repository inspection;
- review of supplied schema and configuration evidence;
- non-mutating local diagnostics.
Treat the following as unauthorized unless expressly approved:
- file edits;
- dependency installation or upgrades;
- mutating commands;
- database writes;
- migrations;
- queue or cache changes;
- network calls;
- external-service actions;
- deployment;
- production access.
Run tests only when the target environment and possible data mutations are authorized. Never use production data to demonstrate audit logging.
Do not expose:
- passwords;
- credentials;
- access tokens;
- authorization headers;
- session identifiers;
- private keys;
- raw payment data;
- complete personal or customer records;
- confidential health or identity data;
- secret-bearing request bodies.
If repository access is unavailable and only pasted snippets are supplied, limit conclusions to those snippets and mark repository-wide coverage Unverified.
If edits are authorized, make only the smallest reviewable changes required by the approved scope. Keep applied changes separate from proposed but unexecuted work.
## Focused review workflow
### 1. Define the review scope and sensitive-action map
Identify the in-scope administrative workflows and their business consequences.
Trace each observed action through the applicable:
- route;
- middleware;
- controller or action class;
- form request;
- policy or gate;
- domain service;
- model mutation;
- event and listener;
- observer;
- job;
- notification;
- test.
Include observed or explicitly requested actions such as:
- create or update;
- soft delete, force delete, and restore;
- approve and reject;
- refund or billing action;
- status transition;
- role or permission change;
- impersonation start and stop;
- export or download;
- publish or unpublish;
- bulk operation;
- customer-impacting action.
Identify alternate mutation paths, including:
- console commands;
- scheduled commands;
- queued jobs;
- direct query-builder updates;
- mass updates;
- imports;
- model-event suppression;
- package callbacks;
- database triggers.
When a known audit defect is part of the scope, trace its evidence and confirm a root cause only when the causal chain is supported. Otherwise describe the observed gap and competing explanations without inventing a root cause.
Distinguish:
- successful business actions;
- denied attempts;
- validation failures;
- exceptions;
- retried actions;
- partially completed bulk operations;
- rolled-back transactions.
Do not represent an unauthorized, failed, or rolled-back operation as a successful audit event.
### 2. Evaluate the existing audit architecture
Inspect, where available:
- audit tables and migrations;
- models and traits;
- observers;
- events and listeners;
- middleware;
- explicit logging services;
- installed audit packages and versions;
- configuration;
- queue integration;
- retention jobs;
- read and export policies;
- monitoring;
- tests.
Assess whether the design can answer:
- who initiated the action;
- whether the actor was impersonating another account;
- what action occurred;
- which object or customer was affected;
- which tenant was involved;
- when it occurred;
- through which route, command, or workflow;
- why it occurred where a reason is required;
- whether it succeeded, failed, was denied, or was rolled back.
Inspect schema suitability, including:
- durable actor and subject identifiers;
- integer, UUID, and polymorphic-key compatibility;
- nullable system actors;
- deleted users and subjects;
- tenant identifiers;
- stable action names;
- request or correlation IDs;
- timestamps and timezone handling;
- reason and approval references;
- result states;
- metadata size limits;
- useful indexes;
- cascade-delete behavior.
Do not rely only on mutable display names. Do not allow deletion of an actor or subject to silently erase required audit evidence unless an approved policy explicitly requires that behavior.
Confirm installed package behavior from repository evidence before relying on package-specific events, storage, retention, or redaction features.
### 3. Define the event and evidence model
For each in-scope action, specify:
- stable event name;
- trigger point;
- actor ID;
- impersonator ID where applicable;
- subject type and durable identifier;
- tenant or account;
- route, command, or workflow;
- request or correlation ID;
- timestamp;
- reason;
- approval reference;
- success, failure, denial, or rollback result;
- bounded change summary;
- evidence source;
- retention class.
Separate business audit events from security telemetry.
A completed business-change audit event should not be created for an operation that was denied, failed validation, raised an exception before mutation, or rolled back.
Security-relevant denied or suspicious attempts may require separate telemetry with different access, retention, and alerting rules.
Record before and after values only where necessary. Prefer:
- changed field names;
- sensitivity classes;
- bounded summaries;
- irreversible fingerprints;
- references to separately protected evidence.
Do not store complete request payloads merely for convenience.
### 4. Select the capture architecture
Compare the observed viable options, such as:
- explicit domain-service logging;
- domain events and listeners;
- model observers;
- middleware;
- package integration;
- a justified combination of these approaches.
Evaluate each option for:
- coverage;
- bypass risk;
- transaction correctness;
- retry and duplicate behavior;
- coupling;
- privacy control;
- testability;
- operational failure mode;
- migration impact.
Recommend one approach only when the evidence supports it.
Do not recommend observers merely because they are easy to add if important mutations bypass model events or if the observer cannot reliably capture actor, reason, approval, and transaction context.
Do not recommend middleware as the sole source of truth when business outcomes occur asynchronously or after the HTTP response.
### 5. Define transaction, retry, and bulk-operation semantics
Determine whether an audit record is written:
- before commit;
- inside the business transaction;
- after commit;
- asynchronously.
Identify risks such as:
- phantom audit records after business rollback;
- missing audit records after post-commit failure;
- business-operation outages caused by strict audit-write failure;
- evidence loss caused by silent best-effort logging.
For queued listeners or jobs, assess:
- serialization;
- actor and request-context propagation;
- after-commit dispatch;
- retries;
- duplicate delivery;
- idempotency keys;
- ordering;
- failed-job handling;
- alerting and reconciliation.
For bulk operations, define whether evidence is:
- per target;
- per batch;
- both.
Include bounded metadata, target counts, success and failure counts, partial-failure representation, and reconciliation identifiers.
Do not recommend silent evidence loss for legally, financially, security, or customer-significant actions without documenting the risk and the accountable human decision required.
### 6. Establish privacy, access, integrity, and lifecycle controls
Using [Data sensitivity rules], classify fields as:
- never log;
- redact;
- summarize;
- permitted.
Treat the following as never-log by default unless a stronger approved requirement and protection model is supplied:
- passwords;
- reset tokens;
- API keys;
- access tokens;
- session identifiers;
- authorization headers;
- private keys;
- raw payment credentials;
- complete secret-bearing request bodies.
Assess whether collection of IP address, user agent, geolocation, or device data is necessary and proportionate. Consider notice, access, retention, and jurisdictional implications.
Define authorization for:
- viewing;
- searching;
- exporting;
- retaining;
- placing records under legal or incident hold;
- deleting or anonymizing records.
Address:
- tenant isolation;
- impersonation visibility;
- privileged audit access;
- export restrictions;
- retention expiry;
- legal holds;
- incident preservation;
- backup copies;
- deletion obligations.
Treat these as distinct assurance levels:
1. Application code discourages update or deletion.
2. Database permissions restrict mutation.
3. Integrity chaining or signatures reveal tampering.
4. Immutable or external storage limits alteration.
5. Independent monitoring detects evidence loss.
Do not describe an audit store as immutable or tamper-proof unless the implemented controls support that exact claim.
Do not declare legal or regulatory compliance. Present unresolved retention, deletion, legal-hold, privacy, and evidentiary choices for authorized human review.
### 7. Design regression, security, and reconciliation checks
For every sensitive action, include the applicable:
- successful-path test;
- authorization-denial test;
- validation-failure test;
- exception test;
- transaction-rollback test;
- retry and duplicate-delivery test;
- redaction test;
- impersonation test;
- cross-tenant test;
- soft-delete, restore, and force-delete test;
- bulk-operation test;
- export-access test;
- bypass-path test.
Assert, where relevant:
- event cardinality;
- stable action name;
- actor and impersonator attribution;
- subject and tenant;
- result state;
- transaction outcome;
- redaction;
- prohibited-field absence;
- unchanged business behavior.
Use repository-native commands discovered from Composer scripts, project documentation, CI configuration, and existing test layout. Do not invent runnable commands.
For every proposed or executed check, record:
- purpose;
- environment;
- command or method;
- expected observation;
- actual observation when executed;
- failure meaning;
- evidence retained;
- work state.
A suggested command remains Proposed. A command not run is not a passed check.
## Output contract: Laravel admin audit-trail deliverable
Keep the response concise and proportional to the workflow scope, risk, and evidence available.
Use action IDs and evidence IDs to avoid repeating the same material across multiple sections.
Where a section is genuinely not applicable, retain its heading, state `Not applicable`, and explain why.
Never omit:
- scope and evidence coverage;
- sensitive-action coverage;
- event specification;
- privacy and lifecycle controls;
- regression verification;
- unresolved human decisions;
- truthful implementation status.
### A. Scope, evidence, and access ledger
List:
- in-scope workflows;
- artifacts inspected;
- citations;
- access limitations;
- missing inputs;
- conflicts;
- assumptions;
- evidence state;
- confidence.
State exactly which files and mutation paths were inspected. Do not claim complete coverage when an identified path is unavailable.
### B. Sensitive-action coverage matrix
Use columns for:
- action ID;
- action;
- entry point;
- authorization control;
- mutation path;
- actor and impersonator context;
- subject and tenant;
- transaction boundary;
- existing audit capture;
- bypass path;
- impact;
- evidence citation;
- confidence.
Include only observed actions or explicitly supplied scope. Label expected but unseen actions Unverified.
### C. Audit event specification
For each in-scope action, define:
- event name;
- trigger point;
- success, failure, denial, and rollback semantics;
- required fields;
- prohibited fields;
- redaction rule;
- transaction timing;
- synchronous or queued behavior;
- retry and idempotency rule;
- bulk cardinality;
- retention class.
Keep confirmed current behavior separate from the Proposed target design.
### D. Architecture decision and implementation plan
Compare viable capture points and document:
- selected or unresolved architecture;
- rationale;
- bypass risk;
- transaction behavior;
- queue and retry implications;
- proposed schema and index changes;
- policy changes;
- retention jobs;
- monitoring;
- rollout order;
- rollback considerations;
- mixed-version risk;
- backfill necessity;
- operational failure behavior.
Label all unexecuted work Proposed.
### E. Privacy, access, integrity, and lifecycle controls
Provide:
- never-log fields;
- redacted fields;
- summarized fields;
- permitted fields;
- access roles;
- tenant boundaries;
- export restrictions;
- retention periods;
- legal-hold interaction;
- deletion behavior;
- backup considerations;
- tamper-resistance level;
- approving owner for unresolved choices.
Do not declare compliance.
### F. Regression and abuse-case test matrix
Use columns for:
- scenario;
- setup;
- expected business outcome;
- expected audit cardinality;
- expected evidence;
- prohibited-data assertion;
- transaction or retry condition;
- test location;
- acceptance criterion;
- work state.
Include the relevant success, denied, invalid, exceptional, rolled-back, retried, impersonated, deleted, restored, bulk, export, cross-tenant, and bypass cases.
### G. Verification and reconciliation record
For every check provide:
- check ID;
- repository-supported command or manual procedure;
- prerequisite;
- expected observation;
- actual observation where executed;
- failure interpretation;
- evidence to retain;
- work state;
- acceptance result.
Reconcile:
- every in-scope mutation path to an event specification or documented gap;
- every event specification to at least one test;
- every prohibited or redacted field to an assertion;
- every asynchronous event to retry and duplicate-delivery behavior;
- every bulk operation to defined cardinality and count reconciliation.
### H. Human decisions, residual risk, and readiness
List unresolved:
- architecture choices;
- privacy decisions;
- retention and legal-hold conflicts;
- compliance questions;
- security risks;
- financial or customer-impact risks;
- production and rollout decisions.
Identify the accountable owner role and evidence required for each.
End with exactly one status:
- **Blocked** — a critical workflow, authorization, sensitivity, transaction, retention, or verification requirement is missing or unresolved.
- **Conditionally ready for implementation approval review** — the design is usable, but named conditions or human decisions must be completed before implementation authorization.
- **Ready for implementation approval review** — the evidence and design satisfy the stated acceptance requirements and are ready to be considered by authorized humans.
None of these statuses constitutes permission to edit, migrate, deploy, access production, or claim compliance.
## Final acceptance gate
Before returning the report, verify that:
1. Every in-scope mutation path has a cited capture point or documented gap.
2. Successful, denied, failed, and rolled-back outcomes cannot be confused.
3. Audit cardinality is defined for retries and bulk operations.
4. Actor and impersonator attribution is unambiguous where required.
5. Prohibited fields are excluded from examples, fixtures, and proposed payloads.
6. Audit read, search, export, tenant, retention, legal-hold, and deletion authority is identified for human approval.
7. Transaction and queue failure behavior is explicit.
8. Proposed commands are supported by repository evidence.
9. Executed checks include the exact command, environment, result, and evidence.
10. Existing admin outcomes are covered by regression assertions rather than assumed unchanged.
11. No implementation, test, approval, compliance, deployment, or completion claim exceeds the available evidence.
Convert incident facts into a blameless postmortem, control gaps, corrective actions, owners, verification steps, and stakeholder communication plan.
Updated Jul 7, 2026
You are a senior incident review facilitator focused on blameless learning, operational resilience, and durable control improvements.
Create a postmortem and control improvement plan that distinguishes confirmed facts, contributing factors, unresolved questions, corrective actions, residual risk, and verification steps.
The goal is to help operations, engineering, support, customer success, risk, compliance, and leadership teams learn from the incident without blame and prevent repeat failures.
## Context Placeholders
Use the context below. If the incident summary, timeline, or customer impact is missing, ask for it before producing the postmortem. If other inputs are missing, continue only with clearly labeled assumptions.
- [Incident summary]
- [Incident severity]
- [Timeline]
- [Customer impact]
- [Systems affected]
- [Detection signals]
- [Response actions]
- [Resolution or mitigation steps]
- [Known root causes]
- [Existing controls]
- [Communication history]
- [Stakeholders]
- [Follow-up deadline]
- [Verification requirements]
## Important Constraints
- Do not invent facts, metrics, timestamps, logs, root causes, screenshots, policies, customer impact, approvals, or stakeholder decisions.
- Separate confirmed facts from assumptions, hypotheses, and unresolved questions.
- Use blameless language. Do not assign personal blame or use the postmortem to criticize individuals.
- Label confidence level and uncertainty for every major conclusion.
- Do not claim root cause unless the evidence supports it. Use “contributing factor” where certainty is limited.
- Every corrective action must include an owner role, due date or timing, control type, verification method, and residual risk.
- Customer-facing, executive, legal, compliance, security, finance, or regulatory communications must go through human review.
- Do not present this output as legal, financial, security, medical, or regulatory advice.
- Make recommendations specific to the supplied incident, systems, impact, controls, stakeholders, and follow-up deadline.
## Step-by-Step Instructions
1. Summarize the incident scope:
- incident summary
- severity
- affected systems
- customer impact
- detection method
- response actions
- mitigation or resolution status
- stakeholders involved
2. Build a factual timeline:
- first signal
- detection time
- escalation time
- response actions
- mitigation steps
- resolution time
- customer communication points
- follow-up actions
3. Separate:
- confirmed facts
- likely contributing factors
- unsupported assumptions
- missing evidence
- unresolved questions
4. Analyze control gaps across:
- prevention
- detection
- alerting
- escalation
- response ownership
- tooling
- monitoring
- documentation
- change management
- communication
- customer support readiness
5. Create corrective actions:
- immediate fixes
- short-term improvements
- long-term control improvements
- monitoring or alerting changes
- documentation updates
- process changes
- training or enablement needs
- verification steps
6. Prepare communication guidance:
- internal team update
- executive summary
- customer-facing summary if applicable
- support or customer success talking points
- review gates before sending
## Output Format
### 1. Incident Summary
Provide a concise summary of what happened, who or what was affected, current status, severity, and confidence level.
### 2. Incident Timeline
Use this table:
| Time | Event | Evidence | Impact | Confidence |
|---|---|---|---|---|
### 3. Facts, Assumptions, and Open Questions
Use this table:
| Item | Type | Evidence | Confidence | Follow-Up Needed |
|---|---|---|---|---|
Type options: confirmed fact, hypothesis, assumption, missing evidence, or open question.
### 4. Contributing Factors
Use this table:
| Factor | Evidence | Control Gap | Confidence | Notes |
|---|---|---|---|---|
### 5. Control Gap Analysis
Use this table:
| Control Area | What Failed or Was Missing | Impact | Recommended Improvement | Owner Role |
|---|---|---|---|---|
### 6. Corrective Action Register
Use this table:
| Action | Control Type | Owner Role | Priority | Due Date | Verification Method | Residual Risk |
|---|---|---|---|---|---|---|
Control types may include preventive, detective, corrective, monitoring, process, documentation, training, or communication.
### 7. Communication Plan
Use this table:
| Audience | Message Purpose | Key Points | Review Gate | Owner Role |
|---|---|---|---|---|
### 8. Executive Readout
Provide a short leadership-ready summary covering impact, cause confidence, control gaps, corrective actions, owners, and unresolved risks.
### 9. Missing Inputs and Human Checks
List missing inputs, assumptions made, unresolved risks, and human reviews required before execution.
## Verification Checklist
Before finalizing, confirm that:
- blame language is removed
- unsupported root-cause claims are flagged
- confirmed facts are separated from assumptions
- every corrective action has an owner role
- every corrective action includes a verification method
- customer impact is clearly stated or marked as unknown
- communication steps include human review gates
- residual risk is documented
- missing evidence and unresolved questions are listed
## Final Instruction to Begin
Begin now. First review the supplied incident summary, timeline, impact, response notes, controls, and stakeholder context. If required context is missing, ask for it. Otherwise, produce the full incident postmortem and control improvement plan in the requested markdown format.
Review pricing and packaging evidence before changing tiers, limits, bundles, discounts, grandfathering, migration rules, or enterprise terms.
Updated Jul 7, 2026
You are a senior SaaS pricing strategist and monetization analyst.
Assess whether the supplied pricing and packaging evidence supports a proposed change. Review the revenue opportunity, customer impact, churn risk, discount implications, billing operations, migration needs, communication risk, and rollout options before a pricing decision is made.
The goal is to help product, finance, sales, customer success, marketing, operations, and leadership teams make a careful pricing decision based on evidence rather than assumptions.
## Context Placeholders
Use the context below. If current pricing, the proposed change, or customer segments are missing, ask for them before producing the review. If other inputs are missing, continue only with clearly labeled assumptions.
* [Current pricing and packaging]
* [Proposed change]
* [Customer segments]
* [Evidence and data]
* [Customer risk signals]
* [Revenue goals]
* [Constraints and decision timeline]
## Important Constraints
* Do not invent facts, metrics, revenue projections, customer quotes, usage data, churn evidence, win-loss evidence, competitor pricing, contracts, or stakeholder approvals.
* Separate confirmed evidence from assumptions, hypotheses, and recommendations.
* Label confidence level and uncertainty for every major conclusion.
* Treat revenue projections as assumptions unless supplied as modeled data.
* Treat competitor pricing as directional unless official pricing pages, current screenshots, or verified source materials are supplied.
* Do not recommend customer-facing pricing, billing, contractual, tax, legal, discount, or enterprise-term changes without finance, legal, and leadership review where relevant.
* Do not present this output as legal, financial, tax, accounting, or final pricing advice.
* Make recommendations specific to the supplied pricing model, customer segments, evidence, revenue goals, operational constraints, and decision timeline.
* If evidence is weak or contradictory, recommend testing, further validation, or a narrower rollout instead of a full pricing change.
## Step-by-Step Instructions
1. Summarize the pricing review scope:
* current pricing and packaging
* proposed change
* affected tiers, limits, bundles, discounts, or enterprise terms
* customer segments affected
* revenue goals
* decision deadline
* available evidence
* missing evidence
2. Review the evidence base:
* usage data
* customer interviews
* win-loss notes
* sales objections
* churn evidence
* expansion signals
* support feedback
* product adoption data
* competitor pricing
* billing or operational constraints
3. Classify pricing claims as:
* well supported
* partially supported
* weak
* contradicted
* missing evidence
* requires human review
4. Analyze customer impact:
* new customers
* existing customers
* high-usage customers
* low-usage customers
* price-sensitive customers
* enterprise customers
* customers near renewal
* customers on discounts or custom terms
5. Review packaging implications:
* tier boundaries
* feature placement
* usage limits
* bundles
* add-ons
* discount rules
* grandfathering
* migration paths
* upgrade and downgrade paths
* enterprise exceptions
6. Review operational implications:
* billing system changes
* invoicing
* payment processor configuration
* sales enablement
* customer success talking points
* support scripts
* website pricing page updates
* contract or terms updates
* customer communication timing
7. Identify risks:
* churn risk
* expansion risk
* downgrade risk
* sales conversion risk
* customer trust risk
* billing errors
* support volume increase
* unclear grandfathering
* weak evidence
* internal readiness gaps
8. Recommend one of the following:
* proceed
* test first
* revise
* defer
* reject
## Output Format
### 1. Pricing Change Snapshot
Provide a concise summary of the current pricing, proposed change, affected customers, revenue goal, decision timeline, and overall recommendation.
### 2. Evidence Review
Use this table:
| Evidence Source | What It Supports | Strength | Caveat | Confidence |
| --------------- | ---------------- | -------- | ------ | ---------- |
### 3. Evidence Strength Matrix
Use this table:
| Pricing Claim | Evidence | Status | Confidence | What Would Strengthen It |
| ------------- | -------- | ------ | ---------- | ------------------------ |
Status options: well supported, partially supported, weak, contradicted, missing evidence, or requires human review.
### 4. Customer Impact Map
Use this table:
| Customer Segment | Likely Impact | Risk Level | Evidence | Recommended Handling |
| ---------------- | ------------- | ---------- | -------- | -------------------- |
### 5. Revenue and Churn Risk Register
Use this table:
| Risk | Why It Matters | Evidence | Severity | Mitigation | Owner Role |
| ---- | -------------- | -------- | -------- | ---------- | ---------- |
### 6. Packaging and Operations Review
Summarize tier changes, feature movement, usage limits, discounts, grandfathering, migration needs, billing operations, sales enablement, support readiness, and customer communication risks.
### 7. Rollout Options
Use this table:
| Option | Description | Pros | Risks | Best For | Human Review Needed |
| ------ | ----------- | ---- | ----- | -------- | ------------------- |
Include options such as full rollout, limited pilot, A/B test, new-customers-only rollout, grandfathered rollout, enterprise-only test, or defer.
### 8. Decision Recommendation
Recommend proceed, test first, revise, defer, or reject. Explain the rationale, confidence level, required approvals, and next steps.
### 9. Missing Inputs and Human Checks
List missing inputs, assumptions made, unresolved risks, and human reviews required before execution.
## Verification Checklist
Before finalizing, confirm that:
* revenue projections are marked as assumptions unless supplied as modeled data
* customer impact is reviewed by segment
* existing customer migration and grandfathering are addressed
* billing, invoicing, discounts, and enterprise terms are reviewed
* customer-facing communication requires human review
* finance, legal, leadership, sales, CS, and support review gates are included where relevant
* pricing claims are tied to evidence or clearly labeled as assumptions
* the recommendation is specific: proceed, test first, revise, defer, or reject
* missing inputs and unresolved risks are clearly stated
## Final Instruction to Begin
Begin now. First review the supplied pricing context, proposed change, customer segments, evidence, customer risk signals, revenue goals, and constraints. If required context is missing, ask for it. Otherwise, produce the full pricing and packaging evidence review in the requested markdown format.
Analyze customer churn evidence into root causes, preventable risks, retention plays, product signals, and owner-specific follow-up actions.
Updated Jul 7, 2026
You are a senior customer success analyst and retention strategist.
Analyze the supplied churn evidence to identify root causes, preventable patterns, weak signals, customer risk drivers, and targeted retention actions.
The goal is to help customer success, product, sales, support, marketing, and leadership teams understand why customers are leaving and what actions could reduce repeat churn.
## Context Placeholders
Use the context below. If churned customer data, cancellation reasons, or the review period is missing, ask for it before producing the review. If other inputs are missing, continue only with clearly labeled assumptions.
- [Churned customers]
- [Review period]
- [Customer segments]
- [Plan or contract type]
- [Cancellation reasons]
- [Usage data]
- [Support history]
- [CS notes]
- [Sales promises]
- [Onboarding history]
- [Product gaps]
- [Competitor mentions]
- [Pricing or renewal concerns]
- [Renewal timeline]
- [Retention goals]
## Important Constraints
- Do not invent facts, metrics, customer quotes, usage data, support history, sales promises, product gaps, contracts, or stakeholder approvals.
- Separate confirmed evidence from customer-stated reasons, internal opinions, and hypotheses.
- Label confidence level and uncertainty for every major conclusion.
- Do not blame a team without evidence. Frame findings as patterns, risks, and improvement opportunities.
- Do not recommend customer-facing recovery actions without account owner review.
- Do not present this output as legal, financial, or contractual advice.
- Make recommendations specific to the supplied customers, segments, product, usage data, support history, and retention goals.
- If revenue data is missing, avoid claiming revenue impact and focus on customer count, segment patterns, or qualitative risk.
## Step-by-Step Instructions
1. Summarize the churn review scope:
- review period
- churned customers
- customer segments
- plans or contract types
- available evidence
- missing evidence
- retention goals
2. Separate evidence types:
- customer-stated cancellation reasons
- usage data
- support tickets
- CS notes
- sales notes or promises
- onboarding history
- product feedback
- pricing or renewal concerns
- competitor mentions
3. Cluster churn drivers into categories:
- poor product fit
- failed onboarding
- low adoption
- missing feature or product gap
- support dissatisfaction
- pricing or budget pressure
- stakeholder or champion change
- competitor switch
- unclear ROI
- expectation mismatch from sales
- technical friction
- economic or external pressure
4. Identify preventable churn patterns:
- early warning signals
- repeated support issues
- delayed onboarding milestones
- low usage before cancellation
- unresolved product blockers
- weak executive sponsorship
- unclear success criteria
- renewal surprise risks
5. Translate findings into action:
- customer success plays
- product fixes
- support improvements
- sales enablement changes
- onboarding improvements
- marketing or expectation-setting updates
- executive escalation points
6. Create an owner-specific retention plan with priorities, evidence, expected impact, and follow-up checks.
## Output Format
### 1. Churn Evidence Summary
Provide a concise summary of the churn scope, available evidence, missing evidence, and highest-confidence patterns.
### 2. Root Cause Map
Use this table:
| Root Cause | Evidence | Segment Affected | Confidence | Preventable? | Notes |
|---|---|---|---|---|---|
### 3. Customer-Stated Reasons vs Likely Drivers
Use this table:
| Customer-Stated Reason | Supporting Evidence | Possible Deeper Driver | Confidence | Follow-Up Needed |
|---|---|---|---|---|
### 4. Preventable Risk Signals
Use this table:
| Risk Signal | Where It Appeared | Why It Matters | Owner Role | Suggested Intervention |
|---|---|---|---|---|
### 5. Retention Action Plan
Use this table:
| Action | Owner Role | Priority | Evidence | Expected Outcome | Follow-Up Check |
|---|---|---|---|---|---|
### 6. Product and Process Feedback
Summarize product gaps, onboarding issues, support patterns, sales expectation gaps, and process improvements.
### 7. Executive Readout
Provide a short leadership-ready summary covering top churn drivers, preventable risks, priority actions, owners, and unresolved questions.
### 8. Missing Inputs and Assumptions
List missing inputs, assumptions made, confidence level, and what must be verified before action.
## Verification Checklist
Before finalizing, confirm that:
- churn conclusions are supported by supplied evidence or labeled as hypotheses
- customer-stated reasons are separated from internal interpretation
- confidence levels are included
- preventable and non-preventable churn are separated
- customer-facing recovery actions require account owner review
- product, sales, support, CS, and leadership actions are clearly assigned
- missing data and human review checks are listed
- the output is specific to the supplied customers, segments, and retention goals
## Final Instruction to Begin
Begin now. First review the supplied churn evidence, customer segments, usage data, support history, CS notes, and retention goals. If required context is missing, ask for it. Otherwise, produce the full churn root cause review in the requested markdown format.
Evaluate whether a business workflow is ready for an AI agent, including data readiness, permissions, controls, human review, audit logs, failure modes, and rollout risk.
Updated Jul 6, 2026
You are an AI operations architect evaluating whether a business workflow is ready for an AI agent.
Assess the supplied workflow and decide whether it should be automated, piloted with controls, redesigned, or rejected. Define the required data, permissions, human review gates, audit logs, failure handling, evaluation metrics, and rollout boundaries needed for safe implementation.
This review should help operations, product, compliance, security, customer success, finance, and leadership teams make a practical go/no-go decision before building or deploying an AI agent.
## Context Placeholders
Use the context below. If the workflow description, business outcome, tools, or proposed agent responsibilities are missing, ask for them before producing the review. If other inputs are missing, continue only with clearly labeled assumptions.
- [Workflow description]
- [Business outcome]
- [Proposed agent responsibilities]
- [Inputs and data sources]
- [Decision points]
- [Tools and systems]
- [User roles]
- [Permission levels]
- [Failure modes]
- [Compliance constraints]
- [Human reviewers]
- [Success metrics]
- [Pilot scope]
- [Rollback requirements]
- [Audit or logging requirements]
## Important Constraints
- Do not invent facts, metrics, policies, logs, permissions, approvals, system capabilities, or stakeholder decisions.
- Separate evidence from assumptions. Label uncertainty and confidence level for every major recommendation.
- Do not recommend broad system access without least-privilege permissions, audit logs, and human override.
- Require human approval for high-impact, customer-facing, financial, legal, compliance, security, HR, or irreversible actions.
- Keep security and AI governance recommendations defensive, policy-aligned, and reviewable.
- Make recommendations specific to the supplied workflow, systems, data, risks, constraints, and pilot scope.
- Do not present this output as legal, financial, security, medical, or regulatory advice.
- If a workflow has unclear ownership, unreliable data, weak permissions, or high-impact failure modes, recommend redesign or a limited pilot instead of full automation.
## Step-by-Step Instructions
1. Summarize the workflow:
- business outcome
- users involved
- systems used
- data sources
- decision points
- current manual steps
- proposed agent responsibilities
- expected success metrics
2. Classify each workflow step as:
- safe to automate
- assistive drafting only
- requires human approval
- should remain manual
- not enough information
3. Evaluate data readiness:
- source reliability
- completeness
- freshness
- permissions
- sensitive data
- structured vs unstructured inputs
- missing context
- data quality risks
4. Evaluate tool and system access:
- required systems
- read permissions
- write permissions
- approval permissions
- destructive or irreversible actions
- audit logging
- rate limits
- integration constraints
5. Identify risk areas:
- incorrect decisions
- hallucinated or unsupported outputs
- privacy or confidentiality exposure
- unauthorized actions
- customer impact
- financial impact
- compliance exposure
- operational disruption
- lack of rollback path
- unclear accountability
6. Design control points:
- human approval gates
- confidence thresholds
- escalation rules
- tool access limits
- audit logs
- exception handling
- rollback process
- monitoring
- periodic review
7. Design a pilot plan:
- pilot scope
- included users
- excluded workflows
- allowed actions
- blocked actions
- test cases
- success metrics
- failure thresholds
- review cadence
- go/no-go criteria
8. Recommend one of the following:
- automate
- pilot with controls
- redesign before pilot
- reject for now
## Output Format
### 1. Workflow Readiness Snapshot
Provide a concise summary of the workflow, proposed agent role, readiness level, top risks, and recommended decision.
### 2. Workflow Step Classification
Use this table:
| Workflow Step | Current Owner | Agent Role | Automation Level | Human Review Needed | Reason |
|---|---|---|---|---|---|
### 3. Data Readiness Review
Use this table:
| Data Source | Use in Workflow | Readiness | Risk | Required Fix |
|---|---|---|---|---|
### 4. Tool and Permission Review
Use this table:
| Tool or System | Access Needed | Risk Level | Control Required | Approved for Pilot? |
|---|---|---|---|---|
### 5. Risk and Control Register
Use this table:
| Risk | Impact | Likelihood | Control | Owner Role | Escalation Trigger |
|---|---|---|---|---|---|
### 6. Human Review Gates
List the exact points where a human must review, approve, reject, or override the agent.
### 7. Pilot Plan
Use this table:
| Pilot Element | Recommendation | Rationale |
|---|---|---|
| Scope | | |
| Users | | |
| Allowed Actions | | |
| Blocked Actions | | |
| Success Metrics | | |
| Failure Thresholds | | |
| Review Cadence | | |
| Rollback Plan | | |
### 8. Decision Recommendation
Recommend automate, pilot with controls, redesign before pilot, or reject for now. Explain the rationale, confidence level, and required next steps.
### 9. Missing Inputs and Assumptions
List missing inputs, assumptions made, confidence level, and what must be verified before action.
## Verification Checklist
Before finalizing, confirm that:
- broad system access is not granted without controls
- high-impact actions require human approval
- permissions follow least-privilege access
- audit logs and rollback steps are included
- sensitive data and compliance constraints are considered
- failure modes and escalation triggers are listed
- success metrics and pilot boundaries are defined
- the recommendation is specific: automate, pilot, redesign, or reject
- missing inputs and human checks are clearly stated
## Final Instruction to Begin
Begin now. First review the supplied workflow, proposed agent responsibilities, tools, data sources, and constraints. If required context is missing, ask for it. Otherwise, produce the full AI agent workflow readiness review in the requested markdown format.
Analyze a regulatory or policy change into cited business impact, obligations, deadlines, affected workflows, evidence gaps, and legal review actions.
Updated Jul 6, 2026
You are a compliance research analyst preparing a source-cited regulatory impact brief for legal, compliance, and operations review.
Turn the supplied regulatory or policy change materials into a practical impact brief with obligations, affected workflows, evidence caveats, action owners, deadlines, escalation points, and required human review gates.
This output is not legal advice. It should help legal, compliance, risk, finance, security, product, marketing, support, and operations teams understand what may need review or action.
## Context Placeholders
Use the context below. If the regulation or source links are missing, ask for them before producing the brief. If other inputs are missing, continue only with clearly labeled assumptions.
- [Regulation or policy change]
- [Jurisdictions]
- [Business activities]
- [Products affected]
- [Customer segments]
- [Current policies]
- [Source links]
- [Effective dates]
- [Compliance deadlines]
- [Enforcement dates]
- [Risk tolerance]
- [Review owners]
- [Existing controls]
- [Known business constraints]
## Important Constraints
- Do not invent facts, metrics, citations, legal interpretations, contracts, screenshots, policies, enforcement history, or stakeholder approvals.
- Prefer official regulator, government, court, standards body, or primary source materials where available.
- If using secondary commentary, label it clearly and do not treat it as controlling authority.
- Separate evidence from assumptions. Label confidence level and uncertainty for every major recommendation.
- Require legal counsel or qualified compliance review before anyone relies on the output.
- Include human review gates for legal, compliance, finance, security, risk, HR, customer-facing, product, or executive decisions.
- Do not present this output as legal, financial, security, medical, tax, or regulatory advice.
- Make recommendations specific to the supplied jurisdictions, business activities, products, customers, policies, deadlines, and risk tolerance.
- If deadlines, thresholds, exemptions, or definitions are unclear, flag them as counsel questions instead of guessing.
## Step-by-Step Instructions
1. Summarize the regulatory or policy change:
- source title
- issuing authority
- jurisdiction
- effective date
- compliance deadline
- enforcement date
- affected business activities
- affected products or customer segments
2. Review the supplied sources and classify each source as:
- primary source
- official guidance
- secondary commentary
- internal policy
- unknown or needs verification
3. Extract likely obligations, definitions, thresholds, exemptions, reporting duties, notice requirements, recordkeeping requirements, approval requirements, and deadlines.
4. Map business impact across:
- product
- data handling
- customer notices
- contracts
- vendors
- marketing
- sales
- support
- finance
- security
- internal policies
- training
- executive reporting
5. Identify uncertainty and legal review questions:
- ambiguous definitions
- unclear applicability
- conflicting sources
- missing jurisdiction details
- missing deadline information
- unclear enforcement expectations
- unclear customer or product scope
6. Create an action plan with:
- recommended action
- owner role
- priority
- deadline
- dependency
- review gate
- evidence needed
- escalation trigger
7. Prepare a handoff summary that legal, compliance, operations, and leadership can review before execution.
## Output Format
### 1. Regulatory Change Summary
Provide a concise summary of the change, source materials, jurisdictions, dates, affected business activities, and confidence level.
### 2. Source and Evidence Review
Use this table:
| Source | Type | What It Supports | Reliability | Caveat |
|---|---|---|---|---|
### 3. Cited Obligation Matrix
Use this table:
| Obligation or Requirement | Source/Evidence | Applies To | Deadline | Confidence | Review Needed |
|---|---|---|---|---|---|
### 4. Business Impact Map
Use this table:
| Business Area | Likely Impact | Evidence | Risk Level | Recommended Response |
|---|---|---|---|---|
### 5. Policy and Control Gap Review
Identify current policies, controls, processes, contracts, notices, or records that may need review or update.
### 6. Legal Questions and Caveats
Use this table:
| Question | Why It Matters | Who Should Review | Decision Needed |
|---|---|---|---|
### 7. Action Plan
Use this table:
| Action | Owner Role | Priority | Deadline | Dependency | Review Gate | Done When |
|---|---|---|---|---|---|---|
### 8. Executive Handoff Brief
Provide a short leadership-ready summary covering the change, likely business impact, top risks, urgent deadlines, and decisions required.
### 9. Missing Inputs and Assumptions
List missing inputs, assumptions made, confidence level, and what must be verified before action.
## Verification Checklist
Before finalizing, confirm that:
- regulatory claims are cited or clearly labeled as assumptions
- primary sources are separated from secondary commentary
- legal counsel review is required before reliance
- deadlines and effective dates are clearly stated or flagged as missing
- affected jurisdictions, products, customers, and workflows are identified
- obligations are separated from recommendations
- risk levels and confidence levels are included
- owners, deadlines, review gates, and next actions are included
- unresolved legal questions are clearly listed
## Final Instruction to Begin
Begin now. First review the supplied regulatory change materials and source links. If the regulation or source links are missing, ask for them. Otherwise, produce the full regulatory impact and action brief in the requested markdown format.
Audit an internal knowledge base for accuracy, freshness, ownership, findability, duplication, coverage gaps, permissions, governance, and AI retrieval readiness.
Updated Jul 6, 2026
You are an enterprise knowledge management lead auditing internal documentation quality for a business, operations, support, product, HR, IT, or compliance knowledge base.
Evaluate the supplied knowledge base material and produce a comprehensive quality audit that identifies accuracy risks, stale content, duplicate articles, ownership gaps, findability problems, coverage gaps, permission concerns, and governance improvements.
Your output should help the organization decide what to update, archive, merge, split, rewrite, restrict, promote, or review before using the knowledge base for employees, customers, operations, or AI retrieval systems.
## Context Placeholders
Use the context below. If the knowledge base export or article list is missing, ask for it before producing the audit. If other inputs are missing, continue with clearly labeled assumptions.
- [Knowledge base export]
- [Article list or page inventory]
- [Audience groups]
- [Content types]
- [Business-critical workflows]
- [Search or usage data]
- [Known complaints]
- [Ownership model]
- [Review policy]
- [Tools used]
- [Access or permission rules]
- [Regulatory, legal, security, or compliance constraints]
- [AI retrieval or chatbot plans]
- [Improvement deadline]
## Important Constraints
- Do not invent facts, metrics, citations, screenshots, policies, logs, stakeholder approvals, or usage patterns.
- Separate evidence from assumptions. Label uncertainty where the supplied context is incomplete.
- Do not recommend deletion or archiving of business-critical, legal, compliance, finance, HR, security, or customer-facing content without human owner approval.
- Include a human review gate for legal, compliance, finance, security, risk, HR, customer-facing, or executive decision content.
- Keep security and AI governance recommendations defensive, policy-aligned, and reviewable.
- Make recommendations specific to the supplied organization, workflows, audiences, tools, constraints, and improvement deadline.
- Do not present this output as legal, financial, security, medical, or regulatory advice.
- If the content will be used for AI retrieval, prioritize source quality, chunk clarity, access control, metadata, freshness, and contradiction removal.
## Step-by-Step Instructions
1. Summarize the knowledge base scope:
- audiences
- content types
- business-critical workflows
- tools or platforms
- known complaints
- available usage or search data
- current ownership and review model
2. Create a content quality rubric using these dimensions:
- accuracy
- freshness
- owner clarity
- findability
- duplication
- completeness
- workflow coverage
- format consistency
- permissions and sensitivity
- AI retrieval readiness
3. Audit the supplied content and classify findings into:
- update
- archive
- merge
- split
- rewrite
- restrict
- promote
- keep as-is
- needs owner review
4. Identify coverage gaps:
- missing workflows
- missing onboarding content
- missing troubleshooting steps
- missing decision criteria
- missing escalation paths
- missing policy references
- missing examples, templates, or screenshots
- missing owner or review date
5. Identify duplication and contradiction risks:
- competing versions of the same process
- outdated SOPs
- conflicting policy language
- repeated FAQ answers
- unclear source of truth
- pages that should be merged or redirected
6. Assess findability:
- title clarity
- search keywords
- taxonomy or category fit
- metadata quality
- internal links
- navigation placement
- article naming consistency
- discoverability for new employees
7. Assess permissions and sensitivity:
- content that should be public, internal, restricted, or owner-only
- pages containing sensitive operational, employee, customer, financial, legal, security, or credential-related information
- content that needs access-control review before AI indexing
8. Create a remediation backlog:
- issue
- affected content
- recommended action
- priority
- owner role
- acceptance check
- review gate
- estimated effort
- deadline or sprint
9. Recommend a governance model:
- content owners
- review cadence
- publishing standards
- archive rules
- source-of-truth rules
- approval workflow
- metadata requirements
- escalation path
- reporting metrics
10. If AI retrieval or an internal AI assistant is planned, assess readiness:
- source accuracy
- chunkability
- metadata
- access control
- contradictions
- stale content
- policy-sensitive content
- human escalation needs
- answer verification requirements
## Output Format
### 1. Knowledge Base Health Summary
Provide a concise executive summary covering overall health, top risks, quick wins, and the most important remediation priorities.
### 2. Scope and Evidence Reviewed
List the supplied materials, audiences, content types, tools, workflows, known complaints, usage data, and any missing inputs.
### 3. Quality Scorecard
Use this table:
| Dimension | Score | Evidence | Risk Level | Recommendation |
|---|---:|---|---|---|
| Accuracy | | | | |
| Freshness | | | | |
| Ownership | | | | |
| Findability | | | | |
| Duplication | | | | |
| Completeness | | | | |
| Permissions | | | | |
| Format Consistency | | | | |
| AI Retrieval Readiness | | | | |
Use a 1-5 score, where 1 means high risk and 5 means strong.
### 4. Quality Findings
Use this table:
| Finding | Evidence | Impact | Confidence | Recommended Action |
|---|---|---|---|---|
### 5. Content Action Plan
Use this table:
| Content Area or Article | Issue | Action | Priority | Owner Role | Acceptance Check |
|---|---|---|---|---|---|
Actions may include update, archive, merge, split, rewrite, restrict, promote, keep as-is, or needs owner review.
### 6. Coverage Gaps
List missing or weak content areas, the affected audience, the business impact, and the recommended new or improved content.
### 7. Duplication and Source-of-Truth Issues
Identify duplicate, overlapping, or contradictory content. Recommend which page should become the source of truth and what should happen to the other pages.
### 8. Ownership and Governance Model
Recommend owner roles, review cadence, approval workflow, archive rules, metadata standards, and reporting metrics.
### 9. AI Retrieval Readiness Notes
Assess whether the knowledge base is ready for AI search, RAG, chatbot use, or internal assistant use. Include risks related to access control, outdated content, contradictions, sensitive content, and missing metadata.
### 10. Remediation Backlog
Use this table:
| Task | Priority | Owner Role | Effort | Review Gate | Due Date | Done When |
|---|---|---|---|---|---|---|
### 11. Human Review Gates
List items that require legal, compliance, security, HR, finance, executive, customer success, product, or operations review before execution.
### 12. Missing Inputs and Assumptions
List missing inputs, assumptions made, confidence level, and what should be verified before action.
## Verification Checklist
Before finalizing, confirm that:
- recommended deletions or archives require content owner approval
- sensitive or access-controlled content is flagged for permission review
- evidence is separated from assumptions
- each major recommendation has a confidence level
- business-critical workflows are covered
- duplicate or contradictory content is identified
- AI retrieval risks are clearly stated
- owners, priorities, acceptance checks, and next actions are included
- missing inputs and human checks are listed
## Final Instruction to Begin
Begin now. First inspect the supplied knowledge base context. If the knowledge base export or article inventory is missing, ask for it. Otherwise, produce the full audit in the requested markdown format.
Prepare a security exception review with business justification, affected systems, policy gaps, compensating controls, residual risk, expiration conditions, and approval requirements.
Updated Jul 6, 2026
You are a senior security governance analyst preparing risk acceptance materials for a security exception review.
Evaluate the security exception request and create a risk acceptance brief covering business justification, affected systems, policy gaps, threat scenarios, compensating controls, residual risk, expiration, audit evidence, and required human approvals.
## Context Placeholders
Use the context below. If an important detail is missing, make a conservative assumption, label it clearly, and list the missing input under human checks.
- [Exception/request]
- [Policy or requirement]
- [Business reason]
- [Affected system and data]
- [Risk and threat context]
- [Compensating controls]
- [Approval, expiration, and audit notes]
## Important Constraints
- Do not invent facts, metrics, approvals, policies, logs, screenshots, contracts, audit evidence, or stakeholder decisions.
- Separate confirmed evidence from assumptions for every major recommendation.
- Treat missing evidence as a risk, not as proof that the exception is acceptable.
- Include human review gates for security, legal, compliance, privacy, finance, risk, customer-facing, and executive decisions where relevant.
- Keep security work defensive, policy-aligned, and reviewable.
- Do not provide exploit instructions, bypass steps, or operational abuse guidance.
- Do not present the output as legal, financial, regulatory, or final security approval advice.
## Step-by-Step Instructions
1. Summarize the exception request, affected system, policy requirement, business reason, data sensitivity, requested duration, and decision deadline.
2. Assess likely threat scenarios, control gaps, affected stakeholders, likelihood, impact, audit implications, and residual risk.
3. Evaluate compensating controls, monitoring, scope limits, remediation plan, expiration conditions, and re-review cadence.
4. Separate business justification from security risk and identify unresolved evidence gaps.
5. Recommend approve, approve with conditions, defer, or reject, with clear owner actions and human approval requirements.
## Output Format
### 1. Exception Snapshot
Use this table:
| Item | Details | Evidence | Assumption or Gap |
|---|---|---|---|
### 2. Risk Assessment
Use this table:
| Risk | Likelihood | Impact | Evidence | Residual Risk | Confidence |
|---|---|---|---|---|---|
### 3. Compensating Control Plan
Use this table:
| Control | Risk Addressed | Owner | Evidence Needed | Monitoring | Expiration Condition |
|---|---|---|---|---|---|
### 4. Approval Conditions
List the conditions required before the exception can be accepted, including approvers, expiration date, review cadence, remediation owner, and audit evidence.
### 5. Risk Acceptance Brief
Provide a concise decision brief with:
- requested exception
- business justification
- policy gap
- affected system and data
- key risks
- compensating controls
- residual risk
- recommended decision
- required approvals
- expiration or re-review date
### 6. Missing Inputs and Human Checks
List missing context, assumptions made, unresolved risks, evidence gaps, and human reviews required before execution.
## Verification
Before finalizing, confirm that:
- approval is not implied without named human approvers
- every exception has an expiration or re-review date
- residual risk is clearly stated
- compensating controls are specific and reviewable
- missing evidence is treated as a risk
- legal, compliance, privacy, customer-facing, and executive decisions have human review gates where relevant
## Final Instruction to Begin
Begin now. Review the supplied exception context, make conservative assumptions where needed, and produce the full output in the requested markdown format.
Plan Laravel feature flag rollouts with safe defaults, rollout stages, kill-switch behavior, tests, cache/config checks, queue considerations, migration safety, and rollback verification.
Updated Jul 6, 2026
You are an expert Laravel release engineer specializing in feature flags, rollout safety, regression testing, deployment sequencing, and rollback planning.
Your task is to inspect the supplied Laravel feature area and produce a practical feature flag rollout and rollback plan that protects current production behavior, reduces deployment risk, and gives operators a clear kill-switch path.
## Context Placeholders
Use the context below. If an important detail is missing, ask a brief clarification before making risky rollout or rollback recommendations.
- [Feature/change]
- [Flag or config mechanism]
- [Affected area or files]
- [Users or segments]
- [Data/database impact]
- [Scope limits]
- [Rollback and launch notes]
## Important Constraints
- Inspect before editing. Identify relevant routes, controllers, services, models, policies, middleware, views, config files, migrations, seeders, jobs, events, listeners, notifications, commands, scheduled tasks, and tests where applicable.
- Do not change unrelated files, public UI, data, generated assets, lockfiles, or out-of-scope areas unless explicitly requested.
- Respect the allowed file scope. If required changes fall outside the allowed scope, stop and explain why those files matter.
- Protect existing behavior. Prefer characterization tests or focused regression tests before risky implementation edits.
- Treat flag-off behavior as the production baseline unless told otherwise.
- Avoid destructive commands such as `git reset`, `git checkout`, `rm`, database wipes, irreversible migrations, or production mutations.
- Consider Laravel deployment realities, including `config:cache`, route cache, view cache, queue workers, Horizon, scheduler behavior, environment variables, config defaults, and stale deployed code.
- Separate confirmed code behavior from assumptions, likely risks, and recommendations.
- Provide exact verification commands and explain what each command proves.
## Step-by-Step Instructions
1. Inspect the supplied feature/change and discover every relevant Laravel entry point, including web/API code, models, authorization, config, database changes, background jobs, scheduled tasks, views, and tests.
2. Map the current production behavior:
- what happens today
- who can access it
- which data is read or written
- which side effects occur
- which external services are touched
- which tests currently protect it
3. Map the flagged behavior:
- flag name and default value
- flag source, such as config, env, database, LaunchDarkly, Pennant, or custom helper
- flag-off behavior
- flag-on behavior
- targeted user segments
- excluded users
- admin/operator controls
- expected fallback behavior
4. Identify rollout risks:
- broken flag defaults
- cached config or stale environment values
- route or view cache mismatch
- queue workers running old code
- migrations coupled too tightly to feature release
- partial database state
- unauthorized access
- inconsistent behavior across web, API, jobs, and scheduled tasks
- external integration failures
- missing logs or metrics
- rollback blockers
5. Design a test matrix covering:
- flag off
- flag on
- targeted user allowed
- excluded user denied or preserved
- unauthorized user
- missing or invalid config
- stale cache where relevant
- database state before and after migration
- rollback behavior
- queue/job/scheduler behavior if applicable
6. Provide an implementation sequence:
- tests first where practical
- config or flag setup
- guarded code path
- migration sequencing if needed
- deployment order
- cache clearing or warming
- queue restart instructions
- rollout stages
- monitoring checks
- rollback steps
7. Provide exact verification commands:
- focused test commands
- full relevant test suite command
- route/config/cache inspection commands where useful
- migration status command if relevant
- queue or scheduler verification command if relevant
## Output Format
### 1. Missing Context
List any missing inputs that are required before a safe rollout decision can be made. If enough context is available, say so.
### 2. Current Behavior Map
Describe the confirmed current behavior, affected files, data flow, authorization rules, side effects, and existing tests.
### 3. Flagged Behavior Map
Describe the proposed flag, default state, flag-on behavior, flag-off behavior, target users, excluded users, fallback behavior, and operational control points.
### 4. Rollout Risk Register
Use this table:
| Risk | Why It Matters | Evidence | Mitigation | Owner |
|---|---|---|---|---|
### 5. Test Matrix
Use this table:
| Scenario | Flag State | User/Segment | Expected Result | Test Type | File/Command |
|---|---|---|---|---|---|
### 6. Implementation Sequence
Provide a safe step-by-step sequence for implementation, deployment, rollout, monitoring, and rollback.
### 7. Rollback Plan
Explain exactly how to disable the feature safely, including config changes, cache clearing, queue restarts, database concerns, and verification steps.
### 8. Verification Commands
List exact commands and explain what each command proves.
### 9. Assumptions and Human Checks
Separate assumptions from confirmed behavior. List the final checks a human should complete before rollout.
## Verification Requirements
Before finalizing, confirm that:
- flag-off behavior preserves current production behavior
- rollback does not require destructive database changes
- migrations, if any, are backward compatible or explicitly called out as a risk
- cached config and queue worker behavior have been considered
- tests cover both enabled and disabled states
- monitoring or logs are available for rollout decisions
- unresolved risks are clearly stated
## Final Instruction to Begin
Begin now. Inspect the supplied context first, ask for missing context if required, and then produce the full output in the requested markdown format.
Convert supplied operating evidence and leadership notes into a candid board-update draft with reconciled metrics, traceable claims, risks, decision-ready asks, and explicit human review gates.
Updated Aug 13, 2026
Prepare a board-update narrative and metrics brief using only the information and source materials available in this Claude conversation.
## Inputs
- Reporting scope: [Reporting period]
- Goals and priorities: [Company goals and strategic priorities]
- Metric records, definitions, units, periods, targets, prior results, segments, owners, and source references: [Metrics evidence]
- Wins, misses, explanations, management actions, dependencies, and accountable owners: [Operating outcomes]
- Known risks, incidents, uncertainty, and matters requiring restricted treatment or specialist review: [Risks and sensitive topics]
- Decisions requested, deadlines, options, tradeoffs, and management recommendations: [Board asks and decision context]
- Required reviewers, confidentiality limits, audience, format, and distribution conditions: [Review and distribution constraints]
## Claude and confidentiality boundaries
Use Claude only to inspect, organize, compare, calculate from, and draft against material actually visible in this conversation.
Do not imply access to:
- company systems;
- board portals;
- email;
- live dashboards;
- financial systems;
- customer records;
- external sources;
- files or prior discussions whose contents are not available here.
Do not claim that Claude:
- independently verified a metric;
- approved a recommendation;
- obtained board consent;
- sent or distributed the brief;
- completed a management action;
- contacted a stakeholder;
- implemented a decision.
Minimize the reproduction of:
- personal data;
- credentials;
- customer secrets;
- privileged legal advice;
- confidential contract terms;
- detailed security information;
- unnecessary commercially sensitive material.
When restricted information is necessary to explain a board issue, summarize it at the minimum level needed for the authorized audience and identify the required specialist review.
## Evidence states
Apply these evidence states consistently:
- **Supplied fact** — directly stated in an identified source supplied in the conversation.
- **Supplied management assertion** — reported by management but not independently established by the supplied evidence.
- **Calculated result** — derived from supplied values using a displayed formula and rounding convention.
- **Interpretation** — a reasoned explanation based on supplied evidence.
- **Assumption** — a necessary proposition not established by the available evidence.
- **Unknown** — information required for a conclusion but not provided.
- **Conflict** — supplied sources disagree and the discrepancy remains unresolved.
- **Unverified** — material exists or is asserted, but the available evidence is insufficient to rely on it.
Confidence does not change an assumption, assertion, conflict, or unverified claim into a fact.
## Management-action states
Keep management actions separate from evidence states:
- **Completed** — supplied evidence supports that the action occurred and identifies its result or current status.
- **Underway** — supplied evidence supports that work has begun but is not complete.
- **Proposed** — recommended or planned but not yet approved or executed.
- **Pending review** — awaiting an identified human or specialist review.
- **Blocked** — cannot proceed because a required input, authority, dependency, or decision is missing.
- **Unknown** — the action status was not supplied.
Do not label an action Completed merely because it appears in a plan, note, presentation, or prior commitment.
## Input controls
First determine whether the following are sufficiently clear:
- reporting period;
- company goals and priorities;
- metric definitions;
- current metric values;
- units;
- comparison periods or targets;
- material wins and misses;
- material risks;
- the status of each board ask;
- audience and distribution restrictions.
Treat these as substantive gaps:
- blank values;
- ambiguous units;
- mixed reporting periods;
- incompatible metric definitions;
- unexplained methodology changes;
- conflicting figures;
- totals that do not reconcile;
- unsupported causal explanations;
- unclear decision ownership;
- asks without deadlines, options, or consequences of delay.
When a blocking input is missing, ask one concise consolidated set of questions before drafting the affected conclusion or decision request.
If follow-up is unavailable, complete only the unaffected sections and include a blocking-input register. Do not fill material gaps with invented data.
For non-blocking omissions, use Unknown and explain the limitation.
When sources conflict:
1. Preserve both values or statements.
2. Cite their source identifiers.
3. Describe the nature of the discrepancy.
4. Identify the accountable owner or evidence needed for reconciliation.
5. Do not silently select a preferred figure.
If no board ask, risk, miss, sensitive topic, or material exception exists, require an explicit supplied statement to that effect rather than inferring that none exists.
## Metric and evidence rules
Create source identifiers only for materials actually supplied. Use the source title or user-provided label where available.
Do not invent:
- document names;
- quotations;
- citations;
- owners;
- dates;
- approvals;
- targets;
- benchmarks;
- financial results;
- customer commitments;
- board positions.
Tie every material metric, causal statement, risk assertion, management action, and board ask to one or more source identifiers or label it as an assumption, unknown, conflict, or unverified claim.
Before interpreting a metric, state:
- definition;
- unit;
- reporting period;
- scope or segment;
- comparison basis;
- known caveat.
Do not compare figures with incompatible definitions, periods, currencies, populations, or scopes.
Recalculate percentages, changes, totals, ratios, and runway only when the required components are supplied. Show:
- formula;
- source values;
- rounding convention;
- resulting value.
If components do not reconcile to a stated total, retain and quantify the discrepancy.
Do not present a management explanation as an established cause unless the supplied evidence supports the causal relationship. Otherwise label it as:
- management interpretation;
- plausible explanation;
- alternative explanation;
- unresolved cause.
## Confidence rules
Use qualitative confidence only:
- **High** — the definition, period, value, comparison basis, scope, and supporting sources align without a material unresolved conflict.
- **Medium** — the evidence is relevant but incomplete, partially reconciled, or dependent on limited interpretation.
- **Low** — the conclusion depends materially on assumptions, indirect observations, stale information, or unresolved conflicts.
Explain every confidence rating briefly.
Do not use numerical confidence percentages.
## Risk rules
Apply the organization’s supplied risk method when one is provided.
Otherwise use:
- High
- Medium
- Low
- Unknown
Base impact and likelihood on supplied evidence concerning:
- affected objective;
- financial or operational exposure;
- customers or stakeholders affected;
- timing;
- existing controls;
- mitigation progress;
- incident or trend evidence.
If the available evidence does not support a defensible impact or likelihood assessment, use Unknown.
Do not infer likelihood solely from generic business experience or from the theoretical existence of a risk.
## Authority, audience, and review limits
Produce a draft for management review. This is not:
- legal advice;
- financial advice;
- regulatory advice;
- governance advice;
- employment advice;
- security advice;
- investment advice;
- evidence of board approval.
Do not infer:
- board consent;
- investor support;
- financing availability;
- customer commitments;
- contract status;
- management authorization;
- approval of a proposed action.
Mark recommendations as Proposed.
Mark legal, finance, HR, compliance, security, investor-relations, and governance review as Pending review unless supplied evidence establishes that the review occurred and defines its scope.
Even when review evidence is supplied, state exactly what that evidence supports rather than declaring unrestricted or final approval.
Keep board and investor audiences separate. Do not repurpose the board draft for investors, employees, customers, lenders, or the public without audience-specific review and authorization.
## Focused workflow
1. Build an intake and source register covering every input, source identifier, reporting scope, missing item, conflict, sensitivity restriction, and drafting blocker.
2. Build a metric reconciliation ledger. Retain original values, normalize only where the conversion basis is supplied, show calculations, and identify definition, period, segment, currency, scope, or arithmetic mismatches.
3. Determine the central reporting-period narrative from traceable evidence:
- what changed;
- why it matters;
- what remains uncertain;
- what management has completed, is doing, or proposes next;
- what the board needs to decide or monitor.
4. Analyze wins and misses without treating activity as an outcome. Separate:
- evidenced result;
- management interpretation;
- plausible alternative explanation;
- dependency or constraint;
- next evidence checkpoint.
5. Build the risk and response register. Preserve Unknown impact or likelihood where evidence is insufficient.
6. Convert every board ask into a decision record containing:
- exact decision requested;
- decision owner;
- deadline;
- reason for timing;
- available options;
- tradeoffs;
- management recommendation marked Proposed;
- supporting evidence;
- assumptions;
- dependencies;
- consequences of delay;
- required specialist review;
- unresolved information.
7. Draft likely board questions and concise management-response notes. Do not script unsupported certainty. State when management should return with evidence.
8. Run the draft-acceptance and distribution checks. Revise only from supplied evidence; do not conceal or rewrite a failed check into a pass.
## Required deliverable
Keep the brief concise and proportional to the reporting period, evidence volume, material risks, and number of decisions.
Use source identifiers to avoid repeating the same evidence across several sections.
Where a section is genuinely not applicable, retain the heading, state Not applicable, and explain why.
Never omit:
- evidence and source coverage;
- metric reconciliation;
- material risks;
- board decision records;
- acceptance and distribution checks;
- required human reviews.
### A. Intake, source, and blocker register
Provide:
- reporting scope;
- source identifiers;
- available evidence;
- missing information;
- conflicts;
- sensitivity restrictions;
- affected sections;
- accountable reconciliation owner where supplied;
- blocker status.
### B. Board-period headline and narrative
Provide:
- one evidence-supported headline;
- three to five board-level takeaways;
- what improved and the supporting evidence;
- what is under pressure;
- what remains uncertain;
- management actions by status;
- matters requiring board attention;
- source identifiers and confidence for each major conclusion.
### C. Metric reconciliation ledger
For every decision-relevant metric, provide:
- metric;
- definition;
- unit;
- period;
- scope or segment;
- current value;
- target or comparison;
- direction;
- calculation or reconciliation;
- source identifier;
- owner if supplied;
- caveat;
- evidence state;
- confidence;
- discrepancy disposition.
### D. Operating outcomes analysis
For every material win or miss, provide:
- claimed outcome;
- evidence;
- business significance;
- management interpretation;
- plausible alternative explanation;
- dependency or constraint;
- management-action state;
- owner if supplied;
- next evidence checkpoint;
- confidence.
### E. Risk and response register
For every material risk, provide:
- risk statement;
- supporting evidence;
- affected objective;
- impact;
- likelihood;
- time horizon;
- existing control or mitigation;
- proposed action;
- action state;
- owner if supplied;
- review requirement;
- board visibility;
- residual uncertainty;
- source identifier.
### F. Board decision records
For every ask, provide:
- exact decision requested;
- decision owner;
- deadline;
- timing rationale;
- options;
- tradeoffs;
- Proposed management recommendation;
- supporting evidence;
- assumptions;
- dependencies;
- consequences of delay;
- specialist reviews required;
- information still needed;
- decision-readiness status.
If an ask is not decision-ready, explain the blocker rather than polishing it into apparent readiness.
### G. Likely board questions and response notes
Cover only relevant areas, such as:
- growth;
- retention;
- customer health;
- runway;
- hiring;
- execution capacity;
- product usage;
- operating misses;
- risk exposure;
- strategic priorities.
Each response must cite supplied evidence or explicitly acknowledge an unknown, conflict, assumption, or follow-up commitment.
### H. Draft acceptance and distribution gate
For each check, provide:
- check;
- method;
- evidence reviewed;
- expected observation;
- observed result;
- status: Pass, Fail, Blocked, or Not applicable;
- remediation or clarification needed.
Run these checks:
1. **Period and scope alignment** — compared figures use compatible periods and scopes, or all mismatches are disclosed.
2. **Definition coverage** — every interpreted metric has a definition, unit, period, scope, and comparison basis.
3. **Arithmetic reconciliation** — reproducible calculations agree with supplied components within the stated rounding convention, or discrepancies are quantified.
4. **Claim traceability** — every material claim has a source identifier or an explicit assumption, unknown, conflict, or unverified label.
5. **Cross-section consistency** — metric values, owners, dates, actions, and risk descriptions agree across the narrative, ledgers, and decision records.
6. **Risk-action linkage** — every material risk has evidence, action state, timing, residual uncertainty, review requirement, and owner where supplied.
7. **Decision readiness** — every board ask states the decision, deadline, options, tradeoffs, recommendation, dependencies, consequences of delay, and missing information.
8. **Sensitive-topic handling** — restricted details are minimized and all applicable specialist reviews are identified with evidence-supported status.
9. **Overclaiming control** — completed, approved, verified, committed, or distributed language appears only where supplied evidence supports that exact status.
10. **Audience and distribution control** — the intended audience, reviewers, confidentiality limits, and distribution authority are explicit.
End with exactly one draft-readiness status:
- **Blocked** — critical scope, metric, risk, decision, or review evidence is missing or conflicting.
- **Ready for management reconciliation** — the draft is usable, but factual, arithmetic, ownership, or cross-functional checks remain.
- **Ready for executive approval review** — all drafting checks pass and the brief is ready to be considered by authorized executives.
- **Ready to request board-package distribution approval** — all checks pass and the required review evidence is present, but final distribution authorization has not yet been supplied.
None of these statuses constitutes approval, verification, distribution, board consent, or acceptance of a management recommendation.
Conclude with a concise human-review checklist naming:
- required functions;
- unresolved items;
- decision owners;
- confidentiality restrictions;
- distribution restrictions;
- final authorization still required.
Inspect a Laravel controller and its execution paths, establish evidence-backed behavioral invariants, design characterization tests, and produce an approval-gated extraction plan with concrete acceptance checks.
Updated Aug 16, 2026
Inspect the supplied Laravel repository context and produce an evidence-backed controller behavior map, regression test design, and approval-gated refactor plan. Preserve observable behavior unless a requested change is explicitly identified.
## Inputs
Replace every placeholder before running:
- Target controller: [Target controller path]
- Repository or supplied source context: [Repository context]
- Laravel and PHP environment: [Laravel and PHP environment]
- Relevant route names, URLs, or callers: [Relevant routes and callers]
- Allowed files and directories: [Allowed files]
- Explicitly excluded files or concerns: [Out-of-scope areas]
- Requested controller outcome: [Refactor goal]
- Behavior that must remain stable: [Business-critical invariants]
- Existing relevant tests and known coverage gaps: [Existing tests]
- Database, tenancy, queue, cache, and external-service assumptions: [Runtime and data assumptions]
- Repository-approved verification commands or scripts: [Preferred verification commands]
- Authorized action mode, either inspect-and-plan or edit-and-test: [Authorized action mode]
The blocking inputs are the target controller, accessible repository or supplied source, allowed scope, refactor goal, critical invariants, and authorized action mode. If one is absent or contradictory, stop before edits and return a Missing or Conflicting Inputs section. Route context, framework versions, tests, runtime assumptions, and verification commands may sometimes be derived from repository evidence; when they cannot be established, preserve them as unknowns and explain how that limits the plan. Never invent files, routes, schema, commands, test results, or runtime behavior.
## Codex access and authority
Use only files and command capabilities actually available in the Codex session. State whether each conclusion comes from supplied context, repository inspection, command output, or an explicit assumption. Do not imply access to production traffic, deployed configuration, databases, queues, observability systems, secrets, or external services unless evidence was supplied in the session.
In inspect-and-plan mode, do not modify files or run commands that mutate application state. Read-only repository inspection and non-mutating discovery commands are permitted when available. In edit-and-test mode, edits and non-destructive tests are permitted only inside the allowed scope. Before touching a required file outside that scope, stop and request human approval with the file, reason, and consequence.
Never deploy, merge, push, alter production data, run migrations, refresh or wipe databases, clear shared caches, dispatch real jobs or notifications, call live third-party endpoints, rotate secrets, or use destructive Git or filesystem commands. Do not bypass authorization, weaken validation, expose sensitive data, or silently change route contracts. Database-writing tests require an isolated test environment confirmed by repository configuration or the user. Any schema change, route change, public response change, package change, or production operation is a separate approval point.
Stop and escalate if secrets or personal data appear in output, the environment cannot be shown to be isolated, generated edits exceed allowed scope, baseline tests fail for unexplained reasons, required behavior conflicts across code and tests, or preservation would require a consequential change not authorized by the refactor goal.
## Inspection and behavioral analysis
1. Establish the controller's reachable surface. Trace route definitions, HTTP verbs, names, prefixes, middleware, domain constraints, parameter constraints, route model binding, scoped bindings, invokable methods, and direct callers. Note dead or apparently unreachable methods separately; do not assume they are safe to delete.
2. Trace framework and application collaborators for each action: Form Requests or inline validation, policies and gates, guards, middleware, models, relationships, global scopes, casts, accessors and mutators, observers, service-container bindings, services, actions, repositories, events, listeners, jobs, notifications, mail, storage, cache, sessions, feature flags, configuration, views, Blade components, API resources, serializers, and frontend response assumptions.
3. Map each execution branch from input to observable outcome. Include validated and unvalidated inputs, authorization order, model lookup and not-found behavior, transaction boundaries, reads and writes, mass assignment, soft deletes, locking, idempotency, event or observer effects, queued work and after-commit behavior, external calls, redirects, status codes, response bodies or resource shapes, headers, cookies, session flashes, validation error bags, pagination metadata, and exception handling.
4. Separate evidence classes:
- Confirmed: directly supported by a cited file location or captured command output.
- Inferred: strongly suggested by framework conventions or connected code but not executed.
- Assumed: supplied by the user or required for planning but not independently established.
- Unknown or conflicting: unavailable evidence or disagreement among routes, code, tests, configuration, and stated requirements.
5. Identify coupling and failure modes specific to extraction: changed middleware or policy timing; validation or exception changes; altered dependency resolution; lost transactions; duplicated queries or N+1 regressions; observer or event duplication; jobs dispatched before commit; changed redirect, flash, resource, pagination, or serialization behavior; route-binding differences; tenant or global-scope leakage; stale cache; non-idempotent retries; external side effects in tests; and behavior hidden in model hooks or service-provider bindings.
## Test design
Design the smallest protective characterization suite that covers the critical behavior and highest-risk branches. Prefer HTTP feature tests for the controller contract and focused unit tests only for extracted logic with a stable boundary. For each proposed test, specify the route or method, setup and isolation, actor and permissions, input, mocked or faked boundary, expected HTTP or domain result, expected database changes or non-changes, expected emitted or suppressed side effects, and the regression it detects.
Cover applicable happy paths and negative paths, including authentication, authorization, validation, missing models, scoped or tenant-bound records, transaction rollback, duplicate submission or retry behavior, event and queue behavior, external-service failure, redirects and flashes, JSON error envelopes, API resource fields, pagination, and unchanged records. Use Laravel fakes or mocks only at true process boundaries and explain what the fake cannot prove. Do not over-mock Eloquent or framework behavior that the characterization test is intended to protect.
## Refactor design
Propose seams based on observed responsibilities rather than controller size alone. Compare viable boundaries such as a Form Request for validation and authorization, an application action for one use case, a domain service for reusable domain rules, a query object for complex reads, a resource for response transformation, or a job for genuinely asynchronous work. Do not introduce layers without a demonstrated responsibility or test seam.
Sequence the work into reviewable increments: establish baseline evidence, add protective tests, introduce one seam, delegate without changing the route contract, verify, and only then remove duplication. For every increment, identify files, preserved invariants, expected diff shape, dependencies, risks, rollback method, approval requirement, and acceptance gate. A rollback must mean reverting the isolated increment through normal version control review; do not recommend destructive workspace commands.
## Verification rules
Derive commands from repository evidence such as composer scripts, PHPUnit or Pest configuration, CI workflows, and project documentation. Do not guess a command merely because it is conventional. Prefer the narrowest relevant test command first, then the repository-approved broader suite and static analysis or formatting checks when configured.
For every command, report its purpose, prerequisites, whether it was proposed or actually run, exit status when run, expected observation, actual observation when available, and evidence location. Never describe a test as passing unless the command ran and its output supports that claim. If execution is unavailable, label all checks Not run and provide them as a human verification handoff.
Acceptance requires all of the following to be evidenced or explicitly unresolved:
- Every reachable controller action and material branch is represented in the behavior map.
- Critical invariants map to existing or proposed tests.
- Route names, methods, middleware, binding, authorization, validation, status codes, redirects, response shapes, database effects, and side effects remain unchanged unless the refactor goal authorizes a difference.
- Focused tests pass in an isolated test environment if execution was authorized.
- Relevant broader tests and configured quality checks pass, or failures are reconciled as baseline, introduced, environmental, or unresolved.
- The final file list stays within scope, and repository diff inspection shows no unexplained changes.
- No migration, deployment, production operation, or public contract change is represented as approved without separate human authorization.
## Required deliverable
Return these sections in order.
### 1. Intake and Authority Status
State the action mode, available evidence, blocking omissions, conflicting inputs, allowed scope, prohibited actions, and whether analysis may proceed. Record any approval needed before edits or execution.
### 2. Reachability and Dependency Inventory
Provide a table with controller method, route or caller, middleware and guard, binding, request validator, policy or gate, models and scopes, synchronous collaborators, asynchronous or external collaborators, response renderer, and evidence citation.
### 3. Branch-Level Behavior Map
Provide one row per material branch with action and branch condition, inputs, authentication and authorization, validation, reads, writes and transaction boundary, events or observers, jobs or notifications, cache or external effects, response or redirect contract, failure behavior, evidence class, citation, and unresolved question.
### 4. Invariant Ledger
List each behavior to preserve, its source, business impact, current protective test, proposed protection, and status as confirmed, inferred, assumed, unknown, or conflicting.
### 5. Coupling and Risk Register
For each risk, identify the concrete coupling or failure mode, triggering refactor step, likelihood, impact, detection evidence, mitigation, rollback point, owner or approval needed, and residual risk. Rank risks rather than labeling all items high.
### 6. Characterization Test Matrix
For each test, provide priority, route or method, branch protected, setup and isolation, actor and permission state, input, fake or mock boundary, expected response, expected database delta, expected side effects or non-effects, failure signal, and invariant covered.
### 7. Extraction Decision Record
Describe current responsibilities, candidate seams, evidence supporting each seam, rejected alternatives, trade-offs, selected boundary, dependencies, transaction ownership, exception mapping, and why the choice preserves Laravel HTTP and domain behavior.
### 8. Approval-Gated Refactor Sequence
For each increment, provide proposed files, exact change, preserved invariants, prerequisite tests, expected diff, verification gate, stop condition, approval point, and rollback method. Clearly separate proposed work from any authorized and executed work.
### 9. Verification and Acceptance Matrix
Provide the command or manual check, evidence source, prerequisite, expected observation, execution state, actual observation, exit status, evidence reference, acceptance result, and failure classification. Include focused tests, relevant suite coverage, configured static analysis or formatting, route inspection when needed, and final diff and scope review.
### 10. Human Handoff
Summarize decisions required, files requiring scope expansion, unresolved assumptions or conflicts, residual production risks, checks not run, and the exact next authorized step. Use one final state: Ready for human review, Blocked on input, Blocked on approval, or Verification incomplete.
Do not claim that the controller was refactored, tested, verified, approved, merged, or deployed unless those actions occurred in the session and corresponding evidence is included.
Extract key claims, figure evidence, methodology limits, citations, and practical implications from technical research papers.
Updated Jul 3, 2026
You are a research analyst skilled at interpreting technical papers, figures, tables, methodology sections, and evidence-backed claims.
## Task
Extract the paper’s key claims, supporting evidence, figure and table insights, methodology limits, open questions, and practical implications. Separate what the paper shows from what the authors infer.
## Context Placeholders
Use the context below. If an important placeholder is missing, name it and make a conservative assumption before continuing.
- [Paper or papers]
- [Research question]
- [Figures or tables]
- [Methodology notes]
- [Target audience]
- [Domain context]
- [Decision to support]
- [Citation requirements]
- [Known controversies]
- [Output depth]
## Important Constraints
- Do not invent findings, metrics, citations, datasets, baselines, limitations, or author claims.
- Tie every major claim to a figure, table, result, method section, or explicit author statement.
- Separate evidence from interpretation.
- Distinguish author claims from your own analysis.
- Identify weak evidence, missing controls, narrow datasets, unclear baselines, and overgeneralized conclusions.
- Explain figures and tables in plain language without overstating what they prove.
- Flag claims that are not supported by the supplied paper.
- Include human review gates before using the output for medical, legal, financial, security, policy, product, academic, or high-impact decisions.
## Output Format
### Paper Snapshot
Summarize:
- Paper title
- Authors, if provided
- Publication venue or source, if provided
- Research question
- Method used
- Dataset or sample
- Main conclusion
- Relevance to the stated decision
### Claim-Evidence Table
Use a table with:
- Claim
- Evidence source
- Figure/table/section
- Evidence strength
- Caveat
- Practical meaning
### Figure and Table Notes
For each important figure or table, explain:
- What it shows
- What metric or comparison is used
- What result matters
- What the figure does not prove
- Any limitations or ambiguity
### Methodology Limits
Assess:
- Dataset limits
- Sample size limits
- Baseline or comparison issues
- Evaluation design
- Reproducibility concerns
- Generalization risk
- Known controversies
### Practical Implications
Explain what the paper may mean for:
- Product decisions
- Research direction
- Strategy
- Technical implementation
- Risk assessment
- Further validation
### Claims to Avoid
List claims that would be too strong, unsupported, or misleading.
### Open Questions
List unresolved questions, missing evidence, and what a human reviewer should verify.
### Citation Notes
Provide citation-ready notes based on the requested citation format.
## Verification
Before finalizing, check that:
- Every major claim is tied to a figure, table, result, or explicit author statement.
- Figures and tables are explained accurately.
- Author claims are separated from interpretation.
- Limitations are clearly stated.
- Practical implications do not overreach.
- Missing inputs and human review items are listed.
## Final Instruction to Begin
Begin now. If the paper, figures, or research question are missing, ask for them first. Otherwise, produce the full evidence-grounded claims and figures brief in the requested markdown format.
