feat: Nested sub folder feature enhancement

.gitignore

@@ -62,3 +62,8 @@ credentials.json
 # Node modules (if any frontend components added later)
 node_modules/
 npm-debug.log
+
+#Agents
+.claude/
+.cursor/
+.codex/

plugins/keeper-admin/skills/keeper-admin/SKILL.md

@@ -50,11 +50,13 @@ Check installation: `keeper version`
   - `ksm --help`
 4. Confirm session or auth state before any secret read.
 5. Check login status using whoami, if not logged in, complete login process and then continue rest flow.
-6. ALAWYS ask the user inputs for REQUIRED fields, DONT GUESS REQUIRED fields.
-7. Search or inspect metadata first, then retrieve only the exact requested field, do not expose any sensitive data.
-8. Prefer secret injection or one-command environment scoping over writing secrets to disk.
-9. If syntax differs from expectation, fall back to `--help` and Keeper docs immediately.
-10. ALWAYS ask confirmation from users for any delete operations.
+6. ALWAYS ask the user inputs for REQUIRED fields, DONT GUESS REQUIRED fields.
+7. For any record management operations or record sharing operation, VERIFY if the record is a Classic record type or New record type.
+8. If a record or folder type is NEW or Nested Sub Folder the use nsf commands. Refer `references/nested-sub-folders.md` for nsf commands.
+9. Search or inspect metadata first, then retrieve only the exact requested field, do not expose any sensitive data.
+10. Prefer secret injection or one-command environment scoping over writing secrets to disk.
+11. If syntax differs from expectation, fall back to `--help` and Keeper docs immediately.
+12. ALWAYS ask confirmation from users for any delete operations.
 
 
 ## REQUIRED tmux session
@@ -122,21 +124,35 @@ My Vault> get <RECORD_UID>        # Show full record details
 
 ### Record Management
 
+1. While create a new record ALWAYS ask user "Use Classic Permission Model?"
+2. If user says Yes, then use classic commands, Otherwise use nsf or Nested sub folder commands.
+3. Classic workflows supports record-add command and new workflows support Nested Sub Folder Commands.
+
+## Classic Commands
+
 ```bash
-My Vault> add --record-type login --title "New Record" \
+My Vault> record-add --record-type login --title "New Record" \
   --field login=admin
 # Set passwords and other sensitive fields via interactive prompts, or supply values only from the user’s secure input—never embed sample secrets in commands.
 
-My Vault> edit <RECORD_UID>
+My Vault> record-update -r <RECORD_UID>
 # Or non-interactive field updates for non-secret fields only, e.g. --field login=newuser
 
 My Vault> rm <RECORD_UID>
 
 My Vault> record-history <RECORD_UID>
 ```
 
-### Sharing
+## Sharing Workflow
+
+1. ALWAYS get record details and check if the record or folder type is Classic or nested sub folder type.
+2. IF record or folder type is nested sub folder then use nsf commands from references. Otherwise use the classic commands.
+3. ALWAYS check if the given record or folder type is PamUser or PAM folder that stores PamUser type records, If YES then ask use if they want to auto rotate the password after a certain time or if access time provided is over.
+4. ALWAYS ask user for setting up a expiration time while sharing a record or folder.
+5. Use -h flag for the supporting flags.
+6. MUST ask users inputs for permission flag, Once confirmed, then only share a record, Otherwise DONT proceed ahead.
 
+## Classic Commands
 ```bash
 My Vault> share-record -e user@company.com -a grant -u <RECORD_UID>
 My Vault> share-folder -e user@company.com -a grant -u <FOLDER_UID>
@@ -254,6 +270,7 @@ echo "list" | keeper --batch-mode --user admin@co.com
 - Use `references/enterprise-mgmt.md` for enterprise management scenarios and commands.
 - Use `references/pam-commands.md` for privileged access management or KeeperPAM functionalities.
 - Use `references/msp-management.md` for commands specific to Managed Service Provider (MSP) tenants
+- 
 
 ## Guardrails
 

plugins/keeper-admin/skills/keeper-admin/references/endpoint-privilege-management.md

@@ -30,7 +30,7 @@ collection
 approval
 scim
 ```
-Use -h to know exact syntac and working for each sub-commands.
+Use -h to know exact syntax and working for each sub-commands.
 
 Refer [keeper official EPM documentation](https://docs.keeper.io/en/keeperpam/commander-cli/command-reference/endpoint-privilege-manager-commands) instead of guessing a particular command.
 

plugins/keeper-admin/skills/keeper-admin/references/nested-sub-folders.md

@@ -0,0 +1,27 @@
+# Nested Sub Folder Commands
+
+Commands that support nested sub folder creation for newer or default workflows.
+Nested Share Subfolders is built on the Keeper v3 API. The commands listed below operate exclusively on Nested Share folders and records and use the nsf- prefix to keep them clearly separated from the classic vault commands.
+
+# Record Management
+```bash
+My Vault> nsf-record-add          # Create a Nested share record
+My Vault> nsf-mkdir               # Create a Nested share folder
+My Vault> nsf-rndir               # Rename or recolor a Nested share folder
+My Vault> nsf-rmdir               # Remove a Nested share folder and its entire contents
+My Vault> nsf-record-update       # Update an existing Nested share record
+My Vault> nsf-rm                  # Remove (trash, permanently delete, or unlink) a Nested share record
+```
+
+# Sharing Commands
+
+```bash
+My Vault> nsf-share-folder          # Grant or revoke folder sharing
+My Vault> nsf-share-record          # Grant, update, revoke, or transfer ownership of a record share
+My Vault> nsf-record-permission     # Bulk-update record sharing permissions for every record inside a folder
+```
+
+Use -h to know exact syntax and working for each sub-commands.
+
+Refer [keeper official NSF command documentation](https://docs.keeper.io/keeperpam/commander-cli/command-reference/nested-shared-folder) instead of guessing a particular command.
+

plugins/keeper-secrets/skills/keeper-secrets/SKILL.md

@@ -37,6 +37,43 @@ Application + Client Device authentication with one-time access tokens.
 
 Check installation: `ksm version`
 
+## Workflow
+1. ALWAYS use dedicated TMUX session for all KSM related operations.
+2. While configuring KSM for first time, pre-configure the KSM init command, Ask use input for one time token and inject that in pre-configured tmux session.
+3. ALWAYS ask the user inputs for REQUIRED fields, DONT GUESS REQUIRED fields.
+4. Search or inspect metadata first, then retrieve only the exact requested field, do not expose any sensitive data.
+5. Prefer secret injection or one-command environment scoping over writing secrets to disk.
+6. If syntax differs from expectation, fall back to `--help` and Keeper docs immediately.
+7. ALWAYS ask confirmation from users for any delete operations.
+
+## REQUIRED tmux session
+
+The shell tool uses a fresh TTY per command. To preserve Keeper interactive context, authentication state, and MFA prompts, run interactive Keeper commands or secrets manager command inside a dedicated tmux session.
+
+
+Example pattern:
+
+```bash
+SOCKET_DIR="${TMUX_SOCKET_DIR:-${TMPDIR:-/tmp}/keeper-tmux-sockets}"
+mkdir -p "$SOCKET_DIR"
+SOCKET="$SOCKET_DIR/keeper-commander.sock"
+SESSION="keeper-auth-$(date +%Y%m%d-%H%M%S)"
+
+tmux -S "$SOCKET" new -d -s "$SESSION" -n shell
+tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -- "ksm shell || bash" Enter
+tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -120
+```
+
+Then drive the session carefully:
+
+```bash
+tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 -l -- "whoami"
+tmux -S "$SOCKET" send-keys -t "$SESSION":0.0 Enter
+tmux -S "$SOCKET" capture-pane -p -J -t "$SESSION":0.0 -S -120
+```
+
+Kill the tmux session when the task is complete unless the user wants a persistent Keeper shell.
+
 ## Authentication & Profile Setup
 
 KSM uses profile-based authentication. Credentials are stored in OS-native