@nt-ai-lab/opencode-skillz 0.3.11 → 0.3.13

package/commands/component-design.md

@@ -77,7 +77,7 @@ The following guidelines should be applied when designing components.
 
 ### Layering
 
-Components should be put into the correct layer based on the type of logic they contain.
+Components should be put into the correct layer based on the type of logic they contain. They MUST live in a folder (or sub folder) that represents their layer. Dumping everyting in the root of the module is forbidden (only entrypoints can live their like `index.ts` and `main.ts`)
 
 - `domain`: Business rules and domain logic. This should be kept pure and isolated from technical concerns like database transactions. A domain expert should be able to read it and understand it
 
@@ -85,7 +85,15 @@ Components should be put into the correct layer based on the type of logic they
 
 - `infra`: Technical capabilities live in here like database transactions, persistence, external service clients and so on. Use dedicated sub-folders to properly organize like `/persistence`, `/external-service`
 
-- `/infra/{gateway}`: This sub-layer handles receiving inputs from the outside world and returning responses to the outside world, like gateways sitting at the edge of the application. It's common to see http controllers and event handlers in this layer. Examples of `{gateway}` include `http`, `event-handlers`
+- `/infra/{gateway}`: This sub-layer handles receiving inputs from the outside world and returning responses to the outside world, like gateways sitting at the edge of the application. It's common to see http controllers and event handlers in this layer. Examples of `{gateway}` include `http`, `event-handlers`. Everything inside this layer must live in a sub-folder to avoid the root becoming a dumping ground and hiding design issues.
+
+The following folder names are baned because they are generic terms that become a dumping ground or workaround for bad design. Find a more precise name or ask for help.
+
+- `utils`
+- `helpers`
+- `models`
+- `core`
+- `shared`
 
 Each codebase has it's own layering conventions that should be respected, but when no layering convention exists use the above as the default.
 
@@ -203,4 +211,6 @@ Before presenting the final design, review every component name against all rule
 
 If any name violates any naming rule, revise the design before presenting it.
 
+Then review all components against all guidelines in Layering. If any components violates a layering rule, revise the design befor presenting it.
+
 Ask the user which option to approve, reject, or combine.

package/commands/create-pr.md

@@ -12,7 +12,7 @@ Create a draft pull request for the current branch.
 - The branch contains unrelated changes that do not belong in the same pull request
 - The base branch is unclear
 - The change requires assumptions about user value, scope, or design intent
-- An existing commit already on the branch does not comply with the required commit format and fixing it would require rewriting history
+- An existing commit title already on the branch does not comply with the required commit title format and fixing it would require rewriting history
 
 ## Required context gathering
 
@@ -42,9 +42,9 @@ If local changes exist:
 
 Do not create the pull request until `git status` is clean.
 
-## Commit rules
+## Commit title rules
 
-Every commit included in the pull request must use the full commit format defined below.
+Every commit included in the pull request must use the commit title format defined below.
 
 Use semantic commit types:
 
@@ -65,43 +65,13 @@ Rules:
 - Use `release` for version bumps or release preparation work
 - Use the smallest accurate scope
 - The commit subject must describe the user-facing change or the real engineering outcome
-- The commit body must explain why the change exists, not list files changed
-- The commit body must reference all relevant source-of-truth materials
-- The acceptance criteria must be copied from the source material, not loosely rewritten
+- Commit bodies are optional
+- Do not require existing commits to contain body sections
 
-Commit subject format:
+Commit title format:
 
 `<type>(<scope>): <short summary>`
 
-Commit body format:
-
-```text
-<type>(<scope>): <short summary>
-
-## Problem
-
-Source of truth:
-- Ticket: <ticket id or link>
-- Plan: <link>
-- Design: <link>
-- Additional references: <link if relevant>
-
-<Describe the actual user problem, business problem, or engineering risk being solved.
-Explain the user value or operational value.>
-
-## Solution
-
-<Describe the chosen solution and why it solves the problem. Focus on outcome and approach, not file inventory.>
-
-## Acceptance Criteria
-
-Source: copied from <ticket or plan reference>
-
-- <criterion 1>
-- <criterion 2>
-- <criterion 3>
-```
-
 ## Pull request title
 
 Use a clear title that matches the real change. Reuse the best semantic commit subject when that is the best title.
@@ -139,39 +109,23 @@ Rules:
 - do not invent new criteria without stating that they are additional reviewer notes
 - do not paraphrase loosely if exact wording exists in the source material
 
-### `## Architecture and software design`
-
-This section is free-form.
-
-Include the architectural and design details that matter most for review, based on the current change. Use judgment instead of rigid structure.
-
-Good topics to include when relevant:
+Acceptance criteria describe verifiable outcomes like "Users can log i with their email address". An acceptance criteria is not an implementation instruction like "Add a script that accepts the same parameters". If you find yourself using workds like "add", "modify" in "acceptance criteria" stop and ask for help.
 
-- important new components that were added
-- important existing components that were modified
-- responsibility or boundary changes between components
-- meaningful flow changes through the system
-- changed persistence, messaging, API, or integration behavior
-- new or changed dependencies
-- contract changes between internal modules or external systems
-- how the implemented design maps back to the approved design or plan
-
-Avoid low-signal detail such as trivial renames, minor refactors, or file-by-file narration unless those details are central to the design review.
-
-Write this section as a reviewer-focused design summary.
-
-## GitHub command authentication
+### `## Architecture and software design`
 
-Before a GitHub command that needs authentication:
+Describe major architectural changes like:
 
-1. Run `gh auth token`
-2. Use the returned token inline as `GITHUB_TOKEN=<token>` on the next GitHub command
+1. Which packages / modules were added, removed, or impacted?
+2. Which components were added / modified inside each module and why?
+3. Are there any significant domain model changes (new concepts, changes to terminology)
+4. New or modified depeendecies between components
+5. New or modified dependencies on other services or libraries
 
 ## Execution steps
 
 1. Confirm the branch is ready for a pull request
 2. If local changes exist, stage the relevant changes and create the required semantic commits until the working tree is clean
-3. Verify every commit included in the pull request complies with the required format
+3. Verify every commit included in the pull request complies with the required commit title format
 4. Push the branch if needed
 5. Create a draft pull request with the required description format
 6. Return the pull request URL

package/commands/review-pr.md

@@ -1,42 +1,90 @@
 ---
-description: Run Vitest coverage for a pull request and update the PR description coverage block
+description: Review PR code quality, test quality, and coverage
 ---
 
-Review pull request coverage for:
+Review pull request code quality, test quality, and coverage for:
 $ARGUMENTS
 
-## Software Design Compliance
+## PR Resolution
+
+1. Resolve the pull request from `$ARGUMENTS`.
+2. If `$ARGUMENTS` does not identify a PR URL or PR number, stop and ask for one.
+3. Run `gh pr diff <pr> --name-only` to identify changed files.
+4. Fetch existing PR review comments and do not post the same comment twice on the same line.
+
+## Parallel Review Subtasks
+
+The `Software Design Compliance` and `Test Quality` reviews should run in parallel.
+
+### Software Design Compliance
+
+Invoke the default subagent with a task prompt that requires it to:
+
+1. Review new and modified production code against `/nt-skillz:software-design`.
+2. Leave inline feedback only on changed PR diff lines.
+3. Prefix every inline message with `[Software Design]`.
+4. If a finding cannot be attached to a changed diff line, return it as a summary finding instead of posting an inline comment.
+5. Return the count of inline findings and summary findings.
+
+Provide the subagent with:
+
+- the resolved PR identifier
+- the changed file list
+- the changed diff context
 
-Ensure all new and modified code complies with `/nt-skillz:software-design`
 
-Leave in-line feedback on the PR for lines that do not comply. Prefix messages with [Software Design]
+### Test Quality
 
-## Test Quality 
+Invoke the default subagent with a task prompt that requires it to:
 
-Ensure all new and modified tests comply with  `/nt-skillz-writing-tests`
+1. Review new and modified tests against `/nt-skillz:writing-tests`.
+2. Leave inline feedback only on changed PR diff lines.
+3. Prefix every inline message with `[Test Quality]`.
+4. If a finding cannot be attached to a changed diff line, return it as a summary finding instead of posting an inline comment.
+5. Return the count of inline findings and summary findings.
 
-Leave in-line feedback on the PR for lines that do not comply. Prefix messages with [Test Quality]
+Provide the subagent with:
 
-## Test Coverage Analysis 
+- the resolved PR identifier
+- the changed file list
+- the changed diff context
+
+## Test Coverage Analysis
 
 Add a test coverage analysis results section to the PR description:
 
-1. Resolve the pull request from `$ARGUMENTS`.
-2. If `$ARGUMENTS` does not identify a PR URL or PR number, stop and ask for one.
-3. Run `gh pr diff <pr> --name-only`.
-4. For each changed path from that output, run `/nt-skillz:vitest-coverage <file>`.
-5. Ignore only runs that print a `SKIP:` line.
-6. If every run prints a `SKIP:` line, use one fenced `text` block containing `No changed TypeScript source files.` as the coverage content.
-7. Otherwise, build the PR coverage block in this exact shape:
+1. For each changed path from `gh pr diff <pr> --name-only`, run `/nt-skillz:vitest-coverage <file>`.
+2. Ignore only runs that print a `SKIP:` line.
+3. If every run prints a `SKIP:` line, use one fenced `text` block containing `No changed TypeScript source files.` as the coverage content.
+4. Otherwise, build the PR coverage block in this exact shape:
     - `<!-- nt-skillz-coverage:start -->`
     - `## Coverage`
     - one `### \`<file>\`` heading for each non-`SKIP:` file
     - one fenced `text` block containing the exact raw `/nt-skillz:vitest-coverage <file>` output directly under that file heading
     - `<!-- nt-skillz-coverage:end -->`
-8. Run `gh pr view <pr> --json body --jq '.body'` and use the returned text as the current PR body.
-9. If the current PR body already contains both marker lines, replace only the text from `<!-- nt-skillz-coverage:start -->` through `<!-- nt-skillz-coverage:end -->` with the new coverage block.
-10. If the current PR body does not contain both marker lines, append the new coverage block to the end of the PR body separated by two newlines.
-11. Write the updated PR body to a temporary file.
-12. Run `gh pr edit <pr> --body-file <temporary-file>`.
-13. Do not summarize, interpret, or paraphrase the coverage output.
-14. Do not modify any other part of the PR body.
+5. Run `gh pr view <pr> --json body --jq '.body'` and use the returned text as the current PR body.
+6. If the current PR body already contains both marker lines, replace only the text from `<!-- nt-skillz-coverage:start -->` through `<!-- nt-skillz-coverage:end -->` with the new coverage block.
+7. If the current PR body does not contain both marker lines, append the new coverage block to the end of the PR body separated by two newlines.
+8. Write the updated PR body to a temporary file.
+9. Run `gh pr edit <pr> --body-file <temporary-file>`.
+10. Do not summarize, interpret, or paraphrase the coverage output.
+11. Do not modify any other part of the PR body.
+
+## Basic PR checks
+
+Look for the following issues on the PR:
+
+1. Unnecessary noise: does the PR contains noise in the dif like unnecessary formatting changes? Those should be removed to make the reviewer's job easier unless they are enforced by the project conventions.
+
+2. Out of scope changes: does the PR contain modification to files that are not strictly necessary that add more unnecessary noise to the diff? Like refactoring existing code.
+
+## Final Report
+
+Report only:
+
+- software design inline findings count
+- software design summary findings count
+- test quality inline findings count
+- test quality summary findings count
+- coverage block update status
+- blockers that require user action

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nt-ai-lab/opencode-skillz",
-  "version": "0.3.11",
+  "version": "0.3.13",
   "description": "Bundled OpenCode commands and agents",
   "type": "module",
   "main": "dist/index.js",