Update to DPDP Planner and Organizer

{
  "description": "Use this when a company in India wants a dated DPDP action plan: what to do in week one, week two, week three and week four, who owns each action, and what proves it is done. Also use for DPDP roadmap, 30 day privacy plan, data protection remediation plan, and where to start on India's data protection law. Do not use for a law outside India.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 460
    }
  ],
  "name": "dpdp-30-day-plan",
  "skill_md_contents": "---\nname: dpdp-30-day-plan\ndescription: Use this when a company in India wants a dated DPDP action plan: what to do in week one, week two, week three and week four, who owns each action, and what proves it is done. Also use for DPDP roadmap, 30 day privacy plan, data protection remediation plan, and where to start on India's data protection law. Do not use for a law outside India.\n---\n\n# DPDP 30-Day Plan\n\nThis step turns the gap register into four weeks of work with an owner and a proof for every action.\n\n## Tools\n\n- `start_dpdp_plan` and `confirm_company_profile`: run the interview and return the profile.\n- `build_data_map`: builds the map.\n- `assess_dpdp_gaps`: returns the gap register the plan is built from.\n- `build_30_day_plan`: returns the four weeks.\n\n## The seed: what every call carries\n\nThe server keeps no state. It derives the profile, the map, the note, the gaps and the plan from a small seed every time.\n\n- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`\n- `company_name`, `business_description`, `role`\n- `answers`: every answer so far, keyed by question id, each `{ value, basis }`\n- `map_changes`: every map edit so far\n- `model_added_gaps`: optional, any gap added at the gap step\n\nRules:\n\n- `basis` is `stated` for a fact the user gave and `assumed` for anything you worked out. Use the value `dont_know` for an unknown.\n- Carry all answers, all map changes and all added gaps forward on every call. The full seed runs about 2 KB.\n- Never send a `plan` field. The server rejects it.\n- Keep the whole argument under 8,000 bytes.\n\n## Getting here from an empty seed\n\nThe server derives the plan from the seed, so the interview and the map run first.\n\n1. Call `start_dpdp_plan` with the industry, a short business description, the user's role and `answers: {}`.\n2. The intake screen appears with every question and a \"Send my answers\" button. Say the user can answer on the screen or in the chat. Screen path: call `confirm_company_profile` once with all their answers. Chat path: ask the `interview.next_questions` batch, call `confirm_company_profile` with every answer so far, and repeat until `interview.remaining` is zero.\n3. Show the profile and have the user confirm it.\n4. Call `build_data_map` with `map_changes: {}` to get the node keys, show the map, ask what is right, what they lack, their own tool names, the owners, what sits outside India and which outside companies have signed data terms. Call it again with those corrections in `map_changes`.\n\nKeep that catch-up short, then come back here.\n\n## Step 1: Build the plan\n\n- Call `build_30_day_plan` with the seed, `map_changes` and any `model_added_gaps`.\n- The weeks follow a fixed order. Week 1 names owners and lists what exists. Week 2 takes the questions to a lawyer and decides. Week 3 fixes notices, contracts and access. Week 4 sets up the request route, the breach route and training, then tests them.\n- A gap you added at the gap step enters week one.\n\n## Step 2: Show the plan\n\nFor each of the four weeks show the `theme`, then the actions. Each action carries:\n\n- `action`, the thing to do\n- `owner_role`, the job that owns it\n- `proof_of_closure`, what proves it is done\n- `gap_id`, the gap it closes\n\nSay the counts from the result: weeks and actions.\n\n## Step 3: Make it usable\n\n- Ask the user to put a job title against each `owner_role`. Use job titles. Do not record people's names.\n- Say which actions wait on the lawyer, so the user books that meeting in week 1.\n- Offer the buying guide for the gaps that need a tool.\n\n## Reading a result\n\nEach result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the four weeks. The screen shows the detail.\n\n- Say the counts and read out week 1.\n- Do not recite every action in the chat. Point the user at the screen.\n- Never name an action or a gap id the result did not return.\n\n## What you must never say\n\n- Never say finishing the plan makes the company compliant.\n- Never predict a penalty, a fine or an outcome.\n- Never promise a date the law does not set.\n- Show the `disclaimer` from the result with the plan.\n\n## Legal statements\n\n- Cite the section or rule the result gives on every legal point.\n- Leave out any point with no citation in the result.\n- Do not import GDPR words into DPDP.\n- An action built on an assumed gap carries that mark.\n\n## Support requests\n\n- Do not add a contact line to your replies.\n- When the user is stuck, help with the step itself.\n- If the user asks how to reach MBS about the planner, give the contact page once: https://www.meridianbridgestrategy.com/contact\n- Never give a person's name, an email address or a booking link.\n\n## What to leave out\n\n- Send only the seed fields the schema asks for. No chat history, no files, no unrelated context.\n- Never ask for names, contact details or records of real people. The server rejects them with `PERSONAL_RECORDS`. If the user pastes such records, say you will not take them, and ask for the kinds of data held.\n\n## Host reply\n\n- Describe the result in plain text on Codex. Screens and the Save the pack button belong to ChatGPT; mention them when that host provides them.\n- Explain the planner boundary in your own words. Keep internal skill paths and instruction quotes out of the reply.\n\n## User confirmation\n\n- Ask a question batch, then wait for the user. Repeat confirm only after answers change. Mark other answers dont_know when the user asks to leave them unknown.\n- Carry profile_confirmed true only after the user confirms the profile, and map_confirmed true only after the user confirms the map. Clear the relevant confirmation when its inputs change.\n"
}