generator-folklore 3.0.55 → 3.0.56

package/lib/generators/agents/index.js

@@ -22,7 +22,7 @@ class AgentsGenerator extends _generator.default {
     const hasPackageJson = this.fs.exists(this.destinationPath('package.json'));
     const existingContent = this.fs.exists(destPath) ? this.fs.read(destPath) : '';
     const separator = '\n\n---\n\n';
-    const parts = [this.fs.read(this.templatePath('general.md')), hasComposerJson ? this.fs.read(this.templatePath('laravel.md')) : null, hasPackageJson ? this.fs.read(this.templatePath('frontend.md')) : null, hasComposerJson ? this.fs.read(this.templatePath('serve-laravel.md')) : null, !hasComposerJson && hasPackageJson ? this.fs.read(this.templatePath('serve-html.md')) : null, this.fs.read(this.templatePath('after.md'))].filter(it => it !== null).join(separator);
+    const parts = [this.fs.read(this.templatePath('general.md')), this.fs.read(this.templatePath('workflow.md')), hasComposerJson ? this.fs.read(this.templatePath('laravel.md')) : null, hasPackageJson ? this.fs.read(this.templatePath('frontend.md')) : null, hasComposerJson ? this.fs.read(this.templatePath('serve-laravel.md')) : null, !hasComposerJson && hasPackageJson ? this.fs.read(this.templatePath('serve-html.md')) : null, this.fs.read(this.templatePath('after.md'))].filter(it => it !== null).join(separator);
     const newContent = existingContent.length > 0 ? `${existingContent}${separator}${parts}` : parts;
     this.fs.write(destPath, newContent);
   }

package/lib/generators/agents/templates/general.md

@@ -8,8 +8,8 @@ This file defines how coding agents should work in this repository.
 
 ## Language Rules
 
-- Write all code, comments, identifiers, commit messages, and technical docs in English.
-- User-facing chat can be in French, but repository content stays in English.
+- Everything written for people is in French: conversations, GitHub issues and their comments, pull request titles, bodies and review comments.
+- Code is always in English: identifiers, comments, file names, and commit messages.
 
 ## Editing Guidelines
 

package/lib/generators/agents/templates/workflow.md

@@ -0,0 +1,43 @@
+## Development Workflow
+
+Branching follows Gitflow, kept light. `develop` is where development happens: every commit and every merge lands there first. `main` is production: it only receives `develop` when deploying to prod. The backlog is the repository's GitHub Issues; pull requests are where reviewed work lands. Most day-to-day work skips both: the issue/PR flow exists to run work in parallel and to review what deserves it, not to slow down small changes.
+
+On GitHub, `develop` is the default branch (so PRs target it and `Closes #<number>` closes issues on merge), and the `bug`, `enhancement` and `in-progress` labels exist.
+
+### Commit straight to `develop` (default)
+
+- Small changes asked for directly in conversation: fixes, style or copy tweaks, translations, content. The request was reviewed by being asked for.
+- Documentation, comments and config with no runtime effect.
+- Run the checks before committing. Never push unless asked.
+
+### Use an issue and a PR
+
+- A feature or a chunk of work that spans several sessions, or needs a written plan.
+- Work meant to run in parallel with other sessions.
+- Risky or broad changes: migrations, refactors, dependencies, routing, or any diff the maintainer would want to read.
+- Anything started from an existing issue.
+
+What decides the flow is where the request came from and what it touches, not the size of the diff. When unsure, ask.
+
+### Working an issue
+
+1. Read the issue and its comments first; they may change the plan.
+2. Add the `in-progress` label before starting: it stops a second session from picking the same issue. Remove it if the work is abandoned.
+3. For an `enhancement`, write a short plan in the issue body before coding. `bug` issues skip the plan.
+4. One branch per issue, prefixed by its type: `feature/<number>-<slug>` for an `enhancement`, `bug/<number>-<slug>` for a `bug` (other types follow the same pattern, e.g. `docs/`, `refactor/`). Branch from an up-to-date `develop`, in its own worktree under `.claude/worktrees/<number>-<slug>` so parallel sessions don't share a checkout.
+5. Run the checks, push and open the PR against `develop` with `Closes #<number>` in its body, without asking. If the change couldn't be verified in the session, list the test scenario as a checkbox list in the PR body.
+6. The issue closes when the PR merges into `develop`, never just because code was pushed. Remove the worktree (`git worktree remove`) once merged.
+
+Something out of scope noticed along the way becomes a new issue (title, context, files involved) rather than growing the current change. Every issue carries a type label: `bug` or `enhancement`.
+
+### Releasing to production
+
+When deploying, merge `develop` into `main` (only when asked). An urgent fix for prod goes on a `hotfix/<slug>` branch from `main`, merged into `main` and then into `develop` so the two don't diverge.
+
+### Checks
+
+Run the project's lint, format, typecheck and test scripts (see `package.json` and `composer.json`) on what changed. When the codebase has pre-existing errors, a check passes when it reports nothing new in the files touched.
+
+### Rules live in this file
+
+Rules that always apply to this project (workflow, conventions, setup) are written here, not in an agent's private memory, so every session and every teammate shares them.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "generator-folklore",
-    "version": "3.0.55",
+    "version": "3.0.56",
     "description": "Yeoman generator for projects at Folklore",
     "keywords": [
         "yeoman-generator"
@@ -40,5 +40,5 @@
         "yeoman-generator": "5.9.0",
         "yeoman-remote": "^1.0.1"
     },
-    "gitHead": "47b0be3c067e8ff829ed3f2bd713852cb5450c50"
+    "gitHead": "588abc69c30c5a8954352431f3aed90375582714"
 }