winter-super-cli 2026.5.26 → 2026.5.27

package/resources/local/codex/plugins/cache/openai-primary-runtime/spreadsheets/26.505.10851/skills/spreadsheets/style_guidelines.md

@@ -1,99 +0,0 @@
-# Default Style and Formatting Instructions
-Apply these defaults to all spreadsheet outputs but ensure user provided style reference(s), template, or explicit formatting instructions take precadence. If the user specifies a style, match that style.
-
-## Formatting Baseline
-- If editing an uploaded/template workbook: render first, preserve and match existing style unless user asks to restyle.
-- Typical defaults when unspecified:
-  - content columns: ~10-24
-  - text-heavy columns: cap ~32-40
-  - row heights: ~15-20 (titles may be larger)
-  - avoid oversized body fonts (>12pt) except intentional titles
-- Use fill colors, borders, and merged cells judiciously to give the spreadsheet a professional visual style with a clear layout without overdoing it
-- Add data validation for editable categorical columns (`Status`, `Priority`, `Owner`) where feasible.
-- Unless conflicting style guidelines are provided: style headers, correct number/date formats, sensible column widths, and row heights, light borders.
-- Use larger text only for titles or major section labels.
-- Use blank space or slightly taller section/header rows to separate sections
-- Keep row heights consistent within each section unless wrapped content requires expansion.
-- When text wraps, prefer widening the column before allowing deep multi-line rows; if wrapping is necessary, increase row height just enough to fully show the content.
-- Before editing, inspect all relevant current styling attributes (fills, fonts, borders, merged cells, number formats). If changing values only, never overwrite or clear cell formats.
-- Maintain structural elements (filters, tables, totals rows), and never introduce merged cells in calculation areas.
-- If users are likely to edit the workbook after export, make worksheet cells the live source of truth: any downstream values or visual states that depend on editable inputs should be driven by formulas referencing worksheet cells, then styled with conditional formatting or presentation-only formatting instead of Python-precomputed values or one-time manual fills.
-- Use simple helper values when they make behavior easier to inspect and formatting easier to apply;
-
-## Document structure
-When creating a new spreadsheet, compose a clear visual layout with distinct zones: a title/header area, the primary table or working region, and—when space and task type allow—a secondary adjacent to the main table to cover summary section or instructions for how to use the sheet. When appropriate, design the sheet so it reads like a structured document, not just a matrix of cells. Use layout, scale, and selective merging to create clear sections and give headers enough room to breathe.
-
-- Vary font size and weight intentionally so the sheet has a readable hierarchy: larger for title, medium for section headers, standard for body text.
-- Let major headers occupy more space than body cells so the sheet can feel like a real document with sections, not a uniformly sized table.
-- Size status and other validated categorical columns to the longest expected label plus dropdown space; do not leave values clipped.
-- If the same label would otherwise repeat across many adjacent rows or columns, prefer a grouped header band, merged label, or legend rather than repeating the text cell by cell.
-
-### Create strong visual hierarchy
-Establish at least three hierarchy levels:
-1. page title band (larger type, stronger fill, centered, often merged)
-2. section/header bands (distinct fill, bold text, clear alignment)
-3. body area (light or neutral surface, restrained styling)
-
-### Use a theme palette
-Choose a small coordinated palette and assign colors by role:
-- primary accent for titles or major headers
-- secondary accent for subheaders or section bars
-- soft surface/background fill for the working canvas
-- neutral/light fill for body cells
-- darker text colors for readability
-- avoid harsh contrast, excessive saturation, or too many unrelated fills
-
-### Avoiding gridlines
-Define structure with explicit fills and borders rather than relying on default gridlines. Use subtle internal borders for separation and slightly stronger outside borders to frame sections or cards. Hide gridlines when explicit section styling already defines the sheet.
-
-### Use adjacent whitespace intentionally
-When appropriate, place summary cards, assumptions, instructions, charts, legends, and small supporting lists in unused columns to the right or below the primary table as compact bounded panels sized to their content. Keep these panels visually separate from the main data region with whitespace and aligned edges, but avoid oversized sparse blocks that consume more space than the information warrants. Keep short legends and short validation vocabularies on the main sheet when they fit cleanly; use a helper sheet only when the supporting data is large, heavily reused, or would clutter the main layout.
-
-### Align and format by data type
-Apply semantic formatting to entire columns or blocks:
-- text/descriptive fields left-aligned
-- labels centered or left-aligned depending on context
-- numeric and currency fields right-aligned
-- dates with explicit date formats
-- financial values with explicit currency/accounting formats
-- do not leave important numeric fields in raw General format
-
-### Use typography intentionally but conservatively
-Use one display-style font choice for titles/section headers and one neutral readable font for body content when supported by the workbook viewer. Keep body text modest in size, reserve larger fonts for titles, and avoid mixing many fonts or excessive emphasis.
-
-### Style the body lightly for scanability
-Body regions should remain readable and calm. Use light fills, subtle borders, and minimal emphasis. If one column is the primary descriptive field, it may receive slightly stronger text emphasis to aid scanning, but avoid over-styling entire data regions.
-For dense operational tables, use subtle alternating row banding together with thin light borders so users can track across rows without making the grid feel heavy.
-
-### Prefer visible summaries over buried totals
-Important totals should usually appear in a visible summary area near the top or in a side panel, even if table-footer totals also exist. Use formulas, not hardcoded values, and style summary cards as distinct panels with their own fill and border treatment.
-
-## Colors and borders
-- Use a restrained and professional color palette that matches the nature of the task: neutral text/grid styling, one primary accent family, and at most one secondary accent for exceptions such as warnings or special states.
-- Use thin, light borders for structure; use stronger borders only for important section breaks.
-- If the sheet includes progress indicators, status indicators, timelines, heatmaps, or other cell-based visuals, make them read as consistent visual bands or blocks with restrained fills, uniform repeated-column styling, and clear accents for milestones or special states rather than noisy repeated symbols or unrelated colors.
-- Ensure conditional formatting is applied properly (i.e. such as red for negative, green for positive values)
-
-## Typography and whitespace
-- Use bold sparingly and only to establish reading order.
-- Give titles, summaries, and section breaks visible breathing room so the sheet does not feel cramped.
-
-## Charting and plotting data
-When a spreadsheet includes charts, they should feel like part of the document rather than generic spreadsheet defaults dropped onto the page.
-
-- Create charts from a bounded source range whose first row is headers, whose first column contains the exact x-axis labels to display, and whose remaining columns are the plotted series. If the available data is not already in that shape, write a helper range in that shape first and chart the helper range instead of the raw block. Use clear titles and explicitly set axis titles and unit/number formats whenever the chart communicates a measured value or comparison.
-- When the workbook needs both a detailed data table and a chart, keep the detailed table for browsing/filtering, but place the chart next to a smaller chart-driving range that contains only the fields actually plotted.
-- Choose chart types intentionally (e.g., clustered column for group comparisons, line for trends over time, pie for share of a whole) and place them close to the relevant data.
-- Use tables for structured data that benefits from filtering/sorting; name tables clearly.
-- Do not place a chart so it is overlapping or hides data
-
-### Axes, scales, and labels
-- Use readable axis labels with sensible tick density; do not overcrowd the x-axis.
-- If needed, angle the axis labels if they are at risk of overlapping and this would boost readability.
-- For time-based charts, if raw dates would create crowded labels or unreliable date-axis grouping, add an explicit grouped field such as Year, Quarter, Month, or Week to the chart source and chart that field instead of charting every raw date.
-
-## Citation Requirements
-### Cite sources inside the spreadsheet
-- Use plain-text URLs in spreadsheet cells.
-- For financial models, cite model-input sources in cell comments.
-- For researched row-wise data tables, include source URLs in a dedicated source column.

package/resources/local/codex/plugins/cache/openai-primary-runtime/spreadsheets/26.505.10851/skills/spreadsheets/templates/financial_models.md

@@ -1,121 +0,0 @@
-## Financial Modeling Guidance
-
-Follow this additional guidance for finance, accounting, valuation, forecasting, budgeting, investing, operations metrics, and investment-banking work unless it conflicts with the user's request. Keep simple finance-adjacent trackers lightweight.
-
-### Financial Model Guidance
-- Treat correctness as reputation-critical. For source-backed finance work, linked models, valuation, forecasting, and other high-impact analysis, run a finance audit pass and fix meaningful issues; do not rely only on a generic formula-error scan.
-- Apply finance number formats to source values and formula outputs; do not leave calculated model rows in `General`. Label units in headers or row labels (for example, `Revenue ($mm)`, `Margin %`, `EV/EBITDA`).
-- Default finance formats:
-  ```
-  Currency/financial amounts: "$#,##0;[Red]($#,##0);-"
-  Per-share values: "$0.00;[Red]($0.00);-"
-  Percentages: "0.0%;[Red](0.0%);-"
-  Multiples: "0.0x;[Red](0.0x);-"
-  Counts/non-currency amounts: "#,##0;[Red](#,##0);-"
-  ```
-- All added raw inputs should have their sources cited in the appropriate cell comment
-- Assumptions / data inputs (growth rates, multiples, margins, tax rates, WACC, terminal growth, etc.) should be in separate cells or sheets.
-- Anchor forecast assumptions to history, source data, or a visible ramp/step change where possible.
-- Do not embed business assumptions or source data as magic numbers inside formulas. Put them in labeled input/source cells and reference them.
-- Financial return formulas must be guarded until the cash-flow sign pattern and minimum data requirements are valid. If IRR/XIRR cannot be valid for an illustrative template, use a documented estimate metric such as cash-on-cash return, NPV at the stated discount rate, or a guarded RATE approximation instead of surfacing `#NUM!`.
-- State core model conventions in the workbook: currency/unit scale, fiscal period basis, forecast period, valuation date, source date, scenario/case, and discounting convention where relevant.
-- Source, historical-data, notes, and description columns must be readable at normal zoom. Use compact source IDs in historical/model rows and put full URLs in a separate Sources/Audit sheet; do not repeat long URLs down working tables. Sources/Audit should capture item, value, units, period/as-of date, source name/link, and notes. Use aliases or a mapping table for long XBRL tags. Widen text columns and use wrap text/row height so filing references, source notes, and audit notes are not clipped.
-- Complex calculations or assumptions can be explained via a cell comment.
-- Build in error checks such as ensuring balance sheet balances when possible.
-- Tables, charts and graphs can be used to summarize important information.
-- Prefer INDEX MATCH functions over VLOOKUP to query data
-- If many iterations are requested, it may be helpful to maintain a version history or changelog (often on the cover sheet or in a separate tab) to track updates.
-
-### Existing model formatting/edit safety
-- For formatting-only or restyling edits, preserve formulas, named ranges, tables, external links, hidden rows/columns, sheet order, and semantically correct existing formats unless the user asks to restructure. Prefer new analysis sheets when that avoids disrupting a live model.
-- Preserve workbook navigation and period semantics: freeze panes, filters, grouped headers, and date/period header formats should remain intact unless explicitly changed.
-- Classify row formats from labels, existing formats, nearby context, and sample values before applying ranges. Do not convert source values to percentages unless the row is clearly a margin, rate, growth, yield, WACC/TGR, cost of equity/debt, discount rate, risk-free rate, risk premium, or tax-rate row.
-- EV/EBITDA, P/E, and similar valuation rows are multiples; shares/counts are non-currency; day-count metrics use plain numbers with `days` in the label; tax expense/payable/deferred-tax rows keep amount formats.
-
-### Preferred finance model architecture
-When creating a finance model from scratch, use a readable flow such as cover/summary, assumptions, drivers, financials/model, valuation or outputs, sensitivities/scenarios, checks, and Sources/Audit. Adapt this structure to the request and preserve existing workbook architecture when editing a live model.
-
-For 3-statement or IB-style models:
-- Use explicit forecast drivers instead of hardcoding outputs.
-- Retained earnings should roll forward from beginning balance, net income, distributions, repurchases, and other equity movements.
-- Cash flow statement ending cash should tie to balance sheet cash.
-- Debt, cash, and share count schedules should be explicit when they affect valuation.
-- Do not let balance-sheet checks pass only because cash, equity, or "other" rows are plugged. If a plug is unavoidable, label and justify it.
-
-### Finance audit pass
-For complex financial models, DCFs, 3-statement models, scenario/sensitivity models, or source-backed finance analysis, before final export:
-- Confirm sources, assumptions, and representative formulas tie together; trace representative cells when it clarifies a high-impact calculation or check.
-- Check that income statement, balance sheet, cash flow, DCF/valuation, sensitivity/scenario tables, and checks tie together where present.
-- Review large forecast step-changes versus history; fix them, bridge them with driver logic, or add a clear source/assumption note.
-- Confirm any cash/equity/other plug is clearly labeled and justified; do not treat a passing balance-sheet check as sufficient validation.
-- Use helper rows or blocks for complex formulas instead of long opaque formulas in output tables.
-
-### Timeline and actuals vs forecast
-For period-based models:
-- Use one consistent time axis per block; clearly label actuals, budget/forecast, prior year, forecast periods, and the period basis.
-- Visually separate historical/actual from forecast periods, and keep copy-across formulas consistent across each time series.
-- Do not mix monthly, quarterly, and annual periods in the same calculation block unless separated and tied with clear rollups.
-
-### Formatting Guidance
-Follow these financial formatting conventions unless specifically overridden:
-- **Blue text (RGB: 0,0,255)**: Hardcoded inputs, and numbers users will change for scenarios
-- **Black text (RGB: 0,0,0)**: ALL formulas and calculations
-- **Green text (RGB: 0,128,0)**: Links/References to other worksheets cell(s) within same workbook
-- **Red text (RGB: 255,0,0)**: External links to other files
-- **Yellow background (RGB: 255,255,0)**: Key assumptions needing attention or cells that need to be updated
-- Include a compact legend if the workbook has more than one type of input, formula, or link coloring; legend colors must match the actual styles.
-- Formatting must be consistent, following user-specified formatting first, then skill guidance.
-- Use real date values for period headers and format forecast periods like `yyyy"E"` instead of typing `2027E`.
-- For grouped period headers such as Historicals, Forecast, or CAGRs, prefer center-across-selection or a clean merged band.
-- All number and date formats must be set, with numbers right-aligned.
-- Inputs, calculations and outputs should be organized into separate sheets
-
-### Formula and Verification Guidance
-- Prefer simple, auditable formulas: one row, one formula pattern across forecast periods where possible; use helper rows instead of dense nested formulas.
-- Keep calculations formula-driven in the workbook, not hidden in the builder script. Users should be able to trace the model from inputs to outputs.
-- Derive aggregate outputs from modeled components instead of separately forecasting both.
-- Prefer direct links to original source/input cells. For larger models, pull cross-sheet assumptions into local handoff rows, then calculate from those local rows.
-- Avoid external workbook links unless explicitly requested; if unavoidable, label and color-code them red.
-- Avoid circular references in most cases, as they can make models unstable and difficult to audit. However, in certain financial models: such as cash flow sweeps, interest on average balances, or working capital loops,  they may be required. When circular logic is intentional, clearly document the purpose and ensure that iteration settings are configured correctly.
-- Create or maintain a visible `Checks` section or sheet when the model is nontrivial. At minimum, include checks for formula errors, source/input completeness, totals vs components, sign/units, and model status.
-- Financial checks should be decomposed into readable rows: one assertion per row with labeled Actual, Expected, Difference, Tolerance, Status, and Notes columns. The final model-status formula should aggregate check statuses with conditional formatting (e.g. with "OK" being green fill), not recompute business logic inline.
-- For larger finance workbooks, surface a model status on the cover/summary; failed checks should show a fix hint or location.
-- If a financial/check formula is longer than roughly 150 characters, contains nested `IF`/`AND`/`OR`, or validates multiple concepts, split it into helper rows or columns with clear labels.
-- For IB-style, 3-statement, or operating models, include applicable balance sheet balance, cash flow/cash roll-forward, debt roll-forward, sign convention, total/subtotal tie-out, and revenue/margin sanity checks.
-- For valuation models, include checks that free cash flow ties to its components, discount factors and terminal value are correct, enterprise value bridges to equity value when relevant, and key valuation outputs are not hardcoded.
-- Before final export, inspect representative formulas/styles and verify color conventions: inputs are blue, formulas are black, internal sheet links are green, no business-assumption hardcodes are embedded in formulas, and checks show `OK` or clearly explain any limitation.
-- After bulk formatting, spot-check representative row labels against formats so rate/percentage rows and period/date headers were not converted to currency or plain numbers.
-- Before final export, render the cover/summary, assumptions, sources, historical/input data, valuation, sensitivity/scenario, and checks sheets that exist. Fix any clipped labels, source notes, formulas, or important outputs before returning the workbook.
-
-### Sensitivity/scenario table correctness
-- Changed drivers should be obvious in row/column headers.
-- Each output cell must calculate from the row/column driver inputs and the target output cell or equivalent driver logic. Do not paste static sensitivity outputs.
-- Sensitivities must recalculate the underlying valuation or return mechanics, not just tweak final outputs.
-- Use helper rows/blocks for PV of FCF, terminal value, equity bridge, per-share value, returns, or other intermediate outputs instead of hiding huge formulas in the table body.
-
-### Corporate finance and FP&A minimums
-If the request involves budgets, forecasts, monthly business reviews, KPI packs, headcount, opex, revenue planning, or variance analysis:
-- Lead with the management question: summarize the decision, variance, forecast, or KPI story before detailed data.
-- Use a clear Actual / Budget or Forecast / Var $ / Var % / Prior Year layout for variance tables, with favorable/unfavorable signs defined.
-- Keep assumptions, imported actuals, calculation logic, outputs, scenarios, checks, and sources distinct. Include source refresh/as-of notes when the workbook depends on external reports.
-- Make scenario selectors and key overrides visible, and distinguish source-backed guidance from analyst assumptions.
-
-### DCF and valuation minimums
-If the request involves DCF, company valuation, investment banking, equity research, or similar:
-- Build within the finance model architecture above; for DCF/valuation, make the valuation output, sensitivities/scenarios, checks, and Sources/Audit explicit.
-- Include the key DCF bridge unless the prompt specifies otherwise: revenue/EBIT or EBITDA drivers, taxes, D&A, capex, change in NWC, unlevered FCF, discount factors, PV of forecast FCF, terminal value, PV of terminal value, enterprise value, and equity value bridge when net debt/share data is available.
-- Label simplified assumptions explicitly if source data is missing. Do not imply precision where the prompt or inputs do not support it.
-- Document whether terminal value uses Gordon growth or exit multiple, and ensure the terminal value is discounted using the same timing convention as forecast cash flows.
-- Follow the sensitivity/scenario table correctness rules above.
-
-#### Useful financial functions
-Use standard Excel functions when they improve auditability: NPV/XNPV, IRR/XIRR, PMT/IPMT, SLN/DB/DDB, and exact-match lookups such as INDEX/MATCH or XLOOKUP where appropriate. Keep formulas readable and source assumptions from input cells.
-
-### Investment Banking Guidance
-If the spreadsheet is related to investment banking (LBO, DCF, 3-statement, valuation model, or similar):
-- Total calculations should sum a range of cells directly above them.
-- Hide gridlines. Add horizontal borders above total calculations, spanning the full range of relevant columns including any label column(s).
-- Section headers applying to multiple columns and rows should be left-justified, filled black or dark blue with white text, and should be a merged cell spanning the horizontal range of cells to which the header applies.
-- Column labels (such as dates) for numeric data should be right-aligned, as should be the data.
-- Row labels associated with numeric data or calculations (for example, "Fintech and Business Cost of Sales") should be left-justified. Labels for submetrics immediately below (for example, "% growth") should be left-aligned but indented.
-- Freeze panes on large model sheets and avoid hiding rows/columns; use grouping sparingly when needed.

package/resources/local/codex/plugins/cache/openai-primary-runtime/spreadsheets/26.505.10851/skills/spreadsheets/templates/healthcare.md

@@ -1,33 +0,0 @@
-## Healthcare (clinical/administrative) spreadsheets
-
-### Tab structure
-- Use separate tabs for distinct data sets and separate raw data from summary or analysis: Data Entry (raw clinical or administrative data inputs), Calculations (where any metrics or aggregations are computed), and Reports (for summaries, charts, or tables for decision-making).
-- In a clinical context, you might have one sheet for patient-level data (each row = one patient or encounter), and another sheet that pivots or summarizes by clinic or by month.
-- Administrative workbooks (like a staffing or finance tracker) might split sheets by function – e.g., a “Staff List” sheet, a “Schedule” sheet, a “Payroll Calc” sheet, etc.
-- Name each tab descriptively, such as “Appointments_RawData”, “Clinic KPI Dashboard”.
-
-### Formatting
-- Clarity and readability can have real consequences in healthcare, so adhere to common formatting signals.
-- Highlight input fields (shaded light yellow) or form elements that staff are meant to fill out. If input is not used for calculation, placeholder “enter data here” may be used.
-- Use conditional formatting to flag values that are out of normal range or require attention: e.g., automatically shade a cell red if a lab value is critical, or highlight an entire row if a patient is overdue for a follow-up.
-- Include color legend (e.g. red = critical, orange = caution, green = within target, etc.).
-- Use clear data formatting (e.g. YYYY-MM-DD or MM/DD/YYYY as required), identifiers (like medical record numbers), and units for all measurements (e.g. weight in kg, temperature in °C).
-- Layout must be printable and scannable in urgent situations: use adequate font sizes, avoid crowding too much info, and freeze header rows for long lists of data so column titles (like “Patient ID”, “Last Visit Date”) are always visible.
-
-
-### Formulas
-- Accuracy is paramount, so double-check and simplify formulas wherever possible. If calculating clinical indicators (e.g. average length of stay, readmission rates), use straightforward aggregate formulas or pivot tables, which are less error-prone than manually crafted arrays.
-- Where calculations involve thresholds or guidelines (say, flagging patients with BMI over a certain value), consider referencing those thresholds from a single cell named “BMI_threshold” so that it’s clear and adjustable, rather than embedding the number in multiple formulas.
-- Include sanity checks: for example, if you calculate a total patient count from different categories, include a check that the sum of categories equals the total from the raw data. Any critical formula (like one computing a dosage or a financial total) might be independently verified or at least labeled clearly with comments.
-
-### Raw data and outputs
-- Never alter or delete original healthcare data
-- For data entries that need correction (e.g., a misspelled diagnosis or an out-of-range age), consider doing it via a data validation process or noting corrections in a separate column (“Corrected value”) rather than overwriting, or maintain an audit log of changes.
-
-
-### Metadata, units, and codes
-- Healthcare data is full of codes and units, which must be documented.
-- Always provide the units for each metric (e.g., blood glucose “mg/dL”, heart rate “bpm”).
-- If the sheet is used for clinical purposes, including normal ranges or target ranges in the metadata can be helpful (for instance, note “Normal range: 70–100 mg/dL” next to a blood sugar metric).
-- Make use of separate sheets to list code definitions: for example, a sheet “Codebook” could map ICD-10 codes or lab test codes to plain English descriptions.
-- If the main data uses abbreviations (like “M”/“F” for sex or clinic codes like “NYC” for New York Clinic), ensure there is a legend or the full term in the header (“Sex (M/F)” is clear).

package/resources/local/codex/plugins/cache/openai-primary-runtime/spreadsheets/26.505.10851/skills/spreadsheets/templates/marketing_advertising.md

@@ -1,31 +0,0 @@
-## Marketing/Advertising Guidance
-
-### Tab structure
-- Default to splitting data and analysis, with separate "Source Data" tab (e.g., an export of ad performance or web analytics data), one or more "Analysis" tabs (where pivot tables, lookup tables, or calculations summarize the raw data), and a Dashboard/Report tab that presents key results and charts for stakeholders.
-- Clearly name tabs by content (e.g., “Leads_Q1_2025”, “Pipeline Analysis”, “ROI Dashboard”) so that users can easily find inputs versus results.
-
-### Cell formatting
-- Highlight key performance metrics to make them stand out. Use consistent coloring or emphasis for important numbers. For instance, you might shade cells green for metrics that hit target and red for those below target.
-- Include a color key with text to ensure meaning is clear
-- Bold fonts and borders can draw attention to total figures or summary KPIs.
-- Input cells (e.g., cells where a user can adjust an assumption like a growth rate or a budget allocation) can be given a distinct fill color (such as light yellow), so that planners know what fields they can edit.
-- For metrics, ensure formatting matches common practice and is legible, e.g. percent metrics with one decimal and a % sign, currency with appropriate symbols and no excessive decimals, and so on, for professional appearance.
-- If the spreadsheet serves as a report, you should incorporate the company’s branding colors in charts or headers.
-
-
-### Marketing Analysis
-- Formula clarity is important. Keep formulas straightforward (SUMIFS, COUNTIFS) and avoid overly complex nested IF logic for scenarios. Instead, consider a separate table mapping conditions to outcomes.
-- Leverage pivot tables or summary functions to aggregate data by campaign, channel, etc., rather than a tangle of manual formulas.
-- For time series, keep a helper column with Excel dates converted to ISO YYYY-MM-DD so the sheet can be pushed to BI tools without reformatting.
-
-### Raw data vs. outputs
-- Keep raw data, including import data, intact and separate from any modifications
-- Any cleaning (like removing test entries or combining categories) should be done in an adjacent column or in a processing sheet, so the original dump remains as a source of truth. Then use references or pivot tables to feed your analysis. This way, if new data arrives (say, next month’s metrics), you can paste it into the Data tab and refresh the analysis easily.
-- The Output or Dashboard sheet should pull its figures from the analysis/calculation layer, not directly from raw data scattered around, to avoid errors.
-- Include charts or graphs on the output sheet to visualize trends in impressions, click-through rates, conversion funnels, etc., for which the underlying data might reside in hidden supporting sheets or off to the side.
-
-
-### Metadata and sources
-- Marketing analytics often involves combining data from multiple sources (ad platforms, surveys, sales figures). Always document these sources. For example, label a data column “Facebook Ads – Impressions (source: Ads Manager export on 2025-05-01)” or have a small note on the dashboard: “Data Sources: Google Analytics, CRM database (as of Apr 2025).” This gives context to the numbers and their freshness. Include time frames and units in your labels – e.g., “Budget (USD)” or “Weekly Reach”.
-- Label any assumptions clearly
-- Consistency is also key: if “CPC” means cost per click, ensure it’s defined somewhere or obvious from context, so everyone reading the sheet interprets metrics correctly.

package/resources/local/codex/plugins/cache/openai-primary-runtime/spreadsheets/26.505.10851/skills/spreadsheets/templates/scientific_research.md

@@ -1,19 +0,0 @@
-## Scientific Research Guidance
-
-### Tab structure & naming
-- Organize spreadsheets to separate raw data from analysis.
-- Raw data (e.g. experimental measurements or survey data) should be in its own sheet, typically as a flat table where each column is a variable and each row is an observation.
-- Any cleaning or transformation of data should be done in a processed data or analysis sheet, rather than directly in the raw dataset. Do not alter original measurements or raw data. Create an analysis or processed-data copy of raw data if necessary. Cleaning steps can be documented in a separate README or protocol sheet to indicate how raw data was processed (e.g., “removed entries where Temperature < 0, converted units from °F to °C”) for peer review.
-- Additional sheets might include Calculations (for intermediate computations, pivot tables, or statistical analyses) and Results (for summary tables or graphs). This structure makes it clear where results come from.
-
-### Formatting
-- Each column should contain one type of data (with units in the header, not mixed into the cells) and each row one record.
-- Avoid merging cells or creating multi-row headers that can complicate data import into analysis tools.
-- Do not use formatting (color, bold, italics) as the sole means to encode information in data tables as analytical software may not recognize cell color. Instead, if certain values need flagging (e.g. outliers or notable entries), add a separate “Flag” column or annotation.
-- Layout should be plain and data-focused: for instance, list any comments or notes in a separate column rather than as Excel cell comments or text boxes. This makes the data more machine-readable.
-
-### Formula practices
-- In scientific spreadsheets, complex data analysis is often done outside Excel, but when using formulas, prioritize transparency and accuracy.
-- Avoid volatile functions (e.g. RAND() for randomization) unless necessary for simulation, and document any usage clearly.
-- Do not introduce circular references; iterative calculations can obscure the lineage of results and complicate reproducibility.
-- If performing calculations like statistical formulas or unit conversions in-sheet, show the formula or use helper columns for each step so others can verify the math. This stepwise approach makes it easier to verify scientific calculations. Where possible, cross-check Excel results with another tool or manual calculation to ensure no spreadsheet errors are affecting the outcomes.

package/resources/local/codex/rules/default.rules

@@ -1,13 +0,0 @@
-prefix_rule(pattern=["C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "-Command", "if(Test-Path 'e:\\dev\\18.03\\my-translator\\.electron-runtime'){ Remove-Item -Recurse -Force 'e:\\dev\\18.03\\my-translator\\.electron-runtime' }"], decision="allow")
-prefix_rule(pattern=["C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "-Command", "if(Test-Path 'e:\\dev\\18.03\\my-translator\\scripts\\__pycache__'){ Remove-Item -Recurse -Force 'e:\\dev\\18.03\\my-translator\\scripts\\__pycache__' }"], decision="allow")
-prefix_rule(pattern=["C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "-Command", "npm.cmd run tauri -- build"], decision="allow")
-prefix_rule(pattern=["C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe", "-Command", "npx.cmd vitest run src/tests/auth-mfa.e2e.test.ts --config vitest.config.ts"], decision="allow")
-prefix_rule(pattern=["powershell.exe", "-Command", "Get-ChildItem -LiteralPath 'C:\\Users\\PHUCANSOLUTIONS\\awesome-design-md\\design-md' -Recurse -Force | Select-Object FullName, Length, Mode | Format-Table -AutoSize"], decision="allow")
-prefix_rule(pattern=["powershell.exe", "-Command", "Get-ChildItem -LiteralPath 'C:\\Users\\PHUCANSOLUTIONS\\awesome-design-md\\design-md' -Filter *.md -Recurse -Force | Select-Object FullName, Length | Format-Table -AutoSize"], decision="allow")
-prefix_rule(pattern=["Format-List", "*"], decision="allow")
-prefix_rule(pattern=["powershell.exe", "-Command", "Get-Item -LiteralPath 'E:\\dev\\app\\winter' | Select-Object FullName, PSIsContainer, CreationTime"], decision="allow")
-prefix_rule(pattern=["New-Item", "-ItemType", "Directory", "-Path", "E:\\dev\\app\\winter\\src", "-Force"], decision="allow")
-prefix_rule(pattern=["Set-Content", "-Path", "E:\\dev\\app\\winter\\package.json", "-Value", "{\"name\":\"winter-cli\",\"version\":\"0.1.0\",\"description\":\"CLI tool for the Winter project with AI provider integration\",\"main\":\"src/cli.js\",\"bin\":{\"winter\":\"src/cli.js\"},\"scripts\":{\"start\":\"node src/cli.js\"},\"author\":\"\",\"license\":\"MIT\",\"dependencies\":{\"commander\":\"^10.0.0\",\"chalk\":\"^5.3.0\",\"node-fetch\":\"^3.3.2\"}}", "-Encoding", "UTF8"], decision="allow")
-prefix_rule(pattern=["Set-Content", "-Path", "E:\\dev\\app\\winter\\src\\cli.js", "-Value", "const { program } = require('commander');\\nconst chalk = require('chalk');\\nconst fetch = require('node-fetch');\\n\\nconst logo = chalk.hex('#00aaff').bold(\\n   *   \\n  ***  \\n ***** \\n*******\\n ***** \\n  ***  \\n   *   \\n);\\n\\nprogram\\n  .name('winter')\\n  .description('CLI tool for Winter project with AI provider support')\\n  .version('0.1.0');\\n\\nprogram\\n  .command('say <message>')\\n  .description('Send a message to the AI provider (placeholder)')\\n  .action(async (message) => {\\n    console.log(logo);\\n    console.log(chalk.green('Sending to AI provider...'));\\n    try {\\n      const response = await fetch('https://api.example.com/ai', {\\n        method: 'POST',\\n        headers: { 'Content-Type': 'application/json' },\\n        body: JSON.stringify({ prompt: message })\\n      });\\n      const data = await response.json();\\n      console.log(chalk.cyan(data.reply ?? '[no reply]'));\\n    } catch (e) {\\n      console.error(chalk.red('Request failed'), e);\\n    }\\n  });\\n\\nprogram.parse(process.argv);", "-Encoding", "UTF8"], decision="allow")
-prefix_rule(pattern=["powershell.exe", "-Command", "Get-ChildItem -LiteralPath 'E:\\dev\\app\\winter\\src' -Recurse -Force | Select-Object FullName, Length, Mode"], decision="allow")
-prefix_rule(pattern=["New-Item", "-ItemType", "Directory", "-Path", "E:\\dev\\app\\winter\\src\\plugins", "-Force"], decision="allow")

package/resources/local/codex/skills/.system/.codex-system-skills.marker

@@ -1 +0,0 @@
-df4cbae2c616dd6f

package/resources/local/codex/skills/.system/imagegen/LICENSE.txt

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