@aicgen/aicgen 1.1.0 → 1.1.1

package/data/workflows/sdlc.md

@@ -0,0 +1,133 @@
+# SDLC Workflows
+
+## /spec [name]
+Capture the full specification for a feature or task before any code is written.
+
+**Steps:**
+1. Ask for a feature name if not provided as an argument
+2. Ask the user to describe: goal, user stories, acceptance criteria, constraints, and what is explicitly out of scope
+3. Create `docs/specs/` directory if it does not exist
+4. Save the gathered information to `docs/specs/{name}.md` using the template below
+5. Confirm the file was saved and prompt the user to run `/research`
+
+**Output template (`docs/specs/{name}.md`):**
+```markdown
+# Spec: {name}
+
+## Goal
+{goal}
+
+## User Stories
+{user stories}
+
+## Acceptance Criteria
+{acceptance criteria}
+
+## Constraints
+{constraints}
+
+## Out of Scope
+{out of scope}
+```
+
+---
+
+## /research
+Analyze the active spec with internal codebase scanning and external web research.
+
+**Pre-condition:** An active spec must exist in `docs/specs/` — if none is found, tell the user to run `/spec` first and stop.
+
+**Steps:**
+1. Read the most recently modified spec from `docs/specs/`
+2. **Internal scan:** Search the codebase for related code, existing patterns, similar implementations, dependencies, and potential conflicts relevant to the spec
+3. **Infrastructure prompt:** Ask the user:
+   > "Does this feature require infrastructure decisions?"
+   > - Cost-optimised / serverless (pay-per-use: Cloud Run, Cloud Functions, AWS Lambda, Fargate, etc.)
+   > - Fixed / dedicated (predictable load: Kubernetes, EC2, GKE, dedicated VMs, etc.)
+   > - No infrastructure involved
+4. **Web research:** Search for architecture patterns, best practices, reference implementations, and cost comparisons relevant to the spec. Bias results toward the chosen infrastructure model if one was selected.
+5. Surface: recommended approaches, trade-offs, cost implications, and links to reference material
+6. Suggest any improvements or clarifications to the spec based on findings
+7. Append a `## Research Findings` section to the active spec file containing: internal findings, web research summary, infrastructure recommendation (if applicable), and suggested spec improvements
+8. Prompt the user to run `/plan`
+
+---
+
+## /plan
+Produce a phased, checkpoint-driven implementation plan based on the spec and research findings.
+
+**Pre-condition:** An active spec with a `## Research Findings` section must exist — if research has not been run, warn the user and ask them to confirm they want to skip it before proceeding.
+
+**Steps:**
+1. Read the active spec (including research findings) from `docs/specs/`
+2. Analyse the codebase to understand existing structure, patterns, and conventions
+3. Break the implementation into phases — each phase must be independently verifiable
+4. For each phase, list: files to create or modify, key decisions, and how to verify it is complete
+5. Identify risks and propose mitigations
+6. Create `docs/plans/` directory if it does not exist
+7. Save the plan to `docs/plans/{spec-name}.md`
+8. Confirm the file was saved and prompt the user to run `/build`
+
+---
+
+## /build [phase]
+Execute the next (or a specified) phase of the current implementation plan.
+
+**Pre-condition:** An active plan must exist in `docs/plans/` — if none is found, tell the user to run `/plan` first and stop.
+
+**Steps:**
+1. Read the active plan from `docs/plans/`
+2. Determine the next incomplete phase (or the phase specified by the argument)
+3. Announce which phase is being executed and what it covers
+4. Implement the phase step by step, following existing codebase patterns and conventions
+5. After completing the phase, summarise what was changed and what was created
+6. Mark the phase as complete in the plan file
+7. Run any tests relevant to the completed phase and report results
+8. Pause and ask: "Phase {n} complete. Continue to phase {n+1}?" before proceeding
+
+---
+
+## /check
+Verify the current implementation against the active spec — tests, code review, and regression check.
+
+**Steps:**
+1. Read the active spec from `docs/specs/` and the active plan from `docs/plans/`
+2. Run the full test suite and report results
+3. Review all changed files against the spec's acceptance criteria — flag any gaps
+4. Check for regressions by reviewing changed files for unintended side effects
+5. Produce a structured report:
+   - ✅ Acceptance criteria met
+   - ❌ Acceptance criteria not met (with details)
+   - ⚠️ Potential regressions (with details)
+   - 📋 Suggested fixes
+6. If all criteria are met and no regressions are found, prompt the user to run `/ship`
+
+---
+
+## /ship
+Pre-flight wrap-up — verify everything is ready, then draft a PR description.
+
+**Steps:**
+1. Run the full test suite — stop and report if any tests fail
+2. Read the active spec and plan
+3. Verify that `docs/specs/{name}.md` and `docs/plans/{name}.md` are up to date
+4. Check for uncommitted changes and list them
+5. Draft a PR description referencing the spec and plan:
+   ```
+   ## Summary
+   {goal from spec}
+
+   ## Changes
+   {summary of phases completed}
+
+   ## Spec
+   docs/specs/{name}.md
+
+   ## Plan
+   docs/plans/{name}.md
+
+   ## Test plan
+   {acceptance criteria from spec as a checklist}
+   ```
+6. Present the PR description to the user for review
+7. Ask: "Ready to commit and push?" — if yes, stage all changes and create a commit with a conventional commit message

package/dist/index.js

@@ -66052,6 +66052,140 @@ const validateUser = (data: unknown) => {
 \`\`\`
 `,
     "workflows/README.md": "# SDLC Workflows\n\naicgen injects a structured 6-command SDLC workflow into every generated assistant configuration. These commands guide the AI assistant through a repeatable, artifact-driven development lifecycle.\n\n## The Flow\n\n```\n/spec → /research → /plan → /build → /check → /ship\n```\n\n| Step | Command | Output artifact |\n|------|---------|----------------|\n| 1 | [`/spec [name]`](sdlc/spec.md) | `docs/specs/{name}.md` |\n| 2 | [`/research`](sdlc/research.md) | Appends `## Research Findings` to spec |\n| 3 | [`/plan`](sdlc/plan.md) | `docs/plans/{name}.md` |\n| 4 | [`/build [phase?]`](sdlc/build.md) | Code changes |\n| 5 | [`/check`](sdlc/check.md) | Inline verification report |\n| 6 | [`/ship`](sdlc/ship.md) | PR description draft |\n\n## Commands\n\n- [/spec](sdlc/spec.md) — Capture feature requirements before writing any code\n- [/research](sdlc/research.md) — Codebase scan + web research + infrastructure preference\n- [/plan](sdlc/plan.md) — Phased, checkpoint-driven implementation plan\n- [/build](sdlc/build.md) — Execute plan phase by phase with review checkpoints\n- [/check](sdlc/check.md) — Verify implementation against spec and run tests\n- [/ship](sdlc/ship.md) — Pre-flight checks and PR description draft\n\n## Output directory\n\nAll spec and plan artifacts are saved to the `docs/` directory in the user's project. This directory is created automatically if it does not exist.\n\n```\ndocs/\n├── specs/\n│   └── {feature-name}.md\n└── plans/\n    └── {feature-name}.md\n```\n\n## Guard rails\n\n| Command | Pre-condition |\n|---------|--------------|\n| `/research` | Active spec in `docs/specs/` — prompts `/spec` if missing |\n| `/plan` | Active spec with `## Research Findings` — warns if research was skipped |\n| `/build` | Active plan in `docs/plans/` — prompts `/plan` if missing |\n\n## Source\n\nCommand definitions are maintained in [`aicgen/data/workflows/sdlc.md`](https://github.com/aicgen/aicgen/blob/main/data/workflows/sdlc.md) and injected into every generated config at `aicgen init` time.\n",
+    "workflows/sdlc.md": `# SDLC Workflows
+
+## /spec [name]
+Capture the full specification for a feature or task before any code is written.
+
+**Steps:**
+1. Ask for a feature name if not provided as an argument
+2. Ask the user to describe: goal, user stories, acceptance criteria, constraints, and what is explicitly out of scope
+3. Create \`docs/specs/\` directory if it does not exist
+4. Save the gathered information to \`docs/specs/{name}.md\` using the template below
+5. Confirm the file was saved and prompt the user to run \`/research\`
+
+**Output template (\`docs/specs/{name}.md\`):**
+\`\`\`markdown
+# Spec: {name}
+
+## Goal
+{goal}
+
+## User Stories
+{user stories}
+
+## Acceptance Criteria
+{acceptance criteria}
+
+## Constraints
+{constraints}
+
+## Out of Scope
+{out of scope}
+\`\`\`
+
+---
+
+## /research
+Analyze the active spec with internal codebase scanning and external web research.
+
+**Pre-condition:** An active spec must exist in \`docs/specs/\` — if none is found, tell the user to run \`/spec\` first and stop.
+
+**Steps:**
+1. Read the most recently modified spec from \`docs/specs/\`
+2. **Internal scan:** Search the codebase for related code, existing patterns, similar implementations, dependencies, and potential conflicts relevant to the spec
+3. **Infrastructure prompt:** Ask the user:
+   > "Does this feature require infrastructure decisions?"
+   > - Cost-optimised / serverless (pay-per-use: Cloud Run, Cloud Functions, AWS Lambda, Fargate, etc.)
+   > - Fixed / dedicated (predictable load: Kubernetes, EC2, GKE, dedicated VMs, etc.)
+   > - No infrastructure involved
+4. **Web research:** Search for architecture patterns, best practices, reference implementations, and cost comparisons relevant to the spec. Bias results toward the chosen infrastructure model if one was selected.
+5. Surface: recommended approaches, trade-offs, cost implications, and links to reference material
+6. Suggest any improvements or clarifications to the spec based on findings
+7. Append a \`## Research Findings\` section to the active spec file containing: internal findings, web research summary, infrastructure recommendation (if applicable), and suggested spec improvements
+8. Prompt the user to run \`/plan\`
+
+---
+
+## /plan
+Produce a phased, checkpoint-driven implementation plan based on the spec and research findings.
+
+**Pre-condition:** An active spec with a \`## Research Findings\` section must exist — if research has not been run, warn the user and ask them to confirm they want to skip it before proceeding.
+
+**Steps:**
+1. Read the active spec (including research findings) from \`docs/specs/\`
+2. Analyse the codebase to understand existing structure, patterns, and conventions
+3. Break the implementation into phases — each phase must be independently verifiable
+4. For each phase, list: files to create or modify, key decisions, and how to verify it is complete
+5. Identify risks and propose mitigations
+6. Create \`docs/plans/\` directory if it does not exist
+7. Save the plan to \`docs/plans/{spec-name}.md\`
+8. Confirm the file was saved and prompt the user to run \`/build\`
+
+---
+
+## /build [phase]
+Execute the next (or a specified) phase of the current implementation plan.
+
+**Pre-condition:** An active plan must exist in \`docs/plans/\` — if none is found, tell the user to run \`/plan\` first and stop.
+
+**Steps:**
+1. Read the active plan from \`docs/plans/\`
+2. Determine the next incomplete phase (or the phase specified by the argument)
+3. Announce which phase is being executed and what it covers
+4. Implement the phase step by step, following existing codebase patterns and conventions
+5. After completing the phase, summarise what was changed and what was created
+6. Mark the phase as complete in the plan file
+7. Run any tests relevant to the completed phase and report results
+8. Pause and ask: "Phase {n} complete. Continue to phase {n+1}?" before proceeding
+
+---
+
+## /check
+Verify the current implementation against the active spec — tests, code review, and regression check.
+
+**Steps:**
+1. Read the active spec from \`docs/specs/\` and the active plan from \`docs/plans/\`
+2. Run the full test suite and report results
+3. Review all changed files against the spec's acceptance criteria — flag any gaps
+4. Check for regressions by reviewing changed files for unintended side effects
+5. Produce a structured report:
+   - ✅ Acceptance criteria met
+   - ❌ Acceptance criteria not met (with details)
+   - ⚠️ Potential regressions (with details)
+   - \uD83D\uDCCB Suggested fixes
+6. If all criteria are met and no regressions are found, prompt the user to run \`/ship\`
+
+---
+
+## /ship
+Pre-flight wrap-up — verify everything is ready, then draft a PR description.
+
+**Steps:**
+1. Run the full test suite — stop and report if any tests fail
+2. Read the active spec and plan
+3. Verify that \`docs/specs/{name}.md\` and \`docs/plans/{name}.md\` are up to date
+4. Check for uncommitted changes and list them
+5. Draft a PR description referencing the spec and plan:
+   \`\`\`
+   ## Summary
+   {goal from spec}
+
+   ## Changes
+   {summary of phases completed}
+
+   ## Spec
+   docs/specs/{name}.md
+
+   ## Plan
+   docs/plans/{name}.md
+
+   ## Test plan
+   {acceptance criteria from spec as a checklist}
+   \`\`\`
+6. Present the PR description to the user for review
+7. Ask: "Ready to commit and push?" — if yes, stage all changes and create a commit with a conventional commit message
+`,
     "workflows/sdlc/plan.md": `# /plan
 
 **Purpose:** Produce a phased, checkpoint-driven implementation plan based on the spec and research findings.
@@ -66355,6 +66489,140 @@ If all criteria are met and no regressions: run [\`/ship\`](ship.md).
 `
   }
 };
+var EMBEDDED_SDLC_CONTENT = `# SDLC Workflows
+
+## /spec [name]
+Capture the full specification for a feature or task before any code is written.
+
+**Steps:**
+1. Ask for a feature name if not provided as an argument
+2. Ask the user to describe: goal, user stories, acceptance criteria, constraints, and what is explicitly out of scope
+3. Create \`docs/specs/\` directory if it does not exist
+4. Save the gathered information to \`docs/specs/{name}.md\` using the template below
+5. Confirm the file was saved and prompt the user to run \`/research\`
+
+**Output template (\`docs/specs/{name}.md\`):**
+\`\`\`markdown
+# Spec: {name}
+
+## Goal
+{goal}
+
+## User Stories
+{user stories}
+
+## Acceptance Criteria
+{acceptance criteria}
+
+## Constraints
+{constraints}
+
+## Out of Scope
+{out of scope}
+\`\`\`
+
+---
+
+## /research
+Analyze the active spec with internal codebase scanning and external web research.
+
+**Pre-condition:** An active spec must exist in \`docs/specs/\` — if none is found, tell the user to run \`/spec\` first and stop.
+
+**Steps:**
+1. Read the most recently modified spec from \`docs/specs/\`
+2. **Internal scan:** Search the codebase for related code, existing patterns, similar implementations, dependencies, and potential conflicts relevant to the spec
+3. **Infrastructure prompt:** Ask the user:
+   > "Does this feature require infrastructure decisions?"
+   > - Cost-optimised / serverless (pay-per-use: Cloud Run, Cloud Functions, AWS Lambda, Fargate, etc.)
+   > - Fixed / dedicated (predictable load: Kubernetes, EC2, GKE, dedicated VMs, etc.)
+   > - No infrastructure involved
+4. **Web research:** Search for architecture patterns, best practices, reference implementations, and cost comparisons relevant to the spec. Bias results toward the chosen infrastructure model if one was selected.
+5. Surface: recommended approaches, trade-offs, cost implications, and links to reference material
+6. Suggest any improvements or clarifications to the spec based on findings
+7. Append a \`## Research Findings\` section to the active spec file containing: internal findings, web research summary, infrastructure recommendation (if applicable), and suggested spec improvements
+8. Prompt the user to run \`/plan\`
+
+---
+
+## /plan
+Produce a phased, checkpoint-driven implementation plan based on the spec and research findings.
+
+**Pre-condition:** An active spec with a \`## Research Findings\` section must exist — if research has not been run, warn the user and ask them to confirm they want to skip it before proceeding.
+
+**Steps:**
+1. Read the active spec (including research findings) from \`docs/specs/\`
+2. Analyse the codebase to understand existing structure, patterns, and conventions
+3. Break the implementation into phases — each phase must be independently verifiable
+4. For each phase, list: files to create or modify, key decisions, and how to verify it is complete
+5. Identify risks and propose mitigations
+6. Create \`docs/plans/\` directory if it does not exist
+7. Save the plan to \`docs/plans/{spec-name}.md\`
+8. Confirm the file was saved and prompt the user to run \`/build\`
+
+---
+
+## /build [phase]
+Execute the next (or a specified) phase of the current implementation plan.
+
+**Pre-condition:** An active plan must exist in \`docs/plans/\` — if none is found, tell the user to run \`/plan\` first and stop.
+
+**Steps:**
+1. Read the active plan from \`docs/plans/\`
+2. Determine the next incomplete phase (or the phase specified by the argument)
+3. Announce which phase is being executed and what it covers
+4. Implement the phase step by step, following existing codebase patterns and conventions
+5. After completing the phase, summarise what was changed and what was created
+6. Mark the phase as complete in the plan file
+7. Run any tests relevant to the completed phase and report results
+8. Pause and ask: "Phase {n} complete. Continue to phase {n+1}?" before proceeding
+
+---
+
+## /check
+Verify the current implementation against the active spec — tests, code review, and regression check.
+
+**Steps:**
+1. Read the active spec from \`docs/specs/\` and the active plan from \`docs/plans/\`
+2. Run the full test suite and report results
+3. Review all changed files against the spec's acceptance criteria — flag any gaps
+4. Check for regressions by reviewing changed files for unintended side effects
+5. Produce a structured report:
+   - ✅ Acceptance criteria met
+   - ❌ Acceptance criteria not met (with details)
+   - ⚠️ Potential regressions (with details)
+   - \uD83D\uDCCB Suggested fixes
+6. If all criteria are met and no regressions are found, prompt the user to run \`/ship\`
+
+---
+
+## /ship
+Pre-flight wrap-up — verify everything is ready, then draft a PR description.
+
+**Steps:**
+1. Run the full test suite — stop and report if any tests fail
+2. Read the active spec and plan
+3. Verify that \`docs/specs/{name}.md\` and \`docs/plans/{name}.md\` are up to date
+4. Check for uncommitted changes and list them
+5. Draft a PR description referencing the spec and plan:
+   \`\`\`
+   ## Summary
+   {goal from spec}
+
+   ## Changes
+   {summary of phases completed}
+
+   ## Spec
+   docs/specs/{name}.md
+
+   ## Plan
+   docs/plans/{name}.md
+
+   ## Test plan
+   {acceptance criteria from spec as a checklist}
+   \`\`\`
+6. Present the PR description to the user for review
+7. Ask: "Ready to commit and push?" — if yes, stage all changes and create a commit with a conventional commit message
+`;
 
 // src/services/data-source.ts
 class EmbeddedDataSource {
@@ -67348,7 +67616,6 @@ class SubAgentGenerator {
 // src/services/workflow-injector.ts
 import { readFile as readFile3 } from "fs/promises";
 import { join as join4 } from "path";
-
 class WorkflowInjector {
   commands;
   constructor(commands) {
@@ -67358,13 +67625,15 @@ class WorkflowInjector {
     return new WorkflowInjector(WorkflowInjector.parse(sdlcContent));
   }
   static async create(dataDir) {
-    const root = dataDir ?? process.cwd();
-    const sdlcPath = join4(root, "data/workflows/sdlc.md");
+    if (!dataDir) {
+      return WorkflowInjector.fromContent(EMBEDDED_SDLC_CONTENT);
+    }
+    const sdlcPath = join4(dataDir, "data/workflows/sdlc.md");
     try {
       const content = await readFile3(sdlcPath, "utf-8");
       return WorkflowInjector.fromContent(content);
-    } catch (err) {
-      throw new Error(`WorkflowInjector: could not read "${sdlcPath}". ` + `Pass the aicgen package root as dataDir, or ensure process.cwd() is the package root. ` + `Original error: ${err.message}`);
+    } catch {
+      return WorkflowInjector.fromContent(EMBEDDED_SDLC_CONTENT);
     }
   }
   static parse(content) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aicgen/aicgen",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "description": "AI Config Generator - Automated AI assistant configuration for your projects",
   "keywords": [
     "ai",