# ============================================================================
#  Deborah's Copilot Prompt Library — canonical source of truth
# ============================================================================
#  This file is the ONLY place you edit prompts. Everything else is generated:
#     python3 build.py
#  ...produces the Espanso match file, the HTML library, and the admin CSV.
#
#  Plain text. Yours. Portable. No vendor owns it.
#
#  FIELDS
#    id        short slug, used for filenames/anchors
#    trigger   what you type to fire it (prefix is set in settings below)
#    title     <= 35 chars  (M365 admin centre limit)
#    display   <= 132 chars (short pill text)
#    task_type Analyze | Create | Edit  (verify against your tenant's list)
#    dept      free text, used for filtering
#    tags      list, used for search in the HTML library
#    prompt    the actual thing sent to Copilot. <= 8000 chars.
#              Use $|$ to mark where the cursor should land after expansion.
# ============================================================================

settings:
  trigger_prefix: ";;"
  owner: "Deborah"
  locale: "en-AU"
  default_dept: "Information Management"

  # The category list offered in the Add-prompt form. A category can sit here
  # with nothing in it yet — it still gets a filter chip, just an empty one
  # until its first prompt arrives. The build warns if a prompt uses a
  # category that isn't on this list, which catches typos before they
  # fragment the library.
  categories:
    - "Records Management"
    - "Governance"
    - "Information Security"
    - "Information Management"
    - "Continuous Improvement"
    - "AI Capability"
    - "Communications"
    - "Training"
    - "Apps"
    - "Agents"

  # --- optional: self-updating skill --------------------------------------
  # Off. OneDrive already carries your skills between machines, so this is only
  # worth turning on if the library lives in a public git repo and you want
  # Cowork to pull changes itself.
  #
  # To switch it on: set sync_skill to true, fill in both URLs, run build.py,
  # and copy the new skills/prompt-library-sync/ folder into OneDrive. Then
  # "update my prompt library" works in Cowork.
  sync_skill: false
  repo_raw_base: ""   # e.g. https://raw.githubusercontent.com/you/copilot-prompt-library/main
  repo_web: ""        # e.g. https://github.com/you/copilot-prompt-library

# --------------------------------------------------------------------------
#  Copilot Cowork / Claude skill packaging
#  Prompts are grouped by `dept` into SKILL.md files. The description is what
#  makes Cowork load the skill at the right moment, so write it as trigger
#  language, not marketing copy.
# --------------------------------------------------------------------------
skill_groups:
  "Records Management":
    name: "Records Disposal and Archives"
    description: >-
      Deborah's standard method for Tasmanian local government records work.
      Use when asked how long to keep a record, whether something can be
      destroyed, which disposal class applies under DA2200, DA2158 or DA2159,
      whether a record is permanent or temporary, or what metadata a permanent
      record needs before transfer to the Tasmanian Archives under the OSA
      Metadata Standard.
  "Governance":
    name: "Clause Analysis and Briefs"
    description: >-
      Deborah's standard method for reading clauses and writing for decision
      makers. Use when asked to interpret a clause from an Act, regulation,
      award, enterprise agreement, policy, procedure or contract ("what does
      this mean", "do I have to", "am I allowed to"), to write an executive or
      council brief, to pull decisions and actions out of meeting notes, or to
      risk-screen a change before it is made.
  "Information Security":
    name: "Sensitivity Label Decisions"
    description: >-
      Deborah's standard method for Microsoft Purview classification. Use when
      asked which sensitivity label to apply, whether to label at item or
      container level, what encryption will break, whether auto-labelling
      suits a case, or how labelling affects Copilot grounding and sharing.
  "Information Management":
    name: "SharePoint and M365 Review"
    description: >-
      Deborah's standard method for reviewing the Microsoft 365 estate. Use
      when asked to assess a SharePoint site for governance, oversharing or
      Copilot readiness, to draft a procedure or SOP from rough notes, or to
      run a structured search for information across emails, Teams, meetings
      and SharePoint.
  "Continuous Improvement":
    name: "5S LEAN Assessment"
    description: >-
      Deborah's standard method for improvement work. Use when asked to
      assess a system, workflow, library or process for waste and improvement
      opportunities, to clean up a messy environment, or when 5S, LEAN,
      kaizen, continuous improvement or waste reduction are mentioned.
  "AI Capability":
    name: "AI Judgment and Agent Design"
    description: >-
      Deborah's standard method for AI practice. Use when asked to critically
      evaluate or stress-test an AI answer before relying on it, to draft
      instructions and starter prompts for a declarative Copilot agent, or to
      turn a technical concept into practical training for council staff.
  "Training":
    name: "Staff Training Materials"
    description: >-
      Deborah's standard method for building training. Use when asked to turn a
      concept, system or policy into training material for council staff, to
      write a how-to or step guide, to design a learning path or onboarding
      session, or to work out why staff aren't adopting something.
  "Apps":
    name: "Power Platform and Apps"
    description: >-
      Deborah's standard method for app and workflow work. Use when asked to
      design, review, document or troubleshoot a Power App, a Power Automate
      flow, a form, or a list-backed business process.
  "Agents":
    name: "Agent Building"
    description: >-
      Deborah's standard method for building agents. Use when asked to design,
      write instructions for, test, govern or troubleshoot a declarative agent —
      Agent Builder, Copilot Studio, or a SharePoint site agent — including
      choosing knowledge sources and starter prompts.
  "Communications":
    name: "Plain English and Replies"
    description: >-
      Deborah's standard method for writing. Use when asked to rewrite
      something in plain English without losing legal or procedural meaning,
      to draft a measured reply to a difficult message, or to simplify and
      quieten a piece of writing using wabi-sabi principles.

prompts:

  - id: dispose
    trigger: dispose
    title: "Records disposal decision"
    display: "Work out retention and disposal for a record under Tasmanian schedules"
    task_type: Analyze
    dept: "Records Management"
    tags: [records, disposal, DA2200, retention, tasmania]
    prompt: |
      Act as a Tasmanian local government records analyst.

      RECORD / RECORD SET:
      $|$

      Work through this in order and show your reasoning:
      1. What is this record actually evidence of? (the business function, not the file name)
      2. Which disposal schedule applies — DA2200 (Local Government), DA2158 (Short Term
         Value), or DA2159 (Source Records)? Say why the others do not.
      3. Nominate the disposal class and quote its wording.
      4. State the retention period and the trigger event that starts the clock.
      5. Permanent or temporary? If permanent, flag that OSA metadata requirements apply.
      6. List what would have to be true for this decision to be WRONG.

      If you cannot identify the class with confidence, say so plainly and tell me what
      extra information you need. Do not guess a class number.

  - id: perm
    trigger: perm
    title: "Permanent record metadata check"
    display: "Check metadata on a permanent record against the OSA standard before transfer"
    task_type: Analyze
    dept: "Records Management"
    tags: [metadata, OSA, permanent, archives, transfer]
    prompt: |
      Act as an archivist preparing records for transfer to the Tasmanian Archives.

      RECORD / METADATA I CURRENTLY HAVE:
      $|$

      Assess against the Office of the State Archivist metadata standard:
      1. Which mandatory metadata elements are present, complete and usable?
      2. Which are missing, empty, or populated with junk (e.g. "Document", system defaults)?
      3. For each gap: where in SharePoint / M365 could that value realistically come from,
         and can it be derived automatically or does a human have to supply it?
      4. Which gaps are blockers for transfer versus which are quality issues?
      5. Give me a remediation list ordered by effort-to-value.

      Be specific about element names. Do not pad with general advice about good metadata.

  - id: rope
    trigger: rope
    title: "ROPE clause analysis"
    display: "Break a clause into Right, Obligation, Process and Exclusion"
    task_type: Analyze
    dept: "Governance"
    tags: [ROPE, clause, policy, agreement, legislation]
    prompt: |
      Analyse the clause below using the ROPE framework. Plain language, no legalese.

      CLAUSE:
      $|$

      RIGHT — what does this let someone do? Who holds it? Is it discretionary?
      OBLIGATION — what MUST happen? Who is bound? What triggers it?
      PROCESS — what steps, forms, timeframes or approvals does it require?
      EXCLUSION — who or what falls outside it? What are the carve-outs and limits?

      Then answer directly:
      - In one sentence, what does this clause actually mean for me?
      - What is the single most commonly misread part of it?
      - What would I need to check elsewhere before relying on this reading?

      Distinguish clearly between "you may" and "you must". Quote the words that carry
      the obligation.

  - id: label
    trigger: label
    title: "Sensitivity label decision"
    display: "Decide the right Purview sensitivity label and where it should be applied"
    task_type: Analyze
    dept: "Information Security"
    tags: [purview, sensitivity, label, classification, DLP]
    prompt: |
      Help me decide the correct Microsoft Purview sensitivity label.

      CONTENT / CONTAINER:
      $|$

      Cover:
      1. What is the actual sensitivity here — personal information, commercially
         confidential, legally privileged, publicly releasable, or routine?
      2. Recommended label, and the next label up and down with why they are wrong.
      3. Scope: item-level, container-level (site/Team/group), or both?
      4. If encryption is involved — who loses access, and what breaks? (co-authoring,
         search, eDiscovery, external sharing, Copilot grounding)
      5. Auto-labelling: is this a good candidate? Client-side or service-side?
      6. What I should run in simulation mode before turning anything on.

      Flag anything that is irreversible or affects many users.

  - id: spgov
    trigger: spgov
    title: "SharePoint site health review"
    display: "Review a SharePoint site for governance, oversharing and Copilot readiness"
    task_type: Analyze
    dept: "Information Management"
    tags: [sharepoint, governance, oversharing, copilot, permissions]
    prompt: |
      Review this SharePoint site as an information manager, not as an IT admin.

      SITE / DETAILS:
      $|$

      1. Purpose — can you tell what this site is FOR from its structure? If not, say so.
      2. Permissions and oversharing risk: broad links, "Everyone except external users",
         orphaned access, inherited sprawl.
      3. Copilot exposure: what would Copilot surface from here that shouldn't be surfaced?
         Is Restricted Content Discovery warranted?
      4. Metadata and structure: is content findable without knowing where it lives?
      5. Records: is anything here a record that isn't being managed as one?
      6. Give me the three changes with the highest benefit-to-disruption ratio.

  - id: fives
    trigger: 5s
    title: "5S LEAN assessment"
    display: "Run a Sort / Set in Order / Shine / Standardise / Sustain pass over a system"
    task_type: Analyze
    dept: "Continuous Improvement"
    tags: [5S, lean, kaizen, waste, improvement]
    prompt: |
      Run a 5S LEAN assessment on what I describe. Be concrete, not motivational.

      SUBJECT:
      $|$

      SORT — what is genuinely not needed and can go? Name it.
      SET IN ORDER — what is in the wrong place or hard to find? Where should it live?
      SHINE — what is broken, stale, duplicated or misleading right now?
      STANDARDISE — what should be a documented, repeatable default?
      SUSTAIN — what check, cadence or owner keeps this from decaying again?

      Finish with:
      - The single biggest source of waste here, named plainly.
      - One thing I could do this week that makes a visible difference.
      - What will quietly undo this work in six months if nobody watches it.

  - id: proc
    trigger: proc
    title: "Draft a procedure or SOP"
    display: "Turn messy knowledge into a clear step-by-step procedure staff will follow"
    task_type: Create
    dept: "Information Management"
    tags: [procedure, SOP, how-to, documentation]
    prompt: |
      Turn the following into a procedure that a competent person could follow without
      asking me anything.

      RAW KNOWLEDGE / NOTES:
      $|$

      Structure:
      - Purpose: one sentence, what this achieves.
      - When to use it / when NOT to use it.
      - Prerequisites: access, permissions, tools, information needed before starting.
      - Steps: numbered, imperative, one action per step, with what "done" looks like.
      - Decision points: where the reader has to choose, and how to choose.
      - What to do when it goes wrong.
      - Who owns this and when it gets reviewed.

      Australian English. Short sentences. No jargon unless you define it on first use.
      If a step depends on something I haven't told you, mark it [NEEDS INPUT] rather
      than inventing it.

  - id: critique
    trigger: critique
    title: "Stress-test an AI answer"
    display: "Critically evaluate AI output before you rely on it"
    task_type: Analyze
    dept: "AI Capability"
    tags: [critique, verification, quality, 201, judgment]
    prompt: |
      I'm about to rely on the output below. Stress-test it before I do.

      OUTPUT:
      $|$

      1. Which claims are verifiable, and how would I verify each one?
      2. Which claims are plausible-sounding but unsupported? Name them specifically.
      3. What has been silently assumed about my context that may not hold?
      4. What's missing that a knowledgeable person would expect to see?
      5. Where is this confidently wrong versus honestly uncertain?
      6. If I acted on this and it went badly, what would the failure look like?

      Be adversarial. Do not soften. If it's actually sound, say that briefly and stop.

  - id: agent
    trigger: agent
    title: "Draft agent instructions"
    display: "Write instructions and starter prompts for a declarative Copilot agent"
    task_type: Create
    dept: "AI Capability"
    tags: [agent, agent builder, copilot studio, declarative, instructions]
    prompt: |
      Help me build a declarative Copilot agent.

      WHAT IT NEEDS TO DO:
      $|$

      Produce:
      1. Name and one-line description (what a user would see).
      2. Instructions — written as directives to the agent, covering: role, scope,
         what it must always do, what it must never do, tone, and how to handle
         questions outside its scope.
      3. Knowledge sources: which SharePoint sites, libraries or files it should be
         grounded in, and what it must NOT be grounded in.
      4. Four starter prompts a first-time user would actually click.
      5. Governance notes: who should have access, what could go wrong, what to review
         after two weeks of use.

      Keep instructions under 8000 characters. Write them so a non-technical colleague
      could read them and predict the agent's behaviour.

  - id: train
    trigger: train
    title: "Turn this into staff training"
    display: "Convert a concept into a short, practical how-to for council staff"
    task_type: Create
    dept: "AI Capability"
    tags: [training, how-to, adoption, staff, card]
    prompt: |
      Turn this into training material for council staff who are competent at their job
      but not technical.

      TOPIC:
      $|$

      Produce:
      - The one thing they must walk away understanding (one sentence).
      - Why it matters to THEM — framed around their work, not compliance.
      - A worked example using a realistic local government scenario.
      - Steps: maximum six, each doable in under a minute.
      - The two mistakes people actually make here.
      - One "you'll know it's working when..." check.

      No motivational filler. No "in today's fast-paced world". Assume they are busy,
      slightly sceptical, and have been burned by a system rollout before.

  - id: brief
    trigger: brief
    title: "Executive brief"
    display: "Compress a document or situation into a decision-ready brief"
    task_type: Create
    dept: "Governance"
    tags: [brief, summary, executive, report, decision]
    prompt: |
      Write a decision-ready brief from the material below.

      MATERIAL:
      $|$

      Format:
      - RECOMMENDATION: what should happen, in one sentence.
      - WHY: three points maximum, strongest first.
      - WHAT IT COSTS: time, money, disruption, risk.
      - WHAT WE LOSE IF WE DON'T.
      - WHAT I'M NOT CERTAIN ABOUT: be honest here.
      - DECISION NEEDED FROM: who, by when.

      Maximum one page. Australian English. No headings beyond those listed. If the
      material doesn't support a recommendation, say that instead of manufacturing one.

  - id: mins
    trigger: mins
    title: "Meeting notes to actions"
    display: "Pull decisions, actions and owners out of messy meeting notes"
    task_type: Edit
    dept: "Governance"
    tags: [meeting, minutes, actions, decisions]
    prompt: |
      Extract the useful content from these meeting notes.

      NOTES:
      $|$

      Return exactly three sections:

      DECISIONS MADE — what was actually decided (not discussed). If nothing was
      decided, say "No decisions recorded."

      ACTIONS — table: Action | Owner | Due | Depends on. Only include items with a
      real owner. Flag any action where the owner was never named.

      UNRESOLVED — questions raised and left hanging, and who needs to answer them.

      Do not summarise the discussion. Do not editorialise. If something is ambiguous
      in the notes, mark it [UNCLEAR] rather than resolving it yourself.

  - id: plain
    trigger: plain
    title: "Rewrite in plain English"
    display: "Strip bureaucratic language without losing accuracy or obligation"
    task_type: Edit
    dept: "Communications"
    tags: [plain english, rewrite, clarity, public]
    prompt: |
      Rewrite this in plain English for a general audience.

      TEXT:
      $|$

      Rules:
      - Keep every obligation, condition and deadline exactly as binding as it was.
      - Active voice. Say who does what.
      - Replace jargon with the plain word, or define it once in brackets.
      - Shorter sentences. One idea each.
      - Australian English and Australian conventions (dates, spelling).
      - Do not add reassurance, apology or warmth that wasn't in the original.

      Then list separately: any place where plain language changed the legal or
      procedural meaning, so I can check it.

  - id: reply
    trigger: reply
    title: "Draft a measured reply"
    display: "Draft a calm, clear response to a difficult message"
    task_type: Create
    dept: "Communications"
    tags: [email, reply, difficult, response]
    prompt: |
      Draft a reply to the message below.

      MESSAGE:
      $|$

      WHAT I WANT TO ACHIEVE:
      [state your outcome here]

      Draft it:
      - Calm, direct, not defensive, not over-apologetic.
      - Acknowledge the substance of their point before responding to it.
      - Say clearly what I will do, what I won't, and what I need from them.
      - No hedging stacks ("I just wanted to possibly suggest maybe").
      - Australian English.

      Then tell me, in one line, what this reply is likely to trigger in response.

  - id: findit
    trigger: findit
    title: "Find it across M365"
    display: "Structured search prompt for locating information across the tenant"
    task_type: Analyze
    dept: "Information Management"
    tags: [search, find, m365, sharepoint, email]
    prompt: |
      Help me find something across our Microsoft 365 environment.

      WHAT I'M LOOKING FOR:
      $|$

      TIMEFRAME:
      PEOPLE / TEAMS LIKELY INVOLVED:

      Search across emails, Teams chats, meetings and SharePoint. Then return:
      1. What you found, with a link and a date for each item.
      2. The chronology — what happened in what order.
      3. What the current state appears to be.
      4. What you looked for and did NOT find (this matters as much as what you did).

      Cite every claim to a specific item. If you're inferring rather than reading,
      say so.

  - id: risk
    trigger: risk
    title: "Pre-action risk screen"
    display: "Check a change for privacy, records and blast-radius risk before doing it"
    task_type: Analyze
    dept: "Governance"
    tags: [risk, privacy, safety, change, blast radius]
    prompt: |
      I'm about to do the following. Screen it before I proceed.

      PROPOSED ACTION:
      $|$

      1. BLAST RADIUS — how many files, users, sites or systems does this touch?
      2. REVERSIBILITY — can this be undone? By whom, how, and within what window?
      3. RECORDS IMPACT — does this destroy, alter or obscure anything that is a record?
      4. PRIVACY — does this expose, move or aggregate personal information?
      5. WHO FINDS OUT AND HOW — will affected people notice, and were they told?
      6. THE QUIET FAILURE — what goes wrong in a way nobody notices for six months?

      End with: PROCEED / PROCEED WITH CONDITIONS / STOP — and the conditions.

  - id: wabi
    trigger: wabi
    title: "Wabi-sabi simplify"
    display: "Strip something back to what actually matters — kanso, ma, shizen"
    task_type: Edit
    dept: "Communications"
    tags: [wabi-sabi, simplify, kanso, ma, design]
    prompt: |
      Apply wabi-sabi principles to what follows.

      SUBJECT:
      $|$

      KANSO (simplicity) — what can be removed without loss? Remove it.
      MA (negative space) — where does this need room to breathe? What is over-filled?
      SHIZEN (naturalness) — where does this sound forced, corporate or performed?
      SEIJAKU (stillness) — what is the calm version of this?

      Give me the reworked version first, then a short note on what you took out and why.
      Do not make it precious or mystical. Make it quieter and more useful.
