@exaudeus/workrail 3.12.0 → 3.13.0
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/dist/console/assets/{index-CRgjJiMS.js → index-EsSXrC_a.js} +11 -11
- package/dist/console/index.html +1 -1
- package/dist/di/container.js +8 -0
- package/dist/di/tokens.d.ts +1 -0
- package/dist/di/tokens.js +1 -0
- package/dist/infrastructure/session/HttpServer.js +2 -14
- package/dist/manifest.json +83 -43
- package/dist/mcp/boundary-coercion.d.ts +2 -0
- package/dist/mcp/boundary-coercion.js +73 -0
- package/dist/mcp/handler-factory.d.ts +1 -1
- package/dist/mcp/handler-factory.js +13 -6
- package/dist/mcp/handlers/v2-manage-workflow-source.d.ts +7 -0
- package/dist/mcp/handlers/v2-manage-workflow-source.js +50 -0
- package/dist/mcp/server.js +2 -0
- package/dist/mcp/tool-descriptions.js +20 -0
- package/dist/mcp/tools.js +6 -0
- package/dist/mcp/types/tool-description-types.d.ts +1 -1
- package/dist/mcp/types/tool-description-types.js +1 -0
- package/dist/mcp/types/workflow-tool-edition.d.ts +1 -1
- package/dist/mcp/types.d.ts +2 -0
- package/dist/mcp/v2/tool-registry.js +8 -0
- package/dist/mcp/v2/tools.d.ts +12 -0
- package/dist/mcp/v2/tools.js +7 -1
- package/dist/v2/infra/in-memory/managed-source-store/index.d.ts +8 -0
- package/dist/v2/infra/in-memory/managed-source-store/index.js +33 -0
- package/dist/v2/infra/local/data-dir/index.d.ts +2 -0
- package/dist/v2/infra/local/data-dir/index.js +6 -0
- package/dist/v2/infra/local/managed-source-store/index.d.ts +15 -0
- package/dist/v2/infra/local/managed-source-store/index.js +164 -0
- package/dist/v2/ports/data-dir.port.d.ts +2 -0
- package/dist/v2/ports/managed-source-store.port.d.ts +25 -0
- package/dist/v2/ports/managed-source-store.port.js +2 -0
- package/package.json +1 -1
- package/workflows/adaptive-ticket-creation.json +276 -282
- package/workflows/document-creation-workflow.json +70 -191
- package/workflows/documentation-update-workflow.json +59 -309
- package/workflows/intelligent-test-case-generation.json +37 -212
- package/workflows/personal-learning-materials-creation-branched.json +1 -21
- package/workflows/presentation-creation.json +143 -308
- package/workflows/relocation-workflow-us.json +161 -535
- package/workflows/scoped-documentation-workflow.json +110 -181
- package/workflows/workflow-for-workflows.v2.json +21 -5
- package/workflows/CHANGELOG-bug-investigation.md +0 -298
- package/workflows/bug-investigation.agentic.json +0 -212
- package/workflows/bug-investigation.json +0 -112
- package/workflows/mr-review-workflow.agentic.json +0 -538
- package/workflows/mr-review-workflow.json +0 -277
|
@@ -1,235 +1,114 @@
|
|
|
1
1
|
{
|
|
2
2
|
"id": "document-creation-workflow",
|
|
3
3
|
"name": "Document Creation Workflow",
|
|
4
|
-
"version": "0.0
|
|
5
|
-
"description": "Create
|
|
6
|
-
"clarificationPrompts": [
|
|
7
|
-
"What type of document do you need? (README, API documentation, user guide, technical specification, or custom)",
|
|
8
|
-
"What's the document's purpose and target audience?",
|
|
9
|
-
"Do you have existing documentation that should inform style/structure?",
|
|
10
|
-
"What's your automation preference? (High: auto-approve low-risk decisions, Medium: standard confirmations, Low: extra safety checks)",
|
|
11
|
-
"Are there specific constraints, templates, or organizational standards to follow?"
|
|
12
|
-
],
|
|
4
|
+
"version": "1.0.0",
|
|
5
|
+
"description": "Create broad or comprehensive documentation spanning multiple components or systems. Suited for project READMEs, complete API documentation, user guides covering multiple features, and technical specifications. Uses complexity triage (Simple/Standard/Complex) to adapt rigor. For single, bounded subjects (one class, one integration), use scoped-documentation-workflow instead.",
|
|
13
6
|
"preconditions": [
|
|
14
|
-
"User has a clear idea of the document type and purpose",
|
|
15
|
-
"Relevant project files or information are available for reference",
|
|
16
|
-
"Agent has access to file reading, editing, and analysis tools",
|
|
17
|
-
"Git repository recommended for version control (workflow degrades gracefully if unavailable)"
|
|
7
|
+
"User has a clear idea of the document type and purpose.",
|
|
8
|
+
"Relevant project files or information are available for reference.",
|
|
9
|
+
"Agent has access to file reading, editing, and analysis tools.",
|
|
10
|
+
"Git repository recommended for version control (workflow degrades gracefully if unavailable)."
|
|
18
11
|
],
|
|
19
12
|
"metaGuidance": [
|
|
20
|
-
"
|
|
21
|
-
"
|
|
22
|
-
"
|
|
23
|
-
"
|
|
24
|
-
"
|
|
25
|
-
"Deep project analysis informs documentation style, structure, and content accuracy.",
|
|
26
|
-
"Validation criteria ensure output quality and completeness before finalization.",
|
|
27
|
-
"Devil's advocate review strengthens content through systematic critique.",
|
|
28
|
-
"Tool integration leverages codebase analysis, existing documentation discovery, and automated operations."
|
|
13
|
+
"NOTES-FIRST DURABILITY: use output.notesMarkdown as the primary durable record. Do NOT create CONTEXT.md, doc_spec.md, or content_plan.md as workflow memory.",
|
|
14
|
+
"DISCOVER BEFORE ASKING: use tools to explore the project before asking clarification questions. Only ask what tools cannot answer.",
|
|
15
|
+
"COMPLEXITY DRIVES BRANCHING: docComplexity=Simple uses the fast path; Standard/Complex uses the full path. If complexity changes during work, note it in notesMarkdown and adapt — no retriage ceremony needed.",
|
|
16
|
+
"CONTENT-FIRST: the deliverable is the document, not planning artifacts. Keep planning proportional to scope.",
|
|
17
|
+
"EVIDENCE-BASED QUALITY: each quality dimension in the review step requires a one-sentence evidence statement and a pass or needs-work verdict — not a numeric score."
|
|
29
18
|
],
|
|
30
19
|
"steps": [
|
|
31
20
|
{
|
|
32
|
-
"id": "phase-0-
|
|
33
|
-
"title": "Phase 0:
|
|
34
|
-
"prompt": "
|
|
35
|
-
"
|
|
36
|
-
|
|
37
|
-
"
|
|
38
|
-
|
|
39
|
-
"When uncertain, err toward higher complexity for better quality",
|
|
40
|
-
"Automation levels: High=auto-approve confidence >8, Medium=standard, Low=extra confirmations"
|
|
41
|
-
],
|
|
42
|
-
"requireConfirmation": true
|
|
21
|
+
"id": "phase-0-triage",
|
|
22
|
+
"title": "Phase 0: Triage and Classify",
|
|
23
|
+
"prompt": "Analyze this documentation request and classify its complexity.\n\n**Simple** indicators:\n- Single document type with clear requirements\n- Straightforward content (basic README, simple user guide)\n- Existing templates or examples available\n- Minimal research needed\n\n**Standard** indicators:\n- Moderate complexity documentation\n- Some codebase or system analysis required\n- Multiple sections or integration points\n- Standard business documentation needs\n\n**Complex** indicators:\n- Comprehensive technical documentation\n- Requires deep system analysis\n- Multiple stakeholders or use cases\n- Integration with an existing documentation ecosystem\n- Custom or specialized documentation needs\n\nIf uncertain, classify upward.\n\nCapture:\n- `docComplexity`: Simple / Standard / Complex",
|
|
24
|
+
"requireConfirmation": {
|
|
25
|
+
"var": "docComplexity",
|
|
26
|
+
"equals": "Complex"
|
|
27
|
+
}
|
|
43
28
|
},
|
|
44
29
|
{
|
|
45
|
-
"id": "phase-1-
|
|
30
|
+
"id": "phase-1-analyze",
|
|
31
|
+
"title": "Phase 1: Project Analysis",
|
|
46
32
|
"runCondition": {
|
|
47
33
|
"or": [
|
|
48
|
-
{"var": "docComplexity", "equals": "Standard"},
|
|
49
|
-
{"var": "docComplexity", "equals": "Complex"}
|
|
34
|
+
{ "var": "docComplexity", "equals": "Standard" },
|
|
35
|
+
{ "var": "docComplexity", "equals": "Complex" }
|
|
50
36
|
]
|
|
51
37
|
},
|
|
52
|
-
"
|
|
53
|
-
"prompt": "**SYSTEMATIC PROJECT INVESTIGATION** - Analyze the project to inform documentation strategy.\n\n**ANALYSIS BOUNDS: Limit output to 1500 words; prioritize documentation-relevant insights.**\n\n**Your analysis must include:**\n1. **Existing Documentation Landscape**: Current docs, style patterns, gaps\n2. **Project Architecture**: Key components relevant to documentation\n3. **User/Developer Workflows**: How documentation fits into user journeys\n4. **Technical Constraints**: APIs, systems, integrations to document\n5. **Style Conventions**: Existing patterns for consistency\n6. **Content Sources**: Code comments, READMEs, specs to reference\n7. **Audience Analysis**: Who will use this documentation and how\n8. **Complexity Indicators**: Factors that might affect initial assessment\n\nThis analysis will inform all subsequent requirements gathering, content planning, and quality standards.",
|
|
54
|
-
"agentRole": "You are an expert documentation analyst specializing in understanding project ecosystems and documentation needs. Your expertise lies in quickly assessing technical landscapes and identifying optimal documentation strategies.",
|
|
55
|
-
"askForFiles": true,
|
|
56
|
-
"guidance": [
|
|
57
|
-
"Focus on documentation-relevant aspects of the project",
|
|
58
|
-
"Identify existing patterns and standards to maintain consistency",
|
|
59
|
-
"Note any discoveries that might warrant complexity re-assessment",
|
|
60
|
-
"Use tools to explore codebase, existing docs, and project structure"
|
|
61
|
-
],
|
|
38
|
+
"prompt": "Analyze the project to inform documentation strategy. Limit this analysis to 1500 words; prioritize documentation-relevant insights.\n\nCover:\n1. **Existing documentation landscape** — current docs, style patterns, gaps\n2. **Project architecture** — key components relevant to this document\n3. **User or developer workflows** — how documentation fits into user journeys\n4. **Technical constraints** — APIs, systems, integrations to document\n5. **Style conventions** — terminology, formatting, naming patterns to follow\n6. **Audience** — who will use this documentation and what they need to accomplish\n\nNote any complexity indicators that might warrant reclassifying `docComplexity` upward.",
|
|
62
39
|
"requireConfirmation": false
|
|
63
40
|
},
|
|
64
41
|
{
|
|
65
|
-
"id": "phase-2-requirements
|
|
66
|
-
"
|
|
67
|
-
"
|
|
68
|
-
"prompt": "Based on your project analysis, ask intelligent, targeted questions to clarify documentation requirements:\n\n**Technical Clarifications:**\n- Content scope and depth based on discovered architecture\n- Integration with existing documentation systems\n- Specific technical details to include/exclude\n- Audience-specific customization needs\n\n**Quality Standards:**\n- Validation criteria and acceptance requirements\n- Review processes and stakeholder approvals\n- Maintenance and update responsibilities\n\n**Operational Considerations:**\n- Documentation toolchain and publishing workflow\n- Version control and change management\n- Timeline and milestone requirements\n\n**Present 3-7 specific questions that will significantly improve documentation quality and implementability.**",
|
|
69
|
-
"agentRole": "You are a senior documentation consultant specializing in requirements elicitation. Your expertise lies in translating project understanding into precise documentation requirements that eliminate ambiguity.",
|
|
70
|
-
"guidance": [
|
|
71
|
-
"Ask questions that could only be formulated after understanding the project",
|
|
72
|
-
"Focus on clarifications that significantly impact content and structure",
|
|
73
|
-
"Address both technical content and operational requirements",
|
|
74
|
-
"Consider validation and maintenance aspects"
|
|
75
|
-
],
|
|
76
|
-
"requireConfirmation": {
|
|
42
|
+
"id": "phase-2-requirements",
|
|
43
|
+
"title": "Phase 2: Targeted Requirements",
|
|
44
|
+
"runCondition": {
|
|
77
45
|
"or": [
|
|
78
|
-
{"var": "
|
|
79
|
-
{"var": "
|
|
46
|
+
{ "var": "docComplexity", "equals": "Standard" },
|
|
47
|
+
{ "var": "docComplexity", "equals": "Complex" }
|
|
80
48
|
]
|
|
81
|
-
}
|
|
49
|
+
},
|
|
50
|
+
"prompt": "Based on your project analysis, ask 2 to 4 targeted questions that you genuinely cannot answer from the codebase or project files.\n\nFocus on clarifications that materially affect content or structure:\n- Specific scope boundaries (what to include or exclude)\n- Audience-specific requirements not evident from the code\n- Constraints, templates, or organizational standards to follow\n- Integration requirements with existing documentation systems\n\nDo not ask questions the analysis already answered.",
|
|
51
|
+
"requireConfirmation": false
|
|
82
52
|
},
|
|
83
53
|
{
|
|
84
|
-
"id": "phase-
|
|
85
|
-
"
|
|
86
|
-
"
|
|
87
|
-
"prompt": "Based on project analysis and requirements clarification, re-evaluate the initial complexity classification:\n\n**EVALUATE:**\n1. Review original `docComplexity` classification\n2. Consider new insights from project analysis and clarifications\n3. Assess if complexity should be upgraded or downgraded\n\n**If recommending complexity upgrade:**\n- Explain what discoveries led to this recommendation\n- Describe additional complexity or risk factors\n- Request user confirmation to change `docComplexity`\n\n**If recommending complexity downgrade:**\n- Set `proposedDowngrade` context variable to true\n- Explain what simplifies the documentation task\n- Provide evidence of reduced scope/complexity\n- Require confirmation unless automationLevel=High and confidence >8\n\n**If classification remains appropriate:**\n- Briefly confirm assessment is still accurate\n- Proceed without changes\n\n**Both upgrades and downgrades allowed with proper justification.**",
|
|
88
|
-
"agentRole": "You are a technical risk assessor specializing in documentation complexity evaluation. Your expertise lies in identifying complexity factors that emerge during analysis phases and ensuring optimal workflow rigor.",
|
|
89
|
-
"guidance": [
|
|
90
|
-
"Only change complexity with clear, justifiable reasons",
|
|
91
|
-
"For downgrades, require explicit approval unless high automation and confidence",
|
|
92
|
-
"Document reasoning for any complexity changes",
|
|
93
|
-
"Reset proposedDowngrade flag after user decision"
|
|
94
|
-
],
|
|
95
|
-
"requireConfirmation": {
|
|
54
|
+
"id": "phase-3-plan",
|
|
55
|
+
"title": "Phase 3: Content Plan",
|
|
56
|
+
"runCondition": {
|
|
96
57
|
"or": [
|
|
97
|
-
{"var": "
|
|
98
|
-
{"var": "
|
|
99
|
-
{"var": "proposedDowngrade", "equals": true}
|
|
58
|
+
{ "var": "docComplexity", "equals": "Standard" },
|
|
59
|
+
{ "var": "docComplexity", "equals": "Complex" }
|
|
100
60
|
]
|
|
101
|
-
}
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
"guidance": [
|
|
110
|
-
"Create actionable specification that drives implementation",
|
|
111
|
-
"Incorporate all project analysis insights and clarifications",
|
|
112
|
-
"Define clear quality standards and success metrics",
|
|
113
|
-
"Consider integration with existing documentation ecosystem"
|
|
114
|
-
],
|
|
115
|
-
"requireConfirmation": false
|
|
116
|
-
},
|
|
117
|
-
{
|
|
118
|
-
"id": "phase-3b-context-documentation",
|
|
119
|
-
"runCondition": {"var": "docComplexity", "not_equals": "Simple"},
|
|
120
|
-
"title": "Phase 3b: Create Context Documentation",
|
|
121
|
-
"prompt": "Create comprehensive context documentation (`CONTEXT.md`) for workflow continuity:\n\n**For automationLevel=High: limit 1000 words; otherwise full documentation (limit 2000 words).**\n\n## 1. ORIGINAL REQUEST CONTEXT\n- Document type and requirements\n- Complexity classification and reasoning\n- Automation level and implications\n\n## 2. PROJECT ANALYSIS SUMMARY\n- Key architectural patterns and documentation standards\n- Existing documentation landscape and gaps\n- Relevant technical components and workflows\n- Style conventions and quality standards\n\n## 3. REQUIREMENTS & CLARIFICATIONS\n- Questions asked and answers received\n- Scope boundaries and constraints\n- Quality standards and validation criteria\n\n## 4. SPECIFICATION SUMMARY\n- Core objectives and success criteria\n- Content architecture and structure\n- Integration and maintenance requirements\n\n## 5. WORKFLOW PROGRESS\n- ✅ Completed phases (0, 1, 2, 2b, 3, 3b)\n- 🔄 Current: Content Planning (Phase 4)\n- ⏳ Remaining: 4, 5, 6, 7, 8\n- 📋 Context variables: docComplexity, automationLevel, etc.\n\n## 6. HANDOFF INSTRUCTIONS\n- Files to attach when resuming\n- Critical decisions and constraints\n- Next phase requirements",
|
|
122
|
-
"agentRole": "You are a meticulous documentation specialist focused on comprehensive project handoff documentation. Your expertise lies in capturing all critical context for seamless workflow continuation.",
|
|
123
|
-
"guidance": [
|
|
124
|
-
"Enable seamless handoff to new agent/session",
|
|
125
|
-
"Include specific technical details and decisions",
|
|
126
|
-
"Reference all key files and project insights",
|
|
127
|
-
"Make progress tracking very clear for continuation"
|
|
128
|
-
],
|
|
129
|
-
"requireConfirmation": false
|
|
130
|
-
},
|
|
131
|
-
{
|
|
132
|
-
"id": "phase-4-content-planning",
|
|
133
|
-
"runCondition": {"var": "docComplexity", "not_equals": "Simple"},
|
|
134
|
-
"title": "Phase 4: Content Planning & Architecture",
|
|
135
|
-
"prompt": "Create detailed content plan based on the specification:\n\n**Content Plan (`content_plan.md`):**\n1. **Information Architecture**: Detailed outline with sections, subsections\n2. **Content Sources**: Where information will come from (code, specs, interviews)\n3. **Writing Strategy**: Tone, style, technical depth for target audience\n4. **Visual Elements**: Diagrams, screenshots, code examples needed\n5. **Quality Assurance**: Review checkpoints and validation criteria\n6. **Dependencies**: External inputs or approvals required\n\n**The plan must:**\n- Follow specification requirements precisely\n- Leverage project analysis insights\n- Address all identified audience needs\n- Include measurable completion criteria\n\nOutput content plan; use edit_file tool to create `content_plan.md`.",
|
|
136
|
-
"agentRole": "You are a content strategy expert specializing in technical documentation planning. Your expertise lies in creating detailed, actionable content plans that ensure high-quality documentation delivery.",
|
|
137
|
-
"guidance": [
|
|
138
|
-
"Create implementable plan with clear action items",
|
|
139
|
-
"Reference specification and project analysis throughout",
|
|
140
|
-
"Include quality checkpoints and validation steps",
|
|
141
|
-
"Consider visual elements and technical examples"
|
|
61
|
+
},
|
|
62
|
+
"prompt": "Create a content plan for this documentation in your notes.\n\nThe plan should cover:\n1. Document purpose and success criteria\n2. Target audience and their primary goals\n3. Section outline with one-line descriptions\n4. Writing strategy — tone, technical depth, key terminology\n5. Visual elements or code examples needed\n\nKeep the plan proportional to scope. The goal is a clear outline to execute against, not a heavyweight specification.",
|
|
63
|
+
"promptFragments": [
|
|
64
|
+
{
|
|
65
|
+
"id": "phase-3-plan-complex",
|
|
66
|
+
"when": { "var": "docComplexity", "equals": "Complex" },
|
|
67
|
+
"text": "For Complex documentation, also include: integration strategy (how this doc connects to the existing documentation ecosystem), maintenance ownership, and any stakeholder review requirements."
|
|
68
|
+
}
|
|
142
69
|
],
|
|
143
70
|
"requireConfirmation": false
|
|
144
71
|
},
|
|
145
72
|
{
|
|
146
|
-
"id": "phase-
|
|
147
|
-
"title": "Phase
|
|
148
|
-
"prompt": "
|
|
149
|
-
"agentRole": "You are a meticulous technical writer focused on high-quality content creation. Your approach emphasizes systematic execution, quality verification, and thorough documentation of progress.",
|
|
150
|
-
"guidance": [
|
|
151
|
-
"Follow content plan precisely while maintaining quality standards",
|
|
152
|
-
"Use project analysis insights to inform content accuracy",
|
|
153
|
-
"Commit regularly for version control and progress tracking",
|
|
154
|
-
"Update context documentation for workflow continuity"
|
|
155
|
-
],
|
|
73
|
+
"id": "phase-4-create",
|
|
74
|
+
"title": "Phase 4: Content Creation",
|
|
75
|
+
"prompt": "Write the documentation following your content plan.\n\nBefore writing, check for any templates or existing documentation patterns to follow.\n\nWork section by section. After each major section:\n- Verify accuracy against actual project files or code\n- Ensure consistency with established style and terminology\n\n**Git integration** (if git is available):\n- Create a feature branch: `git checkout -b docs/[document-type]-[brief-description]`\n- Capture the branch name as `featureBranch`\n- Commit after completing major sections: `docs([type]): [section description]`\n- If git is unavailable, proceed without it\n\nKeep writing until all planned sections are complete.",
|
|
156
76
|
"requireConfirmation": false
|
|
157
77
|
},
|
|
158
78
|
{
|
|
159
|
-
"id": "phase-
|
|
160
|
-
"
|
|
161
|
-
"
|
|
162
|
-
"prompt": "Perform rigorous critique of the created documentation to strengthen quality:\n\n**Analyze the documentation through these lenses:**\n\n1. **Accuracy & Completeness**: Are there gaps, inaccuracies, or missing critical information?\n2. **Audience Alignment**: Does it truly serve the target audience's needs and skill level?\n3. **Clarity & Usability**: Could users actually accomplish their goals with this documentation?\n4. **Consistency & Standards**: Does it maintain consistency with project conventions?\n5. **Maintenance Burden**: Is it structured for easy updates and long-term maintenance?\n\n**For each critique point, provide:**\n- Specific evidence from the documentation\n- Concrete suggestions for improvement\n- Assessment of impact severity\n\n**Conclude with:**\n- Balanced summary of strengths and weaknesses\n- Prioritized improvement recommendations\n- **Set `qualityScore` variable (1-10)** for documentation quality\n\n**CRITICAL**: All critique must be evidence-based with specific citations.",
|
|
163
|
-
"agentRole": "You are a skeptical but constructive senior documentation reviewer with expertise in technical communication. Your role is to identify weaknesses and improvement opportunities while recognizing strengths.",
|
|
164
|
-
"guidance": [
|
|
165
|
-
"Focus on substantive quality issues, not minor style preferences",
|
|
166
|
-
"Provide actionable improvement suggestions with clear reasoning",
|
|
167
|
-
"Balance critique with recognition of strong elements",
|
|
168
|
-
"Set qualityScore variable for automation decisions"
|
|
169
|
-
],
|
|
170
|
-
"requireConfirmation": {
|
|
79
|
+
"id": "phase-5-quality-review",
|
|
80
|
+
"title": "Phase 5: Quality Review",
|
|
81
|
+
"runCondition": {
|
|
171
82
|
"or": [
|
|
172
|
-
{"var": "
|
|
173
|
-
{"var": "
|
|
174
|
-
{"and": [
|
|
175
|
-
{"var": "automationLevel", "equals": "High"},
|
|
176
|
-
{"var": "qualityScore", "lt": 8}
|
|
177
|
-
]}
|
|
83
|
+
{ "var": "docComplexity", "equals": "Standard" },
|
|
84
|
+
{ "var": "docComplexity", "equals": "Complex" }
|
|
178
85
|
]
|
|
179
86
|
},
|
|
180
|
-
"
|
|
87
|
+
"prompt": "Review the documentation you just wrote using this rubric. For each dimension, provide a one-sentence evidence statement and a verdict of `pass` or `needs-work`.\n\n1. **Accuracy** — Does the content correctly describe the actual project or system? *(Evidence: cite one verified fact.)*\n2. **Completeness** — Does it cover all planned sections? *(Evidence: list planned vs completed sections.)*\n3. **Audience fit** — Is the technical depth right for the target reader? *(Evidence: identify one audience-appropriate choice made.)*\n4. **Usability** — Could a reader actually accomplish their goal using this doc? *(Evidence: trace one user journey through the doc.)*\n5. **Consistency** — Does it match project conventions for style, terminology, and format? *(Evidence: cite one convention followed.)*\n\nIf any dimension is `needs-work`, fix the issue immediately and re-assert the dimension as `pass` in your notes before continuing.",
|
|
88
|
+
"promptFragments": [
|
|
181
89
|
{
|
|
182
|
-
"
|
|
183
|
-
"
|
|
184
|
-
"
|
|
185
|
-
},
|
|
186
|
-
{
|
|
187
|
-
"type": "regex",
|
|
188
|
-
"pattern": "(accuracy|completeness|clarity|consistency|maintenance)",
|
|
189
|
-
"message": "Must address key quality dimensions in the review"
|
|
90
|
+
"id": "phase-5-quality-review-complex",
|
|
91
|
+
"when": { "var": "docComplexity", "equals": "Complex" },
|
|
92
|
+
"text": "Also review a sixth dimension:\n6. **Integration coherence** — Does the doc integrate correctly with the existing documentation ecosystem? *(Evidence: describe how it cross-links or relates to existing docs.)*"
|
|
190
93
|
}
|
|
191
94
|
],
|
|
192
|
-
"
|
|
95
|
+
"requireConfirmation": false
|
|
193
96
|
},
|
|
194
97
|
{
|
|
195
|
-
"id": "phase-
|
|
196
|
-
"title": "Phase
|
|
197
|
-
"prompt": "
|
|
198
|
-
"
|
|
199
|
-
"guidance": [
|
|
200
|
-
"Ensure all specification requirements are fully met",
|
|
201
|
-
"Complete git workflow properly with appropriate commit messages",
|
|
202
|
-
"Provide comprehensive delivery documentation for maintainers",
|
|
203
|
-
"Include quantitative quality metrics in final summary"
|
|
204
|
-
],
|
|
205
|
-
"requireConfirmation": true,
|
|
206
|
-
"validationCriteria": [
|
|
207
|
-
{
|
|
208
|
-
"type": "contains",
|
|
209
|
-
"value": "final",
|
|
210
|
-
"message": "Must include final documentation delivery"
|
|
211
|
-
},
|
|
212
|
-
{
|
|
213
|
-
"type": "length",
|
|
214
|
-
"min": 200,
|
|
215
|
-
"message": "Delivery summary must be comprehensive (at least 200 characters)"
|
|
216
|
-
}
|
|
217
|
-
],
|
|
218
|
-
"hasValidation": true
|
|
98
|
+
"id": "phase-6-finalize",
|
|
99
|
+
"title": "Phase 6: Finalize and Deliver",
|
|
100
|
+
"prompt": "Save the final documentation with an appropriate filename:\n- `README.md` for project documentation\n- `API.md` for API documentation\n- `UserGuide.md` for user guides\n- `TechnicalSpec.md` for technical specifications\n- A descriptive name for other types\n\n**Git finalization** (if a feature branch was created):\n- Final commit: `docs(complete): [document type] documentation`\n- Merge: `git checkout main && git merge --squash {{featureBranch}}`\n- Cleanup: `git branch -d {{featureBranch}}`\n\nProvide a delivery summary covering:\n- What was created and who it serves\n- Quality review results (all dimensions passed)\n- Maintenance recommendations\n- Any follow-up documentation needs",
|
|
101
|
+
"requireConfirmation": true
|
|
219
102
|
},
|
|
220
103
|
{
|
|
221
|
-
"id": "phase-simple-
|
|
222
|
-
"
|
|
223
|
-
"
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
"Use established patterns and templates when available",
|
|
229
|
-
"Escalate to higher complexity if needed rather than compromise quality",
|
|
230
|
-
"Maintain quality standards despite streamlined process"
|
|
231
|
-
],
|
|
104
|
+
"id": "phase-simple-create",
|
|
105
|
+
"title": "Phase Simple: Direct Creation",
|
|
106
|
+
"runCondition": {
|
|
107
|
+
"var": "docComplexity",
|
|
108
|
+
"equals": "Simple"
|
|
109
|
+
},
|
|
110
|
+
"prompt": "Create this documentation directly.\n\nBefore writing:\n- Check for any existing templates or documentation patterns to follow\n- Confirm the document type, target audience, and basic requirements\n\nCreate a brief outline, then write the content. Review for accuracy and readability before saving.\n\nSave with an appropriate filename and provide a brief summary of what was created.\n\nIf during creation you discover the task is more complex than Simple, note it and adapt your approach inline.",
|
|
232
111
|
"requireConfirmation": false
|
|
233
112
|
}
|
|
234
113
|
]
|
|
235
|
-
}
|
|
114
|
+
}
|