siesa-agents 2.1.88 → 2.1.90

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.
Files changed (7) hide show
  1. package/claude/skills/sa-init-devops/SKILL.md +35 -36
  2. package/package.json +1 -1
  3. package/siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/templates/epics-template.md +6 -4
  4. package/siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/workflow_ext.md +27 -26
  5. package/siesa-agents/core/tasks/shard-doc.md +17 -14
  6. package/siesa-agents/resources/conventions/epic-story-naming-convention.md +130 -0
  7. package/siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js +46 -50
package/claude/skills/sa-init-devops/SKILL.md CHANGED
@@ -1,33 +1,33 @@
1
1
  ---
2
2
  name: sa-init-devops
3
- description: 'Bootstrap the DevOps workspace and skills in Siesa-Agents in one shot: clones architecture-sa-devops into `_siesa-agents/devops/`, detects conflicts between local and upstream copies of the `sa-*` DevOps skills and the deploy workflows (asks the user via AskUserQuestion which side to keep when there are diffs), then MOVES the chosen versions into `.claude/skills/` (and `claude/skills/`) so `/sa-aplicar`, `/sa-nuevo-servicio`, `/sa-auditar-servicio`, etc. become immediately invocable, MOVES the workflows into `.github/workflows/`, deletes the now-empty `.claude/` and `.github/` directories from the clone, then mirrors the cleaned tree to `siesa-agents/devops/`. Use whenever the user wants to set up the DevOps workspace for the first time, refresh it after upstream changes, mentions needing terraform/k8s/environments files, or when any `sa-*` deploy skill is missing from Claude Code.'
3
+ description: 'Bootstrap the DevOps workspace and commands in Siesa-Agents in one shot: clones business-shared-deploy into `_siesa-agents/devops/`, detects conflicts between local and upstream copies of the `flow-*`/`agent-*` DevOps slash commands and the deploy workflows (asks the user via AskUserQuestion which side to keep when there are diffs), then MOVES the chosen versions into `.claude/commands/` (and `claude/commands/`) so `/flow-aplicar`, `/flow-nuevo-servicio`, `/flow-auditar-servicio`, etc. become immediately invocable, MOVES the workflows into `.github/workflows/`, deletes the now-empty `.claude/` and `.github/` directories from the clone, then mirrors the cleaned tree to `siesa-agents/devops/`. Use whenever the user wants to set up the DevOps workspace for the first time, refresh it after upstream changes, mentions needing terraform/k8s/environments files, or when any `flow-*` deploy command is missing from Claude Code.'
4
4
  ---
5
5
 
6
- # Init DevOps — clone the workspace + materialize the DevOps skills
6
+ # Init DevOps — clone the workspace + materialize the DevOps commands
7
7
 
8
- **Goal:** In a single invocation, populate Siesa-Agents with everything an engineer needs to run the Finance DevOps skills. After a successful run the layout is:
8
+ **Goal:** In a single invocation, populate Siesa-Agents with everything an engineer needs to run the Finance DevOps commands. After a successful run the layout is:
9
9
 
10
10
  | Location | Contents |
11
11
  |---|---|
12
- | `_siesa-agents/devops/` | Git working tree cloned from `architecture-sa-devops`. **Only** the deployment workspace: `terraform/`, `k8s/`, `environments/`, `scripts/`, `cicd-templates/`, `docs/`, `CLAUDE.md`, `README.md`, `.gitignore`. The `.claude/` and `.github/` directories from upstream are wiped from the clone after their contents are moved to Siesa-Agents level. |
12
+ | `_siesa-agents/devops/` | Git working tree cloned from `business-shared-deploy`. **Only** the deployment workspace: `terraform/`, `k8s/`, `environments/`, `scripts/`, `cicd-templates/`, `docs/`, `seed/`, `CLAUDE.md`, `README.md`, `.gitignore`. The `.claude/` and `.github/` directories from upstream are wiped from the clone after their contents are moved to Siesa-Agents level. |
13
13
  | `siesa-agents/devops/` | Flat snapshot mirror of the cleaned clone (no `.git/`, no `.claude/`, no `.github/`). The npm-publishable copy. |
14
- | `.claude/skills/sa-*/SKILL.md` | The 8 DevOps skills moved out of the clone: `sa-aplicar`, `sa-auditar-servicio`, `sa-nueva-transversal`, `sa-nuevo-ambiente`, `sa-nuevo-servicio`, `sa-onboard-db`, `sa-registrar-permisos`, `sa-agent-sre-sentinel`. |
15
- | `claude/skills/sa-*/SKILL.md` | Same skills, in the npm mirror. |
16
- | `.github/workflows/*.yml` | The 4 deploy workflow files moved out of the clone (`infra-pipeline-dev/qa/shared.yml`, `reconcile-geographic-projections.yml`). **These do not fire from Siesa-Agents** — gitignored, for visibility only. They fire from `architecture-sa-devops` where they originally live. |
14
+ | `.claude/commands/*.md` | The DevOps slash commands moved out of the clone: `flow-aplicar`, `flow-auditar-servicio`, `flow-nueva-transversal`, `flow-nuevo-ambiente`, `flow-nuevo-servicio`, `flow-onboard-db`, `flow-registrar-permisos`, `agent-sre-sentinel`. |
15
+ | `claude/commands/*.md` | Same commands, in the npm mirror. |
16
+ | `.github/workflows/*.yml` | The deploy workflow files moved out of the clone (`infra-pipeline-dev.yml`, `infra-pipeline-qa.yml`, `infra-pipeline-shared.yml`). **These do not fire from Siesa-Agents** — gitignored, for visibility only. They fire from `business-shared-deploy` where they originally live. |
17
17
 
18
- **Why this matters:** Without this skill, Siesa-Agents is missing every Finance DevOps capability. The DevOps skills cannot live statically in this repo because they evolve with the deploy workspace (`environments/`, `terraform/`, `k8s/`) — keeping them in sync would require a PR every time Finance bumps the workspace. Instead the upstream `architecture-sa-devops` repo is the single source of truth, and this skill pulls everything down on demand.
18
+ **Why this matters:** Without this skill, Siesa-Agents is missing every Finance DevOps capability. The DevOps commands cannot live statically in this repo because they evolve with the deploy workspace (`environments/`, `terraform/`, `k8s/`) — keeping them in sync would require a PR every time Finance bumps the workspace. Instead the upstream `business-shared-deploy` repo is the single source of truth, and this skill pulls everything down on demand.
19
19
 
20
20
  ## When to use this skill
21
21
 
22
22
  Trigger immediately when the user:
23
23
 
24
- - Says "init devops", "setup devops", "clone architecture-sa-devops", "trae el workspace de despliegue", or similar
25
- - Tries to invoke any deploy skill (`/sa-aplicar`, `/sa-nuevo-servicio`, etc.) and Claude Code reports the skill is not available
26
- - Tries to invoke a deploy skill and it complains about missing paths (`environments/shared.yaml`, `terraform/environments/`, `k8s/overlays/`, etc.)
27
- - Mentions wanting to refresh / pull latest from `architecture-sa-devops`
28
- - Has just cloned Siesa-Agents and is preparing to use the deploy skills
24
+ - Says "init devops", "setup devops", "clone business-shared-deploy", "trae el workspace de despliegue", or similar
25
+ - Tries to invoke any deploy command (`/flow-aplicar`, `/flow-nuevo-servicio`, etc.) and Claude Code reports the command is not available
26
+ - Tries to invoke a deploy command and it complains about missing paths (`environments/shared.yaml`, `terraform/environments/`, `k8s/overlays/`, etc.)
27
+ - Mentions wanting to refresh / pull latest from `business-shared-deploy`
28
+ - Has just cloned Siesa-Agents and is preparing to use the deploy commands
29
29
 
30
- Do **not** trigger for: editing the deploy skills themselves (those edits must go to `architecture-sa-devops`), modifying terraform/k8s contents (those go to `architecture-sa-devops` too), or anything unrelated to bootstrapping.
30
+ Do **not** trigger for: editing the deploy commands themselves (those edits must go to `business-shared-deploy`), modifying terraform/k8s contents (those go to `business-shared-deploy` too), or anything unrelated to bootstrapping.
31
31
 
32
32
  ## Prerequisites
33
33
 
@@ -35,7 +35,7 @@ Do **not** trigger for: editing the deploy skills themselves (those edits must g
35
35
  - The user has network access to GitHub.com.
36
36
  - The helper script lives at `_siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js` (source of truth) and is mirrored to `siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js` (npm copy). Prefer the source-of-truth path when both exist.
37
37
 
38
- If the script is missing or `git` is unavailable, stop and tell the user — do not improvise the work inline. The script handles all the edge cases (existing clone with wrong remote, partial state, conflicting local edits, skill/workflow copy overwrites) that an inline shell sequence would miss.
38
+ If the script is missing or `git` is unavailable, stop and tell the user — do not improvise the work inline. The script handles all the edge cases (existing clone with wrong remote, partial state, conflicting local edits, command/workflow copy overwrites) that an inline shell sequence would miss.
39
39
 
40
40
  ## Workflow
41
41
 
@@ -52,19 +52,19 @@ node _siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js
52
52
  Default mode does:
53
53
 
54
54
  1. **Clone or update.** `git clone` (if `_siesa-agents/devops/` does not exist) **or** `git checkout HEAD -- .claude .github && git fetch && git checkout main && git pull --ff-only` (if it does). The `git checkout HEAD -- .claude .github` step restores files that the previous run wiped so the pull doesn't fail on "uncommitted deletions".
55
- 2. **Dry-run conflict detection.** For each upstream `.claude/skills/sa-*/SKILL.md` and `.github/workflows/*.yml`, compare to the local copy in Siesa-Agents (`.claude/skills/`, `claude/skills/`, and `.github/workflows/`). The bootstrap skill `sa-init-devops` is always excluded from this comparison.
56
- 3. **If any local file differs from upstream → abort.** Exit 4 with `status: "conflicts"` and lists `skill_conflicts` / `workflow_conflicts`. Nothing is mutated. The model proceeds to Step 2.
55
+ 2. **Dry-run conflict detection.** For each upstream `.claude/commands/*.md` and `.github/workflows/*.yml`, compare to the local copy in Siesa-Agents (`.claude/commands/`, `claude/commands/`, and `.github/workflows/`).
56
+ 3. **If any local file differs from upstream → abort.** Exit 4 with `status: "conflicts"` and lists `command_conflicts` / `workflow_conflicts`. Nothing is mutated. The model proceeds to Step 2.
57
57
  4. **If no conflicts → apply.** Copy the upstream files into Siesa-Agents (creating new files, leaving identical ones alone), then delete `.claude/` and `.github/` from the clone working tree, then mirror the cleaned tree to `siesa-agents/devops/`. Exit 0.
58
58
 
59
59
  ### Step 2 — Handle conflicts (only when `status: "conflicts"`)
60
60
 
61
- When the JSON output has `status: "conflicts"`, **ask the user which side to keep** before any local file is changed. Use `AskUserQuestion` with the list of conflicting items from `skill_conflicts` and `workflow_conflicts`.
61
+ When the JSON output has `status: "conflicts"`, **ask the user which side to keep** before any local file is changed. Use `AskUserQuestion` with the list of conflicting items from `command_conflicts` and `workflow_conflicts`.
62
62
 
63
63
  For most cases, one question with three options is enough:
64
64
 
65
65
  ```
66
- question: "Estos N archivos locales difieren del upstream architecture-sa-devops:
67
- <list with skill_conflicts + workflow_conflicts>
66
+ question: "Estos N archivos locales difieren del upstream business-shared-deploy:
67
+ <list with command_conflicts + workflow_conflicts>
68
68
  ¿Cómo resuelvo?"
69
69
  options:
70
70
  - "Take all from upstream" (overwrite all conflicts with upstream version)
@@ -87,7 +87,7 @@ node _siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js --keep-local
87
87
  If the user picks **"Resolve per file"**, ask one more question per conflicting item (with `AskUserQuestion`, max 4 items per call — chunk if needed) collecting which ones to keep local, then re-run with `--keep-local=<csv>`:
88
88
 
89
89
  ```bash
90
- node _siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js --keep-local=sa-aplicar,infra-pipeline-qa.yml
90
+ node _siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js --keep-local=flow-aplicar.md,infra-pipeline-qa.yml
91
91
  ```
92
92
 
93
93
  The named items keep their local version; everything else takes upstream.
@@ -96,21 +96,21 @@ The named items keep their local version; everything else takes upstream.
96
96
 
97
97
  After the (possibly second) successful invocation, read the `status` field:
98
98
 
99
- - **`status: "cloned"`** — Fresh clone. Tell the user: "Cloned `architecture-sa-devops`. Created `<N>` skills + `<M>` workflows in Siesa-Agents. The deploy skills (`/sa-aplicar`, `/sa-nuevo-servicio`, etc.) are now available in Claude Code."
100
- - **`status: "updated"`** — Existing clone pulled new commits. Report `before_sha..after_sha` and the per-category counts (`skills_created`, `skills_overwritten`, `skills_kept_local`, `skills_unchanged`, same for workflows).
99
+ - **`status: "cloned"`** — Fresh clone. Tell the user: "Cloned `business-shared-deploy`. Created `<N>` commands + `<M>` workflows in Siesa-Agents. The deploy commands (`/flow-aplicar`, `/flow-nuevo-servicio`, etc.) are now available in Claude Code."
100
+ - **`status: "updated"`** — Existing clone pulled new commits. Report `before_sha..after_sha` and the per-category counts (`commands_created`, `commands_overwritten`, `commands_kept_local`, `commands_unchanged`, same for workflows).
101
101
  - **`status: "already-cloned"`** — Local clone was already at the latest HEAD; no upstream change. The counts reflect what happened in the apply step (likely all `unchanged` if everything matched).
102
102
  - **`status: "conflicts"`** — Should only appear on the FIRST run when conflicts exist; never on a re-run with a policy flag. If you see this twice, surface it as a bug.
103
103
  - **`status: "invalid-source"`** — `_siesa-agents/devops/` exists but is not a git working tree. Surface the message verbatim and stop. Do not try to delete the directory automatically.
104
104
  - **`status: "wrong-remote"`** — Same directory is a clone of a different repo. Surface the message and stop.
105
105
  - **`status: "clone-failed"` / `"fetch-failed"` / `"pull-failed"` / `"checkout-failed"`** — Git operation failed. Surface the underlying git error verbatim. Common causes: no network, branch diverged, local edits blocking ff-pull.
106
106
 
107
- ### Step 3 — Remind the user about cwd for the deploy skills
107
+ ### Step 3 — Remind the user about cwd for the deploy commands
108
108
 
109
109
  After a successful run (any of `cloned`, `updated`, `already-cloned`), remind the user once:
110
110
 
111
- > Las skills de despliegue (`/sa-aplicar`, `/sa-nuevo-servicio`, etc.) asumen que el cwd está dentro de `_siesa-agents/devops/`. Cambia de directorio (`cd _siesa-agents/devops/`) antes de invocarlas, para que las rutas relativas (`environments/`, `terraform/`, `k8s/`) se resuelvan correctamente.
111
+ > Los comandos de despliegue (`/flow-aplicar`, `/flow-nuevo-servicio`, etc.) asumen que el cwd está dentro de `_siesa-agents/devops/`. Cambia de directorio (`cd _siesa-agents/devops/`) antes de invocarlos, para que las rutas relativas (`environments/`, `terraform/`, `k8s/`) se resuelvan correctamente.
112
112
 
113
- If the user invokes one of those skills from elsewhere, the relative paths in their workflows won't resolve and they'll see confusing "file not found" errors.
113
+ If the user invokes one of those commands from elsewhere, the relative paths in their instructions won't resolve and they'll see confusing "file not found" errors.
114
114
 
115
115
  ## Optional flags
116
116
 
@@ -118,28 +118,27 @@ If the user invokes one of those skills from elsewhere, the relative paths in th
118
118
  - `--mirror-only` — Skip the git + move steps; rebuild `siesa-agents/devops/` from the existing clone. Useful when only the mirror is out of sync.
119
119
  - `--take-upstream` — Resolve all conflicts in favor of upstream (overwrite every conflicting local file). Use after the user confirms they want the upstream versions.
120
120
  - `--keep-local` — Keep every local file as-is; only create files that are entirely new in upstream. Use when the user wants to preserve all local edits.
121
- - `--keep-local=<csv>` — Keep these specific items local (comma-separated names matching `skill_conflicts` / `workflow_conflicts` entries); overwrite all other conflicts with upstream. Example: `--keep-local=sa-aplicar,infra-pipeline-qa.yml`.
121
+ - `--keep-local=<csv>` — Keep these specific items local (comma-separated names matching `command_conflicts` / `workflow_conflicts` entries); overwrite all other conflicts with upstream. Example: `--keep-local=flow-aplicar.md,infra-pipeline-qa.yml`.
122
122
 
123
123
  The three policy flags are mutually exclusive; passing more than one returns exit code 1.
124
124
 
125
125
  ## Edge cases
126
126
 
127
- - **Skill conflicts.** The default run aborts on any conflict (local file differs from upstream) and lists them in `skill_conflicts` / `workflow_conflicts`. The model then asks the user with `AskUserQuestion` and re-runs with `--take-upstream`, `--keep-local`, or `--keep-local=<csv>`. Engineers who want their custom edits to survive automatic refresh should fork `architecture-sa-devops` and update `REMOTE_URL` at the top of the helper script — that keeps their fork as the upstream source of truth.
128
- - **The bootstrap skill is never overwritten.** `sa-init-devops/` is explicitly excluded from the copy loop in the helper, so re-running the skill cannot trash itself.
129
- - **The clone has 12 "deleted" files in `git status` after every run.** Expected. The script moves `.claude/skills/sa-*/SKILL.md` and `.github/workflows/*.yml` out of the clone and deletes those directories, but the files are still tracked in upstream HEAD. The next run restores them via `git checkout HEAD -- .claude .github` before pulling, then moves and deletes them again. Engineers should never `git add` or `git commit` those deletions inside `_siesa-agents/devops/` — they are intentional working-tree-only state.
130
- - **Workflows in Siesa-Agents `.github/workflows/`** — moved for inspection but gitignored (see `.gitignore`), so engineers can read them locally but they never fire on Siesa-Agents PRs. The same workflows fire on PRs / pushes to `architecture-sa-devops`, which is where they live.
127
+ - **Command conflicts.** The default run aborts on any conflict (local file differs from upstream) and lists them in `command_conflicts` / `workflow_conflicts`. The model then asks the user with `AskUserQuestion` and re-runs with `--take-upstream`, `--keep-local`, or `--keep-local=<csv>`. Engineers who want their custom edits to survive automatic refresh should fork `business-shared-deploy` and update `REMOTE_URL` at the top of the helper script — that keeps their fork as the upstream source of truth.
128
+ - **The clone shows the moved files as "deleted" in `git status` after every run.** Expected. The script moves `.claude/commands/*.md` and `.github/workflows/*.yml` out of the clone and deletes those directories, but the files are still tracked in upstream HEAD. The next run restores them via `git checkout HEAD -- .claude .github` before pulling, then moves and deletes them again. Engineers should never `git add` or `git commit` those deletions inside `_siesa-agents/devops/` — they are intentional working-tree-only state.
129
+ - **Workflows in Siesa-Agents `.github/workflows/`** — moved for inspection but gitignored (see `.gitignore`), so engineers can read them locally but they never fire on Siesa-Agents PRs. The same workflows fire on PRs / pushes to `business-shared-deploy`, which is where they live.
131
130
  - **`_siesa-agents/devops/` exists from a previous run with local edits to non-managed paths.** The restore step touches only `.claude` and `.github`; edits to `environments/`, `terraform/`, `k8s/`, etc. survive the restore step but `git pull --ff-only` will fail if they conflict with upstream. The script surfaces the git error verbatim. The user should commit, stash, or discard their local changes and re-run.
132
- - **The directory exists but isn't a clone of `architecture-sa-devops`.** The script reports `invalid-source` or `wrong-remote` and refuses to delete. The user must move it aside manually.
133
- - **The mirror or local skills/workflows have manual edits.** The script overwrites them on every run — that is by design. If you need to preserve edits, make them in the upstream `architecture-sa-devops` repo, not locally.
131
+ - **The directory exists but isn't a clone of `business-shared-deploy`.** The script reports `invalid-source` or `wrong-remote` and refuses to delete. The user must move it aside manually.
132
+ - **The mirror or local commands/workflows have manual edits.** The script overwrites them on every run — that is by design. If you need to preserve edits, make them in the upstream `business-shared-deploy` repo, not locally.
134
133
  - **No `git` on PATH.** The first `tryGit` call fails; the script surfaces a `clone-failed` or `fetch-failed` status. Tell the user to install git or add it to PATH.
135
134
 
136
135
  ## Upstream URL
137
136
 
138
- The script currently points at `https://github.com/ssancheze912/architecture-sa-devops.git` as a temporary location while SiesaTeams org-create permissions are being arranged. When the repo is transferred to `https://github.com/SiesaTeams/architecture-sa-devops.git`, update `REMOTE_URL` at the top of the helper script and ship the change.
137
+ The script points at `https://github.com/SiesaTeams/business-shared-deploy.git`. If Finance forks or relocates the deploy repo, update `REMOTE_URL` at the top of the helper script (both the source-of-truth and mirror copies) and ship the change.
139
138
 
140
139
  ## Reminders
141
140
 
142
- - Step 1 is always safe to re-run. Idempotency is built into the script — on `already-cloned` it does nothing destructive other than refresh the mirror and re-copy the skills/workflows from upstream (which is the intended behavior — keeping local in sync with upstream).
141
+ - Step 1 is always safe to re-run. Idempotency is built into the script — on `already-cloned` it does nothing destructive other than refresh the mirror and re-copy the commands/workflows from upstream (which is the intended behavior — keeping local in sync with upstream).
143
142
  - Never delete `_siesa-agents/devops/` from this skill. The user owns that directory once cloned; they may have in-progress edits.
144
- - Do not modify the DevOps skills themselves from this skill. If a deploy skill's behavior needs to change, that is a PR to `architecture-sa-devops`, not a local edit (which would be wiped on the next run).
143
+ - Do not modify the DevOps commands themselves from this skill. If a deploy command's behavior needs to change, that is a PR to `business-shared-deploy`, not a local edit (which would be wiped on the next run).
145
144
  - The script's JSON output is the contract. If a future field appears (e.g. a new status), surface it to the user rather than guessing what it means.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "siesa-agents",
3
- "version": "2.1.88",
3
+ "version": "2.1.90",
4
4
  "description": "Paquete para instalar y configurar agentes SIESA en tu proyecto",
5
5
  "main": "index.js",
6
6
  "bin": {
package/siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/templates/epics-template.md CHANGED
@@ -16,9 +16,9 @@ Add the following block inside each Epic section, **after the Epic goal statemen
16
16
  These criteria validate the COMPLETE epic functionality.
17
17
  -->
18
18
 
19
- - [ ] **AC-E{{N}}.1:** {{high_level_criterion_1}}
20
- - [ ] **AC-E{{N}}.2:** {{high_level_criterion_2}}
21
- - [ ] **AC-E{{N}}.3:** {{high_level_criterion_3}}
19
+ - [ ] **AC-E{{NNN}}-{{E}}.1:** {{high_level_criterion_1}}
20
+ - [ ] **AC-E{{NNN}}-{{E}}.2:** {{high_level_criterion_2}}
21
+ - [ ] **AC-E{{NNN}}-{{E}}.3:** {{high_level_criterion_3}}
22
22
 
23
23
  **FRs covered:** {{epic_frs}}
24
24
  ```
@@ -41,6 +41,8 @@ Add the following block inside each Epic section, **after the Epic goal statemen
41
41
 
42
42
  ## Numbering Convention
43
43
 
44
- - Epic N → criteria are `AC-E{N}.1`, `AC-E{N}.2`, `AC-E{N}.3`
44
+ Epic and story IDs follow the centralized convention in `@_siesa-agents/resources/conventions/epic-story-naming-convention.md`.
45
+
46
+ - Epic `{NNN}-{E}` → criteria are `AC-E{NNN}-{E}.1`, `AC-E{NNN}-{E}.2`, `AC-E{NNN}-{E}.3` (e.g., Epic 16-1 → `AC-E16-1.1`)
45
47
  - Minimum 3, maximum 5 criteria per epic
46
48
  - Each criterion must map to at least one story within the epic
package/siesa-agents/bmm/workflows/3-solutioning/create-epics-and-stories/workflow_ext.md CHANGED
@@ -52,27 +52,26 @@ Una vez confirmada la lista de features, inyectar las siguientes reglas de estru
52
52
 
53
53
  ### Reglas de estructura para el documento `epics.md`:
54
54
 
55
+ > **Convención de IDs (OBLIGATORIA):** Los IDs de épicas e historias siguen la convención centralizada definida en `@_siesa-agents/resources/conventions/epic-story-naming-convention.md`. Formato: épicas `{NNN}-{E}`, historias `{NNN}-{E}.{HH}`, donde `NNN` es el número del feature (sin ceros a la izquierda, tomado del PRD/shard `feat-{NNN}-*`).
56
+
55
57
  1. **Agrupación por Feature**: Cada feature confirmado será un heading `##` en el documento. Las épicas de ese feature van DENTRO como `###`. Las stories van como `####`.
56
58
 
57
59
  2. **Jerarquía de headings obligatoria**:
58
60
  - `## {Feature Name}` — agrupa las épicas de un feature
59
- - `### Epic {N}: {Title}` — cada épica dentro del feature
60
- - `#### Story {N}.{M}: {Title}` — cada story dentro de la épica
61
+ - `### Epic {NNN}-{E}: {Title}` — cada épica dentro del feature (ej: `### Epic 16-1: ...`)
62
+ - `#### Story {NNN}-{E}.{HH}: {Title}` — cada story dentro de la épica (ej: `#### Story 16-1.01: ...`)
61
63
 
62
64
  Nota: La generación del documento de epicas no se realiza por DOMINIO sino por FEATURE.
63
65
 
64
- 3. **Numeración de épicas GLOBAL y CONSECUTIVA**: La numeración de épicas NO se reinicia por feature. Es un consecutivo único a lo largo de todo el documento. Ejemplo:
66
+ 3. **Numeración de épicas POR FEATURE con prefijo de feature**: El número de épica (`E`) es secuencial DENTRO de cada feature, comenzando en `1`. El prefijo `{NNN}-` garantiza la unicidad global del ID. Ejemplo (feature 16 y feature 17):
65
67
  ```
66
- ## Measurement Units
67
- ### Epic 1: ...
68
- ### Epic 2: ...
69
-
70
- ## Cost Models
71
- ### Epic 3: ... ← continúa desde 3, NO reinicia en 1
72
- ### Epic 4: ...
68
+ ## Measurement Units ← feat-016
69
+ ### Epic 16-1: ...
70
+ ### Epic 16-2: ...
73
71
 
74
- ## Storages
75
- ### Epic 5: ...
72
+ ## Cost Models ← feat-017
73
+ ### Epic 17-1: ... ← reinicia en 1, el prefijo 17- lo hace único
74
+ ### Epic 17-2: ...
76
75
  ```
77
76
 
78
77
  4. **Secciones generales** (`## Overview`, `## Requirements Inventory`, etc.) permanecen igual que en el template estándar, al nivel `##`.
@@ -82,16 +81,16 @@ Una vez confirmada la lista de features, inyectar las siguientes reglas de estru
82
81
  ```
83
82
  ## Epic List
84
83
 
85
- ### {Feature Name 1}
86
- - Epic 1: [Title] — FRs: FR1, FR2
87
- - Epic 2: [Title] — FRs: FR3
84
+ ### {Feature Name 1} ← feat-016
85
+ - Epic 16-1: [Title] — FRs: FR1, FR2
86
+ - Epic 16-2: [Title] — FRs: FR3
88
87
 
89
- ### {Feature Name 2}
90
- - Epic 3: [Title] — FRs: FR4, FR5
91
- - Epic 4: [Title] — FRs: FR6
88
+ ### {Feature Name 2} ← feat-017
89
+ - Epic 17-1: [Title] — FRs: FR4, FR5
90
+ - Epic 17-2: [Title] — FRs: FR6
92
91
  ```
93
92
 
94
- 6. **Step 3 (Stories)**: Al generar épicas y stories, escribir cada feature como sección `##`, con sus épicas como `###` y stories como `####`. La numeración de stories sigue el patrón `{epic_num}.{story_num}` (ej: Story 3.1, Story 3.2 para Epic 3).
93
+ 6. **Step 3 (Stories)**: Al generar épicas y stories, escribir cada feature como sección `##`, con sus épicas como `###` y stories como `####`. La numeración de stories sigue el patrón `{NNN}-{E}.{HH}` con `HH` de dos dígitos (ej: Story 16-3.01, Story 16-3.02 para Epic 16-3).
95
94
 
96
95
  7. **Marcador `FEATURE_CODE_JIRA`**: Cada archivo shard de épica debe comenzar con la siguiente línea como **primera línea del archivo**, antes de cualquier heading:
97
96
  ```
@@ -159,11 +158,13 @@ For EACH epic, after the goal statement, add **3-5 high-level Acceptance Criteri
159
158
 
160
159
  ```markdown
161
160
  #### Acceptance Criteria (QA Validation)
162
- - [ ] **AC-E{N}.1:** [High-level criterion from user perspective]
163
- - [ ] **AC-E{N}.2:** [High-level criterion from user perspective]
164
- - [ ] **AC-E{N}.3:** [High-level criterion from user perspective]
161
+ - [ ] **AC-E{NNN}-{E}.1:** [High-level criterion from user perspective]
162
+ - [ ] **AC-E{NNN}-{E}.2:** [High-level criterion from user perspective]
163
+ - [ ] **AC-E{NNN}-{E}.3:** [High-level criterion from user perspective]
165
164
  ```
166
165
 
166
+ Donde `{NNN}-{E}` es el ID de la épica según la convención centralizada (ej: `AC-E16-1.1`, `AC-E16-1.2`). Ver `@_siesa-agents/resources/conventions/epic-story-naming-convention.md`.
167
+
167
168
  **🎯 WRITING GUIDELINES:**
168
169
 
169
170
  ✅ **DO (Business language, user perspective):**
@@ -190,10 +191,10 @@ Template reference: `@_siesa-agents/bmm/workflows/3-solutioning/create-epics-and
190
191
  After all epics and stories are generated, validate that every Epic AC has at least one supporting story:
191
192
 
192
193
  ```
193
- Epic N: [Title]
194
- ├── AC-EN.1: [Criterion] → Supported by: Story N.X, Story N.Y
195
- ├── AC-EN.2: [Criterion] → Supported by: Story N.Z
196
- └── AC-EN.3: [Criterion] → Supported by: Story N.X, Story N.W
194
+ Epic 16-1: [Title]
195
+ ├── AC-E16-1.1: [Criterion] → Supported by: Story 16-1.01, Story 16-1.02
196
+ ├── AC-E16-1.2: [Criterion] → Supported by: Story 16-1.03
197
+ └── AC-E16-1.3: [Criterion] → Supported by: Story 16-1.01, Story 16-1.04
197
198
  ```
198
199
 
199
200
  **🚨 VALIDATION RULES:**
package/siesa-agents/core/tasks/shard-doc.md CHANGED
@@ -24,7 +24,7 @@ The agent determines the sharding mode by analyzing the document content:
24
24
  | Signal | Detected Mode |
25
25
  |--------|--------------|
26
26
  | Contains `### feature —` or `### feature -` headings | **PRD Mode** |
27
- | Contains `## Epic` headings with story subsections (`### Story`) | **Epic Mode** |
27
+ | Contains `### Epic` headings with story subsections (`#### Story`) | **Epic Mode** |
28
28
  | Neither detected | **Generic Mode** (standard `##` level sharding) |
29
29
 
30
30
  The agent MUST confirm the detected mode with the user before proceeding.
@@ -119,32 +119,34 @@ Section Map (PRD Mode):
119
119
 
120
120
  ## Mode 2: Epic Sharding
121
121
 
122
+ > **Epic/Story ID convention (MANDATORY):** Epic and story IDs follow the centralized convention defined in `@_siesa-agents/resources/conventions/epic-story-naming-convention.md`: epics `{NNN}-{E}`, stories `{NNN}-{E}.{HH}` (e.g., `Epic 16-1`, `Story 16-1.01`). Sharding MUST preserve these IDs as-is in the shard content and use them in the index.
123
+
122
124
  ### When It Applies
123
125
 
124
126
  The source document is an epics breakdown organized by feature, where each feature groups its epics under a `##` heading:
125
127
 
126
128
  ```markdown
127
- # Project Name - Epic Breakdown
129
+ # feat-016 — Project Name - Epic Breakdown
128
130
 
129
131
  ## Overview
130
132
  ...
131
133
 
132
134
  ## Measurement Units
133
135
 
134
- ### Epic 1: Core Entity & CRUD API
135
- #### Story 1.1: Domain Entity & Database Schema
136
+ ### Epic 16-1: Core Entity & CRUD API
137
+ #### Story 16-1.01: Domain Entity & Database Schema
136
138
  ...
137
- #### Story 1.2: API Setup & Secure Create Endpoint
139
+ #### Story 16-1.02: API Setup & Secure Create Endpoint
138
140
  ...
139
141
 
140
- ### Epic 2: Business Rules & Integrity
141
- #### Story 2.1: Usage Detection Service
142
+ ### Epic 16-2: Business Rules & Integrity
143
+ #### Story 16-2.01: Usage Detection Service
142
144
  ...
143
145
 
144
146
  ## Cost Models
145
147
 
146
- ### Epic 1: Entity & Creation API
147
- #### Story 1.1: Database & Entity Infrastructure
148
+ ### Epic 16-3: Entity & Creation API
149
+ #### Story 16-3.01: Database & Entity Infrastructure
148
150
  ...
149
151
  ```
150
152
 
@@ -152,9 +154,10 @@ The source document is an epics breakdown organized by feature, where each featu
152
154
 
153
155
  Before generating filenames, the agent MUST resolve the feature number (`NNN`) by following this priority order:
154
156
 
155
- 1. **Source filename pattern**: Look for `feat-{digits}` in the filename (e.g., `epics-feat-016-name.md` → `16`, `epic-feat-083.md` → `83`). Strip leading zeros.
156
- 2. **Document title**: Look for `feat-{digits}` in the first `#` heading (e.g., `# feat-016 — Proyecciones Financieros` → `16`).
157
- 3. **Not found**: Ask the user: *"¿Cuál es el número del feature (`NNN`) para este documento de épicas?"*
157
+ 1. **Epic ID prefix**: If the epic headings already follow the centralized convention (`### Epic {NNN}-{E}: ...`, e.g., `### Epic 16-1:`), take `NNN` directly from the epic IDs. If different `##` sections carry different `NNN` prefixes (multi-feature document), resolve `NNN` **per section** from its own epic IDs.
158
+ 2. **Source filename pattern**: Look for `feat-{digits}` in the filename (e.g., `epics-feat-016-name.md` → `16`, `epic-feat-083.md` → `83`). Strip leading zeros.
159
+ 3. **Document title**: Look for `feat-{digits}` in the first `#` heading (e.g., `# feat-016 — Proyecciones Financieros` → `16`).
160
+ 4. **Not found**: Ask the user: *"¿Cuál es el número del feature (`NNN`) para este documento de épicas?"*
158
161
 
159
162
  ### Naming Convention
160
163
 
@@ -322,7 +325,7 @@ Intelligent Shard Complete ({MODE} Mode):
322
325
 
323
326
  Applied to heading text to generate filenames:
324
327
 
325
- 1. Remove the prefix (`feature — `, `Epic N:`, numbering like `1.`, `2.`, etc.)
328
+ 1. Remove the prefix (`feature — `, `Epic {NNN}-{E}:`, numbering like `1.`, `2.`, etc.)
326
329
  2. Lowercase all text
327
330
  3. Replace spaces with hyphens
328
331
  4. Remove special characters: `&`, `,`, `(`, `)`, `/`, `'`, `"`, `:`, `;`
@@ -338,4 +341,4 @@ Applied to heading text to generate filenames:
338
341
  3. **Mixed content before first subsection**: Include intro text in index.md
339
342
  4. **Empty sections**: Skip sections with no content (heading only)
340
343
  5. **Deep nesting**: Only shard at the detection level. Everything below stays inside the shard
341
- 6. **Epic feature number (`NNN`) not detectable**: If neither the filename nor the document title contain a `feat-{digits}` pattern, the agent MUST ask the user before proceeding — never assume or default to `0`.
344
+ 6. **Epic feature number (`NNN`) not detectable**: If none of the detection sources (epic ID prefixes, filename, document title) yield a feature number, the agent MUST ask the user before proceeding — never assume or default to `0`.
package/siesa-agents/resources/conventions/epic-story-naming-convention.md ADDED
@@ -0,0 +1,130 @@
1
+ # Convención de Nomenclatura para Épicas e Historias
2
+
3
+ > **Fuente centralizada.** Todo workflow, task o skill que genere, shardee o referencie épicas e historias DEBE seguir esta convención. Referenciar este archivo como:
4
+ > `@_siesa-agents/resources/conventions/epic-story-naming-convention.md`
5
+
6
+ ## Objetivo
7
+
8
+ Definir un estándar de numeración que vincule cada épica e historia con su feature de origen, garantizando trazabilidad y unicidad global en todo el proyecto. Cada ID es auto-descriptivo: al leer `16-3.02` se sabe inmediatamente que pertenece al Feature 016, Épica 3, Historia 02.
9
+
10
+ ---
11
+
12
+ ## 1. Formato de IDs
13
+
14
+ ### Épicas
15
+
16
+ ```
17
+ {NNN}-{E}
18
+ ```
19
+
20
+ | Componente | Descripción | Ejemplo |
21
+ |------------|-------------|---------|
22
+ | `NNN` | Número del feature (sin ceros a la izquierda) | `16` |
23
+ | `E` | Número secuencial de la épica dentro del feature | `1`, `48`, `56` |
24
+
25
+ **Ejemplos:** `16-1`, `16-48`, `83-1`
26
+
27
+ ### Historias
28
+
29
+ ```
30
+ {NNN}-{E}.{HH}
31
+ ```
32
+
33
+ | Componente | Descripción | Ejemplo |
34
+ |------------|-------------|---------|
35
+ | `NNN` | Número del feature (sin ceros a la izquierda) | `16` |
36
+ | `E` | Número de la épica dentro del feature | `1`, `48` |
37
+ | `HH` | Número secuencial de la historia (con cero a la izquierda si < 10) | `01`, `12` |
38
+
39
+ **Ejemplos:** `16-1.01`, `16-48.02`, `83-3.05`
40
+
41
+ ### Acceptance Criteria de épica
42
+
43
+ ```
44
+ AC-E{NNN}-{E}.{X}
45
+ ```
46
+
47
+ **Ejemplos:** `AC-E16-49.1`, `AC-E16-56.5`
48
+
49
+ ---
50
+
51
+ ## 2. Ejemplo Visual Completo
52
+
53
+ ```
54
+ feat-016 — Proyecciones Financieros Segmentos
55
+
56
+ Epic 16-1: Company Retrieval Feature
57
+ Historia 16-1.01: Establish Company Domain & Schema
58
+ Historia 16-1.02: List Companies Endpoint
59
+ Historia 16-1.03: Get & Search Endpoints
60
+
61
+ Epic 16-2: Operation Center Core Availability
62
+ Historia 16-2.01: Domain Entity & DB Schema
63
+ Historia 16-2.02: Read-Only Repository
64
+ ```
65
+
66
+ ---
67
+
68
+ ## 3. Nombres de Archivo por Artefacto
69
+
70
+ | Artefacto | Ubicación | Patrón |
71
+ |-----------|-----------|--------|
72
+ | Épicas consolidadas (shard por feature) | `planning-artifacts/epics/` | `epic-feat-{NNN}-{slug}.md` |
73
+ | Stories | `implementation-artifacts/stories/` | `story-{NNN}-{E}.{HH}-{slug}.md` |
74
+ | Reviews | `implementation-artifacts/reviews/` | `review-{NNN}-{E}.{HH}-{slug}.md` |
75
+
76
+ **Ejemplos:**
77
+ - `epic-feat-16-measurement-units.md`
78
+ - `story-16-1.01-establish-company-domain-schema.md`
79
+ - `review-16-1.01-company-domain-schema.md`
80
+
81
+ ---
82
+
83
+ ## 4. Uso del ID en el Contenido
84
+
85
+ ### Encabezados en el documento de épicas
86
+
87
+ ```markdown
88
+ ### Epic 16-1: Company Retrieval Feature
89
+ #### Story 16-1.01: Establish Company Domain & Schema
90
+ ```
91
+
92
+ ### Rangos de épicas (frontmatter, secciones, tablas)
93
+
94
+ ```markdown
95
+ activeEpics: "16-49 to 16-56"
96
+ ## §4.2 Accounting Infrastructure (Epics 16-1 – 16-4)
97
+ ```
98
+
99
+ ### Título de una story individual
100
+
101
+ ```markdown
102
+ # Story 16-1.01: Establish Company Domain & Schema
103
+ ```
104
+
105
+ ### IDs en YAML (`sprint-status.yaml`)
106
+
107
+ ```yaml
108
+ - id: "16-1" # épica — SIEMPRE entre comillas (contiene guión)
109
+ stories:
110
+ - id: "16-1.01"
111
+ file: "story-16-1.01-establish-company-domain-schema.md"
112
+ ```
113
+
114
+ ### Labels de Acceptance Criteria dentro de una story
115
+
116
+ ```markdown
117
+ 1. **Entity Definition:** ... [AC: 16-1.01.1]
118
+ ```
119
+
120
+ ---
121
+
122
+ ## 5. Reglas
123
+
124
+ 1. **El número del feature (`NNN`) se toma del PRD** correspondiente (ej: `feat-016` → `16`, `feat-083` → `83`). Se escribe sin ceros a la izquierda en los IDs.
125
+ 2. **La numeración de épicas (`E`) es secuencial dentro de cada feature**, comenzando en `1`. NO es un consecutivo global del documento: el prefijo `{NNN}-` garantiza la unicidad global.
126
+ 3. **La numeración de historias (`HH`) es secuencial dentro de cada épica**, comenzando en `01` (con cero a la izquierda para valores < 10).
127
+ 4. **No se reutilizan números** de épicas o historias eliminadas.
128
+ 5. **Los IDs en YAML deben ir entre comillas** (`"16-1"`) ya que contienen guión.
129
+ 6. **Las referencias posicionales internas** (`AC: 1, 2, 3` dentro de subtasks de la misma story) **no se modifican** — solo usan el formato completo las referencias con ID de épica/historia (`{NNN}-{E}` o `{NNN}-{E}.{HH}`).
130
+ 7. **Consistencia total:** la convención aplica a todos los artefactos (épicas, stories, reviews, sprint-status, referencias cruzadas), no solo a archivos individuales.
package/siesa-agents/sa/sa-init-devops/scripts/sa-init-devops.js CHANGED
@@ -1,9 +1,9 @@
1
1
  #!/usr/bin/env node
2
- // sa-init-devops.js — Bootstrap the DevOps workspace and skills in Siesa-Agents.
2
+ // sa-init-devops.js — Bootstrap the DevOps workspace and commands in Siesa-Agents.
3
3
  //
4
4
  // In one invocation the script:
5
- // 1. Clones (or pulls) architecture-sa-devops into `_siesa-agents/devops/`.
6
- // 2. Detects conflicts: for each upstream `.claude/skills/sa-*/SKILL.md` and
5
+ // 1. Clones (or pulls) business-shared-deploy into `_siesa-agents/devops/`.
6
+ // 2. Detects conflicts: for each upstream `.claude/commands/*.md` and
7
7
  // `.github/workflows/*.yml`, compares to the local copy in Siesa-Agents. If any local
8
8
  // file differs from upstream and no policy flag was passed, aborts with `status:
9
9
  // "conflicts"` and lists the conflicting items so the caller can ask the user how to
@@ -19,7 +19,7 @@
19
19
  // entirely new in upstream.
20
20
  // --keep-local=<csv> Keep these specific files (comma-separated names) local;
21
21
  // overwrite the rest. Example:
22
- // --keep-local=sa-aplicar,infra-pipeline-qa.yml
22
+ // --keep-local=flow-aplicar.md,infra-pipeline-qa.yml
23
23
  //
24
24
  // Idempotency: between runs the clone's `.claude/` and `.github/` directories are gone from
25
25
  // the working tree but still tracked in upstream HEAD. The script restores those paths
@@ -46,9 +46,7 @@ const fs = require('fs')
46
46
  const path = require('path')
47
47
  const { spawnSync } = require('child_process')
48
48
 
49
- // TODO(siesa-admin): change to https://github.com/SiesaTeams/architecture-sa-devops.git
50
- // once the repo is transferred to the SiesaTeams organization.
51
- const REMOTE_URL = 'https://github.com/ssancheze912/architecture-sa-devops.git'
49
+ const REMOTE_URL = 'https://github.com/SiesaTeams/business-shared-deploy.git'
52
50
  const REMOTE_NAME = 'origin'
53
51
  const DEFAULT_BRANCH = 'main'
54
52
 
@@ -171,56 +169,54 @@ function decideAction(name, upstreamPath, localPaths, policy) {
171
169
  return 'conflict'
172
170
  }
173
171
 
174
- // MOVE `<sourceDir>/.claude/skills/sa-*/SKILL.md` into Siesa-Agents `.claude/skills/sa-*/`
175
- // (and `claude/skills/sa-*/`) according to the policy. Records conflicts in
176
- // status.skill_conflicts; the caller checks that before any mutation happens.
177
- function planAndApplySkills(sourceDir, projectRoot, status, policy, dryRun) {
178
- const srcSkillsDir = path.join(sourceDir, '.claude', 'skills')
179
- status.skills_created = []
180
- status.skills_overwritten = []
181
- status.skills_kept_local = []
182
- status.skills_unchanged = []
183
- status.skill_conflicts = []
184
-
185
- if (!fs.existsSync(srcSkillsDir)) {
186
- status.skills_source_missing = true
172
+ // MOVE `<sourceDir>/.claude/commands/*.md` into Siesa-Agents `.claude/commands/` (and
173
+ // `claude/commands/`) according to the policy. Records conflicts in status.command_conflicts;
174
+ // the caller checks that before any mutation happens.
175
+ function planAndApplyCommands(sourceDir, projectRoot, status, policy, dryRun) {
176
+ const srcCommandsDir = path.join(sourceDir, '.claude', 'commands')
177
+ status.commands_created = []
178
+ status.commands_overwritten = []
179
+ status.commands_kept_local = []
180
+ status.commands_unchanged = []
181
+ status.command_conflicts = []
182
+
183
+ if (!fs.existsSync(srcCommandsDir)) {
184
+ status.commands_source_missing = true
187
185
  return
188
186
  }
189
187
 
190
- const dstA = path.join(projectRoot, '.claude', 'skills')
191
- const dstB = path.join(projectRoot, 'claude', 'skills')
188
+ const dstA = path.join(projectRoot, '.claude', 'commands')
189
+ const dstB = path.join(projectRoot, 'claude', 'commands')
192
190
 
193
- for (const entry of fs.readdirSync(srcSkillsDir, { withFileTypes: true })) {
194
- if (!entry.isDirectory()) continue
195
- if (!entry.name.startsWith('sa-')) continue
196
- if (entry.name === 'sa-init-devops') continue // never overwrite the bootstrap itself
197
- const srcSkill = path.join(srcSkillsDir, entry.name, 'SKILL.md')
198
- if (!fs.existsSync(srcSkill)) continue
191
+ for (const entry of fs.readdirSync(srcCommandsDir, { withFileTypes: true })) {
192
+ if (!entry.isFile()) continue
193
+ if (!entry.name.endsWith('.md')) continue
199
194
 
200
- const dstSkillA = path.join(dstA, entry.name, 'SKILL.md')
201
- const dstSkillB = path.join(dstB, entry.name, 'SKILL.md')
195
+ const srcCommand = path.join(srcCommandsDir, entry.name)
196
+ const dstCommandA = path.join(dstA, entry.name)
197
+ const dstCommandB = path.join(dstB, entry.name)
202
198
 
203
- const action = decideAction(entry.name, srcSkill, [dstSkillA, dstSkillB], policy)
199
+ const action = decideAction(entry.name, srcCommand, [dstCommandA, dstCommandB], policy)
204
200
 
205
201
  if (action === 'conflict') {
206
- status.skill_conflicts.push(entry.name)
202
+ status.command_conflicts.push(entry.name)
207
203
  continue
208
204
  }
209
205
  if (action === 'identical') {
210
- status.skills_unchanged.push(entry.name)
206
+ status.commands_unchanged.push(entry.name)
211
207
  continue
212
208
  }
213
209
  if (dryRun) continue
214
210
 
215
211
  if (action === 'create' || action === 'overwrite') {
216
- fs.mkdirSync(path.dirname(dstSkillA), { recursive: true })
217
- fs.mkdirSync(path.dirname(dstSkillB), { recursive: true })
218
- fs.copyFileSync(srcSkill, dstSkillA)
219
- fs.copyFileSync(srcSkill, dstSkillB)
220
- if (action === 'create') status.skills_created.push(entry.name)
221
- else status.skills_overwritten.push(entry.name)
212
+ fs.mkdirSync(dstA, { recursive: true })
213
+ fs.mkdirSync(dstB, { recursive: true })
214
+ fs.copyFileSync(srcCommand, dstCommandA)
215
+ fs.copyFileSync(srcCommand, dstCommandB)
216
+ if (action === 'create') status.commands_created.push(entry.name)
217
+ else status.commands_overwritten.push(entry.name)
222
218
  } else if (action === 'keep-local') {
223
- status.skills_kept_local.push(entry.name)
219
+ status.commands_kept_local.push(entry.name)
224
220
  }
225
221
  }
226
222
  }
@@ -356,11 +352,11 @@ function runCheck(projectRoot) {
356
352
  // Dry-run conflict detection so callers can preview before running default mode.
357
353
  restoreClonePaths(sourceDir)
358
354
  const policy = { takeUpstream: false, keepLocalAll: false, keepLocalList: null }
359
- planAndApplySkills(sourceDir, projectRoot, state, policy, true)
355
+ planAndApplyCommands(sourceDir, projectRoot, state, policy, true)
360
356
  planAndApplyWorkflows(sourceDir, projectRoot, state, policy, true)
361
357
 
362
358
  state.status = 'already-cloned'
363
- const conflictCount = state.skill_conflicts.length + state.workflow_conflicts.length
359
+ const conflictCount = state.command_conflicts.length + state.workflow_conflicts.length
364
360
  state.message = `${sourceDir} is a clean clone of ${REMOTE_URL}. ${conflictCount} conflict(s) would be raised by a default run.`
365
361
  emit(state)
366
362
  return 0
@@ -475,30 +471,30 @@ function runClone(projectRoot, mirrorOnly, args) {
475
471
 
476
472
  function finalizeMoveAndMirror(sourceDir, projectRoot, mirrorDir, status, policy, terminalStatus) {
477
473
  // Phase A: dry-run to compute the action plan and conflicts.
478
- planAndApplySkills(sourceDir, projectRoot, status, policy, true)
474
+ planAndApplyCommands(sourceDir, projectRoot, status, policy, true)
479
475
  planAndApplyWorkflows(sourceDir, projectRoot, status, policy, true)
480
476
 
481
- const totalConflicts = status.skill_conflicts.length + status.workflow_conflicts.length
477
+ const totalConflicts = status.command_conflicts.length + status.workflow_conflicts.length
482
478
  if (totalConflicts > 0) {
483
479
  // Abort without mutating. The caller (Claude/SKILL.md) asks the user and re-runs with
484
480
  // a policy flag.
485
481
  status.status = 'conflicts'
486
- status.message = `Detected ${status.skill_conflicts.length} skill conflict(s) and ${status.workflow_conflicts.length} workflow conflict(s). Re-run with one of: --take-upstream (overwrite all), --keep-local (keep all local versions), or --keep-local=<csv> (keep specific ones).`
482
+ status.message = `Detected ${status.command_conflicts.length} command conflict(s) and ${status.workflow_conflicts.length} workflow conflict(s). Re-run with one of: --take-upstream (overwrite all), --keep-local (keep all local versions), or --keep-local=<csv> (keep specific ones).`
487
483
  emit(status)
488
484
  return 4
489
485
  }
490
486
 
491
487
  // Phase B: real apply (no conflicts left to resolve).
492
- planAndApplySkills(sourceDir, projectRoot, status, policy, false)
488
+ planAndApplyCommands(sourceDir, projectRoot, status, policy, false)
493
489
  planAndApplyWorkflows(sourceDir, projectRoot, status, policy, false)
494
490
  cleanCloneDirs(sourceDir)
495
491
  refreshMirror(sourceDir, mirrorDir, status)
496
492
 
497
493
  status.status = terminalStatus
498
- const created = status.skills_created.length + status.workflows_created.length
499
- const over = status.skills_overwritten.length + status.workflows_overwritten.length
500
- const kept = status.skills_kept_local.length + status.workflows_kept_local.length
501
- const unch = status.skills_unchanged.length + status.workflows_unchanged.length
494
+ const created = status.commands_created.length + status.workflows_created.length
495
+ const over = status.commands_overwritten.length + status.workflows_overwritten.length
496
+ const kept = status.commands_kept_local.length + status.workflows_kept_local.length
497
+ const unch = status.commands_unchanged.length + status.workflows_unchanged.length
502
498
  status.message = `${terminalStatus === 'cloned' ? 'Cloned' : (terminalStatus === 'updated' ? 'Pulled' : 'No upstream change')}. Created ${created}, overwrote ${over}, kept local ${kept}, unchanged ${unch}. Mirror refreshed.`
503
499
  emit(status)
504
500
  return 0