sleeke 1.0.0

package/dist/templates/next-app/.claude/docs/conventional-commits.md

@@ -0,0 +1,149 @@
+# Conventional Commits 1.0.0 (Official Spec)
+
+> Source: https://www.conventionalcommits.org/en/v1.0.0/
+> Saved locally so the skill can reference the full spec without needing network access.
+
+## Summary
+
+The Conventional Commits specification is a lightweight convention on top of
+commit messages. It provides an easy set of rules for creating an explicit
+commit history, making it easier to write automated tools on top of it. This
+convention dovetails with SemVer by describing the features, fixes, and
+breaking changes made in commit messages.
+
+The commit message should be structured as follows:
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+Structural elements, to communicate intent to consumers of your library:
+
+- `fix:` a commit of the type `fix` patches a bug in your codebase
+  (correlates with **PATCH** in Semantic Versioning).
+- `feat:` a commit of the type `feat` introduces a new feature to the
+  codebase (correlates with **MINOR** in Semantic Versioning).
+- `BREAKING CHANGE:` a commit that has a footer `BREAKING CHANGE:`, or
+  appends a `!` after the type/scope, introduces a breaking API change
+  (correlates with **MAJOR** in Semantic Versioning). A BREAKING CHANGE can
+  be part of commits of any type.
+- Types other than `fix:` and `feat:` are allowed, e.g.
+  `@commitlint/config-conventional` (based on the Angular convention)
+  recommends `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`,
+  `perf:`, `test:`, and others.
+- Footers other than `BREAKING CHANGE: <description>` may be provided and
+  follow a convention similar to git trailer format.
+
+A scope MAY be provided to a commit's type to give additional contextual
+information, contained within parenthesis, e.g.
+`feat(parser): add ability to parse arrays`.
+
+## Examples
+
+**Commit message with description and breaking change footer**
+```
+feat: allow provided config object to extend other configs
+
+BREAKING CHANGE: `extends` key in config file is now used for extending other config files
+```
+
+**Commit message with `!` to draw attention to breaking change**
+```
+feat!: send an email to the customer when a product is shipped
+```
+
+**Commit message with scope and `!`**
+```
+feat(api)!: send an email to the customer when a product is shipped
+```
+
+**Commit message with both `!` and BREAKING CHANGE footer**
+```
+feat!: drop support for Node 6
+
+BREAKING CHANGE: use JavaScript features not available in Node 6.
+```
+
+**Commit message with no body**
+```
+docs: correct spelling of CHANGELOG
+```
+
+**Commit message with scope**
+```
+feat(lang): add Polish language
+```
+
+**Commit message with multi-paragraph body and multiple footers**
+```
+fix: prevent racing of requests
+
+Introduce a request id and a reference to latest request. Dismiss
+incoming responses other than from latest request.
+
+Remove timeouts which were used to mitigate the racing issue but are
+obsolete now.
+
+Reviewed-by: Z
+Refs: #123
+```
+
+## Specification (RFC 2119 keywords apply)
+
+1. Commits MUST be prefixed with a type (noun: `feat`, `fix`, etc.),
+   followed by an OPTIONAL scope, OPTIONAL `!`, and REQUIRED terminal
+   colon and space.
+2. The type `feat` MUST be used when a commit adds a new feature.
+3. The type `fix` MUST be used when a commit represents a bug fix.
+4. A scope MAY be provided after a type, as a noun in parenthesis, e.g.
+   `fix(parser):`.
+5. A description MUST immediately follow the colon and space after the
+   type/scope prefix, e.g.
+   `fix: array parsing issue when multiple spaces were contained in string`.
+6. A longer commit body MAY be provided, one blank line after the
+   description, giving additional context.
+7. The body is free-form and MAY consist of multiple newline-separated
+   paragraphs.
+8. One or more footers MAY be provided, one blank line after the body.
+   Each footer MUST consist of a word token, followed by `: ` or ` #`,
+   followed by a string value (inspired by git trailer convention).
+9. A footer token MUST use `-` in place of whitespace (e.g. `Acked-by`),
+   except for `BREAKING CHANGE`.
+10. Breaking changes MUST be indicated either in the type/scope prefix
+    (`!`) or as a footer entry.
+11. If in the footer, it MUST be the uppercase text `BREAKING CHANGE:`
+    followed by a description.
+12. If indicated via `!`, `BREAKING CHANGE:` in the footer MAY be omitted,
+    and the description SHALL describe the breaking change.
+13. Types other than `feat`/`fix` MAY be used, e.g. `docs: update ref docs`.
+14. Units of information MUST NOT be treated as case-sensitive, except
+    `BREAKING CHANGE`, which MUST be uppercase.
+15. `BREAKING-CHANGE` MUST be synonymous with `BREAKING CHANGE` as a
+    footer token.
+
+## Why use Conventional Commits
+
+- Automatically generating CHANGELOGs.
+- Automatically determining a semantic version bump.
+- Communicating the nature of changes to teammates and stakeholders.
+- Triggering build and publish processes.
+- Making it easier for people to contribute, via a structured history.
+
+## FAQ (selected)
+
+- **Revert commits:** the spec doesn't define exact revert behavior. A
+  common convention: use the `revert` type with a footer referencing the
+  reverted commit SHAs, e.g.
+  ```
+  revert: let us never again speak of the noodle incident
+
+  Refs: 676104e, a215868
+  ```
+- **Multiple unrelated changes in one commit:** split into multiple commits
+  whenever possible — that's part of the value of the convention.
+- **Wrong type used:** fix via `git rebase -i` before merge/release; after
+  release it depends on your tooling.

package/dist/templates/next-app/.claude/skills/git-commiter/SKILL.md

@@ -0,0 +1,411 @@
+---
+name: git-commiter
+description: Expert Git committer. Reviews code diffs for explicitly targeted files/paths (never the whole repo blindly), updates the changelog, generates high-quality Conventional Commit messages, and performs git commit and git push.
+---
+
+You are a Git commit expert. When asked to commit changes, follow these steps EXACTLY.
+
+## 0. Reference: Conventional Commits Spec
+
+Before generating commit messages, consult `.claude/docs/conventional-commits.md`
+— it's the full official Conventional Commits 1.0.0 specification
+(https://www.conventionalcommits.org/en/v1.0.0/), saved locally for offline
+reference.
+
+- For **standard commits** (feat/fix/docs/etc. with a simple description),
+  you already know the format below — no need to open the reference file.
+- **Open and read `.claude/docs/conventional-commits.md` whenever** the
+  change involves any of the following, since these are easy to get wrong
+  without checking the exact spec rules:
+  - A **breaking change** (needs `!` after type/scope and/or a
+    `BREAKING CHANGE:` footer — see spec rules 10–12, 15).
+  - A **scope** (`feat(parser): ...`) and you're unsure whether it fits the
+    changed area of the codebase.
+  - **Footers** (e.g. `Refs:`, `Reviewed-by:`, `Closes:`) — see spec rule 8–9
+    for correct token/separator format.
+  - A **revert** commit — see the FAQ section for the recommended pattern.
+  - Any doubt about which type applies, or a change that doesn't cleanly
+    fit `feat`/`fix`.
+
+## 1. Determine Changelog File
+
+Always use today's date in `YYMMDD` format and create or update:
+
+`.claude/changes/YYMMDD.md`
+
+---
+
+## 2. Determine Target Files (REQUIRED — never commit blindly)
+
+This skill NEVER stages the whole repository automatically (no blind
+`git add .`). You must know exactly which files/paths to commit before
+doing anything else.
+
+- If the user's request already specifies files, paths, or a scope (e.g.
+  "commit the changes in `src/auth/`", "commit `Button.tsx` and
+  `Button.test.tsx`"), use exactly that as the target list.
+- If the user just says something generic like "commit" or "commita isso"
+  with no files specified, run `git status` first to see what's modified,
+  then **ask the user which of those files/paths they want to commit**
+  before staging anything. Do not assume "all of them."
+- Never use a bare `git add .` or `git add -A` unless the user explicitly
+  says to commit everything / all changes.
+
+### Splitting targets into separate commits (default behavior)
+
+When multiple target files/paths are given, do NOT bundle them into a
+single commit by default — that produces commit messages describing
+unrelated changes lumped together, which pollutes the history.
+
+- **Default: one commit per target file**, each with its own scoped
+  `git diff`, its own Conventional Commit message, and its own changelog
+  entry.
+- **Exception — group into a single commit only when either:**
+  - The user explicitly says the files belong together (e.g. "commit
+    `Button.tsx` and `Button.test.tsx` together, same change"), or
+  - The diffs make it unambiguous they're the same atomic change (e.g. a
+    component file and its matching test/snapshot file that were clearly
+    edited for the same reason, or a rename that touches an import in
+    another file). If there's any doubt, default to separate commits
+    instead of guessing.
+- When grouping, state explicitly why the files were grouped (one
+  sentence) before showing the combined commit message, so the user can
+  correct it if wrong.
+- Process each commit (or group) sequentially: diff → changelog entry →
+  commit message → stage → commit, then move to the next target/group.
+  Push once at the end after all commits are made (not after every single
+  one), unless the user asks to push after each.
+
+---
+
+## 3. Analyze Changes
+
+Once the targets are confirmed, inspect the repository state by running:
+
+- `git status` to confirm the current state of the target files.
+- `git diff -- <target files>` to review unstaged changes scoped only to
+  the targets (not the whole repo).
+- `git log -3 --oneline` to understand the recent commit style.
+
+Use this information to produce an accurate changelog and commit message
+— scoped only to the targeted files.
+
+---
+
+## 4. Update Changelog
+
+Document today's changes in the changelog.
+
+- **Location:** `.claude/changes/YYMMDD.md`
+- Always use today's date.
+- If the file already exists, **append** the new entry.
+- **Never overwrite or remove** existing content.
+
+Include:
+
+- Summary of changes
+- Modified files
+- Features added, improved or removed
+- Database schema changes (if any)
+
+Example:
+
+```markdown
+# 250130 Update
+
+## Changes Summary
+
+- Improved user comment display by showing post titles instead of UUIDs.
+
+## Major File Changes
+
+- `CommentEntity.java`: Added `postTitle` field.
+- `PostRepositoryImpl.java`: Fetch post titles when loading comments.
+- `UserCommentsTab.tsx`: Display post titles.
+
+## Feature Changes
+
+- [Added] Post title support in comment list.
+- [Improved] Better readability for users.
+```
+
+---
+
+## 5. Generate Commit Message
+
+Generate a commit message using the following format, per the Conventional
+Commits spec (`.claude/docs/conventional-commits.md`):
+
+```
+<type>[optional scope][!]: <description>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+### Commit Title
+
+The first line must:
+
+- Be written in English.
+- Be around **50 characters** (maximum **72**).
+- Follow the **Conventional Commits** specification.
+- Start with exactly one commit type:
+  - `feat:`
+  - `fix:`
+  - `docs:`
+  - `style:`
+  - `refactor:`
+  - `perf:`
+  - `test:`
+  - `chore:`
+  - `build:`
+  - `revert:`
+- Optionally include a **scope** in parenthesis right after the type,
+  when the change is clearly localized to one area of the codebase,
+  e.g. `feat(parser): add ability to parse arrays`.
+- Optionally append **`!`** immediately before the colon when the commit
+  introduces a breaking change, e.g. `feat(api)!: change response shape`.
+  When `!` is used, either add a `BREAKING CHANGE:` footer with details, or
+  make sure the description itself clearly explains the break.
+- Clearly summarize the overall change.
+- Never include dates or numeric prefixes.
+
+After the title, insert one blank line.
+
+### Commit Body
+
+The body should:
+
+- Explain **what** changed.
+- Explain **why** the change was made when appropriate.
+- Use concise bullet points.
+- **Do not repeat Conventional Commit prefixes.**
+
+### Commit Footer(s) (when applicable)
+
+- One blank line after the body.
+- Format: `Token: value` or `Token #value` (token uses `-` instead of
+  spaces, e.g. `Reviewed-by`, `Refs`).
+- Use `BREAKING CHANGE: <description>` (must be uppercase) for breaking
+  changes not already covered by `!` in the title.
+
+Example:
+
+```text
+refactor: Improve comment display with post titles
+
+* Add postTitle property to CommentEntity.
+* Load post titles in PostRepositoryImpl.
+* Display post titles in UserCommentsTab.
+```
+
+---
+
+### GOOD Examples
+
+```text
+refactor: Modernize iteration utilities
+
+* Replace legacy loops with intrange.
+* Remove deprecated iteration helpers.
+* Improve code readability.
+```
+
+```text
+feat: Add mobile navigation drawer
+
+* Introduce responsive navigation component.
+* Support gesture-based closing.
+* Improve accessibility.
+```
+
+```text
+fix: Resolve login redirect loop
+
+* Prevent duplicate redirect execution.
+* Handle expired session state correctly.
+* Improve error handling.
+```
+
+```text
+docs: Update authentication guide
+
+* Document OAuth login flow.
+* Add API authentication examples.
+* Clarify environment configuration.
+```
+
+```text
+feat(api)!: change pagination response shape
+
+* Replace offset-based pagination with cursor-based.
+* Update client SDK to consume new shape.
+
+BREAKING CHANGE: `page`/`limit` query params are removed in favor of `cursor`.
+```
+
+---
+
+### BAD Examples
+
+```text
+250818 Improve login
+```
+
+Reason:
+
+- Commit titles must never contain date prefixes.
+
+---
+
+```text
+Update stuff
+```
+
+Reason:
+
+- Missing Conventional Commit type.
+- Too vague.
+
+---
+
+```text
+Misc changes
+```
+
+Reason:
+
+- Missing Conventional Commit type.
+- Not descriptive.
+
+---
+
+```text
+refactor Improve authentication
+```
+
+Reason:
+
+- Missing the colon after the Conventional Commit type.
+
+---
+
+```text
+feat: Add new feature
+
+* feat: Add endpoint.
+* feat: Update UI.
+```
+
+Reason:
+
+- Conventional Commit prefixes belong only in the title, not in the body.
+
+---
+
+```text
+feat: change response format entirely
+```
+
+Reason:
+
+- This is a breaking change but has no `!` and no `BREAKING CHANGE:`
+  footer — consumers won't know it breaks compatibility.
+
+---
+
+## 6. Show Generated Commit Message
+
+Display the complete commit message exactly as it will be committed.
+
+Example:
+
+```text
+refactor: Modernize iteration utilities
+
+* Replace legacy loops with intrange.
+* Remove deprecated iteration helpers.
+* Improve overall readability.
+```
+
+---
+
+## 7. Execute Git Commands
+
+For each commit (or explicitly grouped set of files, per Step 2), repeat
+steps 1–4 below. Only after ALL commits are done, run step 5 (push) once.
+
+1. Update the changelog file in `.claude/changes/` with this commit's entry
+   (append, don't overwrite).
+2. Stage ONLY this commit's target file(s) — never the whole repo unless
+   the user explicitly asked for everything:
+
+```bash
+git add <target-file(s)-for-this-commit>
+git add .claude/changes/YYMMDD.md
+```
+
+   Only use `git add .` / `git add -A` if the user explicitly requested
+   committing all changes.
+
+3. Commit using heredoc syntax:
+
+```bash
+git commit -m "$(cat <<'EOF'
+...
+EOF
+)"
+```
+
+4. Verify the commit:
+
+```bash
+git status
+```
+
+Repeat 1–4 for the next target/group, if any.
+
+5. Once every target has its own commit, push all of them together:
+
+```bash
+git push
+```
+
+6. Report success or failure, listing each commit hash + message that was
+   created.
+
+---
+
+## CRITICAL RULES
+
+- **Never stage the entire repo blindly.** No bare `git add .` / `git add -A`
+  unless the user explicitly asked to commit everything. Always work off an
+  explicit target list (files/paths).
+- **Never bundle multiple unrelated targets into one commit by default.**
+  One commit per target file unless the user explicitly says two or more
+  files are the same change, or the diffs make that unambiguous.
+- If no targets were given and the request is generic ("commit",
+  "commita"), stop and ask the user which files/paths to commit — this is
+  the one case where clarification is required before proceeding.
+- Always inspect the repository before generating a commit.
+- Always update the changelog file in `.claude/changes/` before committing.
+- Always append to an existing changelog file for that date.
+- Never overwrite or delete previous changelog entries.
+- Always display the complete commit message before executing Git commands.
+- Always use heredoc syntax for multiline commit messages.
+- Once targets are confirmed and the commit message is generated, proceed
+  automatically through changelog update, staging, commit, and push
+  without further confirmation.
+- Always follow the Conventional Commits specification
+  (`.claude/docs/conventional-commits.md`).
+- Never include dates or numeric prefixes in commit titles.
+- Use exactly one Conventional Commit prefix in the commit title.
+- Never repeat Conventional Commit prefixes in the commit body.
+- Use `!` and/or a `BREAKING CHANGE:` footer whenever the change breaks
+  backward compatibility — check `.claude/docs/conventional-commits.md` if
+  unsure how to phrase it.
+- The commit title should summarize the overall change.
+- The commit body should explain the implementation details without
+  repeating the title.

package/dist/templates/next-app/.claude/skills/translate-pages/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: translate-pages
+description: It's used to bulk translate all pages of the website, from the default language to other languages defined in `luxm.json`.
+---
+
+# Translate Pages
+
+This skill translates all route pages from the default locale to other locales defined in `luxm.json`.
+
+## Workflow
+
+1. Read `luxm.json` to identify `defaultLocale` and target `locales`
+2. For each locale (except default), create a cloned directory structure under `src/locales/<locale>/routes/`
+3. Translate all JSON locale files using the AI model
+

package/dist/templates/next-app/.prettierignore

@@ -0,0 +1,7 @@
+dist/
+node_modules/
+.next/
+.turbo/
+coverage/
+pnpm-lock.yaml
+.pnpm-store/

package/dist/templates/next-app/.prettierrc

@@ -0,0 +1,11 @@
+{
+  "endOfLine": "lf",
+  "semi": false,
+  "singleQuote": false,
+  "tabWidth": 2,
+  "trailingComma": "es5",
+  "printWidth": 80,
+  "plugins": ["prettier-plugin-tailwindcss"],
+  "tailwindStylesheet": "app/globals.css",
+  "tailwindFunctions": ["cn", "cva"]
+}

package/dist/templates/next-app/CLAUDE.md

@@ -0,0 +1,19 @@
+# Luxw Project
+
+This project was generated with [Luxw](https://github.com/araujoio/luxw)
+
+## What is Luxw?
+
+Luxw is a command-line tool that automates the creation of Next.js projects with support for multiple libraries, eliminating repetitive setup tasks and letting developers focus on what actually matters building the product.
+
+Beyond scaffolding, Luxw leverages AI-powered skills and MCPs (Model Context Protocols) under the hood to automate complex workflows like bulk-translating pages, managing routes, and maintaining project consistency. This means less manual config and more productivity, right from your terminal.
+
+## Rules
+
+- **Consult Specs:** Always consult `.claude/specs/` before suggesting or implementing any changes.
+
+- **Mandatory Documentation Check:** Whenever I ask you to implement a new feature, use an external library, framework, or third-party API, you **MUST** use the Context7 MCP server to fetch and read the most up-to-date documentation before writing any code.
+
+- **Avoid Hallucinations:** Do not rely solely on your pre-trained knowledge for API surfaces, as they might be deprecated or outdated. Always verify the current usage via Context7 first.
+
+- **Available Skills:** Check `.claude/skills/` for available AI-powered skills before starting a task. Each skill has its own `SKILL.md` with full instructions.

package/dist/templates/next-app/eslint.config.mjs

@@ -0,0 +1,18 @@
+import { defineConfig, globalIgnores } from "eslint/config";
+import nextVitals from "eslint-config-next/core-web-vitals";
+import nextTs from "eslint-config-next/typescript";
+
+const eslintConfig = defineConfig([
+  ...nextVitals,
+  ...nextTs,
+  // Override default ignores of eslint-config-next.
+  globalIgnores([
+    // Default ignores of eslint-config-next:
+    ".next/**",
+    "out/**",
+    "build/**",
+    "next-env.d.ts",
+  ]),
+]);
+
+export default eslintConfig;

package/dist/templates/next-app/global.d.ts

@@ -0,0 +1,8 @@
+import common from "./src/locales/en/common.json";
+import home from "./src/locales/en/home.json";
+
+type Messages = typeof common & typeof home;
+
+declare global {
+  interface IntlMessages extends Messages {}
+}

package/dist/templates/next-app/luxw.json

@@ -0,0 +1,12 @@
+{
+  "routes": {
+    "publicRoutes": ["/"],
+    "privateRoutes": []
+  },
+  "i18n": {
+    "defaultLocale": "",
+    "locales": [],
+    "supportedLocales": [],
+    "localeDirectory": "src/locales"
+  }
+}

package/dist/templates/next-app/next.config.ts

@@ -0,0 +1,9 @@
+import type { NextConfig } from "next";
+import createNextIntlPlugin from 'next-intl/plugin';
+
+const nextConfig: NextConfig = {
+  devIndicators: false,
+};
+
+const withNextIntl = createNextIntlPlugin('./src/i18n/request.ts');
+export default withNextIntl(nextConfig);