Get started for non-engineering users

If you work primarily in documents, spreadsheets, meetings, and messages rather than code, Glean Tau combines your company's knowledge with the files already on your computer. You don't need to upload anything, and you don't need to know how to code.

Set up a workspace and create your first artifact, then:

• Try a starter prompt to learn what Glean Tau can do, prepare research, write, analyze, and create.
• Follow a step-by-step use case for your team, from marketing and sales to finance and legal.

Set up your local workspace

A Glean Tau project is a durable group of chats with related subjects, such as a customer, a launch, or a reporting cycle. Use one project per body of work so related conversations stay together and you can pick any of them back up later.

Every project also has a default working folder, which Glean Tau uses when it needs to read or produce files. You don't have to supply that folder yourself.

Choose how to start:

• Start from scratch when the project is mainly a way to group chats by purpose. Glean Tau creates and manages a private working folder for you.
• Import existing folder when you already have files for the work, such as notes, slide decks, documents, or templates.

To create a project:

1

Add a project

In the Glean Tau left sidebar, select Add project (the folder icon beside the Chats heading). Or navigate to New chat and select the project selector.

2

Choose how to start

Select Start from scratch, name the project, and select Create. Or select Import existing folder and choose the folder you want to use. Glean Tau names an imported project after its folder.

If you'd rather gather your files first, create a folder for the work, move the relevant files into it, then import it.

Glean Tau starts a new chat in the project, and the project appears in the sidebar's Chats list so you can return to it any time.

To see what's in a project's working folder, open the Explorer tab in the side panel.

You can also skip projects entirely: select Don't work in a project in the project selector. The chat still runs in a folder on your computer.

You can change a project's default working folder later from its menu. Existing chats keep the folder they're already working in.

note

Adding a folder doesn't add its contents to Glean's company index. Glean Tau reads files from the folder as needed, subject to your operating system permissions and the chat's approval mode.

Glean Tau runs real actions on your computer, so check the approval mode setting. You can accomplish most work efficiently in the default Approve for me mode. Choose Ask for approval if you want to review permission requests yourself. To learn more about approval modes, see Agent approval modes.

Create your first artifact

An artifact is a file Glean Tau creates for you and keeps with the chat that created it. You ask for one in plain language. Glean Tau can create:

• Documents
• Spreadsheets
• Slides
• Webpages
• Message drafts
• Email drafts

To create an artifact, in a chat attached to your project, describe what you want and what it should be based on. For example: "Write a one-page brief on [Project] using the notes in this folder and what you can find in our internal docs. Make it a document."

1. Review the result in the side panel's Library view.
2. Prompt changes in the same chat, such as "Tighten the summary, add a risks section, cut it to one page." Glean Tau revises the existing artifact instead of starting over.

Find every artifact you've made in the Library. Select More → Library. Glean Tau uploads new artifacts to your Glean library as private copies and keeps them in sync, so you can open and share them in Glean Web. See Sync artifacts with Glean.

note

Glean Tau drafts messages and emails but doesn't send them. Sending requires you to ask explicitly.

Work with files in your workspace

Once a folder is a project, working with the files in it is conversational. You don't upload anything and you don't need to name file paths precisely. Here's how to work with files in your workspace:

Add files: Move or save files into the project folder on your computer to make them available as context in your chat. The Explorer tab shows them automatically. If the list looks out of date, select Refresh.

Point at something specific: When a folder holds a lot of files, use + in the composer to attach the exact file you mean, or just name it in your prompt.

Ask about files instead of opening them: Try the following prompts instead of opening and reading multiple files:

• "What's in this folder?"
• "Summarize the three PDFs in here."
• "Which of these is most recent?"

Know what stays local: Files in your project folder stay on your computer. Company knowledge Glean Tau searches comes from Glean and respects your existing permissions. Artifacts sync to your Glean library as private copies unless you turn off uploads in Settings → Extensions → Artifacts.

Expect written output in the folder: When Glean Tau creates or edits a file in your project, it writes into your project folder. You can open the result in Word, Excel, PowerPoint, or any other app you normally use. Artifacts are stored separately, in the Library.

Collect information from the web

Glean Tau can use the built-in Browser to find and download information from websites, then save it to your project folder and analyze it. Consider this example, where you want a local research pack of public financial reports.

1

Create a project for the research

Create a project, or import an empty research folder, so the downloads land in one place. See Set up your local workspace.

2

Describe the task

Prompt the agent with the scope and the output you want: "Collect public PDF financial reports for [companies] into a local folder. Analyze each and create local summaries for review."

The agent opens the sources in the Browser panel and shows its progress as it works.

3

Check the files

Open the Explorer tab, or the folder on your computer, to confirm that each report and summary is there.

4

Turn the results into an artifact

Ask for a comparison: "Compare these companies' reported results and make it an interactive chart artifact. Cite the source for each number." Review and refine the chart in the side panel's Library view.

The Browser panel uses its own signed-in profile. To work in sites where you're already signed in with Chrome, use Browser Use. For a desktop app with no web interface, use Computer Use. Both are off by default. See Browser and Let the agent use your computer.

Starter prompts

Try a starter prompt in a new chat, or tell Glean Tau what you'd like to do. Replace the bracketed placeholders with your own details.

Learn

Ask Glean Tau to explain a feature and walk you through it.

Starter	Prompt
Files & context	"Explain the local and enterprise context Glean Tau can use. Tell me how to change the chat session's local directory."
Projects	"Briefly explain what Glean Tau projects are and why they might be useful for me. Guide me visually through creating one."
Artifacts	"Explain Glean Tau artifacts. Then, create an example HTML artifact status report of my work."

Prepare

Collect research and status updates, once or on a schedule.

Starter	Prompt
Local research pack	"Collect public PDF financial reports for [companies] into a local folder. Analyze each and create local summaries for review."
Morning action plan	"At 7 AM weekdays, draft my open actions from notes, emails, meetings, and chats. Link sources and flag deadlines."
Gather team status	"Every Friday at 4 PM, draft [team]'s progress, blockers, and next actions from Slack, tickets, and docs."

Prompts with a schedule create an automation. Automations created from a chat are active right away, so check the schedule and access mode on the Automations page.

Write

Draft replies and updates, or dictate instead of typing.

Starter	Prompt
Answer a Slack thread	"Read [thread URL] and company docs. Draft a short reply that answers the open question and cites sources. Don't post."
Dictate instead of type	Place your cursor, press the dictation shortcut, and speak. Review the pasted text. See Dictation.
Draft a clear update	"Brief [audience] from [sources] on progress, decisions, risks, owners, and next steps. Flag unknowns."

Analyze

Reconcile records, learn from past calls, and prepare expense claims.

Starter	Prompt
Reconcile records	Select two files, then: "Match by [key]. Flag missing, duplicate, or conflicting records. Save a reconciliation table; keep originals."
Learn from similar sales calls	"Analyze Gong calls from [date range] from opportunities similar to mine. Summarize the best responses to [common question]. Save quotes to my customer quote log."
Prepare expense claims	Sign in to your expense tool in the Browser, then: "Draft expense claims; check receipts, policy, amounts, and duplicates. Flag exceptions; don't submit."

Create

Build a video, a reusable skill, or a small local app.

Starter	Prompt
Create a product explainer video	"Create a 60-second explainer video for [product] using ffmpeg and the external published documentation as reference material."
Save a repeatable workflow	After a task succeeds, stay in the chat: "Make a local skill with inputs, steps, output, sources, and checks. Show its trigger and test plan; don't publish."
Build a personal widget	State your priorities and focus areas, then: "Build a custom local application: a small, joyful widget that keeps me motivated and on track."

note

Analysis might require running a command on your computer. In Approve for me mode, higher-risk actions stop and ask for your approval before they run.

Use cases by team

Each use case lists when to use it, what to start with, the steps, what you get, and a prompt to try. The prompts keep the work in local drafts for review: they tell Glean Tau not to send, publish, or change systems, so you decide what leaves your computer. For engineering, see Engineering use cases.

Marketing

Use it when: Customer advocacy needs a story about an existing customer, without turning internal evidence into approved public claims.

Start with: One customer, the sources you're authorized to use, and a local brand template.

1. Find evidence about the customer in those sources. Keep links, dates, and conflicting numbers.
2. Create a claim table that separates supported outcomes, missing proof, and approval status for external sharing.
3. Draft the story in the local brand template. Leave unsupported claims out for reviewers to decide.

You get: A branded story draft and claim table, ready for customer-advocacy review, not publication. Every outcome has a source, and unresolved metrics and sharing approvals stay visible.

Try it: "For [existing customer], use only [authorized sources] and [local brand template] to draft a customer story in [folder]. Cite each factual claim, flag conflicting metrics, and separate evidence from assumptions and sharing approvals. Don't invent ROI or quotes. Keep everything draft-only; don't send, upload, or publish."

Tip: Save your brand structure and evidence checks as a skill to keep them consistent.

Use it when: A launch needs coordinated copy across channels, but messaging, product availability, and brand rules must stay aligned.

Start with: One approved brief, authorized product sources, and local brand examples.

1. Compare the local brief with authorized messaging and product sources. List availability caveats and unresolved claims.
2. Agree on one audience, message, and call to action. Draft email, social, and landing-page variants locally.
3. Check all variants against the same claim list and brand examples. Save drafts with review questions.

You get: A coordinated set of channel drafts with a shared claim list and open review questions. Shorter copy doesn't make stronger claims or promise broader availability.

Try it: "Use [approved campaign brief], [authorized product sources], and [local brand examples] to draft email, social, and landing-page copy in [folder]. Keep one audience and call to action. Cite claims in a shared checklist; flag uncertain availability or missing proof. Draft only: don't send, upload, publish, or edit live systems."

Use it when: Enablement needs a product walkthrough tied to current behavior, not a feature promise or an unchecked screen recording.

Start with: One approved demo flow, safe sample data, and a screen recorder set up on your computer.

1. Check launch evidence and demo prerequisites. Storyboard only the behavior available in the demo environment.
2. With your explicit approval to record, capture the browser flow and narration with the local recorder.
3. Review representative frames and the full playback for sensitive data, claim accuracy, and pacing. Save an unpublished draft.

You get: An unpublished demo-video draft, scene outline, and source and prerequisite checklist, or a storyboard if recording tools aren't available.

Try it: "Using [authorized launch sources], [approved demo flow], and [safe sample data], prepare a storyboard in [folder]. If [local recorder] is set up, ask for my approval before capturing a browser walkthrough. Verify availability caveats and visible data. Keep output unpublished; don't send, upload, publish, or change production settings."

Also uses: Browser or Computer Use.

Use it when: Product education needs a repeatable spoken briefing from release notes, with source caveats and a review step.

Start with: One authorized release feed, a local folder, and narration tools on your computer.

1. Identify new release posts from the feed. Keep source links, rollout caveats, and a local log of processed posts.
2. Draft the script, transcript, and show notes. Render audio only with narration tools already set up on your computer.
3. Write instructions for a weekly automation. Create it only after you check the files and listen to the audio, and don't let it distribute anything automatically.

You get: A briefing draft and instructions for a recurring run. Audio depends on your local tools.

Try it: "From [authorized release feed], draft a spoken briefing, transcript, and linked show notes in [local folder]. Preserve rollout caveats; process only posts you haven't handled. Use [local narration tool] only if it's set up; otherwise tell me audio is unavailable. Write instructions for a [weekly] automation, but don't create it. Don't download models, send, upload, or publish."

Also uses: Automations. To test an automation before it runs on a schedule, create it without a schedule and select Run now.

Pre-sales

Use it when: After discovery, the account team needs a shared view of customer workflows and what a pilot should prove.

Start with: A call transcript, the account record, and one local assessment template.

1. Confirm the account, people, and roles with company sources. Flag uncertain matches.
2. Map workflow stages, systems, pain points, and proposed proof metrics into your template.
3. Create an editable draft. Distinguish observations, self-reported figures, and hypotheses for account-team review.

You get: A reviewable value brief with evidence labels, open questions, and proposed owners for each proof point. No self-reported figure appears as measured ROI.

Try it: "With [transcript], [account link], and [local template], draft a value brief. Use company context to verify roles. Map workflows, friction, and proof metrics. Label observations, self-reports, and hypotheses; leave unknowns open for [reviewer]. Don't send, publish, deploy, or change production."

Tip: Before you open the draft in PowerPoint for final review, compare it with your template and check fonts, overflow, and charts.

Use it when: A customer sends a technical or security questionnaire that needs a draft grounded in current, shareable evidence.

Start with: A copy of the questionnaire and current, shareable product or security sources.

1. Preserve question IDs, tabs, and the original file. Work in a separate local copy.
2. Draft answers from approved sources. Link evidence, and flag missing, conflicting, or sensitive material.
3. Match every question to an answer or an open item, then prepare the draft for the security owner's review.

You get: An unsubmitted answer workbook with source links, exceptions, and reviewer questions. The workbook structure stays intact, and no certifications or commitments are invented.

Try it: "Create a separate draft of [local questionnaire] using [approved shareable sources]. Preserve IDs and workbook structure. Cite evidence; flag unknown, conflicting, or sensitive answers. Reconcile question coverage for [security reviewer]. Don't infer compliance, submit, send, publish, or change systems."

Tip: Define your approved sources and a freshness cutoff before drafting. Access to internal evidence doesn't make it shareable with customers.

Post-sales

Use it when: Customer promises and blockers are scattered across calls, email, and chat, or an account needs coverage.

Start with: One account, recent calls and messages, and your account-notes folder.

1. Collect the account's calls, messages, and local notes into a customer project.
2. Build a source-linked action view with owners, due dates, open questions, and account changes.
3. Review the plan. Once it's right, set up a read-only automation to refresh it.

You get: A living customer action board and a handoff brief ready for review, with unknowns clearly flagged.

Try it: "For [account], use recent calls, email, chat, and this customer folder to update a source-linked action board. Flag unknown owners and dates. Keep prior notes. Draft the next follow-up; don't send it or change CRM records."

Also uses: Automations with a read-only access mode.

Use it when: An account review needs more than an activity recap: a defensible view of results and what to do next.

Start with: A usage export, the customer's agreed goals, and customer feedback.

1. Combine usage exports, customer interviews, and the account's agreed success goals.
2. Reconcile periods and definitions. Separate observed results, modeled estimates, and evidence gaps.
3. Build editable charts and a review narrative, using a presentation skill if you have one.

You get: A reviewable value deck, an evidence workbook, and questions about adoption or expansion. Each piece of evidence connects to a customer goal and a next decision.

Try it: "Using [account]'s usage export, interview transcripts, and success plan, draft a value-review deck and evidence workbook. Link each claim to its source. Label estimates and gaps. Propose questions for the next adoption or expansion discussion."

Also uses: Skills. Save metric definitions, customer branding, and chart rules in a presentation skill to make reviews consistent.

Use it when: Customers need role-specific training, but repeating live sessions leaves less time for strategic work.

Start with: An approved deck, one customer audience, and one learning goal.

1. Start from approved training decks, scripts, and the customer's rollout requirements.
2. Create short, interactive modules with demos and knowledge checks, using a video skill if you have one.
3. Review accuracy and accessibility, then test the package in the customer's learning environment.

You get: A tailored learning package with reusable modules, demos, and source files. When something changes, update the affected lesson instead of rebuilding the package.

Try it: "Turn these approved decks and scripts into three onboarding modules for [customer roles]. Include demo-video placeholders and knowledge checks. Save editable source files. Flag claims to verify and test the package locally; don't publish or upload it."

Use it when: A deployment or support issue spans a ticket, customer logs, screenshots, and earlier internal discussions.

Start with: A ticket, the logs you're allowed to use, and the time window of the symptom.

1. Read the ticket and local evidence. Inspect authorized tools or browser pages when needed.
2. Compare logs and new findings with earlier incidents, documentation, and customer communication.
3. Preserve findings and draft an escalation or customer update, using an investigation skill if you have one.

You get: An investigation brief with evidence, hypotheses, checks performed, and the next owner.

Try it: "Investigate [ticket URL] using this folder's logs and screenshots plus relevant internal sources. Separate facts from hypotheses. Record checks and missing evidence. Draft an escalation and customer update; don't modify production or send either draft."

Tip: Save a local checkpoint of findings, open tests, and next steps, and resume from it when new logs arrive.

Support

Use it when: A complex ticket needs investigation or a clean engineering handoff.

Start with: One ticket URL, the logs you're allowed to use, and a local case folder.

1. Confirm the customer, time window, impact, and any existing escalation using the ticket and company context.
2. Inspect the logs with read-only tools. Separate observations, hypotheses, attempted checks, and remaining questions.
3. Save a source-linked investigation note. Keep internal technical details separate from a customer-safe response draft.

You get: An investigation packet, a list of next tests, and an unsent customer response with no internal details.

Try it: "Investigate [ticket URL] using [logs folder], company context, and read-only tools. Confirm the customer and time window. Save facts, hypotheses, attempted checks, and next tests in [case folder]; draft internal and customer-safe summaries separately. Flag access gaps. Don't send, publish, change production, or trigger jobs."

Tip: Save a table of attempted checks with timestamps and results, so engineering can review the work without a shared chat.

Use it when: A troubleshooting call contains errors or steps that are missing from the ticket.

Start with: One recording, its ticket URL, and a local evidence folder.

1. Identify the relevant time range and sensitive content. Use local tools to produce a timestamped transcript and a folder of frames.
2. Inspect error frames alongside the nearby transcript. Compare visible behavior with the ticket and current company guidance.
3. Save a redacted timeline that links timestamps, frames, observations, hypotheses, and next checks. Keep the customer response unsent.

You get: A reviewable evidence pack from the recording and draft follow-up questions. Visual clues stay separate from confirmed causes.

Try it: "Analyze [recording] for [ticket URL] during [time range] with local tools. Create a timestamped transcript, selected frames, and a redacted evidence index in [folder]. Distinguish visible facts from hypotheses and flag missing audio or access. Draft next questions; don't send, publish, change production, or install tools."

Product

Use it when: Customer requests need a defensible review, not another opaque ranking.

Start with: One feedback CSV, an account-context table, and a review cutoff date.

1. Check for stable IDs and preserve every raw row before grouping requests into themes.
2. Use Glean to link account context, planning documents, support evidence, and unresolved matches.
3. Draft an advisory initiative table. Record PM decisions, rationale, and overrides separately.

You get: A sourced feedback review with explainable themes, advisory scores, and a separate PM decision table. Every row is accounted for, and no AI suggestion is presented as a commitment.

Try it: "From [feedback.csv] and [account-context.csv], draft a review in [folder] as of [date]. Preserve IDs and raw rows; cite planning evidence and label unresolved matches. Show editable scoring assumptions; keep PM decisions separate. Don't decide the roadmap, send, publish, or change systems."

Use it when: A new product category needs a grounded position before you propose investment.

Start with: One strategic question, a local capability brief, and customer evidence.

1. Define research lanes for capabilities, competitors, and customer needs, each with a completion check.
2. Save sourced findings by lane. Distinguish current offerings, planned work, and unknowns.
3. Draft a comparison matrix and gap hypotheses for PM review, not an approved feature list.

You get: A draft market map and gap brief linked to capability and customer evidence.

Try it: "Research [question] using [brief], company and customer evidence, and public vendor sources. Propose bounded research lanes. Save cited findings in [folder], then draft a market map and gap hypotheses. Flag gaps. Don't commit roadmap items, send, publish, or change systems."

Tip: Approve each research lane, and keep a local checklist of which lanes finished or failed.

Use it when: A product discussion leaves decisions, owners, and open questions scattered across notes and a working brief.

Start with: One transcript, the current local brief, and previously reviewed notes.

1. Use a transcript, or Meeting Notes when it's turned on and everyone has consented to recording.
2. Compare the discussion with current PRD evidence and earlier reviewed notes. Flag contradictions.
3. Save a draft decision-and-action brief that separates confirmed commitments from proposals and unresolved owners.

You get: A reviewable follow-up brief with decisions, candidate actions, source references, and open questions. Proposals aren't promoted to decisions.

Try it: "From [transcript] and [local brief], draft product follow-up in [folder]. Check cited PRD evidence and [reviewed notes]. Separate decisions, proposals, action candidates, and questions. Support owners and dates with evidence; flag transcription uncertainty. Keep drafts for review. Don't send, publish, update tickets, or change systems."

Use it when: Planning depends on a clear feature inventory, but launch notes and inferred relationships keep changing.

Start with: One product area, a feature list, and dated launch sources.

1. Read local feature records and relevant company sources. Keep stable IDs, source links, and dates.
2. Map features to an agreed taxonomy. Distinguish current, beta, proposed, conflicting, and unknown states.
3. Save a draft inventory and change log, and ask the PM to review inferred dependencies and lifecycle updates.

You get: A dated feature inventory with provenance, unresolved mappings, and a reviewable change log.

Try it: "Use [feature list], [launch sources], and [taxonomy] to draft an inventory in [folder] as of [date]. Preserve IDs and cite lifecycle evidence. Flag inferred dependencies, conflicts, and unknowns. Compare without overwriting [reviewed baseline]. Don't decide the roadmap, schedule, send, publish, or change systems."

Security

Use it when: Log evidence needs a traceable timeline before a security owner decides whether to investigate further.

Start with: One redacted log bundle, a time window, and your runbooks.

1. Confirm the file scope, time window, and runbook versions. Preserve the source logs.
2. Build a source-linked timeline. Separate observations, hypotheses, contradictions, and missing evidence.
3. Save an investigation draft with open questions. Leave incident decisions to the security owner.

You get: A draft evidence timeline and review questions, not a confirmed diagnosis or incident declaration.

Try it: "Using only redacted [logs] for [time window] and [runbook links], draft a local evidence timeline with sources, hypotheses, and gaps. Preserve originals; require security review. No live queries, scans, exploitation, credentials, containment, system, access, or policy changes, incident declarations, certification, or communication."

Use it when: Assignment exports disagree and an access owner needs a traceable exception table.

Start with: Two pseudonymized exports, an application inventory, and matching rules.

1. Confirm applications, export dates, pseudonymous user IDs, and aliases before comparing.
2. Merge assignments. Preserve source rows and show duplicates separately, without changing the originals.
3. Add owner context. Draft unmatched rows and count checks for the access owner's review.

You get: An assignment table and exception draft, not an automatic access decision. Unmatched rows aren't labeled as unauthorized access.

Try it: "Reconcile pseudonymized [exports] for [scope and date] using [rules]. Preserve originals and source rows; separate duplicates and unmatched assignments. Draft counts, exceptions, and uncertainties for access-owner review. No live actions, scans, exploitation, credentials, access or policy changes, incident declarations, certification, or communication."

Use it when: One code or configuration diff needs a bounded security review before the owner decides what to change.

Start with: One local diff, the relevant files, and your security standards.

1. Confirm the diff, revision, and standards. Inspect changed files and necessary dependencies statically.
2. Trace authentication, authorization, and data-handling changes. Separate observed behavior from possible risks.
3. Save line-linked findings, assumptions, and reviewer questions. Leave code and configuration unchanged.

You get: A review draft, not a confirmed vulnerability, exploitability verdict, or approved fix.

Try it: "Review [diff] statically against [standards] in [scope]. Draft line-linked evidence, possible risks, and questions; keep code unchanged for security review. No code, test, build, scan, or exploit execution, network requests, credentials, containment, system, access, or policy changes, incident declarations, certification, PRs, or communication."

Tip: To map findings to an existing redacted scan report, give Glean Tau the report. Don't ask it to run scanners.

Use it when: Governance needs a dated record of the models configured for your agents before an evidence review or model change.

Start with: A list of agents to inventory, an inventory skill, and a browser where you're signed in.

1. Use the skill to inspect only the listed agents' model or settings panels.
2. Record exact labels, source links, dates, and owners. Mark unreadable panels as unknown.
3. Save a local CSV and a coverage note. Have the governance owner verify samples and exclusions.

You get: A dated configuration inventory, not proof of compliance or control effectiveness.

Try it: "Use [inventory skill] in my signed-in browser for [agents]. Draft a CSV with exact labels, sources, dates, unknowns, and owners for governance review. Stop at authentication prompts. No scans, exploitation, credentials, containment, settings, access, or policy changes, incident declarations, certification, or communication."

Also uses: Browser and Skills.

Operations

Use it when: Before a steering meeting, milestone, metric, staffing, and blocker updates are scattered across sources.

Start with: One program folder, source links, a review window, and the prior brief.

1. Read the local plan and prior brief. Retrieve company updates for the same review window.
2. Compare milestones, metrics, owners, blockers, and decisions. Flag conflicting periods and unsupported status changes.
3. Save a dated local brief with evidence links, decision requests, and open questions for your review.

You get: A draft program-review brief and evidence register, with decisions separated from recommendations.

Try it: "Use [program folder], [source links], and [date window] to draft a program-review brief. Compare milestones, metrics, owners, blockers, and decisions with [prior brief]. Link evidence; mark stale data and unknowns. Save a local draft for review. Don't send, publish, schedule, or change operational systems."

Use it when: After a cross-functional meeting, decisions and follow-ups need a clear handoff that owners review.

Start with: Meeting notes, the program folder, and the existing action list.

1. Read the notes and current action list. Separate decisions, commitments, suggestions, and unanswered questions.
2. Draft actions with source links, owners, and deadlines. Remove repeated items and label missing or inferred details.
3. Save the local handoff and unsent follow-ups. Let owners confirm priorities before anyone updates a task system.

You get: A draft decision log, a deduplicated action list, and unsent follow-ups. Every action traces to evidence.

Try it: "Use [meeting notes], [program folder], and [existing action list]. Draft a local handoff with decisions, actions, owners, due dates, and source links. Remove repeated items; mark inferred owners and missing deadlines. Keep follow-ups unsent. Don't send, publish, schedule, or update task systems."

Use it when: Before a renewal or vendor review, your inventory, contracts, and spend exports disagree.

Start with: One inventory, a contract register, a spend export, and matching rules.

1. Inspect source dates, currencies, cost periods, and row counts. Keep source files unchanged.
2. Normalize aliases and match vendors using your rules. Separate exclusions, unmatched records, and uncertain owners.
3. Save a local inventory and exception queue with source references. Validate counts and totals for comparable periods.

You get: A draft software inventory, reusable matching rules, and an exception queue. Unmatched records aren't labeled as unauthorized.

Try it: "Reconcile [folder] for [period] using [rules]. Preserve originals. Draft an inventory and exception queue with source rows, owner basis, aliases, exclusions, currencies, and periods. Validate counts and comparable totals; unmatched doesn't mean unauthorized. Don't send, publish, schedule, or change systems."

Use it when: A program has accumulated overlapping AI workflows and needs a consolidation proposal that owners review.

Start with: The workflow definitions you own, local exports, and their dependency IDs.

1. Read the local exports. Separate user-owned, shared, and built-in definitions without changing anything.
2. Group overlaps by purpose, owner, inputs, and outputs. Distinguish duplicates from required dependencies.
3. Save a review-only consolidation map with exact IDs, proposed replacements, unresolved checks, and rollback references.

You get: A draft overlap map and consolidation proposal. Nothing is proposed for retirement without a verified replacement.

Try it: "Audit [workflow exports] across [scope] in [local folder]. Draft an overlap map with exact IDs, owners, dependencies, source links, proposed replacements, and rollback references. Preserve originals and flag uncertain matches. Don't test, disable, delete, schedule, send, publish, or modify workflows."

People and culture

Use it when: A new cohort needs a first-week guide assembled from onboarding materials, not employee records.

Start with: One checklist, a role template, and a folder of onboarding materials.

1. Read the materials in a local project. Note the role, audience, and source dates without employee identifiers.
2. Draft Day 1 and Week 1 tasks and reading links. Cite sources and flag conflicts.
3. Save the pack and questions locally for People team review before distribution.

You get: A first-week checklist, reading links, and unresolved questions in a reviewable draft, with no invented deadlines, access approvals, or personal details.

Try it: "Using [onboarding folder], [role], and [source links], draft a local Day 1 and Week 1 pack with tasks, reading links, and questions. Use no employee records; flag conflicts and gaps. Require People team review. Don't send, publish, update HR systems, or make employment decisions."

Use it when: A role brief and interview plan need consistent documentation before recruiting review. No candidate evaluation is involved.

Start with: One role brief, an interview template, and an intake requirements document.

1. Read the role brief and intake requirements beside the template. Use no candidate records.
2. Draft role responsibilities, round objectives, placeholder interviewer roles, and approved questions.
3. Check completeness and flag gaps. Save the packet for People team and hiring-manager review.

You get: A draft role and interview packet, a map of responsibilities to rounds, and a checklist of missing inputs, with no candidate scores or recommendations.

Try it: "Using [role brief], [interview template], and [intake requirements], draft a local role and interview packet. Map responsibilities to rounds and approved questions; flag gaps. Use no candidate data, rankings, or recommendations. Require People team review. Don't send, publish, update HR systems, or make employment decisions."

Use it when: New policy versions need a change summary and FAQ draft, not individual eligibility advice.

Start with: One old and new policy pair, the document audience, and an FAQ template.

1. Read the old and new files and canonical links. Record version dates and the audience scope.
2. Draft text changes and source-linked FAQ edits. Preserve exceptions and flag conflicts or missing metadata.
3. Save drafts and open questions for People team review. Leave official policy files unchanged.

You get: A draft change log, a cited FAQ, and a list of unresolved sources. Conflicting policies aren't silently resolved.

Try it: "Compare [old and new policies] for [document audience]. Draft a local change log and cited FAQ; preserve exceptions and flag conflicts, missing dates, and unknowns. Don't judge individual eligibility. Require People team review. Don't send, publish, update HR systems, or make employment decisions."

Use it when: De-identified or synthetic feedback needs a theme brief, not individual profiles or workforce recommendations.

Start with: One de-identified or synthetic feedback file and a theme template.

1. Confirm the file is de-identified or synthetic. Stop if identifiers remain.
2. Group themes and questions. Keep anonymous row references and disagreement, without inferring traits, intent, or identities.
3. Save a theme table and a cautious narrative for People team privacy and accuracy review.

You get: A draft theme table and brief with anonymous references, conflicting views, and questions, with no identifying details or individual scores.

Try it: "Using [de-identified or synthetic feedback] and [theme template], draft local themes and questions with anonymous row references. Stop if identifiers remain. Don't identify, rank, or infer traits. Require People team review. Don't send, publish, update HR systems, or make employment decisions."

Finance

Use it when: Receipts need policy checks before an employee or Finance reviewer prepares a reimbursement request.

Start with: Your receipts, claim history, and access to the current expense policy.

1. Read local receipts and retrieve the current policy. Capture purchase dates, line items, and source references.
2. Compare proposed amounts with policy caps and exclusions. Flag missing fields, possible duplicates, and exception requests.
3. Create a draft claim table for review. Don't forward receipts, delete drafts, or submit anything.

You get: A receipt-linked draft claim table with proposed amounts, policy references, and unresolved questions.

Try it: "Review [receipts folder] for [period] against current company policy. Draft dates, sources, amounts, caps, exclusions, duplicates, and open questions. If you can, inspect existing drafts in [expense tool] read-only. Preserve originals for Finance review. Don't forward, submit, delete drafts, send, publish, or change systems."

Tip: Calculate submission timing from purchase dates, not the dates receipts were forwarded, and list late items separately for Finance review.

Use it when: An asset ledger and inventory export disagree, and Finance needs a traceable exception queue rather than automatic adjustments.

Start with: One asset-ledger export, an inventory file, and matching rules that Finance has approved.

1. Confirm the entity, period, currency, record grain, and source totals. Stop on duplicate keys or unclear rules.
2. Use local calculation tools to match keys and compare fields. Keep both source values and unresolved records.
3. Write a new workbook with matches, typed exceptions, source rows, control totals, and reviewer dispositions. Preserve originals.

You get: A draft reconciliation workbook and exception queue for Finance review, not accounting sign-off.

Try it: "Reconcile asset files in [folder] for [entity, period, and currency] using [rules]. Check keys and control totals first; stop on ambiguity. Preserve originals. Draft a workbook with source rows, matches, exceptions, and unresolved items for Finance review. Don't send, publish, post adjustments, or update systems."

Use it when: Finance needs to distinguish supported churn drivers from assumptions before discussing retention performance.

Start with: A few opportunity IDs, a dated cohort export, and classification definitions.

1. Read the local cohort and retrieve account history, customer communications, usage evidence, and renewal events.
2. Build source-linked timelines and proposed reason categories. Separate documented facts, interpretations, and missing evidence.
3. Review known cases with Finance, record corrections, and keep raw metrics beside any proposed classification changes.

You get: A draft churn-driver table, account timelines, and a queue of unresolved classifications. Metrics aren't reclassified automatically.

Try it: "For [opportunity IDs] in [period], combine [local exports] with company evidence. Draft source-linked timelines and proposed reasons; separate facts, inference, and unknowns. Preserve raw metrics and originals. Require Finance review before reclassification. Don't send, publish, change permissions, or update systems."

Tip: Pilot on three known cases and log corrections before you expand to a larger batch.

Use it when: A renewal forecast review needs fresh evidence, explicit assumptions, and a clear record of analyst judgment.

Start with: One renewal cohort, the prior forecast snapshot, and scenario assumptions that Finance has approved.

1. Save a dated local copy of the cohort and prior forecast. Confirm source definitions and scenario assumptions.
2. Retrieve usage, customer communications, and product context. Flag conflicting or stale signals rather than assuming they predict renewal.
3. Calculate scenarios only from the approved assumptions. Keep analyst decisions and unknowns separately in a new review table.

You get: A draft forecast-review table with dated evidence, scenario assumptions, analyst decisions, and open questions.

Try it: "Use [renewal cohort and date], [exports], and [approved assumptions] to draft a forecast-review table. Include dated signals, scenario calculations, source links, and unknowns. Preserve originals and prior forecasts. Require Finance review; don't invent probabilities, send, publish, change permissions, or update systems."

Legal

Use it when: Agreements, amendments, and statements of work are scattered, and Legal Operations needs a trustworthy starting index.

Start with: One local contract folder and rules from counsel for grouping agreement families.

1. Inventory files read-only. Flag scans, duplicates, and missing text before classification.
2. Group possible agreement families using parties, dates, signatures, and cross-references. Preserve original paths and uncertainty.
3. Produce a draft index and relationship map. Sample-check source counts and amendment chains with the repository owner.

You get: A draft family index, a provenance ledger, and a reversible organization plan. Original files stay untouched.

Try it: "Index [contract folder] using [family rules]. Keep originals read-only. Record candidate links, source paths, OCR flags, and uncertainty. Preserve privilege and confidentiality; verify counts and sample chains for counsel. Don't move originals, make legal determinations, sign, send, publish, or change source systems."

Use it when: A matter's emails, notes, and documents need a first-pass chronology before counsel reviews facts or briefs a colleague.

Start with: One matter folder that counsel has approved, a date range, and review questions.

1. Confirm authorized sources, privilege boundaries, and the official matter repository before reading the record.
2. Link events, people, and disputed accounts to exact documents. Keep dates, deadlines, and missing evidence separate.
3. Draft a chronology and issue queue. Have counsel verify material facts and deadlines against the original records.

You get: A source-linked chronology, issue queue, and review outline, not a docket or legal conclusion.

Try it: "From [counsel-approved sources], [dates], and [privilege protocol], draft a source-linked chronology and issue queue. Separate allegations, facts, conflicts, gaps, and unverified deadlines. Preserve confidentiality; require counsel verification. Don't make legal determinations, update dockets or source systems, sign, send, or publish."

Use it when: A competitor publishes comparative product claims, and counsel needs a fact-supported draft before deciding whether to respond.

Start with: One local template, the exact public URLs, and product evidence.

1. Record the exact claim wording, URL, and date. Marketing language isn't proof.
2. Compare with your product sources. Separate supported facts, inference, limits, and unresolved questions.
3. Create an editable draft and factual appendix. Require Legal and Product verification before use.

You get: A draft for counsel review with a claim-by-claim factual appendix and unresolved items.

Try it: "Use [template], [exact claim URLs], and [product sources] to draft a qualified response and factual appendix. Cite material comparisons; separate facts, inference, and gaps. Preserve privilege and confidentiality. Require Legal and Product review. Don't make legal determinations, sign, send, publish, or change systems."

Use it when: IP counsel needs to compare claim files with technical and product evidence, while preserving gaps rather than asserting complete coverage.

Start with: One patent family, the claim files, and a defined technical target.

1. Extract independent claims and limitations. Check the parsing against the issued text.
2. Map technical sources to each limitation. Grade evidence as direct, partial, not shown, or context only, with dated citations.
3. Create a draft chart and verification queue for IP counsel review.

You get: A limitation-level evidence chart, a source inventory, and a verification queue for counsel, not an infringement, validity, or inventorship opinion.

Try it: "Map [claim files] and [sources] for [target] into limitation-level charts with dated citations, grades, and gaps. Preserve privilege and confidentiality. Require IP counsel review; don't mark a claim complete without direct proof of every element. Don't make legal determinations, sign, send, publish, or change systems."