synarcx 0.2.0 → 0.3.0

package/dist/core/templates/workflows/clarify.js

@@ -1,108 +1,130 @@
+import { commandFromSkill } from '../types.js';
 export function getSynClarifySkillTemplate() {
     return {
         name: 'syn-clarify',
         description: 'Ask up to 5 targeted questions about a change\'s proposal, specs, or design to improve clarity before implementation.',
-        instructions: `Ask targeted clarification questions about a change to improve its artifacts before implementation.
-
----
-
-## Steps
-
-1. **Identify the change**
-   - If the user specified a change name, use it
-   - Otherwise, run \`synarcx list --json\` to find active changes
-   - If multiple, ask which one to clarify
-
-2. **Read the artifacts**
-   - \`synspec/changes/<name>/proposal.md\`
-   - \`synspec/changes/<name>/specs/**/*.md\` (if exist)
-   - \`synspec/changes/<name>/design.md\`
-
-3. **Generate up to 5 targeted questions**
-   Focus on areas that are:
-   - Ambiguous or underspecified
-   - Missing edge cases
-   - Unclear scope boundaries
-   - Unstated assumptions
-   - Missing acceptance criteria
-
-   Question categories:
-   - **Scope**: What's in/out? Edge cases?
-   - **Requirements**: Acceptance criteria? Success metrics?
-   - **Design**: Trade-offs considered? Alternatives?
-   - **Implementation**: Dependencies? Migration path?
-   - **Testing**: How to verify?
-
-4. **Ask questions interactively**
-   Use the **AskUserQuestion tool** (open-ended) to present each question.
-   Present questions one at a time. Wait for each answer before moving to the next.
-   Maximum 5 questions per session.
-
-5. **Encode answers back into artifacts**
-   - Edit the relevant artifact in place (proposal.md, design.md, or specs)
-   - Do NOT create new files
-   - Show what was changed and why
-
----
-
-## Output
-
-After completing, summarize:
-- What was clarified
-- Which artifacts were updated
-- Next step: Run \`/syn:analyze\` to check consistency across artifacts`,
+        instructions: `Ask targeted clarification questions about a change to improve its artifacts before implementation.
+
+---
+
+## Steps
+
+1. **Identify the change**
+   - If the user specified a change name, use it
+   - Otherwise, run \`synarcx list --json\` to find active changes
+   - If multiple, ask which one to clarify
+
+2. **Read the artifacts**
+   - \`synspec/changes/<name>/proposal.md\`
+   - \`synspec/changes/<name>/specs/**/*.md\` (if exist)
+   - \`synspec/changes/<name>/design.md\`
+
+3. **Generate targeted questions (5 default, extendable for critical unknowns)**
+   Focus on areas that are:
+   - Ambiguous or underspecified
+   - Missing edge cases
+   - Unclear scope boundaries
+   - Unstated assumptions
+   - Missing acceptance criteria
+
+   Question categories:
+   - **Scope**: What's in/out? Edge cases?
+   - **Requirements**: Acceptance criteria? Success metrics?
+   - **Design**: Trade-offs considered? Alternatives?
+   - **Implementation**: Dependencies? Migration path?
+   - **Testing**: How to verify?
+
+   "Critical" = a hole or contradiction that would produce broken or incorrect code if left unaddressed. Not "nice to know" or stylistic preferences.
+
+4. **Ask questions interactively**
+   Use the **AskUserQuestion tool** (open-ended) to present each question.
+   Present questions one at a time. Wait for each answer before moving to the next.
+   Default maximum: 5 questions. If one or more critical unknowns remain after 5, present each remaining critical question with context and ask the user to confirm before continuing.
+
+5. **Encode answers back into artifacts**
+   - Edit the relevant artifact in place (proposal.md, design.md, or specs)
+   - Do NOT create new files
+   - Show what was changed and why
+   - Note: tasks.md will be read during the auto-analyze step that follows
+
+6. **Auto-analyze: cross-artifact consistency checks**
+   - Read all artifacts including tasks.md
+   - Run 5 checks: terminology, scope, completeness, conflicts, traceability
+   - Fix up to 5 inconsistencies in place
+   - If a fix would contradict a Q&A answer, skip it (user answer wins)
+   - If zero issues found, report each check as "OK"
+
+---
+
+## Output
+
+After completing, summarize:
+- What was clarified
+- Which artifacts were updated
+- Consistency check results (each of 5 checks: OK or fix applied)
+- Next step: Run \`/syn:apply\` to start implementation`,
         license: 'MIT',
         compatibility: 'Requires synarcx CLI.',
         metadata: { author: 'synarcx', version: '0.1' },
     };
 }
 export function getSynClarifyCommandTemplate() {
-    return {
+    return commandFromSkill(getSynClarifySkillTemplate(), {
         name: 'syn:clarify',
         description: 'Ask up to 5 targeted questions to improve change artifacts',
-        category: 'Workflow',
         tags: ['workflow', 'clarify'],
-        content: `Ask targeted clarification questions about a change to improve its artifacts before implementation.
-
----
-
-## Steps
-
-1. **Identify the change**
-   - If the user specified a change name, use it
-   - Otherwise, run \`synarcx list --json\` to find active changes
-   - If multiple, ask which one to clarify
-
-2. **Read the artifacts**
-   - \`synspec/changes/<name>/proposal.md\`
-   - \`synspec/changes/<name>/specs/**/*.md\` (if exist)
-   - \`synspec/changes/<name>/design.md\`
-
-3. **Generate up to 5 targeted questions**
-   Focus on areas that are:
-   - Ambiguous or underspecified
-   - Missing edge cases
-   - Unclear scope boundaries
-   - Unstated assumptions
-   - Missing acceptance criteria
-
-4. **Ask questions interactively**
-   Present questions one at a time. Wait for each answer before moving to the next.
-   Maximum 5 questions per session.
-
-5. **Encode answers back into artifacts**
-   - Edit the relevant artifact in place (proposal.md, design.md, or specs)
-   - Do NOT create new files
-   - Show what was changed and why
-
----
-
-## Output
-
-After completing, summarize:
-- What was clarified
-- Which artifacts were updated
-- Next step: Run \`/syn:analyze\` to check consistency across artifacts`
-    };
+        content: `Ask targeted clarification questions about a change to improve its artifacts before implementation.
+
+---
+
+## Steps
+
+1. **Identify the change**
+   - If the user specified a change name, use it
+   - Otherwise, run \`synarcx list --json\` to find active changes
+   - If multiple, ask which one to clarify
+
+2. **Read the artifacts**
+   - \`synspec/changes/<name>/proposal.md\`
+   - \`synspec/changes/<name>/specs/**/*.md\` (if exist)
+   - \`synspec/changes/<name>/design.md\`
+
+3. **Generate targeted questions (5 default, extendable for critical unknowns)**
+   Focus on areas that are:
+   - Ambiguous or underspecified
+   - Missing edge cases
+   - Unclear scope boundaries
+   - Unstated assumptions
+   - Missing acceptance criteria
+
+   "Critical" = a hole or contradiction that would produce broken or incorrect code if left unaddressed. Not "nice to know" or stylistic preferences.
+
+4. **Ask questions interactively**
+   Present questions one at a time. Wait for each answer before moving to the next.
+   Default maximum: 5 questions. If one or more critical unknowns remain after 5, present each remaining critical question with context and ask the user to confirm before continuing.
+
+5. **Encode answers back into artifacts**
+   - Edit the relevant artifact in place (proposal.md, design.md, or specs)
+   - Do NOT create new files
+   - Show what was changed and why
+   - Note: tasks.md will be read during the auto-analyze step that follows
+
+6. **Auto-analyze: cross-artifact consistency checks**
+   - Read all artifacts including tasks.md
+   - Run 5 checks: terminology, scope, completeness, conflicts, traceability
+   - Fix up to 5 inconsistencies in place
+   - If a fix would contradict a Q&A answer, skip it (user answer wins)
+   - If zero issues found, report each check as "OK"
+
+---
+
+## Output
+
+After completing, summarize:
+- What was clarified
+- Which artifacts were updated
+- Consistency check results (each of 5 checks: OK or fix applied)
+- Next step: Run \`/syn:apply\` to start implementation`
+    });
 }
 //# sourceMappingURL=clarify.js.map

package/dist/core/templates/workflows/debug.js

@@ -1,64 +1,65 @@
+import { commandFromSkill } from '../types.js';
 export function getSynDebugSkillTemplate() {
     return {
         name: 'syn-debug',
         description: 'Investigate a known error or failure — root cause analysis, pattern recognition, and hypothesis formulation. Hands off explicitly to /syn:propose.',
-        instructions: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and explicitly prompts the user to run \`/syn:propose\` — does NOT auto-create artifacts or auto-hand off.
-
-**Input**: Error message, symptom, or failure description. If no input provided, ask what went wrong.
-
----
-
-## Initial Context
-
-If a change is active, read its artifacts first:
-- \`synspec/changes/<name>/proposal.md\`
-- \`synspec/changes/<name>/design.md\`
-- \`synspec/changes/<name>/tasks.md\`
-
-Use that context to understand what was intended vs. what went wrong.
-
----
-
-## The 3 Phases
-
-### Phase 1: Root Cause Analysis
-- Reproduce the issue
-- Gather context (error messages, logs, state)
-- Follow the call stack backward
-- Check input assumptions at each layer
-- Identify the root cause (not symptoms)
-- Document findings under \`### Root Cause\`
-
-### Phase 2: Pattern Recognition
-- Is this a known issue or novel?
-- Have similar bugs been fixed before?
-- Is this a class of issues?
-- Check codebase for related patterns
-- Document under \`### Pattern\`
-
-### Phase 3: Hypothesis
-- Formulate fix hypothesis
-- Consider side effects of the fix
-- Consider alternative approaches
-- Determine minimal change needed
-- Document under \`### Hypothesis\`
-
----
-
-## Output
-
-After completing the 3-phase investigation, present findings and prompt explicitly:
-
-\`\`\`
-### Diagnosis
-
-**Root Cause**: <what was found>
-**Pattern**: <similar issues or novel>
-**Hypothesis**: <proposed fix approach>
-
-**Ready to formalize?** Run \`/syn:propose\` to create a change with these findings.
-\`\`\`
-
+        instructions: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and explicitly prompts the user to run \`/syn:propose\` — does NOT auto-create artifacts or auto-hand off.
+
+**Input**: Error message, symptom, or failure description. If no input provided, ask what went wrong.
+
+---
+
+## Initial Context
+
+If a change is active, read its artifacts first:
+- \`synspec/changes/<name>/proposal.md\`
+- \`synspec/changes/<name>/design.md\`
+- \`synspec/changes/<name>/tasks.md\`
+
+Use that context to understand what was intended vs. what went wrong.
+
+---
+
+## The 3 Phases
+
+### Phase 1: Root Cause Analysis
+- Reproduce the issue
+- Gather context (error messages, logs, state)
+- Follow the call stack backward
+- Check input assumptions at each layer
+- Identify the root cause (not symptoms)
+- Document findings under \`### Root Cause\`
+
+### Phase 2: Pattern Recognition
+- Is this a known issue or novel?
+- Have similar bugs been fixed before?
+- Is this a class of issues?
+- Check codebase for related patterns
+- Document under \`### Pattern\`
+
+### Phase 3: Hypothesis
+- Formulate fix hypothesis
+- Consider side effects of the fix
+- Consider alternative approaches
+- Determine minimal change needed
+- Document under \`### Hypothesis\`
+
+---
+
+## Output
+
+After completing the 3-phase investigation, present findings and prompt explicitly:
+
+\`\`\`
+### Diagnosis
+
+**Root Cause**: <what was found>
+**Pattern**: <similar issues or novel>
+**Hypothesis**: <proposed fix approach>
+
+**Ready to formalize?** Run \`/syn:propose\` to create a change with these findings.
+\`\`\`
+
 Do NOT create any artifacts, do NOT start the pipeline automatically. The user must explicitly run \`/syn:propose\` to formalize.`,
         license: 'MIT',
         compatibility: 'Requires synarcx CLI.',
@@ -66,52 +67,51 @@ Do NOT create any artifacts, do NOT start the pipeline automatically. The user m
     };
 }
 export function getSynDebugCommandTemplate() {
-    return {
+    return commandFromSkill(getSynDebugSkillTemplate(), {
         name: 'syn:debug',
         description: 'Investigate a known error — root cause analysis through hypothesis, explicitly prompts /syn:propose',
-        category: 'Workflow',
         tags: ['workflow', 'debug', 'fix'],
-        content: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and suggests \`/syn:propose\` for creating the fix change.
-
-**Input**: Error message, symptom, or failure description. The argument after \`/syn:debug\` is what went wrong.
-
----
-
-## Initial Context
-
-If a change is active, read its artifacts first to understand what was intended vs. what went wrong.
-
----
-
-## The 3 Phases
-
-### Phase 1: Root Cause Analysis
-- Reproduce the issue
-- Gather context (error messages, logs, state)
-- Follow the call stack backward
-- Check input assumptions at each layer
-- Identify the root cause (not symptoms)
-- Document findings under \`### Root Cause\`
-
-### Phase 2: Pattern Recognition
-- Is this a known issue or novel?
-- Have similar bugs been fixed before?
-- Is this a class of issues?
-- Check codebase for related patterns
-- Document under \`### Pattern\`
-
-### Phase 3: Hypothesis
-- Formulate fix hypothesis
-- Consider side effects of the fix
-- Consider alternative approaches
-- Determine minimal change needed
-- Document under \`### Hypothesis\`
-
----
-
-## Output
-
+        content: `Investigate a known error or failure systematically in 3 phases. Produces a diagnosis and suggests \`/syn:propose\` for creating the fix change.
+
+**Input**: Error message, symptom, or failure description. The argument after \`/syn:debug\` is what went wrong.
+
+---
+
+## Initial Context
+
+If a change is active, read its artifacts first to understand what was intended vs. what went wrong.
+
+---
+
+## The 3 Phases
+
+### Phase 1: Root Cause Analysis
+- Reproduce the issue
+- Gather context (error messages, logs, state)
+- Follow the call stack backward
+- Check input assumptions at each layer
+- Identify the root cause (not symptoms)
+- Document findings under \`### Root Cause\`
+
+### Phase 2: Pattern Recognition
+- Is this a known issue or novel?
+- Have similar bugs been fixed before?
+- Is this a class of issues?
+- Check codebase for related patterns
+- Document under \`### Pattern\`
+
+### Phase 3: Hypothesis
+- Formulate fix hypothesis
+- Consider side effects of the fix
+- Consider alternative approaches
+- Determine minimal change needed
+- Document under \`### Hypothesis\`
+
+---
+
+## Output
+
 After completing, present the diagnosis and explicitly prompt the user to run \`/syn:propose\` to formalize the fix. Do NOT auto-create artifacts.`
-    };
+    });
 }
 //# sourceMappingURL=debug.js.map