@exaudeus/workrail 0.0.2 → 0.0.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +4 -2
- package/spec/examples/adaptive-ticket-creation.json +170 -0
- package/spec/examples/ai-task-prompt-workflow.json +80 -0
- package/spec/examples/coding-task-workflow.json +141 -0
- package/spec/examples/conditional-workflow-example.json +216 -0
- package/spec/examples/invalid-workflow.json +20 -0
- package/spec/examples/valid-workflow.json +118 -0
- package/spec/mcp-api-v1.0.md +714 -0
- package/spec/mcp-compliance-summary.md +211 -0
- package/spec/mcp-protocol-handshake.md +603 -0
- package/spec/workflow.schema.json +327 -0
- package/workflows/adaptive-ticket-creation.json +257 -0
- package/workflows/coding-task-workflow.json +115 -0
- package/workflows/mr-review-workflow.json +79 -0
- package/workflows/presentation-creation.json +245 -0
- package/workflows/workflow-for-workflows.json +74 -0
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
{
|
|
2
|
+
"id": "coding-task-workflow",
|
|
3
|
+
"name": "Excellent Adaptive Coding Workflow with Devil's Advocate Review",
|
|
4
|
+
"version": "0.0.1",
|
|
5
|
+
"description": "A comprehensive and resilient workflow for AI-assisted coding. It adaptively sizes tasks, performs a critical self-review of its own plans, provides efficiency options, enforces closed-loop validation, and defines a robust protocol for handling failures.",
|
|
6
|
+
"preconditions": [
|
|
7
|
+
"User has a clear task description (e.g., from Jira, a dev doc, or a BRD).",
|
|
8
|
+
"The agent has access to necessary tools like `grep`, file readers/editors, and a terminal for commands.",
|
|
9
|
+
"The agent has access to the relevant codebase files."
|
|
10
|
+
],
|
|
11
|
+
"metaGuidance": [
|
|
12
|
+
"This workflow follows the PREP -> IMPLEMENT -> VERIFY pattern for each step in the plan.",
|
|
13
|
+
"Human approval is required after the Devil's Advocate review and before final completion.",
|
|
14
|
+
"Each implementation step should be a small, logical, and committable chunk of work.",
|
|
15
|
+
"The agent should never guess or assume. Always ask for clarification or use tools to find missing information.",
|
|
16
|
+
"Maintain existing coding conventions and architectural patterns found in the codebase."
|
|
17
|
+
],
|
|
18
|
+
"steps": [
|
|
19
|
+
{
|
|
20
|
+
"id": "phase-0-intelligent-triage",
|
|
21
|
+
"title": "Phase 0: Intelligent Task Triage & Complexity Analysis",
|
|
22
|
+
"prompt": "**ANALYZE**: Evaluate the provided task for complexity indicators:\n\n**Small Path Indicators:**\n- Single function changes or minor refactoring\n- Clear bug fixes with obvious solutions\n- Simple configuration changes\n- Low risk of side effects\n- Well-defined, narrow scope\n\n**Medium Path Indicators:**\n- Multi-file changes or moderate features\n- Standard development work\n- Some unknowns but manageable scope\n- Moderate complexity with clear boundaries\n- Requires planning but not architectural analysis\n\n**Large Path Indicators:**\n- Architectural changes or major features\n- Unfamiliar codebase areas\n- High complexity or significant risk\n- Multiple system interactions\n- Requires deep analysis and careful planning\n\n**IMPLEMENT**: \n1. Analyze the task description for the above indicators\n2. Recommend a complexity level (Small/Medium/Large) with detailed reasoning\n3. Set the taskComplexity context variable\n4. Ask user if they agree or want to override your classification\n5. For Medium tasks, ask: \"Would you like optional deep codebase analysis?\" (sets requestDeepAnalysis context variable)\n\n**VERIFY**: Confirm the complexity classification and any optional analysis preferences before proceeding.",
|
|
23
|
+
"guidance": [
|
|
24
|
+
"Be thorough in your analysis - this determines the entire workflow path",
|
|
25
|
+
"Consider both technical complexity and business risk",
|
|
26
|
+
"When in doubt, err on the side of more thorough analysis (higher complexity)",
|
|
27
|
+
"Always allow human override of your classification",
|
|
28
|
+
"Set context variables that will be used for conditional step execution"
|
|
29
|
+
],
|
|
30
|
+
"requireConfirmation": true
|
|
31
|
+
},
|
|
32
|
+
{
|
|
33
|
+
"id": "phase-1-scoping",
|
|
34
|
+
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
35
|
+
"title": "Phase 1: Task Briefing & Scope Definition",
|
|
36
|
+
"prompt": "Your first goal is to understand the task. Analyze the following request, summarize your understanding, ask clarifying questions, and assess which parts of the codebase are relevant.\n\n**Task Description:**\n[User inserts detailed task description here]\n\n**Key Objectives & Success Criteria:**\n[User lists specific, measurable success criteria here]\n\n**Scope and Constraints:**\n[User defines boundaries or areas to avoid here]\n\nFinally, based on your analysis, perform a sanity check on the initial complexity sizing. If you believe the classification is incorrect, state your reasoning and ask for confirmation before proceeding. For example: 'You classified this as Medium, but my analysis shows it impacts several core architectural components. I recommend we upgrade to the Large path to perform a Deep Analysis. Do you agree?'",
|
|
37
|
+
"guidance": [
|
|
38
|
+
"Provide a complete task description. Vague requests will lead to poor plans and wasted effort.",
|
|
39
|
+
"This step is automatically skipped for Small tasks based on the complexity classification"
|
|
40
|
+
]
|
|
41
|
+
},
|
|
42
|
+
{
|
|
43
|
+
"id": "phase-1b-deep-analysis-mandatory",
|
|
44
|
+
"runCondition": {"var": "taskComplexity", "equals": "Large"},
|
|
45
|
+
"title": "Phase 1b: Mandatory Deep Codebase Analysis",
|
|
46
|
+
"prompt": "Your goal is to become an expert on the attached codebase. This deep analysis is mandatory for Large tasks due to their complexity and risk. Your analysis must include:\n1. **Architecture:** Main modules, layers, and patterns.\n2. **Key Concepts:** Core models, conventions, and important components.\n3. **Execution Flow:** Trace major features or entry points.\n4. **Code Quality Assessment:** Note maintainability, readability, or coupling issues.\n5. **Testing Strategy:** Describe how the code is tested.\n6. **Opportunities:** Suggest refactorings or improvements.\n\nProvide summaries and code examples to illustrate your findings. Be exhaustive, as if preparing onboarding documentation for a senior engineer.",
|
|
47
|
+
"askForFiles": true,
|
|
48
|
+
"guidance": [
|
|
49
|
+
"This step is mandatory for Large tasks due to their complexity and risk",
|
|
50
|
+
"Ensure all relevant source files are attached or accessible to the agent before running this step",
|
|
51
|
+
"Be thorough - this analysis will inform the entire implementation strategy"
|
|
52
|
+
]
|
|
53
|
+
},
|
|
54
|
+
{
|
|
55
|
+
"id": "phase-1b-deep-analysis-optional",
|
|
56
|
+
"runCondition": {
|
|
57
|
+
"and": [
|
|
58
|
+
{"var": "taskComplexity", "equals": "Medium"},
|
|
59
|
+
{"var": "requestDeepAnalysis", "equals": true}
|
|
60
|
+
]
|
|
61
|
+
},
|
|
62
|
+
"title": "Phase 1b: Optional Deep Codebase Analysis",
|
|
63
|
+
"prompt": "You requested optional deep analysis for this Medium task. Your goal is to become an expert on the attached codebase. Your analysis must include:\n1. **Architecture:** Main modules, layers, and patterns.\n2. **Key Concepts:** Core models, conventions, and important components.\n3. **Execution Flow:** Trace major features or entry points.\n4. **Code Quality Assessment:** Note maintainability, readability, or coupling issues.\n5. **Testing Strategy:** Describe how the code is tested.\n6. **Opportunities:** Suggest refactorings or improvements.\n\nProvide summaries and code examples to illustrate your findings. Be exhaustive, as if preparing onboarding documentation for a senior engineer.",
|
|
64
|
+
"askForFiles": true,
|
|
65
|
+
"guidance": [
|
|
66
|
+
"This optional analysis was requested for a Medium task",
|
|
67
|
+
"Ensure all relevant source files are attached or accessible to the agent before running this step",
|
|
68
|
+
"Focus on areas most relevant to the current task"
|
|
69
|
+
]
|
|
70
|
+
},
|
|
71
|
+
{
|
|
72
|
+
"id": "phase-2-planning",
|
|
73
|
+
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
74
|
+
"title": "Phase 2: Create Detailed Implementation Plan",
|
|
75
|
+
"prompt": "Your goal is to produce a thorough and actionable plan of attack. Do not write any code. Your plan must be detailed, broken into committable phases, and justified.\n\nYour plan must include these sections:\n1. **Goal Clarification:** Your understanding of the goal, assumptions, and success criteria.\n2. **Impact Assessment:** Affected codebase parts, dependencies, and risks.\n3. **Implementation Strategy:** A list of discrete, actionable steps. Each step must detail the task, its rationale, inputs, and outputs.\n4. **Final Review Checklist:** A specific checklist of items that must be verified to consider this entire task complete. This will be used in the final review phase.\n\nPresent this as a formal proposal.",
|
|
76
|
+
"guidance": [
|
|
77
|
+
"The agent will now proceed to critique its own plan in the next step. Withhold your final approval until after that critique.",
|
|
78
|
+
"This step is automatically skipped for Small tasks based on the complexity classification"
|
|
79
|
+
]
|
|
80
|
+
},
|
|
81
|
+
{
|
|
82
|
+
"id": "phase-2b-devil-advocate-review",
|
|
83
|
+
"runCondition": {"var": "taskComplexity", "not_equals": "Small"},
|
|
84
|
+
"title": "Phase 2b: Devil's Advocate Plan Review",
|
|
85
|
+
"prompt": "Your new goal is to act as a skeptical but fair senior principal engineer. Your task is to perform a 'devil's advocate' review of the implementation plan you just created in Phase 2. The objective is not to discard the plan, but to rigorously stress-test it and make it stronger. Your critique must be balanced and evidence-based.\n\nAnalyze the plan through the following lenses. For every point you make (positive or negative), you must cite specific evidence from the plan, the codebase, or the initial task description.\n\n1. **Hidden Assumptions:** What assumptions does this plan make about the codebase, user behavior, or existing data that might be incorrect?\n2. **Potential Risks & Unintended Side Effects:** What is the biggest risk of this plan? Could it impact performance, security, or another feature in a negative way?\n3. **Overlooked Complexities or Edge Cases:** What specific edge cases (e.g., empty states, invalid inputs, race conditions) does the plan fail to explicitly address?\n4. **Alternative Approaches:** Briefly propose at least one alternative technical approach. What are the pros and cons of the alternative versus the current plan?\n5. **Plan Strengths:** To ensure a balanced review, explicitly state the strongest parts of the plan. What aspects are well-thought-out and likely to succeed?\n\nConclude with a balanced summary. If you found issues, provide concrete suggestions for how to amend the plan. Finally, give a confidence score (1-10) for the plan *if* your suggestions are implemented.",
|
|
86
|
+
"guidance": [
|
|
87
|
+
"This is a critical thinking step. The agent's goal is to find weaknesses in its *own* prior work to improve it. This is a sign of a high-functioning process.",
|
|
88
|
+
"Evaluate the agent's points. Not all 'risks' it identifies may be realistic. Use your judgment to decide which suggestions to incorporate into the plan.",
|
|
89
|
+
"After this review, you can ask the agent to create a final, amended version of the plan before you give your final approval to proceed with implementation.",
|
|
90
|
+
"This step is automatically skipped for Small tasks based on the complexity classification"
|
|
91
|
+
],
|
|
92
|
+
"requireConfirmation": true
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "phase-3-iterative-implementation",
|
|
96
|
+
"title": "Phase 3: Iterative Implementation (PREP -> IMPLEMENT -> VERIFY)",
|
|
97
|
+
"prompt": "The implementation phase has now begun. **Please provide me with the next single step from the approved plan.** If we are on the 'Small' path, provide a single, clear implementation instruction.\n\nI will execute *only* that step using the PREP -> IMPLEMENT -> VERIFY cycle defined in the guidance below, and then await your command for the subsequent step. This process will repeat until all steps are complete.",
|
|
98
|
+
"guidance": [
|
|
99
|
+
"**Efficiency Tip:** For high-confidence plans, you may provide multiple step instructions at once. I will execute them sequentially, performing the P->I->V cycle for each, and will only pause to ask for input if I encounter a verification failure or ambiguity.",
|
|
100
|
+
"**PREP:** Before implementing each step, you must first PREPARE. Re-read the step's description, confirm the previous step was completed correctly, verify the plan for this step is still valid in the current codebase, and list all required inputs or files. Do not proceed if anything is unclear.",
|
|
101
|
+
"**IMPLEMENT:** After preparation is confirmed, you will IMPLEMENT the step. Focus only on this single step. Use your tools to make the necessary code changes, adhering to all quality standards. Provide a commit message upon completion.",
|
|
102
|
+
"**VERIFY:** Immediately after implementation, you must VERIFY your work. Your verification for this step **is not complete until you have**:\n1. **Written necessary unit/integration tests** for the new logic.\n2. **Run the full test suite** to ensure no regressions were introduced.\n3. **Performed a critical self-review** of the changes against the plan, checking for code quality, side effects, and architectural alignment.\n\n**Failure Protocol:** If a verification failure cannot be resolved after two attempts, you must halt. Do not try a third time. Instead, present a summary of the problem, detail your failed attempts, and recommend a course of action to the user (e.g., 'revert this step and re-plan', 'request more information', 'proceed with a known issue')."
|
|
103
|
+
]
|
|
104
|
+
},
|
|
105
|
+
{
|
|
106
|
+
"id": "phase-4-final-review",
|
|
107
|
+
"title": "Phase 4: Final Review & Completion",
|
|
108
|
+
"prompt": "All planned steps have been implemented and verified. Your final goal is to perform a holistic review by validating the work against the **'Final Review Checklist'** created and approved during Phase 2.\n\nFor each item on that checklist, provide a confirmation and evidence that it has been met. Conclude with a summary of any potential follow-ups or new dependencies to note.",
|
|
109
|
+
"guidance": [
|
|
110
|
+
"This is the final quality check. Ensure the agent's summary and checklist validation align with your understanding of the completed work."
|
|
111
|
+
],
|
|
112
|
+
"requireConfirmation": true
|
|
113
|
+
}
|
|
114
|
+
]
|
|
115
|
+
}
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
{
|
|
2
|
+
"id": "mr-review-workflow",
|
|
3
|
+
"name": "Adaptive MR Review Workflow",
|
|
4
|
+
"version": "0.0.1",
|
|
5
|
+
"description": "An adaptive workflow to guide an AI agent in performing a comprehensive code review. It adjusts its rigor based on MR complexity and includes checkpoints for architectural and self-critique to provide deep, actionable feedback.",
|
|
6
|
+
"preconditions": [
|
|
7
|
+
"User has the full code diff accessible (e.g., as text in a file).",
|
|
8
|
+
"User has the MR title, purpose, and any relevant ticket numbers.",
|
|
9
|
+
"The agent has access to file-reading tools."
|
|
10
|
+
],
|
|
11
|
+
"metaGuidance": [
|
|
12
|
+
"The ultimate goal is to assist, not replace, a human reviewer.",
|
|
13
|
+
"All feedback should be constructive and actionable.",
|
|
14
|
+
"When citing issues, always try to provide specific file paths and line numbers from the diff.",
|
|
15
|
+
"Maintain the persona of a helpful, collaborative senior engineer.",
|
|
16
|
+
"If at any point you determine that a crucial piece of information is missing to complete your analysis, you must pause. State what information you need, why it is necessary, and ask the user to provide it."
|
|
17
|
+
],
|
|
18
|
+
"steps": [
|
|
19
|
+
{
|
|
20
|
+
"id": "phase-0-triage",
|
|
21
|
+
"title": "Phase 0: Triage & Review Focus",
|
|
22
|
+
"prompt": "To begin the Merge Request review, please provide the full context below and classify the MR's complexity. This will tailor the depth of the review.\n\n**1. MR Context:**\n* **MR Title/Purpose:** [User provides the title and a brief description of its purpose.]\n* **Related Ticket(s):** [User provides ticket numbers or links.]\n* **Key Requirements/Acceptance Criteria:** [User lists key requirements from the ticket(s).]\n\n**2. Code Diff:**\n[User pastes the full `git diff` output or provides a path to a file containing the diff.]\n\n**3. Complexity Classification & Focus:**\n* **Classification:** Please choose one: **[Trivial]**, **[Standard]**, or **[High-Risk]**.\n* **Areas of Focus (Optional):** Are there specific areas you want me to pay close attention to? (e.g., 'performance implications', 'API design', 'data integrity').",
|
|
23
|
+
"guidance": [
|
|
24
|
+
"**[Trivial]:** For minor fixes (typos, docs). This will run a condensed, single-phase review.",
|
|
25
|
+
"**[Standard]:** For typical features or bug fixes. This uses the full, multi-phase review process.",
|
|
26
|
+
"**[High-Risk]:** For major architectural changes or features touching sensitive code. This follows the full process with maximum diligence."
|
|
27
|
+
]
|
|
28
|
+
},
|
|
29
|
+
{
|
|
30
|
+
"id": "phase-1-context",
|
|
31
|
+
"title": "Phase 1: Contextual Understanding & Confirmation",
|
|
32
|
+
"prompt": "My goal is to ensure I fully understand the MR before the deep analysis. Based on the context you provided, I will perform the following tasks:\n\n1. **Summarize Goal:** Briefly summarize what I understand to be the primary goal and scope of this MR.\n2. **File Overview:** List all changed files (added, modified, deleted) and provide a one-sentence summary of the changes for each.\n3. **Initial Questions:** Formulate any immediate questions I have about the MR's purpose or requirements.\n4. **Confirmation Gate:** Does my summary accurately reflect the MR's goal? Please confirm before I proceed.",
|
|
33
|
+
"guidance": [
|
|
34
|
+
"This is a critical sanity check. If the agent's summary is incorrect, correct it now to prevent a flawed review. This step is skipped for 'Trivial' reviews."
|
|
35
|
+
],
|
|
36
|
+
"requireConfirmation": true
|
|
37
|
+
},
|
|
38
|
+
{
|
|
39
|
+
"id": "phase-2-detailed-analysis",
|
|
40
|
+
"title": "Phase 2: In-Depth Line-by-Line Analysis",
|
|
41
|
+
"prompt": "My goal is to perform a detailed, line-by-line analysis of the code diff, guided by the checklist below and focusing on any specific areas you requested. I will provide specific examples and line numbers for my findings.\n\n**Detailed Analysis Checklist:**\n1. **Functionality & Correctness:** Does the code implement the requirements? Are there logical flaws or unhandled edge cases?\n2. **Readability & Maintainability:** How is the clarity, naming, and complexity? Are comments sufficient and accurate?\n3. **Design & Architecture:** Does the code align with existing patterns? Does it introduce risky dependencies or side effects?\n4. **Best Practices & Conventions:** Does the code follow language-specific best practices and avoid anti-patterns?\n5. **Error Handling:** Is error handling robust and appropriate?\n6. **Performance:** Are there any obvious performance bottlenecks?\n7. **Code Duplication:** Is there significant duplicated code?\n8. **Security:** Are there any potential security vulnerabilities introduced (e.g., injection, improper handling of sensitive data)?\n9. **Debug Statements:** Are there leftover debugging statements (`print`, `console.log`)?",
|
|
42
|
+
"guidance": [
|
|
43
|
+
"The agent will now perform the most time-consuming part of the review. The thoroughness of this checklist helps catch a wide variety of issues."
|
|
44
|
+
]
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "phase-2b-holistic-review",
|
|
48
|
+
"title": "Phase 2b: Holistic Architectural Review",
|
|
49
|
+
"prompt": "Now, I will step back from the line-by-line details to assess the bigger picture.\n\nMy goal is to answer the following high-level questions:\n1. **Simplicity & Approach:** Is this the simplest and most effective approach to solving the problem? Could the same outcome have been achieved more cleanly or with less new code?\n2. **Precedent:** Does this change set a good or bad precedent for future development in this codebase?\n3. **Strategic Alignment:** Does this change feel aligned with the overall architecture, or does it feel like a temporary 'hack' or a one-off solution?",
|
|
50
|
+
"guidance": [
|
|
51
|
+
"This step prevents 'checklist tunnel vision' and encourages the agent to provide strategic, architectural feedback, which is often the most valuable."
|
|
52
|
+
]
|
|
53
|
+
},
|
|
54
|
+
{
|
|
55
|
+
"id": "phase-3-impact-analysis",
|
|
56
|
+
"title": "Phase 3: Testing, Documentation & Impact Analysis",
|
|
57
|
+
"prompt": "My goal is to assess the secondary impacts of this change.\n\n1. **Testing:** Based on the code changes, what tests would be expected (unit, integration, etc.)? Are new tests included? Are existing tests updated? Are there obvious gaps in test coverage for the new logic?\n2. **Documentation:** Is new or complex logic adequately commented? Could any external documentation (e.g., READMEs) be affected by this change?\n3. **Breaking Changes:** Are there any changes that could break backward compatibility for APIs or other parts of the codebase?",
|
|
58
|
+
"guidance": [
|
|
59
|
+
"Assessing test coverage is critical. A lack of tests for new logic is often a 'Major' or 'Critical' concern."
|
|
60
|
+
]
|
|
61
|
+
},
|
|
62
|
+
{
|
|
63
|
+
"id": "phase-4-summary",
|
|
64
|
+
"title": "Phase 4: Final Summary & Structured Feedback",
|
|
65
|
+
"prompt": "My goal is to consolidate all findings into a final, actionable report.\n\nFirst, I will perform a **Devil's Advocate Self-Critique:** I will briefly review my own findings. Are any of my 'Major' concerns actually minor preferences? Conversely, is there a pattern among my 'Minor' suggestions that points to a larger, unstated problem? I will state if this check changed my perspective.\n\nNext, I will provide the final report in this structure:\n1. **Overall MR Assessment:** A 2-3 sentence qualitative summary of the MR.\n2. **Key Positive Aspects:** 2-3 highlights of what was done well.\n3. **Main Areas of Concern (Categorized):**\n * **Critical (Blocking issues, potential bugs):**\n * **Major (Important design flaws, missing core tests):**\n * **Minor/Suggestions (Readability, best practices):**\n4. **Questions for the Author:** A list of specific, clarifying questions.\n5. **Actionable Recommendations:** Concrete suggestions for the most important issues.",
|
|
66
|
+
"guidance": [
|
|
67
|
+
"The final, categorized summary is designed to be copied directly into a GitHub, GitLab, or other code review tool to provide clear and structured feedback to the MR author."
|
|
68
|
+
]
|
|
69
|
+
},
|
|
70
|
+
{
|
|
71
|
+
"id": "phase-5-trivial-review-summary",
|
|
72
|
+
"title": "Phase 5: Trivial Review Summary",
|
|
73
|
+
"prompt": "Based on the trivial nature of this MR, I have performed a quick check for obvious errors. The change appears to correctly address the stated purpose without any clear side effects. I recommend approval.",
|
|
74
|
+
"guidance": [
|
|
75
|
+
"This is the condensed summary for 'Trivial' reviews. The agent skips all other analytical steps and provides a simple confirmation for straightforward changes."
|
|
76
|
+
]
|
|
77
|
+
}
|
|
78
|
+
]
|
|
79
|
+
}
|
|
@@ -0,0 +1,245 @@
|
|
|
1
|
+
{
|
|
2
|
+
"id": "presentation-creation",
|
|
3
|
+
"name": "Dynamic Presentation Creation Workflow",
|
|
4
|
+
"version": "0.0.1",
|
|
5
|
+
"description": "A comprehensive workflow for creating dynamic, interesting, and insightful presentations. Guides users through audience analysis, content strategy, visual design, and delivery preparation to create compelling presentations that engage and inform.",
|
|
6
|
+
"preconditions": [
|
|
7
|
+
"User has a clear presentation topic or objective",
|
|
8
|
+
"User has access to relevant source materials or research",
|
|
9
|
+
"User has identified their target audience",
|
|
10
|
+
"User has a rough timeline for presentation delivery"
|
|
11
|
+
],
|
|
12
|
+
"clarificationPrompts": [
|
|
13
|
+
"What is the main objective or key message of your presentation?",
|
|
14
|
+
"Who is your target audience and what is their expertise level?",
|
|
15
|
+
"What is the presentation format (conference, meeting, webinar, etc.)?",
|
|
16
|
+
"How much time do you have for the presentation?",
|
|
17
|
+
"What supporting materials or data do you have available?",
|
|
18
|
+
"Are there any specific constraints or requirements to consider?"
|
|
19
|
+
],
|
|
20
|
+
"steps": [
|
|
21
|
+
{
|
|
22
|
+
"id": "audience-and-context-analysis",
|
|
23
|
+
"title": "Audience & Context Analysis",
|
|
24
|
+
"prompt": "**PREP**: Thoroughly analyze your audience and presentation context to ensure maximum impact.\n\n**IMPLEMENT**: Create a detailed audience profile:\n- **Audience Demographics**: Professional background, expertise level, role/seniority\n- **Audience Motivations**: What they want to learn, their pain points, success criteria\n- **Context Analysis**: Event type, setting, time constraints, follow-up expectations\n- **Engagement Preferences**: Interactive vs. presentation style, Q&A expectations\n- **Success Metrics**: How will you measure if the presentation achieved its goals?\n\n**VERIFY**: Confirm you have a clear understanding of who you're presenting to and what success looks like.",
|
|
25
|
+
"guidance": [
|
|
26
|
+
"The better you understand your audience, the more you can tailor your message",
|
|
27
|
+
"Consider both explicit and implicit audience needs",
|
|
28
|
+
"Think about the broader context - what happens before and after your presentation?"
|
|
29
|
+
],
|
|
30
|
+
"requireConfirmation": true,
|
|
31
|
+
"validationCriteria": [
|
|
32
|
+
{
|
|
33
|
+
"type": "regex",
|
|
34
|
+
"pattern": "(?i)##?\\s*Audience Demographics:?",
|
|
35
|
+
"message": "Analysis must include audience demographics section"
|
|
36
|
+
},
|
|
37
|
+
{
|
|
38
|
+
"type": "regex",
|
|
39
|
+
"pattern": "(?i)##?\\s*Audience Motivations:?",
|
|
40
|
+
"message": "Analysis must include audience motivations section"
|
|
41
|
+
},
|
|
42
|
+
{
|
|
43
|
+
"type": "length",
|
|
44
|
+
"min": 400,
|
|
45
|
+
"message": "Analysis should be at least 400 characters for comprehensive coverage"
|
|
46
|
+
}
|
|
47
|
+
]
|
|
48
|
+
},
|
|
49
|
+
{
|
|
50
|
+
"id": "content-strategy-and-structure",
|
|
51
|
+
"title": "Content Strategy & Structure Development",
|
|
52
|
+
"prompt": "**PREP**: Develop a compelling content strategy that aligns with your audience analysis.\n\n**IMPLEMENT**: Create a structured content plan:\n- **Core Message**: One clear, memorable takeaway (elevator pitch version)\n- **Supporting Arguments**: 3-5 key points that reinforce your core message\n- **Narrative Arc**: How will you take the audience on a journey? (problem → solution → impact)\n- **Evidence Strategy**: Data, examples, stories, and visuals that support each point\n- **Engagement Hooks**: Surprising statistics, thought-provoking questions, interactive elements\n- **Call-to-Action**: What specific action do you want the audience to take?\n\n**VERIFY**: Ensure your content strategy creates a logical flow that serves your audience's needs while achieving your objectives.",
|
|
53
|
+
"guidance": [
|
|
54
|
+
"Start with your core message - everything else should support it",
|
|
55
|
+
"Use the 'So What?' test for each section - why should the audience care?",
|
|
56
|
+
"Plan for multiple learning styles - visual, auditory, kinesthetic",
|
|
57
|
+
"Include moments of high engagement throughout, not just at the beginning"
|
|
58
|
+
],
|
|
59
|
+
"requireConfirmation": true,
|
|
60
|
+
"validationCriteria": [
|
|
61
|
+
{
|
|
62
|
+
"type": "regex",
|
|
63
|
+
"pattern": "(?i)##?\\s*Core Message:?",
|
|
64
|
+
"message": "Strategy must include a clear core message"
|
|
65
|
+
},
|
|
66
|
+
{
|
|
67
|
+
"type": "regex",
|
|
68
|
+
"pattern": "(?i)##?\\s*Supporting Arguments:?",
|
|
69
|
+
"message": "Strategy must include supporting arguments"
|
|
70
|
+
},
|
|
71
|
+
{
|
|
72
|
+
"type": "regex",
|
|
73
|
+
"pattern": "(?i)##?\\s*Call-to-Action:?",
|
|
74
|
+
"message": "Strategy must include a call-to-action"
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"type": "length",
|
|
78
|
+
"min": 600,
|
|
79
|
+
"message": "Strategy should be at least 600 characters for comprehensive planning"
|
|
80
|
+
}
|
|
81
|
+
]
|
|
82
|
+
},
|
|
83
|
+
{
|
|
84
|
+
"id": "slide-structure-and-flow",
|
|
85
|
+
"title": "Slide Structure & Flow Design",
|
|
86
|
+
"prompt": "**PREP**: Transform your content strategy into a detailed slide-by-slide structure.\n\n**IMPLEMENT**: Create a comprehensive slide outline:\n- **Opening Hook** (1-2 slides): Attention grabber, context setting, agenda preview\n- **Main Content Blocks** (8-15 slides): Each supporting argument with evidence and examples\n- **Transition Slides**: Smooth connections between major sections\n- **Interaction Points**: Polls, Q&A moments, discussion breaks\n- **Visual Hierarchy**: Which slides need charts, images, diagrams, or minimal text\n- **Pacing Strategy**: Balance of information density vs. breathing room\n- **Closing Impact** (2-3 slides): Summary, call-to-action, next steps\n\n**VERIFY**: Review the flow for logical progression, appropriate pacing, and engagement variety.",
|
|
87
|
+
"guidance": [
|
|
88
|
+
"Follow the 6x6 rule: max 6 bullet points with 6 words each",
|
|
89
|
+
"Plan for one key idea per slide",
|
|
90
|
+
"Include slide numbers and estimated timing",
|
|
91
|
+
"Consider how slides will work both in-person and if shared later"
|
|
92
|
+
],
|
|
93
|
+
"requireConfirmation": true,
|
|
94
|
+
"validationCriteria": [
|
|
95
|
+
{
|
|
96
|
+
"type": "regex",
|
|
97
|
+
"pattern": "(?i)slide\\s*\\d+",
|
|
98
|
+
"message": "Outline must include numbered slides (e.g., 'Slide 1', 'Slide 2')"
|
|
99
|
+
},
|
|
100
|
+
{
|
|
101
|
+
"type": "regex",
|
|
102
|
+
"pattern": "(?i)(opening|hook|introduction)",
|
|
103
|
+
"message": "Outline must include opening/hook slides"
|
|
104
|
+
},
|
|
105
|
+
{
|
|
106
|
+
"type": "regex",
|
|
107
|
+
"pattern": "(?i)(closing|conclusion|summary)",
|
|
108
|
+
"message": "Outline must include closing/summary slides"
|
|
109
|
+
},
|
|
110
|
+
{
|
|
111
|
+
"type": "length",
|
|
112
|
+
"min": 800,
|
|
113
|
+
"message": "Slide outline should be at least 800 characters for detailed planning"
|
|
114
|
+
}
|
|
115
|
+
]
|
|
116
|
+
},
|
|
117
|
+
{
|
|
118
|
+
"id": "visual-design-and-engagement",
|
|
119
|
+
"title": "Visual Design & Engagement Elements",
|
|
120
|
+
"prompt": "**PREP**: Design the visual and interactive elements that will make your presentation dynamic and memorable.\n\n**IMPLEMENT**: Plan comprehensive visual and engagement strategy:\n- **Visual Theme**: Color scheme, typography, consistent design language\n- **Data Visualization**: Chart types, infographic concepts, before/after comparisons\n- **Multimedia Elements**: Video clips, animations, interactive demos\n- **Storytelling Visuals**: Metaphors, analogies, journey maps\n- **Engagement Techniques**: Live polls, breakout discussions, hands-on activities\n- **Memory Aids**: Mnemonics, repeated visual themes, callback references\n- **Accessibility**: Readable fonts, color contrast, alternative text descriptions\n\n**VERIFY**: Ensure visual elements enhance rather than distract from your message, and engagement techniques fit naturally into your flow.",
|
|
121
|
+
"guidance": [
|
|
122
|
+
"Visuals should simplify complex ideas, not complicate simple ones",
|
|
123
|
+
"Use consistent visual language throughout the presentation",
|
|
124
|
+
"Plan interactive elements that serve your learning objectives",
|
|
125
|
+
"Consider how visual elements will reproduce in different formats (print, mobile, etc.)"
|
|
126
|
+
],
|
|
127
|
+
"requireConfirmation": true,
|
|
128
|
+
"validationCriteria": [
|
|
129
|
+
{
|
|
130
|
+
"type": "regex",
|
|
131
|
+
"pattern": "(?i)##?\\s*Visual Theme:?",
|
|
132
|
+
"message": "Design plan must include visual theme section"
|
|
133
|
+
},
|
|
134
|
+
{
|
|
135
|
+
"type": "regex",
|
|
136
|
+
"pattern": "(?i)##?\\s*Engagement Techniques:?",
|
|
137
|
+
"message": "Design plan must include engagement techniques"
|
|
138
|
+
},
|
|
139
|
+
{
|
|
140
|
+
"type": "length",
|
|
141
|
+
"min": 500,
|
|
142
|
+
"message": "Visual design plan should be at least 500 characters for comprehensive coverage"
|
|
143
|
+
}
|
|
144
|
+
]
|
|
145
|
+
},
|
|
146
|
+
{
|
|
147
|
+
"id": "content-development-and-refinement",
|
|
148
|
+
"title": "Content Development & Refinement",
|
|
149
|
+
"prompt": "**PREP**: Develop the actual presentation content, focusing on clarity, impact, and memorability.\n\n**IMPLEMENT**: Create polished presentation content:\n- **Slide Content**: Write clear, concise text for each slide following your outline\n- **Speaker Notes**: Detailed talking points, transitions, and timing cues\n- **Stories and Examples**: Develop compelling narratives that illustrate your points\n- **Data Presentation**: Create clear, impactful visualizations of key statistics\n- **Interaction Scripts**: Prepare questions, poll options, and facilitation guidance\n- **Backup Content**: Extra slides for deep-dive questions or extended time\n- **Handout Materials**: Summary sheets, resource lists, contact information\n\n**VERIFY**: Review content for clarity, accuracy, and alignment with your core message. Test that examples resonate with your target audience.",
|
|
150
|
+
"guidance": [
|
|
151
|
+
"Write for the ear, not the eye - content should sound natural when spoken",
|
|
152
|
+
"Use active voice and concrete language",
|
|
153
|
+
"Prepare for different scenarios (early finish, running long, technical difficulties)",
|
|
154
|
+
"Include personal anecdotes or case studies when appropriate"
|
|
155
|
+
],
|
|
156
|
+
"askForFiles": true,
|
|
157
|
+
"requireConfirmation": true,
|
|
158
|
+
"validationCriteria": [
|
|
159
|
+
{
|
|
160
|
+
"type": "regex",
|
|
161
|
+
"pattern": "(?i)##?\\s*Slide Content:?",
|
|
162
|
+
"message": "Content must include slide content section"
|
|
163
|
+
},
|
|
164
|
+
{
|
|
165
|
+
"type": "regex",
|
|
166
|
+
"pattern": "(?i)##?\\s*Speaker Notes:?",
|
|
167
|
+
"message": "Content must include speaker notes section"
|
|
168
|
+
},
|
|
169
|
+
{
|
|
170
|
+
"type": "length",
|
|
171
|
+
"min": 1000,
|
|
172
|
+
"message": "Content development should be at least 1000 characters for comprehensive coverage"
|
|
173
|
+
}
|
|
174
|
+
]
|
|
175
|
+
},
|
|
176
|
+
{
|
|
177
|
+
"id": "practice-and-timing",
|
|
178
|
+
"title": "Practice & Timing Optimization",
|
|
179
|
+
"prompt": "**PREP**: Develop a practice strategy to ensure confident, well-timed delivery.\n\n**IMPLEMENT**: Create a comprehensive practice plan:\n- **Run-Through Schedule**: Multiple practice sessions with increasing realism\n- **Timing Benchmarks**: Target time for each section with buffer zones\n- **Difficult Transitions**: Extra practice on challenging sections or technical demonstrations\n- **Q&A Preparation**: Anticipated questions with prepared responses\n- **Contingency Planning**: Backup plans for technical issues, timing problems, or unexpected situations\n- **Feedback Integration**: Plan for getting feedback and making final adjustments\n- **Confidence Building**: Techniques for managing nerves and maintaining energy\n\n**VERIFY**: Ensure you have a realistic practice schedule that will prepare you for confident delivery.",
|
|
180
|
+
"guidance": [
|
|
181
|
+
"Practice out loud - silent review is not enough",
|
|
182
|
+
"Time each section and the overall presentation",
|
|
183
|
+
"Practice with your actual slides and equipment when possible",
|
|
184
|
+
"Rehearse transitions between slides and topics"
|
|
185
|
+
],
|
|
186
|
+
"requireConfirmation": true,
|
|
187
|
+
"validationCriteria": [
|
|
188
|
+
{
|
|
189
|
+
"type": "regex",
|
|
190
|
+
"pattern": "(?i)##?\\s*Run-Through Schedule:?",
|
|
191
|
+
"message": "Practice plan must include run-through schedule"
|
|
192
|
+
},
|
|
193
|
+
{
|
|
194
|
+
"type": "regex",
|
|
195
|
+
"pattern": "(?i)##?\\s*Q&A Preparation:?",
|
|
196
|
+
"message": "Practice plan must include Q&A preparation"
|
|
197
|
+
},
|
|
198
|
+
{
|
|
199
|
+
"type": "length",
|
|
200
|
+
"min": 400,
|
|
201
|
+
"message": "Practice plan should be at least 400 characters for comprehensive preparation"
|
|
202
|
+
}
|
|
203
|
+
]
|
|
204
|
+
},
|
|
205
|
+
{
|
|
206
|
+
"id": "delivery-preparation-and-logistics",
|
|
207
|
+
"title": "Delivery Preparation & Logistics",
|
|
208
|
+
"prompt": "**PREP**: Finalize all logistical and technical aspects for smooth presentation delivery.\n\n**IMPLEMENT**: Complete pre-delivery checklist:\n- **Technical Setup**: Test all equipment, backup plans, file compatibility\n- **Materials Preparation**: Printed notes, handouts, business cards, feedback forms\n- **Venue Familiarization**: Room layout, microphone, lighting, seating arrangement\n- **Personal Preparation**: Wardrobe, arrival time, pre-presentation routine\n- **Follow-up Planning**: How to share slides, continue conversations, measure impact\n- **Emergency Protocols**: Contact information, backup equipment, alternative delivery methods\n- **Final Review**: Last-minute content updates, current examples, pronunciation check\n\n**VERIFY**: Confirm all logistical elements are in place and you have contingency plans for potential issues.",
|
|
209
|
+
"guidance": [
|
|
210
|
+
"Arrive early to test technology and get comfortable with the space",
|
|
211
|
+
"Have multiple backup options for critical technical components",
|
|
212
|
+
"Prepare a 'presentation day' checklist",
|
|
213
|
+
"Plan how you'll handle unexpected questions or technical difficulties"
|
|
214
|
+
],
|
|
215
|
+
"requireConfirmation": true,
|
|
216
|
+
"validationCriteria": [
|
|
217
|
+
{
|
|
218
|
+
"type": "regex",
|
|
219
|
+
"pattern": "(?i)##?\\s*Technical Setup:?",
|
|
220
|
+
"message": "Preparation must include technical setup section"
|
|
221
|
+
},
|
|
222
|
+
{
|
|
223
|
+
"type": "regex",
|
|
224
|
+
"pattern": "(?i)##?\\s*Follow-up Planning:?",
|
|
225
|
+
"message": "Preparation must include follow-up planning"
|
|
226
|
+
},
|
|
227
|
+
{
|
|
228
|
+
"type": "length",
|
|
229
|
+
"min": 300,
|
|
230
|
+
"message": "Delivery preparation should be at least 300 characters for comprehensive planning"
|
|
231
|
+
}
|
|
232
|
+
]
|
|
233
|
+
}
|
|
234
|
+
],
|
|
235
|
+
"metaGuidance": [
|
|
236
|
+
"Focus on your audience's needs and interests throughout the entire process",
|
|
237
|
+
"Prioritize clarity over complexity - your audience should easily follow your logic",
|
|
238
|
+
"Build in engagement opportunities to maintain attention and encourage participation",
|
|
239
|
+
"Practice storytelling techniques to make your content memorable and relatable",
|
|
240
|
+
"Plan for different learning styles and attention spans in your audience",
|
|
241
|
+
"Always have a clear call-to-action that tells your audience what to do next",
|
|
242
|
+
"Test all technical elements well before your presentation",
|
|
243
|
+
"Prepare for the unexpected - have backup plans for common presentation challenges"
|
|
244
|
+
]
|
|
245
|
+
}
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
{
|
|
2
|
+
"id": "workflow-for-workflows",
|
|
3
|
+
"name": "Workflow for Creating New Workflows",
|
|
4
|
+
"version": "0.0.1",
|
|
5
|
+
"description": "A meta-workflow to guide the creation, validation, and deployment of new, reusable workflow templates.",
|
|
6
|
+
"preconditions": [
|
|
7
|
+
"User has a clear idea of the recurring task or problem the new workflow should solve.",
|
|
8
|
+
"The 'workflow-lookup' MCP server is running and accessible.",
|
|
9
|
+
"The agent has access to 'create_file', 'edit_file', and 'run_terminal_cmd' tools."
|
|
10
|
+
],
|
|
11
|
+
"metaGuidance": [
|
|
12
|
+
"The goal is to create a *reusable template*, not a single-use script. Use placeholders like [User provides X] where appropriate.",
|
|
13
|
+
"Prompts should define goals and roles for the agent, not a rigid script. This allows the agent to use its intelligence to best achieve the task.",
|
|
14
|
+
"At each step, the agent should confirm with the user before proceeding with a file modification or command.",
|
|
15
|
+
"Maintain a clear distinction between the workflow being created and this meta-workflow.",
|
|
16
|
+
"Save progress frequently by confirming file edits."
|
|
17
|
+
],
|
|
18
|
+
"steps": [
|
|
19
|
+
{
|
|
20
|
+
"id": "phase-1-discovery",
|
|
21
|
+
"title": "Phase 1: Assisted Discovery & Ideation",
|
|
22
|
+
"prompt": "We will begin by defining the problem with data and finding a suitable template.\n\n**1. Define the Goal (User's Role):**\n - Please state your initial hypothesis for the problem this workflow solves and its primary failure mode.\n\n**2. Guided Data Gathering (Agent's Goal):**\n - Your goal is to help the user validate their hypothesis. Prompt them to use their tools (`grep`, `git log`, etc.) to find evidence. Ask for things like:\n - Key excerpts from bug reports or incident post-mortems.\n - Common themes in PR review comments.\n - Examples of 'TODO' or 'HACK' comments in the relevant codebase.\n\n**3. Synthesize & Find Template (Agent's Goal):**\n - Your goal is to synthesize the gathered data into a refined problem statement.\n - Once the problem is clear, find the most suitable existing workflow to use as a template by using `workflow_list` and `workflow_get`.",
|
|
23
|
+
"guidance": [
|
|
24
|
+
"Focus on finding the root cause of the problem, not just the symptoms.",
|
|
25
|
+
"A good template is one that solves a problem of similar *structure*, even if the domain is different."
|
|
26
|
+
]
|
|
27
|
+
},
|
|
28
|
+
{
|
|
29
|
+
"id": "phase-2-authoring",
|
|
30
|
+
"title": "Phase 2: Structured Authoring & Drafting",
|
|
31
|
+
"prompt": "Now we will create the first draft of the new workflow file.\n\n**1. Create the File (Agent's Goal):**\n - Ask the user for a filename for the new workflow (e.g., `my-new-workflow.json`).\n - Use the `create_file` tool to create this file, using the template JSON from Phase 1 as the initial content.\n\n**2. Iterative Drafting (Collaborative Task):**\n - Guide the user through the JSON structure in a specific order: `id`, `name`, `version`, `description`, `preconditions`, `metaGuidance`, and finally the `steps`.\n - For each section, the user will provide the high-level content, and your goal as the agent is to translate it into correctly formatted JSON and use the `edit_file` tool to update the file.",
|
|
32
|
+
"guidance": [
|
|
33
|
+
"When writing prompts, use clear placeholders like `[User provides X]` to indicate where customization is needed.",
|
|
34
|
+
"Remember: `metaGuidance` is for global rules, while step `prompts` are for specific actions."
|
|
35
|
+
]
|
|
36
|
+
},
|
|
37
|
+
{
|
|
38
|
+
"id": "phase-3-validation",
|
|
39
|
+
"title": "Phase 3: Syntactic & Structural Validation",
|
|
40
|
+
"prompt": "The first draft is complete. Now, we must ensure it is technically valid.\n\n**1. Run Validation (Agent's Goal):**\n - Your goal is to validate the new workflow file. Announce your plan to use the `run_terminal_cmd` tool to execute `workflow-lookup validate [filename]`.\n\n**2. Analyze & Fix (Agent's Goal):**\n - If validation fails, your goal is to fix it. Parse the error, explain the issue, propose a fix, and use `edit_file` to correct it. Repeat until validation passes.",
|
|
41
|
+
"guidance": [
|
|
42
|
+
"Validation errors are expected on the first run. Treat them as a checklist, not a failure.",
|
|
43
|
+
"Fix one error at a time and re-run validation to avoid introducing new issues."
|
|
44
|
+
]
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": "phase-4-refinement",
|
|
48
|
+
"title": "Phase 4: Structured Red-Teaming",
|
|
49
|
+
"prompt": "The workflow is now technically valid. Next, we will rigorously test its logic against multiple personas.\n\n**1. Select a Step (User's Role):**\n - Please choose a critical step from the new workflow to test.\n\n**2. Structured Simulation (Agent's Goal):**\n - Your goal is to analyze the selected prompt from the following three perspectives:\n - **The Novice Persona:** Is there jargon or assumed knowledge that would confuse a newcomer?\n - **The Rushed Expert Persona:** How could a busy expert misinterpret or shortcut this step? Can it be made more concise?\n - **The Adversarial LLM Persona:** What ambiguity could be exploited to produce a plausible but incorrect result?\n - For each persona, provide your findings and suggest specific revisions. Use `edit_file` to implement approved changes.",
|
|
50
|
+
"guidance": [
|
|
51
|
+
"When simulating personas, be critical. The goal is to find flaws now so that users don't find them later.",
|
|
52
|
+
"Focus on clarity and ambiguity. If a prompt *can* be misinterpreted, assume it *will* be."
|
|
53
|
+
]
|
|
54
|
+
},
|
|
55
|
+
{
|
|
56
|
+
"id": "phase-5-deployment",
|
|
57
|
+
"title": "Phase 5: Finalization & Deployment",
|
|
58
|
+
"prompt": "The workflow has been drafted, validated, and refined. It is ready for deployment.\n\n**1. Final Review (Collaborative Task):**\n - Let's perform a final review of the workflow's `name` and `description` to ensure they are clear and easily discoverable.\n\n**2. Deploy (Agent's Goal):**\n - Once final approval is given, your goal is to move the workflow file into the primary `workflows/` directory. Announce your plan to use the `run_terminal_cmd` tool with the `mv` command to accomplish this.",
|
|
59
|
+
"guidance": [
|
|
60
|
+
"The `name` and `description` are how others will discover this workflow. Make them descriptive and concise.",
|
|
61
|
+
"Before moving the file, do a final `ls` to confirm the target directory exists."
|
|
62
|
+
]
|
|
63
|
+
},
|
|
64
|
+
{
|
|
65
|
+
"id": "phase-6-feedback-loop",
|
|
66
|
+
"title": "Phase 6: Establishing a Continuous Improvement Loop",
|
|
67
|
+
"prompt": "A great workflow evolves. Let's create a mechanism for future feedback.\n\n**1. Create Feedback File (Agent's Goal):**\n - Your goal is to create a companion feedback file. Announce your plan to use `create_file` to create a file named `[workflow-id].feedback.md` in a `workflow-feedback/` directory.\n\n**2. Populate Feedback Template (Agent's Goal):**\n - Use `edit_file` to add a basic feedback template to the new file, including sections for 'Success Stories', 'Pain Points', and 'Suggestions for Improvement'.\n\n**3. Link to Feedback (Agent's Goal):**\n - Announce your plan to add a new `metaGuidance` entry to the *workflow we just created*. The guidance should say: 'After using this workflow, please record your experience in `workflow-feedback/[workflow-id].feedback.md`.' Use `edit_file` to add this.",
|
|
68
|
+
"guidance": [
|
|
69
|
+
"Ensure the feedback filename (`[workflow-id].feedback.md`) exactly matches the workflow's `id` for easy association.",
|
|
70
|
+
"The link in the `metaGuidance` should be a relative path to ensure it works for all users."
|
|
71
|
+
]
|
|
72
|
+
}
|
|
73
|
+
]
|
|
74
|
+
}
|