Update to DPDP Planner and Organizer

{
  "description": "Use this when a company in India wants a plan for the Digital Personal Data Protection Act and has no idea where to start. It runs the whole journey: a short interview, a personal data map, the questions a lawyer must answer, a gap register, a 30-day plan, a buying guide, and one pack the user saves. Also use for India data protection, data fiduciary duties, consent and notice records, privacy compliance planning, and DPDP readiness. Do not use for a data protection law outside India.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 475
    }
  ],
  "name": "dpdp-planner",
  "skill_md_contents": "---\nname: dpdp-planner\ndescription: Use this when a company in India wants a plan for the Digital Personal Data Protection Act and has no idea where to start. It runs the whole journey: a short interview, a personal data map, the questions a lawyer must answer, a gap register, a 30-day plan, a buying guide, and one pack the user saves. Also use for India data protection, data fiduciary duties, consent and notice records, privacy compliance planning, and DPDP readiness. Do not use for a data protection law outside India.\n---\n\n# DPDP Planner\n\nThe user arrives with no plan. They leave with their company's analysis and a list of what to do. Run the steps in order and finish each one before moving on.\n\n## The eight tools\n\nCall them by these exact names.\n\n1. `start_dpdp_plan` returns the first question batch.\n2. `confirm_company_profile` takes the answers so far and returns the next batch, then the profile.\n3. `build_data_map` builds the map from the industry template plus the user's corrections.\n4. `draft_obligations_note` returns the questions for a lawyer and the sample opinion outline.\n5. `assess_dpdp_gaps` returns the gap register in three groups.\n6. `build_30_day_plan` returns four weeks of actions.\n7. `get_dpdp_buying_guide` returns product categories and dated seller facts.\n8. `export_dpdp_plan_pack` returns the pack screen and the file name.\n\n## The seed: what every call carries\n\nThe server keeps no state. It rebuilds the whole plan from a small seed on every call.\n\n- `industry`: one of `healthcare`, `d2c`, `financial-services`, `saas`, `general`\n- `company_name`: at most 160 characters\n- `business_description`: at most 600 characters, a short business category\n- `role`: at most 80 characters, a job label\n- `answers`: every answer so far, keyed by question id\n\nEach answer is `{ value, basis }`.\n\n- `basis` is `stated` for a fact the user gave. It is `assumed` for anything you worked out.\n- Use the value `dont_know` for an unknown, with `basis: \"stated\"`, because the user said they do not know.\n- Each answer string stays under 300 characters. Up to 80 answers.\n\nRules:\n\n- Send the same `industry`, `company_name`, `business_description` and `role` on every call.\n- Carry all earlier answers forward every time. A dropped answer is a lost fact.\n- Never send a `plan` field. The server rejects it.\n- Keep the whole argument under 8,000 bytes. Shorten free text before you drop an answer.\n\n## Reading a result\n\nEach result holds `schema_version: 2`, `step`, `company_name`, `counts`, `disclaimer` and the part this step made. The step names are intake, profile, map, note, gaps, plan, buying, pack.\n\n- The screen shows the detail. Say the counts and the few lines that matter.\n- Do not try to recite every row. Point the user at the screen.\n- Never name a row, a seller or a citation the result did not return.\n- Earlier parts are gone from your view. The seed is what carries them.\n\n## Step 0: Qualify\n\nAsk two questions before any tool call.\n\n1. Is this about your own rights as a person, or about a company?\n2. Do you want a quick answer, or the full plan?\n\nThen:\n\n- Own rights: give a short answer, cite the section or rule, and stop. No tool call.\n- Company plus quick answer: give a short cited answer. Offer the full plan in one line. Wait.\n- Company plus full plan: continue to step 1.\n\n## Step 1: The interview\n\n- Ask the industry, a short business description and the user's role.\n- Call `start_dpdp_plan` with the seed and `answers: {}`.\n- The intake screen appears with every question, grouped in sections, and a \"Send my answers\" button. Say one line right after it appears: the user can answer on the screen or in the chat.\n\nThe screen path:\n\n- The user fills the screen and their answers arrive as one chat message.\n- Call `confirm_company_profile` once with the seed and all of them.\n\nThe chat path:\n\n- Read `interview.next_questions`, up to three at a time. Ask them with their `why` line and their options.\n- Record each answer into `answers`, then call `confirm_company_profile` with the seed and every answer so far.\n- Read `interview.remaining` and repeat until it reaches zero.\n\nBoth paths:\n\n- Accept \"don't know\". That answer leaves the queue and stays in the profile's open list.\n- Never call `confirm_company_profile` with no new answer. Ask first, then call.\n- The full seed with every answer runs about 2 KB, so carrying all answers on every call is cheap.\n\n## Step 2: Confirm the profile\n\n- When `remaining` is zero, the result carries `profile`.\n- Show the facts, the flags and the open questions.\n- Say the counts: stated, assumed, open.\n- Ask the user to correct anything wrong. Fix the answer and call `confirm_company_profile` again.\n\n## Step 3: The data map\n\n- Call `build_data_map` with the seed and `map_changes: {}`. The result returns the sectors and the node list, each node with a stable `key`, its name, its ring and its confirmed mark.\n- Show the map screen. It opens full screen.\n- Then ask the user six things: which of these are right, which they do not have, what they call their own tools, who owns each one, what sits outside India, and which outside companies have signed data terms.\n- Call `build_data_map` again with their answers in `map_changes`:\n  - `confirmed_keys`: nodes the user said they have\n  - `absent_keys`: nodes the user said they lack, which removes their flows\n  - `renames`: key to the user's own label\n  - `owners`: key to an owner role label, and an empty string to clear one\n  - `outside_india_keys`: nodes reachable from outside India\n  - `contracts`: ring 3 key to `yes`, `no` or `unknown`\n  - `added_nodes` and `added_flows`: anything the user named that the template lacks, each with `confirmed`\n- Confirmed means the user said it. Never set a key confirmed to tidy the map.\n- Carry the same `map_changes` on every later call.\n\n## Step 4: The legal obligations note\n\n- Call `draft_obligations_note` with the seed and `map_changes`.\n- Present it as a legal obligations note holding questions for a lawyer.\n- Each question carries a basis: `always` means asked of every company, `stated` and `assumed` follow the user's answers.\n- Never call it a legal opinion. Never say the company is compliant or in breach.\n- Say once that a lawyer gives the legal opinion.\n- Offer the sample opinion outline when the user asks what an opinion looks like.\n\n## Step 5: The gaps\n\n- Call `assess_dpdp_gaps` with the seed and `map_changes`.\n- Show the three groups: legal, technical, operational. Say the counts.\n- You may add a gap the answers show and the rules missed, through `model_added_gaps`. Each one needs a new `id`, its `group`, `evidence`, `fix`, `owner_role`, `priority`, `proof_of_closure`, `flows`, `question_ids`, and `citation_ids` taken from the note result you just read.\n- An added gap always stays assumed and enters week one. Carry it on every later call.\n\n## Step 6: The 30-day plan\n\n- Call `build_30_day_plan` with the seed, `map_changes` and any `model_added_gaps`.\n- Show four weeks. Each action carries an owner role, a proof of closure and its gap id.\n\n## Step 7: The buying guide\n\n- Call `get_dpdp_buying_guide` with the seed, `map_changes` and any `model_added_gaps`.\n- Show the categories, what each does, what each leaves out, and the questions to ask a seller.\n- Use only the seller facts in the result, with the source link and the capture date.\n- Never add a seller, a cost figure or a ranking from your own memory.\n- Show the `disclosure` line.\n\n## Step 8: The pack\n\n- Call `export_dpdp_plan_pack` with the seed, `map_changes` and any `model_added_gaps`.\n- The result carries `pack.file_name` and `pack.counts`.\n- Tell the user to read the pack full screen and use \"Save the pack\" on the screen.\n- Report the stated and assumed counts from `pack.counts`.\n\n## Stated and assumed\n\n- A fact the user said is `stated`. A fact you worked out is `assumed`.\n- The mark rides in the seed, so it survives every step.\n- Never upgrade an assumed answer. The user's own words upgrade it.\n- Say the counts whenever you show the profile, the gaps or the pack.\n\n## Legal statements\n\n- Cite the section or rule from the result. Note and gap rows carry `citation_ids`, and their sources are grouped under `sources`. Cite by the label or the ref the result gives.\n- Leave out any point with no citation in the result.\n- Do not import GDPR words into DPDP.\n- Show the `disclaimer` with the note, the gaps and the pack.\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## Errors and what to do\n\n- `INPUT_SHAPE`: a field is the wrong shape. Fix the named field and call again.\n- `INPUT_SIZE`: the seed is over 8,000 bytes. Shorten the description and the long answers.\n- `PERSONAL_RECORDS`: an email address, a phone number or an ID number reached a tool. Take it out and send the kind of data.\n- `MAP_INPUT`: send `map_changes` on its own.\n- `GAP_CITATION`: an added gap used a citation id the note did not return. Use the ids from the note result.\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- Ask for kinds of data, tools, outside companies and counts.\n- Never ask for names, contact details or records of real people. 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"
}