Build - Agent Skill Package

Scheduled and refresh-oriented wrapper for Torii dashboards in ChatGPT

Purpose

This package is the scheduled and refresh-oriented wrapper for the read-only SaaS rationalization dashboard. To get the assets related to this package contact your Torii Customer Success Manager.

Use it when we need an Agent + Skill deployment that can:

  • Refresh the dashboard on demand
  • Refresh the dashboard on a schedule where supported
  • Reuse an approved tenant mapping
  • Generate digest-style summaries for stakeholders
  • Surface field drift and data-quality issues without writing back to Torii

This package is for the operational delivery layer. It sits on top of:

  • Torii MCP for data access
  • The shared read-only dashboard skill for dashboard logic

What this package depends on

This package assumes all of the following already exist:

  1. ChatGPT is connected to Torii through MCP
  2. The shared read-only dashboard skill is installed or enabled
  3. An agent-capable runtime or scheduled task capability is supported for your ChatGPT account, this will depend on the exact Agent and schedule setup flow for your ChatGPT environment.

Torii’s official MCP support article documents the Torii connector flow for ChatGPT:

  • Use Settings → Connectors
  • Create a custom connector
  • Set the MCP server URL to https://api.toriihq.com/mcp
  • Use OAuth
  • Enable the Torii connector in a new chat
  • Operate under the signed-in user’s Torii role and permissions

This package does not replace that connection. It packages a scheduled or repeatable refresh experience on top of it.

What this package contains

This package contains 12 files arranged like this:

customer-agent-skill-package/
├─ README.md
├─ 01-solution-brief.md
├─ 02-agent-refresh-guide.md
├─ 03-tenant-field-mapping-guide.md
├─ 04-business-user-field-mapping-wizard.md
├─ 05-tenant-mapping-template.json
├─ 06-dashboard-data-spec.md
├─ 07-scoring-and-recommendation-model.md
├─ 08-read-only-dashboard-rules.md
├─ 09-daily-refresh-digest-template.md
├─ 10-business-user-prompt-pack.md
└─ 11-react-dashboard-template.jsx

What each file is for

README.md

This is the package overview.

It explains:

  • The package is for Agent + Skill

  • The dashboard is ChatGPT-native

  • The solution is read-only

  • The agent can refresh on demand or on a schedule

  • The recommended sequence is:

    1. Install or enable the shared Skill
    2. Complete the tenant field mapping setup once
    3. Configure the Agent with the approved tenant mapping
    4. Run an on-demand refresh test
    5. Validate field drift handling and read-only outputs
    6. Enable scheduled refresh if supported
    7. Review daily digest outputs with stakeholders

01-solution-brief.md

It explains:

  • Why SaaS rationalization matters
  • How ChatGPT and Torii data work together
  • That the dashboard supports tenant-specific field mapping
  • That the design is read-only
  • That deployment options include both Custom GPT and Agent wrappers

02-agent-refresh-guide.md

This is the main deployment guide for this package.

It defines:

  • The recommended agent name
  • The recommended behavior
  • The scheduled refresh prompt
  • The on-demand refresh prompt
  • The digest structure
  • Field drift handling expectations

03-tenant-field-mapping-guide.md

This explains how to map tenant-specific fields into the dashboard model.

It covers:

  • Organizational View mapping
  • Functional grouping
  • App metadata
  • Usage fields
  • License and financial fields
  • Contract and renewal fields
  • Security and governance fields
  • Mapping workflow
  • Field drift handling

04-business-user-field-mapping-wizard.md

This is the first-run guided setup for mapping fields.

It includes:

  • Read-only scope confirmation
  • Field discovery
  • Organizational View selection
  • Functional grouping selection
  • Usage and financial field confirmation
  • Mapping review
  • Mapping save behaviour
  • Confidence and drift guidance

05-tenant-mapping-template.json

This is the reusable JSON structure for saving the approved tenant mapping.

The agent should reuse this mapping on future refreshes instead of rediscovering fields every time.

06-dashboard-data-spec.md

This defines the normalized dashboard output model.

Use it to standardize what the refresh agent should generate after mapping is complete.

07-scoring-and-recommendation-model.md

This defines the scoring and review-priority logic.

Use it to keep overlap findings, review candidates, and prioritization labels consistent across refreshes.

08-read-only-dashboard-rules.md

This defines the operating guardrails.

Use it to keep the agent from drifting into write-back or workflow-trigger behavior.

09-daily-refresh-digest-template.md

This defines the recurring digest format.

It includes placeholders for:

  • Date
  • Tenant
  • Mapping version
  • Refresh status
  • Field mapping status
  • Material changes
  • Contract exposure
  • Security and governance signals
  • Decision queue changes
  • Suggested review questions

10-business-user-prompt-pack.md

This provides reusable prompts for on-demand follow-up analysis after a refresh.

Use it when stakeholders want to ask follow-up questions after reading the digest.

11-react-dashboard-template.jsx

This is the optional interactive dashboard template.

Use it when we want a more visual dashboard artifact after the refresh logic is already validated.

What this package is for

This package is most ideally suited for a scenario which needs:

  • A named refresh agent
  • A repeatable refresh motion
  • On-demand and scheduled refresh support
  • Daily or periodic digest-style summaries
  • A stable dashboard that reuses an approved field mapping
  • Stronger operational consistency than a purely conversational setup

This is the right package when the question is no longer just “Can we build the dashboard?” but also “Can we refresh and review it consistently?”

What this package is not for

This package is not the best fit when we only need:

  • A fast pilot
  • Ad hoc interactive exploration
  • Lightweight self-service
  • A named on-demand GPT without scheduling

In those cases, the Custom GPT wrapper package is usually the better fit.

This package also does not replace the shared skill. It depends on it.

Exact prerequisites

Before using this package, make sure all of the following are true:

  • The shared read-only skill is installed or enabled
  • ChatGPT is connected to Torii through MCP
  • The Torii connector can be enabled in a chat
  • The connected Torii account has enough visibility for portfolio analysis
  • The deployment is explicitly intended to be read-only
  • An environment that supports the Agent runtime and, if needed, scheduling.

Exact steps to use this package

Step 1: Install or enable the shared skill

Before this package can work, enable the shared dashboard skill:

  • saas-rationalization-dashboard

This package assumes the dashboard logic comes from that shared skill.

Without the shared skill, this package is only guides, templates, and prompts.

Step 2: Connect ChatGPT to Torii through MCP

Set up Torii as a ChatGPT connector using the official MCP flow:

  1. Open Settings

  2. Open Connectors

  3. Click Create or Add custom connector

  4. Enter:

    • Name: Torii
    • MCP Server URL: https://api.toriihq.com/mcp
    • Authentication: OAuth
  5. Save and connect

  6. Sign in to Torii

  7. Approve the OAuth flow

  8. Open a new chat

  9. Enable the Torii connector from the tools menu

These steps come from Torii’s official MCP article.

Step 3: Set up the tenant mapping once

Before configuring the refresh agent, complete the tenant field mapping setup.

Use these files in order:

  1. 03-tenant-field-mapping-guide.md
  2. 04-business-user-field-mapping-wizard.md
  3. 05-tenant-mapping-template.json

The goal is to approve:

  • The primary Organizational View
  • Functional grouping fields
  • Usage and financial fields
  • Contract and renewal fields
  • Any normalization rules
  • Fallback behaviour for unmapped values or drift

The package README explicitly says to complete the tenant mapping setup once before configuring the Agent.

Step 4: Save the approved tenant mapping

Once the mapping is approved, save it using:

  • 05-tenant-mapping-template.json

This saved mapping becomes the reusable configuration for future refreshes.

The agent should not remap fields on every run unless field drift is detected.

Step 5: Create or configure the Agent

Create the refresh agent in your ChatGPT environment.

Use the values from 02-agent-refresh-guide.md.

Recommended agent name

Use:

SaaS Rationalization Refresh Agent

Recommended agent behavior

Configure the agent so that it:

  • Uses the approved tenant mapping
  • Does not remap fields every day
  • Refreshes the dashboard on demand or on a schedule
  • Summarizes changes since the last refresh
  • Stays strictly read-only
  • Pauses affected sections if field drift is detected

Step 6: Make the package files available to the Agent configuration workflow

When configuring the Agent, use the files in this package as the source material for:

  • Refresh behavior
  • Read-only rules
  • Dashboard schema
  • Scoring logic
  • Digest structure
  • Business follow-up prompts

At a minimum, the agent behavior should reflect:

  • 01-solution-brief.md
  • 02-agent-refresh-guide.md
  • 03-tenant-field-mapping-guide.md
  • 04-business-user-field-mapping-wizard.md
  • 06-dashboard-data-spec.md
  • 07-scoring-and-recommendation-model.md
  • 08-read-only-dashboard-rules.md
  • 09-daily-refresh-digest-template.md
  • 10-business-user-prompt-pack.md

Step 7: Configure the on-demand refresh prompt

The agent refresh guide provides the recommended on-demand prompt.

Use:

Refresh the SaaS rationalization dashboard now using the approved tenant mapping and summarize changes since the last refresh.

This is the correct first operational test because it validates:

  • Mapping reuse
  • Refresh logic
  • Read-only behavior
  • Change summary behavior

Step 8: Configure the scheduled refresh prompt

If we need scheduling, use the scheduled prompt from 02-agent-refresh-guide.md:

Every weekday at 8 AM, refresh the read-only SaaS rationalization dashboard from Torii using the approved tenant mapping. Summarize new apps, changed functional overlaps, license and contract signals, field drift, and new review findings. Do not write back to Torii or trigger workflows.

This prompt is useful because it makes all of the key operational expectations explicit:

  • Recurring schedule
  • Approved mapping reuse
  • Refresh scope
  • Digest summary focus
  • Field drift reporting
  • Read-only constraint

Step 9: Run the first on-demand refresh test

Before you enable scheduling, run the agent once on demand.

Check that the agent:

  • Uses the approved mapping
  • Does not start a fresh mapping flow unnecessarily
  • Generates the expected dashboard sections
  • Summarizes changes since the last run
  • Stays read-only
  • Surfaces drift or missing data clearly

The package README recommends this on-demand refresh test before scheduled use.

Step 10: Validate the daily digest format

Use 09-daily-refresh-digest-template.md as the target digest structure.

The digest should include:

  • Refresh status
  • Field mapping status
  • New or changed apps
  • Functional overlap changes
  • License and financial signals
  • Contract exposure
  • Security and governance signals
  • Decision queue changes
  • Suggested review questions

Validate that stakeholders can actually use this digest before enabling a recurring schedule.

Step 11: Validate field drift handling

This package is explicit that field drift handling is part of the refresh design.

If a mapped field is:

  • Missing
  • Renamed
  • Changed in type

The agent should:

  • Pause dashboard generation for the affected section
  • Ask for a replacement mapping
  • Avoid silently guessing

The refresh guide states this behavior directly.

Step 12: Enable scheduled refreshes if supported

Only after the on-demand test and digest validation are successful should you enable the schedule.

Do this only if:

  • The Agent runtime supports scheduling
  • The Torii connector is available in that runtime
  • There is a requirement for recurring refreshes
  • The operating team is ready to review the output

Step 13: Review outputs with stakeholders

The package README explicitly recommends reviewing the daily digest outputs with stakeholders.

During review, check that:

  • The Organizational View is correct
  • Grouped values are readable
  • Digest structure is useful
  • Overlap findings make sense
  • Review queue labels are clear
  • Warnings are understandable
  • The agent remains read-only

Exact first-run flow

For clarity, the exact first-time sequence is:

  1. Install or enable the shared skill
  2. Connect ChatGPT to Torii through MCP
  3. Complete the tenant field mapping once
  4. Save the approved mapping
  5. Create or configure the Agent
  6. Apply the recommended agent behavior
  7. Configure the on-demand refresh prompt
  8. Run the first refresh test
  9. Validate digest structure
  10. Validate field drift handling
  11. Enable schedule if supported
  12. Review outputs with stakeholders

Exact repeat-run flow

After setup is complete, the normal repeat sequence is:

  1. The agent runs on demand or on schedule
  2. It reuses the approved tenant mapping
  3. It refreshes the dashboard
  4. It summarizes material changes
  5. It emits the digest
  6. It surfaces drift or missing-data warnings
  7. Stakeholders review the results
  8. The mapping is updated only if needed

What the Agent should output

When this package is used correctly, the Agent should produce outputs such as:

  • Refresh status
  • Dashboard summary
  • Usage changes by Organizational View
  • License and financial signals
  • Renewal and contract exposure
  • Overlap changes
  • Security and governance notes
  • Read-only decision queue changes
  • Suggested review questions

It may also generate a React-based dashboard artifact using the template after the text and digest outputs are validated.

Recommended operating model

This package works best when ownership is clear.

A good ownership model is:

  • Business owner for the review questions and decision queue usefulness
  • Technical owner for mapping maintenance and drift handling
  • Platform owner for connector access, schedule behavior, and environment support

What this package must never do

Even though Torii MCP may expose action capabilities, this Agent package should never be used to:

  • Update Torii records
  • Trigger workflows
  • Create contracts
  • Remove licenses
  • Modify ownership
  • Perform automated remediation

Torii’s MCP article confirms that connected assistants can take actions the user has granted them, but this package is intentionally limited to read-only dashboard refreshes and summaries.

Troubleshooting

The agent keeps remapping fields

This usually means the tenant mapping was never saved cleanly or is not being reused consistently.

The digest is too noisy

Tighten the review thresholds in the dashboard logic and confirm that the digest is focusing on material changes rather than all changes.

The grouped output is inconsistent across runs

This usually means the Organizational View normalization rules are incomplete or the source field is drifting.

The agent sees Torii data but some sections are incomplete

This may be a Torii permission-scope issue or related to the prompt.

The agent offers actions

That can happen because MCP may expose action capabilities. Keep the agent instructions explicitly read-only and reject write-back use.

Scheduled refresh is unavailable

That usually means the environment does not support the required Agent runtime, scheduling, or connector behavior.

Final checklist

Before calling this package ready, confirm that:

  • The shared skill is enabled
  • ChatGPT is connected to Torii MCP
  • The Agent is configured
  • The tenant mapping is saved and reused
  • The on-demand refresh test passed
  • The digest format is validated
  • Field drift handling works
  • Scheduled refresh is enabled only if supported
  • Outputs are reviewed by stakeholders
  • No write-back behavior is allowed