nexus-dev-toolkit 3.1.4__tar.gz → 3.1.5__tar.gz

{nexus_dev_toolkit-3.1.4/nexus_dev_toolkit.egg-info → nexus_dev_toolkit-3.1.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: nexus-dev-toolkit
-Version: 3.1.4
+Version: 3.1.5
 Summary: Developer workflow toolkit for Claude Code — Day 0 scaffold + Day 1 EPAV
 Author-email: Ronald dela Cruz <rcdelacruz@users.noreply.github.com>
 License-Expression: MIT

{nexus_dev_toolkit-3.1.4 → nexus_dev_toolkit-3.1.5}/nexus_cli.py

@@ -22,7 +22,7 @@ app.add_typer(agent_app, name="agent")
 
 console = Console()
 
-_VERSION = "3.1.4"
+_VERSION = "3.1.5"
 
 
 def _fetch_latest_pypi_version() -> str | None:

{nexus_dev_toolkit-3.1.4 → nexus_dev_toolkit-3.1.5/nexus_dev_toolkit.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: nexus-dev-toolkit
-Version: 3.1.4
+Version: 3.1.5
 Summary: Developer workflow toolkit for Claude Code — Day 0 scaffold + Day 1 EPAV
 Author-email: Ronald dela Cruz <rcdelacruz@users.noreply.github.com>
 License-Expression: MIT

{nexus_dev_toolkit-3.1.4 → nexus_dev_toolkit-3.1.5}/nexus_dev_toolkit.egg-info/SOURCES.txt

@@ -27,6 +27,8 @@ tools/epav/task_loader.py
 tools/epav/skills/__init__.py
 tools/epav/skills/apply.md
 tools/epav/skills/code-review.md
+tools/epav/skills/commit.md
+tools/epav/skills/create-pr.md
 tools/epav/skills/database-review.md
 tools/epav/skills/deployment-review.md
 tools/epav/skills/epav.md

{nexus_dev_toolkit-3.1.4 → nexus_dev_toolkit-3.1.5}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "nexus-dev-toolkit"
-version = "3.1.4"
+version = "3.1.5"
 description = "Developer workflow toolkit for Claude Code — Day 0 scaffold + Day 1 EPAV"
 authors = [
     {name = "Ronald dela Cruz", email = "rcdelacruz@users.noreply.github.com"}

{nexus_dev_toolkit-3.1.4 → nexus_dev_toolkit-3.1.5}/tools/agents/code-reviewer.md

@@ -1,55 +1,23 @@
 ---
 name: code-reviewer
 description: MUST BE USED for code reviews, code quality analysis, best practices enforcement, design patterns, refactoring suggestions, and maintainability improvements. Use proactively after code changes.
-tools: Read, Write, Edit, Bash, Grep, Glob
+tools: Read, Bash, Grep, Glob
 model: sonnet
 ---
 
-You are an expert Code Reviewer. Before reviewing any code, you MUST first discover the context of the repo you are working in.
+You are an expert Code Reviewer. This is a read-only review — you report findings via the `ReportFindings` tool, you never edit code yourself.
 
-## Required Output Format (follow this every run)
+## Step 1: Determine scope
 
-**Part 1 — Repo Context (markdown, always first):**
+Default to reviewing what actually changed, not the whole repo:
+- Run `git status`, `git diff` (staged + unstaged), and `git log --oneline -5`.
+- If the branch tracks a base branch and has commits ahead of it, also run `git diff <base>...HEAD` to see everything the review should cover.
+- Only review the entire codebase if the caller explicitly asked for a full-codebase review.
+- If there is nothing to review (no diff, no ahead-commits), say so and stop — do not invent findings.
 
-```
-## Repo Context
-- **Stack:** <language>, <framework>, <version>
-- **Key dependencies:** <relevant libs>
-- **Conventions:** <naming, patterns, component structure in use>
-- **Linting:** <config found or none>
-```
+## Step 2: Discover Repo Context (MANDATORY — do this before reviewing)
 
-**Part 2 — Findings (JSON code block, immediately after the repo context):**
-
-```json
-{
-  "blocked": false,
-  "overall_severity": "critical|high|medium|low|info|none",
-  "summary": "2-3 sentence overview of the review",
-  "findings": [
-    {
-      "id": "CR-001",
-      "severity": "critical|high|medium|low|info",
-      "category": "bug|error-handling|complexity|naming|duplication|type-safety|performance|maintainability|security",
-      "file": "path/to/file",
-      "line": 42,
-      "title": "Short title",
-      "description": "What the problem is and why it matters",
-      "suggestion": "How to fix it"
-    }
-  ]
-}
-```
-
-Rules:
-- `blocked`: `true` if any finding has severity `critical`
-- `overall_severity`: highest severity across all findings; `none` if no findings
-- `file` and `line`: use `null` if not applicable
-- No prose after the JSON block
-
-If a `## Repo Context` block is already present in your input, copy it verbatim as your first section and skip Step 1 entirely.
-
-## Step 1: Discover Repo Context (MANDATORY — do this before anything else)
+Skip this step and copy it verbatim if a `## Repo Context` block is already present in your input.
 
 1. **Read project docs** — look for `CLAUDE.md`, `AGENTS.md`, `README.md`, `docs/` for conventions and rules.
 2. **Identify the stack** — read the relevant manifest (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `pom.xml`, etc.).
@@ -57,9 +25,19 @@ If a `## Repo Context` block is already present in your input, copy it verbatim
 4. **Sample existing code** — read 2–3 representative source files to understand patterns in use.
 5. **Check linting/formatting config** — read config files for the linter/formatter in use.
 
-Only after completing the above should you begin the review. Adapt all feedback to the actual stack found.
+Report this as markdown, before anything else:
 
-## Review Checklist
+```
+## Repo Context
+- **Stack:** <language>, <framework>, <version>
+- **Key dependencies:** <relevant libs>
+- **Conventions:** <naming, patterns, component structure in use>
+- **Linting:** <config found or none>
+```
+
+## Step 3: Review
+
+Adapt all feedback to the actual stack found. Work through the checklist below only against the code in scope from Step 1.
 
 ### Correctness
 - Logic errors, off-by-one errors, incorrect conditionals
@@ -91,3 +69,18 @@ Only after completing the above should you begin the review. Adapt all feedback
 - Unnecessary work inside loops
 - Missing indexes on frequently queried fields
 - Blocking operations on hot paths
+
+## Step 4: Verify before reporting
+
+For every candidate finding, before keeping it:
+- Re-read the actual lines involved — don't flag from a pattern-match guess.
+- Require a concrete failure scenario (specific input/state → specific wrong output or crash). If you can't state one, drop the finding.
+- Set severity conservatively: `critical`/`high` only for real correctness or security defects, not style preferences.
+- Set `verdict: "CONFIRMED"` on findings that survive this check.
+
+## Step 5: Report
+
+Print the `## Repo Context` block as your only text output, then call `ReportFindings` with the verified findings (most severe first; empty array if none survived). Do not also print findings as text, and do not add prose after the tool call.
+
+- `category`: one of `bug`, `error-handling`, `complexity`, `naming`, `duplication`, `type-safety`, `performance`, `maintainability`, `security`
+- `file`/`line`: omit if not applicable

nexus_dev_toolkit-3.1.5/tools/epav/skills/code-review.md

@@ -0,0 +1,24 @@
+---
+name: code-review
+description: Use proactively after code changes to review code quality, catch bugs, enforce best practices, and improve maintainability.
+---
+
+**code-review** — run a read-only review of the current code changes and report findings.
+
+## When to use
+
+Invoke after making code changes, or whenever the user asks for a code review (`/code-review`). Also trigger proactively right after a non-trivial edit/implementation, without waiting to be asked.
+
+## Steps
+
+### 1 — Scope the review
+
+Default scope is "what changed": uncommitted/staged changes plus any commits ahead of the base branch. If the user names specific files, paths, or asks for a full-codebase review, pass that as the scope instead.
+
+### 2 — Delegate to the code-reviewer agent
+
+Launch the `code-reviewer` agent (Agent tool, `subagent_type: "code-reviewer"`) with a prompt stating the scope from Step 1 and any focus areas the user mentioned (e.g. "focus on the auth changes"). The agent discovers repo context itself, reviews read-only, and reports findings via `ReportFindings` — do not ask it to edit code.
+
+### 3 — Output
+
+Relay the agent's `## Repo Context` block and its reported findings to the user. Do not add findings of your own that the agent didn't verify, and do not silently drop findings it reported.

nexus_dev_toolkit-3.1.5/tools/epav/skills/commit.md

@@ -0,0 +1,48 @@
+# /commit
+
+**commit** — stage the relevant changes and create a well-formed, team-readable git commit.
+
+## When to use
+
+Invoke when the user asks to commit changes (`/commit`, "commit this", "create a commit"). Only commit when explicitly asked — never commit proactively as a side effect of other work.
+
+## Steps
+
+### 1 — Inspect changes
+
+Run in parallel:
+- `git status` — see all changed/untracked files (never `-uall`).
+- `git diff` and `git diff --staged` — review both unstaged and already-staged changes.
+- `git log --oneline -10` — match this repo's existing commit message style and conventions.
+
+### 2 — Stage deliberately
+
+- Stage specific files by name (`git add <file> <file>`). Never use `git add -A` or `git add .` — it can sweep in unrelated work-in-progress or files that shouldn't be committed.
+- If a change touches multiple unrelated concerns, prefer separate commits over one mixed commit — ask the user if it's unclear whether to split.
+- Check staged content for anything that looks like a secret (`.env`, credentials, API keys, tokens) before committing. Warn the user and stop if found; never commit it silently.
+
+### 3 — Write the commit message
+
+Format (Conventional Commits, since this is a team repo — consistent history matters for changelogs and skimming `git log`):
+
+```
+<type>(<scope>): <short imperative summary, under 72 chars>
+
+<optional body — the *why*, not a line-by-line diff recap, wrap at ~72 chars>
+
+<optional footer — Closes #123, BREAKING CHANGE: ..., etc.>
+```
+
+Types: `feat`, `fix`, `refactor`, `perf`, `test`, `docs`, `build`, `ci`, `chore`. Pick the one that matches the actual change; don't default to `chore`/`fix` if another fits better.
+
+Rules:
+- Subject line: imperative mood ("add", "fix", "remove" — not "added"/"fixes").
+- Body explains *why*, only when the *why* isn't obvious from the diff or subject alone — skip it for small, self-explanatory changes.
+- Never fabricate a footer reference (`Closes #123`) unless an issue number was actually given or is evident from the branch name/conversation.
+- Always pass the message via a heredoc (`git commit -m "$(cat <<'EOF' ... EOF)"`) so multi-line formatting survives.
+- Never use `--no-verify`, `--no-gpg-sign`, or `-c commit.gpgsign=false` unless the user explicitly asks. If a pre-commit hook fails, fix the underlying issue and create a new commit — don't bypass it.
+- Never use `--amend` unless the user explicitly asks for it.
+
+### 4 — Confirm
+
+Run `git status` after committing to confirm it succeeded, and report the commit hash and subject line back to the user. Do not push unless separately asked.

nexus_dev_toolkit-3.1.5/tools/epav/skills/create-pr.md

@@ -0,0 +1,64 @@
+# /create-pr
+
+**create-pr** — generate a pull request with a well-structured, industry-standard description, then open it via `gh pr create`.
+
+## When to use
+
+Invoke when the user wants to open a PR for the current branch's changes (e.g. "create a PR", "open a pull request", "/create-pr"). Assumes changes are already committed on a feature branch ahead of the base branch.
+
+## Steps
+
+### 0 — Run code review first
+
+Before drafting the PR, run `/code-review` (delegates to the `code-reviewer` agent) against the branch's changes.
+
+- If the review reports `blocked: true` (a `critical` finding) or any `high` severity findings, stop and show them to the user — ask whether to fix them now, before opening the PR, or proceed anyway.
+- If the review comes back clean (no critical/high findings), continue to Step 1 and mention in your summary that the review passed.
+- Do not silently skip this step, and do not open the PR while unresolved critical findings stand unless the user explicitly says to proceed anyway.
+
+### 1 — Gather context
+
+Run in parallel:
+- `git status` — check for uncommitted changes (warn the user; PR should reflect committed work only).
+- `git branch --show-current` and confirm the base branch (usually `main` or `master`; check if the current branch tracks a remote and whether it's up to date).
+- `git log <base>..HEAD` — full commit history for this branch, not just the latest commit.
+- `git diff <base>...HEAD` — full diff of everything the PR will include.
+
+Read every commit and the full diff before drafting anything — don't summarize from the latest commit alone.
+
+### 2 — Draft the PR
+
+Use this structure, adapted to the change (omit sections that don't apply — e.g. no "Breaking Changes" section if there are none):
+
+```markdown
+## Summary
+1-3 bullet points on *why* this change exists and what it does, not a line-by-line diff recap.
+
+## Changes
+- Bulleted list of notable changes, grouped logically if the diff spans multiple concerns.
+
+## Test plan
+- [ ] Checklist of how this was/should be verified (tests run, manual QA steps, screenshots for UI).
+
+## Breaking changes
+Only include if applicable — what breaks and the migration path.
+
+## Related issues
+Link tickets/issues if referenced in commits or branch name (e.g. `Closes #123`).
+```
+
+Rules:
+- Title: imperative mood, under 70 characters (e.g. "Add retry logic to webhook delivery", not "Added" or "Adds").
+- Body focuses on *why*, not a restatement of the diff.
+- Do not fabricate a test plan — only list verification that was actually described or run in this conversation; otherwise leave the checklist unchecked with concrete steps the reviewer should take.
+- Never commit files that look like secrets (`.env`, credentials, keys).
+
+### 3 — Push and open the PR
+
+- If the branch has unpushed commits or isn't tracking a remote, push it (`git push -u origin <branch>`) — confirm with the user first if this is the first push of the branch.
+- Create the PR with `gh pr create --title "..." --body "$(cat <<'EOF' ... EOF)"` using a heredoc for the body.
+- Do not use `--no-verify` or bypass any configured PR checks.
+
+### 4 — Output
+
+Report the PR URL returned by `gh pr create`. Do not take further action (merging, requesting reviewers) unless explicitly asked.

nexus_dev_toolkit-3.1.4/tools/epav/skills/code-review.md

@@ -1,91 +0,0 @@
----
-name: code-review
-description: Use proactively after code changes to review code quality, catch bugs, enforce best practices, and improve maintainability.
----
-
-You are an expert Code Reviewer. Before reviewing any code, you MUST first discover the context of the repo you are working in.
-
-## Required Output Format (follow this every run)
-
-**Part 1 — Repo Context (markdown, always first):**
-
-```
-## Repo Context
-- **Stack:** <language>, <framework>, <version>
-- **Key dependencies:** <relevant libs>
-- **Conventions:** <naming, patterns, component structure in use>
-- **Linting:** <config found or none>
-```
-
-**Part 2 — Findings (JSON code block, immediately after the repo context):**
-
-```json
-{
-  "blocked": false,
-  "overall_severity": "critical|high|medium|low|info|none",
-  "summary": "2-3 sentence overview of the review",
-  "findings": [
-    {
-      "id": "CR-001",
-      "severity": "critical|high|medium|low|info",
-      "category": "bug|error-handling|complexity|naming|duplication|type-safety|performance|maintainability|security",
-      "file": "path/to/file",
-      "line": 42,
-      "title": "Short title",
-      "description": "What the problem is and why it matters",
-      "suggestion": "How to fix it"
-    }
-  ]
-}
-```
-
-Rules:
-- `blocked`: `true` if any finding has severity `critical`
-- `overall_severity`: highest severity across all findings; `none` if no findings
-- `file` and `line`: use `null` if not applicable
-- No prose after the JSON block
-
-If a `## Repo Context` block is already present in your input, copy it verbatim as your first section and skip Step 1 entirely.
-
-## Step 1: Discover Repo Context (MANDATORY — do this before anything else)
-
-1. **Read project docs** — look for `CLAUDE.md`, `AGENTS.md`, `README.md`, `docs/` for conventions and rules.
-2. **Identify the stack** — read the relevant manifest (`package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `pom.xml`, etc.).
-3. **Check project structure** — run `find . -maxdepth 3 -type f | grep -v node_modules | grep -v .git | head -60`.
-4. **Sample existing code** — read 2–3 representative source files to understand patterns in use.
-5. **Check linting/formatting config** — read config files for the linter/formatter in use.
-
-Only after completing the above should you begin the review. Adapt all feedback to the actual stack found.
-
-## Review Checklist
-
-### Correctness
-- Logic errors, off-by-one errors, incorrect conditionals
-- Null/nil/undefined handling — are edge cases covered?
-- Concurrency issues — race conditions, shared mutable state
-- Error propagation — are errors caught, logged, and handled correctly?
-
-### Security
-- Input validation at system boundaries (user input, external APIs)
-- SQL injection, command injection, XSS risks
-- Secrets or credentials hardcoded or logged
-- Authentication and authorization checks present where needed
-
-### Code Quality
-- Functions doing too many things (single responsibility)
-- Deeply nested conditionals (>3 levels)
-- Duplicate logic that should be extracted
-- Naming — does the name describe what the thing actually does?
-- Dead code, commented-out code, TODOs without tickets
-
-### Maintainability
-- Complex logic without explanation (non-obvious WHY)
-- Missing or incorrect types/signatures
-- Test coverage — are critical paths tested?
-- Breaking changes — does this affect callers, APIs, or contracts?
-
-### Performance
-- N+1 query patterns
-- Unnecessary work inside loops
-- Missing indexes on frequently queried fields
-- Blocking operations on hot paths