-
Notifications
You must be signed in to change notification settings - Fork 36
Add guardrails, decision rationale, and migration path for campaign workflow creation #9584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- Add workflow creation guardrails in campaign_creation_instructions.md - Clear criteria for when to create new workflows - Safety checklist before workflow creation - Workflow naming guidelines - Add passive vs active campaign guidance - Start with passive mode (recommended for beginners) - Prerequisites before enabling execute-workflows - Migration path from passive to active - Add decision rationale requirements - Examples of good vs poor decision explanations - Rationale for workflow selection, governance settings, KPI selection - Improve failure handling and recovery - Default failure behaviors for compilation and runtime - First-time user support with conservative defaults - Onboarding guidance in campaign body - Enhance orchestrator instructions with decision rationale - Explain WHY decisions are made (state management, date calculations, etc.) - Core principles section with explanations - Improve workflow execution guardrails - Comprehensive checklist before creating workflows - Mandatory testing requirements for new workflows - Detailed guidelines with rationale for each step - Update getting-started guide - Add "First Campaign? Start Here!" section - Show both passive and active mode examples - Add migration guide from passive to active mode These changes address the problem statement by providing: 1. Clearer guardrails for workflow creation (checklists, criteria) 2. Simple path from passive to active (step-by-step migration guide) 3. Better explanations of decisions (rationale throughout) 4. Stronger defaults for failure and onboarding (conservative settings, guidance) Co-authored-by: mnkiefer <8320933+mnkiefer@users.noreply.github.com>
|
- Add "Core Campaign Principles" section with 6 fundamental guidelines: 1. Start with one small, clear goal per campaign 2. Use passive mode first to observe and build trust 3. Reuse existing workflows before creating new ones 4. Keep permissions minimal (issues/draft PRs, no merges) 5. Make outputs standardized and predictable 6. Escalate to humans when unsure - Update campaign_creation_instructions.md with detailed principles - Update workflow_execution.md with permissions and safety guidelines - Update getting-started.md with best practices section for new users Based on feedback from @mnkiefer in PR review. Co-authored-by: mnkiefer <8320933+mnkiefer@users.noreply.github.com>
Added these core principles to the documentation in commit c323853: In campaign_creation_instructions.md - New "Core Campaign Principles" section with detailed explanations for each principle In workflow_execution.md - Added "Permissions and safety" guidelines emphasizing minimal permissions and human escalation In getting-started.md - Added "Campaign Best Practices" section at the top so new users see these principles immediately All six principles are now documented with rationale and examples throughout the campaign creation flow. |
Campaign creators need clearer constraints on workflow creation, explicit decision reasoning, a defined passive→active progression, and better failure/onboarding defaults.
Workflow Creation Guardrails
campaign_creation_instructions.md:
workflow_execution.md:
Passive → Active Migration Path
getting-started.md:
Prerequisites checklist: 2-3 successful passive runs, understand orchestration, have governance rules set.
Decision Rationale
orchestrator_instructions.md - Added "Why?" for core principles:
Phase 2 planning decisions:
campaign_creation_instructions.md - Decision templates:
Good: "Use
security-scannerbecause: scans all Go files (matches scope), creates issues (supports reporting), already tested (reduces risk)"Poor: "Use
security-scannerworkflow"Failure Handling & Onboarding
First-time user defaults:
Compilation failure behavior: Report error with context → Suggest specific fixes → Provide doc link → Keep partial files for debugging
Runtime failure behavior: Continue other work items → Report in status update → Suggest recovery actions → Maintain cursor for next run
Onboarding template in campaign body:
Core Campaign Principles
Added six fundamental principles that guide all campaign creation decisions:
Start with one small, clear goal per campaign - Focus on single, well-defined objectives (e.g., "Upgrade Node.js to v20" not "Upgrade Node.js and refactor auth")
Use passive mode first to observe and build trust - Always start passive, monitor 1-2 weeks to understand orchestration behavior before enabling active execution
Reuse existing workflows before creating new ones - Thoroughly search
.github/workflows/*.mdand the agentics collection before creating new workflowsKeep permissions minimal (issues / draft PRs, no merges) - Grant only necessary permissions, prefer read over write, use draft PRs instead of direct merges
Make outputs standardized and predictable - Use consistent safe-output configurations and follow established patterns for issue/PR formatting
Escalate to humans when unsure - Don't make risky decisions autonomously, create issues requesting human review with context and reasoning
These principles are documented in:
All changes are prompt/documentation improvements to guide agent behavior.
Original prompt
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.