RubyGems - tsykvas_rails_template - Versions diffs - 0.1.0 - Mend

tsykvas_rails_template 0.1.0

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 (79) hide show

data/lib/generators/tsykvas_rails_template/install/templates/.claude/commands/pr-review.md ADDED Viewed

@@ -0,0 +1,81 @@
+Review a GitHub Pull Request using the project's code review standards.
+## Usage
+`/pr-review <PR_NUMBER_OR_URL>`
+Examples:
+- `/pr-review 123`
+- `/pr-review https://github.com/org/repo/pull/123`
+## Steps
+1. Extract the PR number from the argument (strip URL if needed).
+2. Fetch PR metadata:
+   ```
+   gh pr view <number> --json number,title,body,author,baseRefName,headRefName,labels,additions,deletions,changedFiles
+   ```
+3. Fetch list of changed files:
+   ```
+   gh pr diff <number> --name-only
+   ```
+4. Launch **three agents in parallel** using the Agent tool, giving each the PR metadata and list of changed files — let them read the files and diff themselves:
+   **Agent 1 — code-reviewer** (subagent_type: `code-reviewer`)
+   Prompt: "Review the changes in PR #<number> '<title>'. Changed files: [list]. Use `gh pr diff <number>`, Read, Glob, Grep to read the files and understand what changed. Focus on Concepts Pattern compliance, code style, and best practices."
+   **Agent 2 — security-reviewer** (subagent_type: `security-reviewer`)
+   Prompt: "Security audit the changes in PR #<number> '<title>'. Changed files: [list]. Use `gh pr diff <number>`, Read, Glob, Grep to read the files and understand what changed."
+   **Agent 3 — tech-lead** (subagent_type: `tech-lead`)
+   Prompt: "Pre-PR architectural review of PR #<number> '<title>' by <author>. Base: <baseRef> ← <headRef>. PR description: <body>. Changed files: [list]. Use `gh pr diff <number>`, Read, Glob, Grep to read the files and understand what changed."
+5. Collect results from all three agents and present a unified report.
+## Output format
+Present the final report in **English** with the following structure:
+```
+# PR Review: #<number> — <title>
+**Author:** <author> | **Branch:** <headRef> → <baseRef>
+**Changes:** +<additions> / -<deletions> across <changedFiles> files
+## Changed Files
+<list of changed files with a brief one-line description of what changed in each>
+---
+## Code Review (Concepts Pattern, style, best practices)
+<output from code-reviewer agent>
+---
+## Security
+<output from security-reviewer agent>
+---
+## Architecture & Assessment
+<output from tech-lead agent>
+---
+## Summary
+**Merge readiness:** ✅ Ready / ⚠️ Needs fixes / 🔴 Blocker
+<3–5 bullet points: critical blockers, required fixes, optional improvements>
+```
+## Rules
+- If no PR number is provided, print usage instructions and stop.
+- If `gh` returns an error (not authenticated, PR not found), report it clearly and stop.
+- Do not check out the branch or modify the working tree.
+- Skip locale files unless a key is missing, duplicated, or used inconsistently.
+- Every finding must include the file path and line number.

data/lib/generators/tsykvas_rails_template/install/templates/.claude/commands/pushit.md ADDED Viewed

@@ -0,0 +1,160 @@
+Pre-flight checks, commit, and push to current branch on GitHub. Validates nothing sensitive is committed, runs full health checks, then commits and pushes.
+Five phases: **Update docs → Update rules → Safety scan → Health checks → Commit & push**. Stop and ask the user if any phase finds problems.
+## Phase 0a: Update documentation
+Run the `/update-docs` command first. This checks whether documentation in `docs/` (project root) needs updating based on code changes. Follow its full flow (present findings, ask for confirmation, update if approved).
+## Phase 0b: Update rules
+Run the `/update-rules` command. This checks whether `.claude/docs/` or `CLAUDE.md` need updating based on changes to base classes. Follow its full flow (present proposed changes, require explicit confirmation before any edits).
+## Phase 1: Safety scan
+Check that we are not committing something we shouldn't.
+### 1a. Scan staged and unstaged changes for sensitive files
+```bash
+git status --short 2>&1
+```
+Look for files that should NOT be in git:
+| Pattern | Why |
+|---------|-----|
+| `.env`, `.env.*` (not `.env.example`) | Secrets, API keys |
+| `*.key`, `*.pem`, `*.crt`, `*.p12` | Private keys / certs |
+| `credentials.yml.enc` changes without `*.key` in gitignore | Encrypted credentials |
+| `config/master.key` | Rails master key |
+| `*.sqlite3`, `*.sqlite3-*` | Local databases |
+| `node_modules/`, `vendor/bundle/` | Dependencies |
+| `.idea/` (non-shared config), `*.iml` | IDE-specific files |
+| `coverage/` | Test coverage reports |
+| `/storage/*` | Uploaded files |
+| `/log/*`, `/tmp/*` | Logs and temp files |
+| `*.dump`, `*.sql` | Database dumps |
+| Files containing hardcoded tokens/passwords | Secrets in code |
+Also check:
+```bash
+git diff --cached --name-only 2>&1
+git diff --name-only 2>&1
+```
+### 1b. Grep for accidental secrets in changed files
+```bash
+git diff -U0 | grep -iE '(api_key|secret|password|token|private_key)\s*[:=]' 2>&1
+git diff --cached -U0 | grep -iE '(api_key|secret|password|token|private_key)\s*[:=]' 2>&1
+```
+### 1c. Check if .gitignore is missing common patterns
+Verify `.gitignore` covers: `.env*`, `*.key`, `/log/*`, `/tmp/*`, `/storage/*`, `/coverage`, `/public/assets`.
+### If problems found
+Show a table:
+| File / Pattern | Problem | Suggestion |
+|----------------|---------|------------|
+| ... | ... | ... |
+Ask:
+> Found N safety issue(s). Fix them?
+> 1. Yes, fix (add to .gitignore / unstage / remove)
+> 2. No, continue anyway
+> 3. Abort
+Wait for response. Fix if asked, abort if asked, or continue.
+---
+## Phase 2: Health checks
+Run the full check suite as defined in `/check`:
+1. `bin/rails zeitwerk:check 2>&1`
+2. `bundle exec rspec --format progress 2>&1`
+3. `bin/rubocop --format simple 2>&1`
+Run ALL checks, never stop early.
+### If problems found
+Show the summary table:
+| Check | Status | Issues |
+|-------|--------|--------|
+| ... | ... | ... |
+Then show issue details and ask:
+> Found N issue(s). Fix them before pushing?
+> 1. Yes, fix all
+> 2. No, push anyway
+> 3. Abort
+Wait for response. If yes — fix issues, re-run failing checks to confirm, then continue.
+---
+## Phase 3: Commit & push
+### 3a. Stage changes
+```bash
+git add -A
+```
+Review what's being committed:
+```bash
+git diff --cached --stat 2>&1
+```
+### 3b. Create commit
+- Write a concise 1-sentence commit message that describes WHAT changed and WHY
+- Use imperative mood ("Add...", "Fix...", "Refactor...", "Update...")
+- Keep under 72 characters
+```bash
+git commit -m "$(cat <<'EOF'
+Your commit message here
+Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
+EOF
+)"
+```
+### 3c. Push to current branch
+Determine the current branch:
+```bash
+git branch --show-current 2>&1
+```
+Push:
+```bash
+git push origin HEAD 2>&1
+```
+### If push fails
+- **No upstream**: run `git push -u origin HEAD 2>&1`
+- **Rejected (non-fast-forward)**: try `git pull --rebase origin <branch> 2>&1`, resolve conflicts if any, then push again
+- **Merge conflict during rebase**: show the conflicts and ask for guidance
+- **Needs force push**: **NEVER force push automatically**. Show the situation and ask:
+  > Push was rejected. Force push with `--force-with-lease`?
+  > 1. Yes
+  > 2. No, abort
+### 3d. Confirm
+Show final status:
+```
+Pushed to <branch> → <remote-url>
+Commit: <short-hash> <message>
+Files changed: N
+```

data/lib/generators/tsykvas_rails_template/install/templates/.claude/commands/refactor.md ADDED Viewed

@@ -0,0 +1,132 @@
+Refactor the provided files following the project's architecture and clean code principles.
+## Input
+Files to refactor: $ARGUMENTS
+If no files are provided, ask the user which files they want to refactor.
+## Steps
+### 1. Read and understand
+Read every file listed in `$ARGUMENTS`. Also read any closely related files needed for full context:
+- The `.slim` template when refactoring a component `.rb`
+- The operation when refactoring the component that consumes it
+- **Sibling files of the same type** (e.g. if refactoring `users_table.rb`, also read `companies_table.rb`) — they often share duplicated logic that should be extracted together
+### 2. Analyse for issues
+Before writing any code, identify all issues in the files:
+**Clean code:**
+- Methods longer than 30 lines or conceptually doing more than one thing
+- Classes longer than 150 lines — investigate whether the class can be split
+- Logic that can be extracted into a well-named private method
+- Repeated expressions or patterns — both within the file **and across sibling files**. When logic is duplicated across files, extract it (a shared concern, a helper class, or a method on `Base::Component::Base`)
+- Variables or methods with unclear names
+- Deep nesting (more than 2–3 levels) that can be flattened
+- Long parameter lists — group with a value object or keyword args
+- Magic constants — extract to a named constant
+- Comments that explain *what* instead of *why* (replace with expressive code)
+**Ruby / Rails style (per `.claude/docs/code-style.md`):**
+- Missing `# frozen_string_literal: true`
+- Use of `t()` shorthand instead of `I18n.t('full.key')` in components and operations
+- `DateTime.parse(...)` — replace with `Time.zone.parse(...)`
+- Missing trailing commas in multi-line arrays and hashes
+- Missing locale keys in `config/locales/<your-default>.yml` and `config/locales/<other>.yml`
+- `rubocop:disable` annotations — investigate each one; fix the underlying issue if possible
+**Concepts Pattern (per `.claude/docs/architecture.md`):**
+- Components that fetch data (must be pure presentation — only `initialize` + helpers)
+- Operations that contain presentation logic
+- Missing `authorize!` / `policy_scope` / `skip_authorize` in operations
+- Non-compact class notation (nested modules instead of `class Feature::Op::Action`)
+- Controllers that do more than `endpoint Op, Component`
+- Index operations missing `Base::Operation::Sortable` allowlist for sorting params
+**ViewComponent specifics:**
+- `call`-style components: long `call` methods that mix column definitions with logic — extract cell helpers
+- Duplicated column/cell rendering logic across table components
+- `tag.div`/`tag.span` chains that can be extracted into named helper methods
+- Buttons not using `Base::Component::Btn` (all buttons must use it with a valid `type:`)
+- Multiple buttons in a table cell not wrapped in `safe_join([render(...), ...])`
+**Stimulus controllers (per `.claude/docs/stimulus-controllers.md`):**
+- Document-level event listeners not using arrow-function class fields (or properly stored bound references)
+- Missing `disconnect()` cleanup for any listener added in `connect()`
+- `.bind(this)` used in `connect()` without storing the reference for later removal
+- Controller doing more than one responsibility — split into focused controllers
+### 3. Refactor
+Apply all improvements found in step 2. Rules:
+- **Preserve all existing behaviour exactly** — this is a refactor, not a rewrite
+- **Extract private methods** for any logic block that has a clear single responsibility or is used more than once
+- **Name methods after what they return or do**, not how they do it (`role_badge` not `build_span_with_class`)
+- **Keep public interface identical** — same `initialize` signature, same `call` output
+- **One concern per method** — data transformation, formatting, and rendering should not mix
+- **Slim templates**: keep logic minimal; move Ruby expressions into the component `.rb`
+- **Operations**: split `perform!` into private steps when it has more than 3–4 distinct phases
+- **Shared logic across files**: when the same method exists in two or more files, extract it once and call it from both — do not leave duplicates
+- **OpenStruct keys**: if a key in `self.model = ::OpenStruct.new(...)` is never read by the component, remove it from both the operation and the component `initialize`
+- Do NOT add features, change behaviour, or "improve" things that were not identified as issues
+- Do NOT add docstrings or inline comments unless the logic is genuinely non-obvious
+### 4. Update locales if needed
+If you added or renamed any `I18n.t()` call, update both:
+- `config/locales/<your-default>.yml`
+- `config/locales/<other>.yml`
+### 5. Run specs for refactored files
+For each `.rb` file refactored, check whether a corresponding spec exists by mirroring the path under `spec/`. If a spec exists, run it:
+```bash
+bundle exec rspec <spec_file_path>
+```
+If tests fail:
+- **Caused by our changes** (e.g. renamed a private method that was tested directly, changed a return value) — fix the source code or the spec to match the new structure while preserving the intent of the test
+- **Pre-existing failures unrelated to our changes** — report them but do not fix; note them in the output as "pre-existing"
+Do NOT delete or weaken tests to make them pass.
+### 6. Validate
+Run in order and fix any failures before reporting:
+```bash
+bin/rails zeitwerk:check
+bin/rubocop -A
+bin/rubocop
+```
+Run `-A` (autocorrect) first to fix all auto-correctable offenses, then run plain `rubocop` to address any remaining issues manually.
+## Output format
+After completing the refactor, report:
+```
+## Refactored files
+<list of files changed>
+## What changed
+<for each file: bullet list of specific changes made and why>
+## Validation
+<result of zeitwerk / rubocop>
+```
+## Rules
+- Never skip the validation step.
+- If a file is already clean and well-structured, say so and make no changes.
+- If a refactor would require changing a public API used by other files, read those callers first and update them too.
+- Prefer many small focused private methods over few large ones.
+- The final code must be easier to read than the original — that is the only success criterion.

data/lib/generators/tsykvas_rails_template/install/templates/.claude/commands/task-sum.md ADDED Viewed

@@ -0,0 +1,47 @@
+Generate a user-facing release notes Markdown file based on the current git changes in this branch.
+## Steps
+1. Run `git log main..HEAD --oneline` to see all commits in the current branch.
+2. Run `git diff main...HEAD --stat` to get a high-level overview of changed files.
+3. Run `git diff main...HEAD` to read the full diff.
+4. Read any key changed files (components, operations, views, locale files) to understand *what* the feature actually does from the user's perspective.
+5. Determine a short, descriptive filename for the release notes based on the feature, e.g. `RELEASE_NOTES_<FEATURE_NAME>.md`.
+6. Write the file to the **project root** (`<filename>.md`).
+## Output format
+The file must be written in **English** and follow this structure:
+```markdown
+# <Feature Title>
+## What's New
+<1–3 sentences describing the new feature or improvement and the problem it solves.>
+## How It Works
+<Step-by-step or bullet-point explanation of the feature from the user perspective.>
+## Where to Find It
+<Tell the user where in the UI this appears and how to access it.>
+## Notes
+<Optional. Any caveats, edge cases, or useful context for the user.>
+```
+## Rules
+- Write for **end users**, not developers — no class names, no file paths, no framework terms.
+- Focus on **what changed** and **why it matters**, not how it was implemented.
+- If the branch contains multiple unrelated changes, create one file that covers all of them in separate sections.
+- Keep the tone clear, concise, and professional.
+- Do not include a "Notes" section if there is nothing meaningful to say.

data/lib/generators/tsykvas_rails_template/install/templates/.claude/commands/tests.md ADDED Viewed

@@ -0,0 +1,67 @@
+Run RSpec tests and RuboCop linting, check test coverage for uncommitted changes, then automatically fix any issues found.
+Follow the project test conventions defined in: `.claude/docs/testing.md` and `.claude/docs/testing-examples.md`.
+## Step 0: Check test coverage for uncommitted changes
+```bash
+git diff --name-only HEAD 2>&1
+git diff --name-only --cached HEAD 2>&1
+git ls-files --others --exclude-standard 2>&1
+```
+From the combined output, find all `.rb` files that contain logic (controllers, operations, components, models, policies, services — skip empty classes, pure config, migrations, and files with no methods).
+For each such file, check if a corresponding spec exists:
+- `app/concepts/admin/user/operation/index.rb` → `spec/concepts/admin/user/operation/index_spec.rb`
+- `app/controllers/admin/users_controller.rb` → `spec/controllers/admin/users_controller_spec.rb` or `spec/requests/admin/users_spec.rb`
+- `app/policies/crm/company_policy.rb` → `spec/policies/crm/company_policy_spec.rb`
+- `app/models/user.rb` → `spec/models/user_spec.rb`
+- `app/concepts/admin/user/component/users_table.rb` → `spec/concepts/admin/user/component/users_table_spec.rb`
+If a spec file is **missing** — create it following conventions in `.claude/docs/testing.md` and `.claude/docs/testing-examples.md`.
+If a spec file **exists** but doesn't cover the new/changed logic — update it to cover the changes.
+**Important:** For each changed `.rb` file, read the actual diff (`git diff HEAD -- <file>`) and the corresponding spec. Verify that every new/changed public method, conditional branch, and business logic path is covered by tests. Don't just check that a spec file exists — check that it tests the new code.
+**Skip testing for:** Component `.rb` files that only contain parameter initialization (no business logic, no methods beyond `initialize`). These are pure data-passing wrappers and don't need specs.
+## Step 1: RSpec
+```bash
+bundle exec rspec --format progress 2>&1
+```
+If there are failures:
+1. Read each failing spec and the corresponding source file
+2. Determine whether the bug is in the test or in the source code
+3. Fix it
+4. Re-run only the fixed specs to confirm: `bundle exec rspec <file>:<line> 2>&1`
+## Step 2: RuboCop
+```bash
+bin/rubocop --format simple 2>&1
+```
+If there are offenses:
+1. Auto-correct what's safe: `bin/rubocop -A 2>&1`
+2. If offenses remain, fix them manually
+3. Re-run rubocop to confirm: `bin/rubocop --format simple 2>&1`
+## Step 3: Confirm
+After fixing, re-run both to make sure nothing is broken:
+```bash
+bundle exec rspec --format progress 2>&1
+bin/rubocop --format simple 2>&1
+```
+Report final status:
+- **RSpec**: X examples, Y failures, Z pending
+- **RuboCop**: X offenses / no offenses
+If everything passes — just say so.
+If something still fails after your fix attempts — show what's left and ask for guidance.