nowdev-ai-toolbox-instance-grounded-plan

name	nowdev-ai-toolbox-instance-grounded-plan
user-invocable	false
description	Expert planning skill for producing structured ServiceNow implementation structures and plans. Use whenever a user asks to plan, scope, estimate, design, architect, or detail a ServiceNow enhancement. It delegates read-only `now-sdk` grounding to `nowdev-ai-toolbox-servicenow-sdk` before story refinement.

ServiceNow Instance-Grounded Implementation Planner

This skill dictates the process for transforming natural language ServiceNow feature requests into highly structured, technically accurate implementation plans.

The defining characteristic of this planner is Grounding: before a plan is finalized, every referenced platform entity must be verified against the live ServiceNow instance through read-only now-sdk retrieval delegated to nowdev-ai-toolbox-servicenow-sdk.

---

1. Strictly Read-Only Safeguard

You must operate in a strictly read-only manner during the planning process.

• DO NOT create, mutate, update, or delete any records on the ServiceNow instance.
• DO NOT install, build, deploy, or change local metadata files.
• Use now-sdk only for read-only schema, data, and installed-documentation retrieval.
• Load nowdev-ai-toolbox-servicenow-sdk first; it is the sole authority for command construction, flags, authentication aliases, output handling, pagination, and CLI troubleshooting.

---

2. Grounding Verification Workflow (Mandatory First Step)

As soon as a feature request is presented, do not write the plan immediately. First ask the canonical SDK skill to perform small, field-minimized retrievals against the live instance.

Inspect the following directories/tables to anchor your scoping:

Table	Filter intent	Fields	Limit intent
sys_db_object	Name or label contains domain keywords	name,label,sys_id	10 best matches
sys_dictionary	Exact table plus element or column label matching requested concepts	name,element,column_label,internal_type,sys_id	15 best matches
sys_user_role	Role name contains proposed role keywords	name,description,sys_id	10 best matches
sys_script	Business Rule collection matches the target table or name matches domain keywords	name,collection,active,sys_id	10 best matches
sys_hub_flow	Name or internal name matches domain keywords	name,internal_name,sys_id	10 best matches
sys_rest_message	Name matches integration keywords	name,sys_id	10 best matches

---

3. Implementation Plan Structure

Once all query results have been collected, analyzed, and cited, draft the structured plan using the exact template blocks below.

Output Formatting Template

# ServiceNow Technical Implementation Plan: [Feature Name]

## Grounding Query Reference
*Cite the actual queries ran and the live ServiceNow ids/records discovered during the grounding step.*
- **System Tables Queried**: (e.g., `sys_db_object`, `sys_dictionary`, `sys_user_role`)
- **Discovered Records/Details**:
  - Table `[name]` (sys_id: `[sys_id]`) - Label: `[label]`
  - Role `[name]` (sys_id: `[sys_id]`)
  - Integration `[name]` (sys_id: `[sys_id]`)

---

## Required Artifacts
*Provide a table enumerating all physical and logical artifacts required. Do not propose duplicate tables/fields discovered during the grounding phase; instead, flag them as **REUSING**.*

| State | Artifact Type | Programmatic Name | Purpose | Complexity |
| :--- | :--- | :--- | :--- | :--- |
| **[NEW / REUSING]** | (e.g., Table, Field, Role, client script, flow, business rule) | (e.g., `x_scope_my_table`) | Detiled technical purpose and connection to requirements | (Low / Medium / High) |

---

## Dependencies & Prerequisites
- List any tables, plugins, or configurations that must exist before this plan can be deployed.
- Cite specific roles or security credentials needed.

## Technical Risks & Mitigations
- Cite potential conflicts with existing logic discovered during queries.
- Identify performance considerations (e.g., synchronous queries on large tables, lack of indexes).
- Highlight security/ACL implications of reused or new tables.

## Acceptance Criteria
- Set clear, objectively testable criteria for measuring feature completeness. Be specific about testing fields, roles, system events, and data conditions.

---

4. Grounding Principles & Best Practices

• Do not guess name prefixes: Use the active scope namespace prefix for all NEW artifacts.
• Always provide sys_ids: Any REUSING artifact must cite its live sys_id found via the query results.
• Keep retrieval narrow: Always provide explicit filter intent and a bounded limit intent. Avoid bulky payloads; report only parsed relevant fields.