AI-assisted custom code agent

.github/agents/custom-code.agent.md

@@ -0,0 +1,30 @@
+---
+name: custom-code-agent
+description: "Use when adding or modifying Azure CLI command module custom code, including AAZ subclass custom, legacy SDK-backed custom, and legacy non-SDK custom."
+---
+
+You are a focused coding sub-agent for Azure CLI command module custom code.
+
+Goals:
+- Add or modify command logic in custom.py.
+- Register commands in commands.py.
+- Update argument definitions in _params.py.
+- Keep command help in _help.py consistent.
+
+Rules:
+- Prefer small, targeted edits.
+- Before editing custom code, use `common-custom-code-router` unless the route is already recorded in an OpenSpec design or is otherwise unambiguous from local evidence.
+- If an OpenSpec design records the route and implementation plan, follow it. Do not choose a different route during implementation unless the design is updated.
+- Use the selected route to apply exactly one generation workflow: `common-aaz-custom-code-generation`, `common-legacy-sdk-backed-custom-code-generation`, or `common-legacy-non-sdk-custom-code-generation`.
+- Preserve existing command behavior unless the request asks for a change.
+- For any behavior change, perform a consistency pass over the affected command surface and update related implementation, argument definitions, user-facing help, validation/errors, examples, and focused tests as needed.
+- When updating tests, do not treat existing recordings as the source of truth for expected response values or response shape. Use recordings only as historical evidence to locate affected scenarios, understand previous responses, and identify existing assertions. Expected values and response structure must come from the current product/API specification and the requested custom code change; treat documentation as supporting context only, especially when the API behavior is changing. If existing recordings disagree with the new specification, update tests to the specification and expect recordings to be re-recorded rather than relaxing assertions to old values or old structures.
+- Treat `_params.py` argument help as user-facing command help, the same as authored help in `_help.py`.
+- Do not edit generated AAZ files under `aaz/latest` unless the user explicitly asks to modify generated output and accepts regeneration risk.
+- Ignore local/personal memory by default and do not rely on it for behavior decisions.
+- Use only user request, current session context, and repository-tracked guidance as authoritative inputs.
+- Do not create, edit, or delete files outside this repository unless the user explicitly asks and confirms.
+- When creating skills in this workflow, only add module-specific skills.
+- Module skill names must follow `module-<module-name>`.
+- Treat agent instructions as az-cli level guidance, not module-local policy.
+- If a requested specification looks general and reusable across modules, ask to align with the owner alias `bernardpan` before finalizing it as agent-level policy.

.github/instructions/agent-safety.instructions.md

@@ -0,0 +1,13 @@
+---
+applyTo: "**"
+description: "Global safety and scope rules for all agents in this repository."
+---
+
+When handling tasks in this repository:
+
+- Treat repository files and in-session user instructions as the primary source of truth.
+- Ignore local/personal memory by default unless the user explicitly asks to use memory content.
+- Do not create, edit, or delete files outside this repository unless the user explicitly asks and confirms.
+- Do not modify machine-level/user-level settings (for example shell profile, global git config, VS Code user settings) unless explicitly requested.
+- Avoid destructive operations by default; ask for confirmation before deleting resources or running irreversible commands.
+- Keep edits minimal and scoped to the user request.

.github/instructions/custom-code.instructions.md

@@ -0,0 +1,23 @@
+---
+applyTo: "src/azure-cli/azure/cli/command_modules/**/{custom.py,commands.py,_params.py,_help.py}"
+description: "Guidance for editing Azure CLI command module custom code files."
+---
+
+When editing Azure CLI command modules:
+
+- Keep command registration, parameters, and handlers in sync.
+- If a new command is added, wire it in commands.py and define args in _params.py.
+- Keep return shapes compatible with existing CLI output patterns.
+- Keep help/examples aligned with command behavior.
+- Prefer concise error messages through CLIError when user input is invalid.
+- Keep these instructions at az-cli level; do not add module-specific policy here.
+- If a new rule appears to be a general specification, sync with owner in the Azure CLI team before promoting it to shared instruction guidance.
+
+Before generating or modifying custom code, read and apply these repository docs:
+
+- doc/authoring_command_modules/authoring_commands.md (command registration patterns, custom command wiring, argument and validator conventions)
+- doc/command_guidelines.md (CLI UX and argument design expectations)
+- doc/error_handling_guidelines.md (preferred Azure CLI error types and patterns)
+- doc/authoring_help.md (help authoring format in _help.py/help.yaml)
+- doc/reference_doc_guidelines.md (example quality and formatting requirements)
+- doc/authoring_tests.md (test coverage and scenario test expectations)

.github/prompts/opsx-apply.prompt.md

@@ -0,0 +1,153 @@
+---
+description: Implement tasks from an OpenSpec change (Experimental)
+---
+
+Implement tasks from an OpenSpec change.
+
+**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
+
+**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read every file path listed under `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! You can archive this change with `/opsx:archive`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- For implementation tasks that add or update Azure CLI command module custom code, classify the work with `common-custom-code-router` before editing code. Use the router result to select exactly one generation skill: `common-aaz-custom-code-generation`, `common-legacy-sdk-backed-custom-code-generation`, or `common-legacy-non-sdk-custom-code-generation`.
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

.github/prompts/opsx-archive.prompt.md

@@ -0,0 +1,157 @@
+---
+description: Archive a completed change in the experimental workflow
+---
+
+Archive a completed change in the experimental workflow.
+
+**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
+
+**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
+   ```bash
+   mkdir -p "<planningHome.changesDir>/archive"
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move `changeRoot` to the archive directory
+
+   ```bash
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Spec sync status (synced / sync skipped / no delta specs)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success (No Delta Specs)**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success With Warnings**
+
+```
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+```
+
+**Output On Error (Archive Exists)**
+
+```
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting