mirror of
https://github.com/github/awesome-copilot.git
synced 2026-02-20 02:15:12 +00:00
chore: Enforce silent execution
This commit is contained in:
@@ -41,7 +41,7 @@ Browser automation, Validation Matrix scenarios, visual verification via screens
|
||||
- Cleanup: close browser sessions
|
||||
- Errors: transient→handle, persistent→escalate
|
||||
- Sensitive URLs → report, don't navigate
|
||||
- Communication: Be concise: minimal verbosity, no unsolicited elaboration.
|
||||
- Communication: Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary. For questions: direct answer in ≤3 sentences. Never explain your process unless explicitly asked "explain how".
|
||||
</operating_rules>
|
||||
|
||||
<final_anchor>
|
||||
|
||||
@@ -39,7 +39,7 @@ Containerization (Docker) and Orchestration (K8s), CI/CD pipeline design and aut
|
||||
- Errors: transient→handle, persistent→escalate
|
||||
- Plaintext secrets → halt and abort
|
||||
- Prefer multi_replace_string_in_file for file edits (batch for efficiency)
|
||||
- Communication: Be concise: minimal verbosity, no unsolicited elaboration.
|
||||
- Communication: Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary. For questions: direct answer in ≤3 sentences. Never explain your process unless explicitly asked "explain how".
|
||||
</operating_rules>
|
||||
|
||||
<approval_gates>
|
||||
|
||||
@@ -40,7 +40,7 @@ Technical communication and documentation architecture, API specification (OpenA
|
||||
- Handle errors: transient→handle, persistent→escalate
|
||||
- Secrets/PII → halt and remove
|
||||
- Prefer multi_replace_string_in_file for file edits (batch for efficiency)
|
||||
- Communication: Be concise: minimal verbosity, no unsolicited elaboration.
|
||||
- Communication: Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary. For questions: direct answer in ≤3 sentences. Never explain your process unless explicitly asked "explain how".
|
||||
</operating_rules>
|
||||
|
||||
<final_anchor>
|
||||
|
||||
@@ -47,7 +47,7 @@ Full-stack implementation and refactoring, Unit and integration testing (TDD/VDD
|
||||
- Vulnerabilities → fix before handoff
|
||||
- Prefer existing tools/ORM/framework over manual database operations (migrations, seeding, generation)
|
||||
- Prefer multi_replace_string_in_file for file edits (batch for efficiency)
|
||||
- Communication: Be concise: minimal verbosity, no unsolicited elaboration.
|
||||
- Communication: Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary. For questions: direct answer in ≤3 sentences. Never explain your process unless explicitly asked "explain how".
|
||||
</operating_rules>
|
||||
|
||||
<final_anchor>
|
||||
|
||||
@@ -61,7 +61,7 @@ gem-researcher, gem-planner, gem-implementer, gem-chrome-tester, gem-devops, gem
|
||||
- Memory UPDATE: Refresh timestamp when verifying existing memories
|
||||
- Persist product vision, norms in memories
|
||||
- Prefer multi_replace_string_in_file for file edits (batch for efficiency)
|
||||
- Communication: Be concise: minimal verbosity, no unsolicited elaboration.
|
||||
- Communication: Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary. For questions: direct answer in ≤3 sentences. Never explain your process unless explicitly asked "explain how".
|
||||
</operating_rules>
|
||||
|
||||
<final_anchor>
|
||||
|
||||
@@ -65,7 +65,7 @@ System architecture and DAG-based task decomposition, Risk assessment and mitiga
|
||||
- If research confidence low, add open questions
|
||||
- Handle errors: missing research→reject, circular deps→halt, security→halt
|
||||
- Prefer multi_replace_string_in_file for file edits (batch for efficiency)
|
||||
- Communication: Be concise: minimal verbosity, no unsolicited elaboration.
|
||||
- Communication: Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary. For questions: direct answer in ≤3 sentences. Never explain your process unless explicitly asked "explain how".
|
||||
</operating_rules>
|
||||
|
||||
<task_size_limits>
|
||||
|
||||
@@ -64,7 +64,7 @@ Codebase navigation and discovery, Pattern recognition (conventions, architectur
|
||||
- Work autonomously to completion
|
||||
- Handle errors: research failure→retry once, tool errors→handle/escalate
|
||||
- Prefer multi_replace_string_in_file for file edits (batch for efficiency)
|
||||
- Communication: Be concise: minimal verbosity, no unsolicited elaboration.
|
||||
- Communication: Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary. For questions: direct answer in ≤3 sentences. Never explain your process unless explicitly asked "explain how".
|
||||
</operating_rules>
|
||||
|
||||
<final_anchor>
|
||||
|
||||
@@ -48,7 +48,7 @@ Security auditing (OWASP, Secrets, PII), Specification compliance and architectu
|
||||
- Halt immediately on critical security issues
|
||||
- Complete security scan appropriate to review_depth
|
||||
- Handle errors: security issues→must fail, missing context→blocked, invalid handoff→blocked
|
||||
- Communication: Be concise: minimal verbosity, no unsolicited elaboration.
|
||||
- Communication: Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary. For questions: direct answer in ≤3 sentences. Never explain your process unless explicitly asked "explain how".
|
||||
</operating_rules>
|
||||
|
||||
<review_criteria>
|
||||
|
||||
Reference in New Issue
Block a user