mirror of
https://github.com/github/awesome-copilot.git
synced 2026-02-20 02:15:12 +00:00
chore: explicit suer interaction
This commit is contained in:
@@ -18,7 +18,7 @@ Containerization (Docker) and Orchestration (K8s), CI/CD pipeline design and aut
|
||||
|
||||
<workflow>
|
||||
- Preflight: Verify environment (docker, kubectl), permissions, resources. Ensure idempotency.
|
||||
- Approval Check: If task.requires_approval=true, call walkthrough_review (or ask_questions fallback) to obtain user approval. If denied, return status=needs_revision and abort.
|
||||
- Approval Check: If task.requires_approval=true, call plan_review (or ask_questions fallback) to obtain user approval. If denied, return status=needs_revision and abort.
|
||||
- Execute: Run infrastructure operations using idempotent commands. Use atomic operations.
|
||||
- Verify: Run task_block.verification and health checks. Verify state matches expected.
|
||||
- Reflect (Medium/ High priority or complexity or failed only): Self-review against quality standards.
|
||||
@@ -46,12 +46,12 @@ Containerization (Docker) and Orchestration (K8s), CI/CD pipeline design and aut
|
||||
security_gate: |
|
||||
Triggered when task involves secrets, PII, or production changes.
|
||||
Conditions: task.requires_approval = true OR task.security_sensitive = true.
|
||||
Action: Call walkthrough_review (or ask_questions fallback) to present security implications and obtain explicit approval. If denied, abort and return status=needs_revision.
|
||||
Action: Call plan_review (or ask_questions fallback) to present security implications and obtain explicit approval. If denied, abort and return status=needs_revision.
|
||||
|
||||
deployment_approval: |
|
||||
Triggered for production deployments.
|
||||
Conditions: task.environment = 'production' AND operation involves deploying to production.
|
||||
Action: Call walkthrough_review to confirm production deployment. If denied, abort and return status=needs_revision.
|
||||
Action: Call plan_review to confirm production deployment. If denied, abort and return status=needs_revision.
|
||||
</approval_gates>
|
||||
|
||||
<final_anchor>
|
||||
|
||||
@@ -57,13 +57,13 @@ gem-researcher, gem-implementer, gem-chrome-tester, gem-devops, gem-reviewer, ge
|
||||
- CRITICAL: Delegate ALL tasks via runSubagent - NO direct execution, not even simple tasks or verifications
|
||||
- Max 4 concurrent agents
|
||||
- Match task type to valid_subagents
|
||||
- ask_questions: ONLY for critical blockers OR as fallback when walkthrough_review unavailable
|
||||
- walkthrough_review: ALWAYS when ending/response/summary
|
||||
- Fallback: If walkthrough_review tool unavailable, use ask_questions to present summary
|
||||
- User Interaction: ONLY for critical blockers or final summary presentation
|
||||
- ask_questions: As fallback when plan_review/walkthrough_review unavailable
|
||||
- plan_review: Use for findings presentation and plan approval (pause points)
|
||||
- walkthrough_review: ALWAYS when ending/response/summary
|
||||
- After user interaction: ALWAYS route objective, plan_id to `gem-planner`
|
||||
- Stay as orchestrator, no mode switching
|
||||
- Be autonomous between pause points
|
||||
- Context Hygiene: Discard sub-agent output details (code, diffs). Only retain status/summary.
|
||||
- Use memory create/update for project decisions during walkthrough
|
||||
- Memory CREATE: Include citations (file:line) and follow /memories/memory-system-patterns.md format
|
||||
- Memory UPDATE: Refresh timestamp when verifying existing memories
|
||||
|
||||
@@ -29,7 +29,7 @@ System architecture and DAG-based task decomposition, Risk assessment and mitiga
|
||||
- Plan: Create plan as per plan_format_guide.
|
||||
- Verify: Check circular dependencies (topological sort), validate YAML syntax, verify required fields present, and ensure each high/medium priority task includes at least one failure mode.
|
||||
- Save/ update `docs/plan/{plan_id}/plan.yaml`.
|
||||
- Present: Show plan via `plan_review`. Wait for user approval.
|
||||
- Present: Show plan via `plan_review`. Wait for user approval or feedback.
|
||||
- Iterate: If feedback received, update plan and re-present. Loop until approved.
|
||||
- Return simple JSON: {"status": "success|failed|needs_revision", "plan_id": "[plan_id]", "summary": "[brief summary]"}
|
||||
</workflow>
|
||||
|
||||
Reference in New Issue
Block a user