@entelligentsia/forgecli 1.0.36 → 1.0.40

package/dist/forge-payload/.base-pack/commands/init.md

@@ -1,278 +0,0 @@
----
-name: init
-description: Bootstrap Forge's LLM half — KB discovery, config generation, and artifact registration. Run once after `4ge init claude .` has scaffolded the project structure.
----
-
-# /forge:init
-
-You are the Forge init orchestrator. Your job is to run the LLM half of the
-Forge bootstrap — knowledge-base discovery, config generation, and artifact
-registration — in the current working directory. The CLI half (`4ge init claude .`)
-has already scaffolded the project structure, installed the wfl-init.js driver,
-and installed this command wrapper.
-
-## Resume Detection
-
-Before showing the pre-flight plan, check for an existing checkpoint:
-
-```sh
-cat .forge/init-progress.json 2>/dev/null
-```
-
-If the file exists and contains valid JSON, inspect it:
-
-- If `lastPhase > 4`, contains a `mode` field, contains a `phase-7-substep-map` key,
-  or is missing a `timestamp` field — treat as a stale checkpoint from a previous
-  run of the old 12-phase init. Delete the file:
-  ```sh
-  rm -f .forge/init-progress.json
-  ```
-  Then proceed to the **Pre-flight interactive prompts** (new 4-phase flow, no mode prompt).
-  Set `startPhase = 1`.
-
-- If the file contains valid JSON with `lastPhase` in range 1–4 and a `timestamp`
-  field, emit the resume banner:
-
-```
-〇 Previous init detected — last completed phase: {lastPhase} of 4
-
-Resume from Phase {nextPhase}? [Y] Start over [n]
-```
-
-Use the following mapping:
-
-| lastPhase | Resume from (nextPhase) |
-|-----------|-------------------------|
-| 1         | Phase 2                 |
-| 2         | Phase 3                 |
-| 3         | Phase 4                 |
-
-If the user chooses to resume: set `startPhase = nextPhase`.
-If the user chooses to start over: delete `.forge/init-progress.json`
-(`rm -f .forge/init-progress.json`) and set `startPhase = 1`.
-
-If the file does not exist, or contains invalid JSON, or contains an
-unrecognised `lastPhase` value outside 1–4: delete any corrupt file and
-set `startPhase = 1`.
-
-If parsing the file throws (malformed JSON): log a one-line warning
-`△ init-progress.json is malformed — deleting and starting fresh.`, delete
-the file, and set `startPhase = 1`.
-
-## Hero
-
-Render the Forge hero block once per session:
-
-```sh
-node .forge/tools/banners.cjs forge
-node .forge/tools/banners.cjs --subtitle "AI SDLC bootstrapper · forge:init"
-```
-
-The hero runs once. If the user resumes mid-init, do NOT re-render the hero —
-just emit the phase banner for the resume target phase.
-
-## Flag Handling
-
-`--fast` and `--full` are accepted as no-ops for backwards compatibility with
-scripts and CI pipelines. Both flags proceed with the standard 4-phase flow.
-
-**`--migrate` flag:** When `$ARGUMENTS` contains `--migrate`, redirect to the
-store migration workflow. Read `.forge/config.json` to locate `paths.forgeRoot`,
-then read `{forgeRoot}/meta/workflows/meta-migrate.md` and follow it.
-Do NOT proceed to the pre-flight prompts when `--migrate` is present.
-
-## Pre-flight Interactive Prompts
-
-Gather these values before dispatching the workflow:
-
-### a. KB Folder Prompt
-
-```
-What should your engineering knowledge base folder be named?
-  Default: engineering
-  (This is where Forge writes sprint artifacts, docs, and KB files.)
-
-KB folder name [engineering]: ___
-```
-
-If the user provides a custom name (non-empty, not "engineering"), write it now:
-
-```sh
-node .forge/tools/manage-config.cjs set paths.engineering "{name}"
-```
-
-Set `kbFolder` to the chosen name (default: `"engineering"`).
-
-### b. CLAUDE.md Offer
-
-Check whether any agent instruction file exists:
-
-```sh
-ls CLAUDE.md AGENTS.md CLAUDE.local.md .cursorrules 2>/dev/null
-```
-
-If NONE of those files exists, ask:
-
-```
-No CLAUDE.md / AGENTS.md found in this project.
-Create a minimal CLAUDE.md with Forge KB links? [Y/n]: ___
-```
-
-Set `createClaudeMd = true` if user answers Y (or presses Enter); `false` otherwise.
-If any of those files already exists, set `createClaudeMd = false` (silently skip the offer).
-
-### c. Timestamp
-
-Mint the ISO timestamp now (before workflow dispatch, in this command wrapper context):
-
-```js
-isoTimestamp = new Date().toISOString()
-```
-
-## Pre-flight Plan
-
-Before dispatching, emit a summary and wait for confirmation:
-
-```
-## Forge Init — <project-name if discoverable, otherwise current directory name>
-
-4 phases will run via the wfl:init workflow:
-
-  1   Collect      — 5 parallel discovery scans → config.json
-                     KB folder prompt already answered above
-  2   Discover     — KB doc generation (LLM fan-out) + project-context.json
-  3   Materialize  — substitute-placeholders.cjs → fully functional workflows
-  4   Register     — versioning, manifest, cache, store entries, Tomoshibi
-
-Starting from Phase {startPhase}.
-
-Proceed? [Y/n]: ___
-```
-
-If the user declines, stop and advise them to run `/forge:init` again when ready.
-
-## Workflow Dispatch
-
-Execute the workflow:
-
-```
-workflow('wfl:init', {
-  forgeRoot,
-  kbFolder,
-  startPhase,
-  createClaudeMd,
-  isoTimestamp,
-  rawArguments: $ARGUMENTS
-})
-```
-
-Where `forgeRoot` is resolved from `.forge/config.json`'s `paths.forgeRoot` field.
-
-**Workflow-tool-missing error** — if the Workflow tool is unavailable, halt immediately
-with this message:
-
-> The Workflow tool is required to run `/forge:init`. This Claude Code build does not
-> support the Workflow tool. Upgrade Claude Code and try again.
->
-> (Alternatively, run `4ge init claude .` again to re-scaffold, then upgrade Claude Code.)
-
-Do NOT fall back to reading any other document — halt with the above message only.
-
-## Post-Workflow (on success)
-
-When `workflow('wfl:init', ...)` returns with `result.ok === true`:
-
-### Closing Banner
-
-```sh
-node .forge/tools/banners.cjs forge
-node .forge/tools/banners.cjs --subtitle "灯 SDLC ready — welcome to your Forge SDLC"
-```
-
-### Welcome Block
-
-Emit the welcome summary:
-
-```
-✓ Forge SDLC initialised
-
-Your project is now configured with:
-  · Knowledge base in {kbFolder}/
-  · Workflows, personas, and skills in .forge/
-  · Sprint-ready store in .forge/store/
-
-Next steps:
-  · /forge:new-sprint — plan your first sprint
-  · /forge:health     — verify store health
-  · /forge:plan       — plan a single task
-```
-
-### Marketplace Skills Offer
-
-If `result.skillMatches` is present and non-empty, present skill buckets by
-confidence (High → Medium → Low). For each bucket, list skill IDs and descriptions.
-Ask: `Install recommended skills? [Y/n]` (per bucket or all at once — your call).
-
-For each skill the user accepts:
-
-```sh
-node .forge/tools/manage-config.cjs set installedSkills.{skillId} true
-```
-
-Track accepted/skipped counts for the final report. **If the user skips the
-entire offer, proceed without blocking.**
-
-### KB Links Refresh
-
-Invoke the `forge:refresh-kb-links` skill via the Skill tool:
-
-```
-Skill('forge:refresh-kb-links')
-```
-
-If the Skill tool is unavailable or the skill fails, emit:
-
-```
-△ Could not auto-refresh KB links — run /forge:refresh-kb-links manually
-  to wire your CLAUDE.md to your new KB docs.
-```
-
-### Final Report
-
-```
-Forge init complete.
-
-  KB docs generated:   {count from result.kbDocCount or "see .forge/"}
-  Workflows installed: {count from result.workflowCount or "see .forge/workflows/"}
-  Commands installed:  {count from result.commandCount or "see .claude/commands/"}
-  Skills accepted:     {acceptedCount}
-  Skills skipped:      {skippedCount}
-
-Run `/forge:health` to verify the installation.
-```
-
-## Post-Workflow (on failure)
-
-When `workflow('wfl:init', ...)` returns with `result.ok === false`, surface the
-failure as structured JSON and offer a bug report:
-
-```
-✗ Forge init failed.
-
-Failure details:
-{result.failure as formatted JSON}
-
-This looks like a Forge bug. Would you like to file a report?
-Run `/forge:report-bug` — I'll pre-fill the report from this conversation.
-```
-
-## Arguments
-
-$ARGUMENTS
-
-## On Error
-
-If any step above fails unexpectedly, describe what went wrong and ask:
-
-> "This looks like a Forge bug. Would you like to file a report to help improve it?
-> Run `/forge:report-bug` — I'll pre-fill the report from this conversation."

package/dist/forge-payload/init/generation/generate-knowledge-base.md

@@ -1,56 +0,0 @@
-# Generation: Knowledge Base
-
-## Purpose
-
-Generate the project's architecture documentation, business domain documentation,
-and initial stack review checklist from the discovery context.
-
-## Inputs
-
-- Discovery context (from Phase 1)
-- `$FORGE_ROOT/meta/personas/` (to understand what agents need to know)
-
-## Setup
-
-Read the configured KB path:
-
-```sh
-KB_PATH=$(node -e "try{console.log(require('./.forge/config.json').paths.engineering)}catch{console.log('engineering')}")
-```
-
-## Outputs
-
-```
-{KB_PATH}/
-  architecture/
-    INDEX.md
-    stack.md
-    processes.md
-    database.md
-    routing.md
-    deployment.md
-  business-domain/
-    INDEX.md
-    entity-model.md
-  stack-checklist.md
-  MASTER_INDEX.md          (empty scaffold)
-  sprints/                 (empty, with .gitkeep)
-  bugs/                    (empty, with .gitkeep)
-  tools/                   (empty, created for Phase 8)
-
-.forge/
-  store/
-    sprints/               (empty, with .gitkeep)
-    tasks/                 (empty, with .gitkeep)
-    bugs/                  (empty, with .gitkeep)
-    events/                (empty, with .gitkeep)
-```
-
-## Instructions
-
-1. For each architecture sub-doc, synthesise from the discovery context
-2. Include confidence header: `<!-- AUTO-GENERATED by /forge:init — confidence: N% -->`
-3. Mark uncertain lines with `[?]`
-4. The stack-checklist should have 5-10 items based on auth/framework detection
-5. entity-model.md should list all discovered entities with fields and relationships
-6. INDEX.md files should link to all sub-docs with one-line descriptions

package/dist/forge-payload/init/generation/generate-personas.md

@@ -1,54 +0,0 @@
-# Generation: Personas
-
-## Purpose
-
-Generate project-specific agent persona context from meta-personas,
-the discovery context, and the generated knowledge base.
-
-## Inputs
-
-- `$FORGE_ROOT/meta/personas/meta-*.md` (6 meta-personas)
-- Discovery context (from Phase 1)
-- Generated knowledge base (from Phase 2)
-
-## Outputs
-
-Personas are written as standalone files in `.forge/personas/`.
-Each file is named after the persona's role (e.g., `.forge/personas/supervisor.md`).
-
-These files are consumed by Phase 5 (Generate Atomic Workflows) to establish the agent's identity, knowledge, and constraints.
-
-## Instructions
-
-For each meta-persona, read its Generation Instructions section and
-produce a project-specific version that incorporates:
-- The project's actual stack, test commands, build commands
-- The project's actual entity names and business rules
-- The project's actual auth patterns and conventions
-- The project's actual directory structure and paths
-
-**Persona block format** — each persona file opens with a single line using the
-persona's symbol (from its `## Symbol` section) and a quiet first-person announcement.
-Follow the `Persona block format` template in each meta-persona's Generation Instructions,
-substituting `{Project}` with the project's name. The line should be brief, present-tense,
-and speak to what the persona is about to do — not a role description, but a voice.
-
-## Skill Invocation Wiring
-
-Read `.forge/config.json` for `installedSkills`. For each installed skill
-that is relevant to a persona's domain, add an explicit invocation instruction
-to that persona's context.
-
-Read `$FORGE_ROOT/meta/skill-recommendations.md` for the persona integration
-pattern. Apply it: the instruction must be a YOU MUST directive placed at
-the relevant persona's context.
-
-Example — if `vue-best-practices` is installed and the persona is Supervisor:
-
-> "When reviewing Vue components, YOU MUST invoke the `vue-best-practices`
-> skill before applying the stack checklist. That skill provides universal
-> Vue technique depth; the checklist provides project conventions. Both are required."
-
-This wiring is what distinguishes Forge-generated personas from plain skill
-invocation: the persona carries project-specific knowledge *and* knows exactly
-when to reach for a universal technique skill. Neither layer alone is sufficient.

package/dist/forge-payload/init/generation/generate-skills.md

@@ -1,36 +0,0 @@
-# Generation: Skills
-
-## Purpose
-
-Generate project-specific skill sets for each persona, mapping universal 
-techniques to project-specific tools and contexts.
-
-## Inputs
-
-- `$FORGE_ROOT/meta/skills/meta-*.md` (Meta-skill templates)
-- Discovery context (from Phase 1)
-- Generated knowledge base (from Phase 2)
-- `.forge/config.json` (specifically `installedSkills`)
-
-## Outputs
-
-Skill sets are written as standalone files in `.forge/skills/`.
-Each file uses the `-skills.md` suffix matching the persona role (e.g., `.forge/skills/supervisor-skills.md`).
-
-## Instructions
-
-For each persona role defined in the project:
-1. Identify the relevant meta-skills from `$FORGE_ROOT/meta/skills/`.
-2. For each skill, produce a project-interpolated version that:
-   - Replaces generic placeholders with actual project tools, libraries, and paths.
-   - Incorporates specific constraints discovered during Phase 1.
-   - Maps universal techniques to the project's actual implementation patterns.
-3. Integrate `installedSkills` from `.forge/config.json`:
-   - If a marketplace skill is installed that enhances a specific technique, 
-     explicitly reference it in the skill set.
-   - Ensure the skill set explains *how* the persona should combine the 
-     universal marketplace skill with the project-specific skill set.
-
-**Skill set format**:
-Each file should be structured as a cohesive set of capabilities, 
-techniques, and checklists tailored for that specific role within the project.

package/dist/forge-payload/init/generation/generate-templates.md

@@ -1,39 +0,0 @@
-# Generation: Templates
-
-## Purpose
-
-Generate project-specific document templates from meta-templates,
-adding stack-specific sections.
-
-## Inputs
-
-- `$FORGE_ROOT/meta/templates/meta-*.md` (8 meta-templates)
-- Discovery context (from Phase 1)
-- Generated knowledge base (from Phase 2)
-
-## Outputs
-
-`.forge/templates/` with project-specific templates:
-- `TASK_PROMPT_TEMPLATE.md`
-- `PLAN_TEMPLATE.md`
-- `PROGRESS_TEMPLATE.md`
-- `CODE_REVIEW_TEMPLATE.md`
-- `PLAN_REVIEW_TEMPLATE.md`
-- `SPRINT_REQUIREMENTS_TEMPLATE.md`
-- `SPRINT_MANIFEST_TEMPLATE.md`
-- `RETROSPECTIVE_TEMPLATE.md`
-
-## Instructions
-
-For each meta-template:
-1. Read its sections and Generation Instructions
-2. Add framework-specific subsections based on the detected stack
-3. Reference the project's actual entity names and test output formats
-4. Use the project's ID format in template headers
-
-After writing each template file, record it in the generation manifest:
-```sh
-node {paths.tools}/generation-manifest.cjs record {paths.templates}/{filename}.md
-```
-
-If `generation-manifest.cjs` is not yet installed, skip silently.