diff --git a/plugins/spryker-ai-dev-sdk/skills/project-ci-generator/README.md b/plugins/spryker-ai-dev-sdk/skills/project-ci-generator/README.md new file mode 100644 index 0000000..1bb9483 --- /dev/null +++ b/plugins/spryker-ai-dev-sdk/skills/project-ci-generator/README.md @@ -0,0 +1,61 @@ +# project-ci-generator + +Turn a heavy product/vendor-style CI setup into a **single, lean project CI pipeline** — +driven by a questionnaire, portable across CI hosts. + +A product repo's CI must protect every customer, every database, every language version, and +the upstream release process. A project inherits all of it but needs almost none — it targets +one environment and only needs to gate its own commits. This skill reads whatever CI exists, +asks what the project needs, proposes a plan, then keeps only what matters and drops the rest. + +## When it triggers + +Invoke it when the user wants to: "clean up CI for the project", "make a project CI", +"recreate one CI file", "remove product-only CI jobs", "clear the CI folder and rebuild", or +port CI to another host. + +## Flow schema + +```mermaid +flowchart TD + A([Skill invoked]) --> B[1 · Discover
read the CI that exists:
jobs, dependencies,
support files, config] + B --> C[2 · Ask
short questionnaire] + + C --> Q1{Platform?} + C --> Q2{Which suites?} + C --> Q3{Single or matrix?} + C --> Q4{Notifications?} + C --> Q5{Wipe scope?} + + Q1 --> D[3 · Propose
derive keep/drop plan
from discovery + answers] + Q2 --> D + Q3 --> D + Q4 --> D + Q5 --> D + + D --> CONF{User approves?} + CONF -- no --> C + CONF -- yes --> E[4 · Rebuild
prune dropped files,
write one project CI
from surviving jobs,
keep referenced support files] + E --> F[5 · Validate
parse output, confirm
dependencies resolve] + F --> G([Output:
one project CI +
minimal support files]) + + classDef step fill:#1f6feb,stroke:#0b3d91,color:#fff; + classDef decision fill:#f0ad4e,stroke:#8a6d3b,color:#000; + classDef terminal fill:#2ea043,stroke:#176f2c,color:#fff; + class B,D,E,F step; + class Q1,Q2,Q3,Q4,Q5,CONF decision; + class A,G terminal; +``` + +## Design decisions baked in + +- **Investigate, never assume.** CI contents change over time, so every run reads and analyzes + whatever CI actually exists — no remembered job list, filename, or classification is trusted. +- **Questionnaire first.** Output is determined by the answers, never guessed. +- **Propose before acting.** The keep/drop plan is derived from the discovery and answers, + presented, and approved before anything is deleted — CI changes are outward-facing and hard + to reverse. +- **Transform, don't template.** The new CI is built from the surviving jobs of the existing + CI, reusing their real commands so the result is environment-correct. +- **Support files are load-bearing.** Support files referenced by kept jobs are preserved; + everything unreferenced is pruned. diff --git a/plugins/spryker-ai-dev-sdk/skills/project-ci-generator/SKILL.md b/plugins/spryker-ai-dev-sdk/skills/project-ci-generator/SKILL.md new file mode 100644 index 0000000..6ddbe88 --- /dev/null +++ b/plugins/spryker-ai-dev-sdk/skills/project-ci-generator/SKILL.md @@ -0,0 +1,118 @@ +--- +name: project-ci-generator +description: >- + Transform a product/vendor-style CI setup into a single, lean project CI pipeline. + Use this whenever the user wants to "clean up CI for the project", "make a project CI", + "recreate one CI file", "remove product-only CI jobs", "clear the CI folder and rebuild", + or port CI to another host (GitLab, Bitbucket). It first reads and investigates whatever CI + actually exists in the repo, runs a short questionnaire to learn what the project needs + (which test suites, PHP version, notifications, target platform), then proposes a keep/drop + plan to the user before wiping the old CI and emitting one project-tuned pipeline plus only + the support files the surviving jobs reference. +--- + +# Project CI Generator + +Product/vendor repositories ship CI that must protect every customer, every database, every +language version, and the upstream release process. A **project** inherits all that machinery +but needs almost none of it — it targets one environment and only needs to gate its own +commits. This skill turns the heavy inherited CI into a single, honest project pipeline. + +The guiding principle: **a project CI should contain only jobs whose failure a project +developer must act on.** Anything that exists to protect the product's release, its +cross-version or cross-database compatibility, or its full QA matrix belongs to product +delivery, not here. + +## Investigate, never assume + +CI contents change over time — jobs get renamed, added, removed; support files come and go. +Do not rely on any remembered job list, filename, or classification. Every run starts by +reading the CI that is actually present, derives the plan from what you find, and proposes it +to the user for approval before changing anything. + +## Workflow + +### 1. Discover + +The base to start from is the repo's main CI workflow — for a Spryker project this is +`.github/workflows/ci.yml`. Read it first, but do not assume its contents: confirm the file is +there and investigate what it actually contains (it changes over time), and also scan for +other CI files that may exist alongside it. + +Build an accurate picture of: the jobs and how they depend on each other, the support files +each job references (anything a job boots, calls, or uses), and cross-cutting config +(triggers, concurrency, secrets). + +The base CI often already carries inline recommendations — comment markers on jobs and steps +such as "project applicable", "remove for project", or "optional for project". Read these: +they encode the maintainers' own guidance on what a project keeps vs drops, so use them as the +starting classification. Still confirm each one against the questionnaire answers rather than +applying it blindly — a marker is a strong hint, not a final decision. + +### 2. Ask + +Run one short questionnaire. The answers, combined with the discovery, determine the output: + +- **Target platform** — keep the current host or port to another (decides file path/syntax). +- **Which suites to keep** — offer only the suites you actually found; recommend keeping + lightweight gating suites and dropping heavy product QA suites. +- **Single version vs. matrix** — a project runs one version; recommend dropping the matrix. +- **Notifications** — keep or drop chat/ticket steps and their secrets (default: drop). +- **Clear scope** — wipe and regenerate only what's needed, or leave unreferenced files. + +Carry forward anything the user already answered earlier instead of re-asking. + +### 3. Propose + +Derive the plan from the discovery plus the answers — do not recite a canned one. For each +discovered job decide keep vs drop; for each support file decide keep (referenced by a +surviving job) vs drop. Present the keep/drop lists and the output path, and get an explicit +go-ahead. Deleting CI is outward-facing and hard to reverse, so confirm before acting. If the +user hesitates at the wipe, offer to annotate the existing CI in place instead. + +### 4. Rebuild + +Prune the files the plan drops. Write the single project CI from the surviving jobs, reusing +their real commands verbatim — those are already correct for this repo's tooling, which is the +whole reason to transform rather than template. Apply the agreed trims (single version, +product-only steps removed, dependencies wired only among surviving jobs, notifications on or +off). Keep exactly the support files surviving jobs reference. Never invent a job or step: if +the questionnaire selected something the source CI doesn't contain, say so. + +For a different host, reproduce the same jobs, commands, and ordering in that host's structure +— only the wrapper changes. + +### 5. Validate + +Parse the emitted file, confirm every dependency points at a job that still exists, and +sanity-check ordering. Report the final tree of what remains and the job list of the new +pipeline. + +## Quality gate + +Do not consider the work done until every item below holds. Walk the list explicitly and +report it — this is what proves the CI folder was actually cleaned, not just added to. + +- [ ] **Single pipeline.** Exactly one project CI file exists; no leftover secondary + workflows from the old setup remain. +- [ ] **All unneeded files removed.** Every CI file the approved plan marked as dropped is + gone from the CI folder — product-only pipelines, unreferenced support/deploy files, and + composite actions or scripts no surviving job uses. Re-list the CI folder and confirm + nothing dropped is still present. +- [ ] **No orphans kept.** Every file that remains is either the project CI itself or a + support file that a surviving job references. Nothing survives "just in case." +- [ ] **No dangling references.** No surviving job points at a file, action, or script that + was deleted; and no deleted job is still named as a dependency. +- [ ] **Only approved jobs.** The pipeline contains exactly the jobs the user approved — none + dropped, none invented. +- [ ] **No product-only jobs survive.** Nothing that exists purely to protect the upstream + product remains — cross-version/cross-database compatibility matrices, full product QA + and end-to-end suites, release-branch or upmerge automation, and API/doc publishing for + the product. A project must not carry these; confirm each such job is gone. +- [ ] **Trims applied.** Version matrix reduced as agreed, product-only steps removed, + notifications on/off per the answer, dependencies wired only among surviving jobs. +- [ ] **Commands preserved.** Surviving jobs use the original discovered commands verbatim, + not paraphrased. +- [ ] **Parses cleanly.** The output file parses and its dependency/ordering graph resolves. + +If any item fails, fix it before reporting completion.