@codyswann/lisa 1.79.1 → 1.80.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.
- package/cdk/package-lisa/package.lisa.json +1 -0
- package/nestjs/package-lisa/package.lisa.json +1 -0
- package/package.json +3 -2
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/rules/base-rules.md +2 -0
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/src/base/rules/base-rules.md +2 -0
- package/rails/create-only/.github/workflows/claude-code-review-response.yml +30 -0
package/package.json
CHANGED
|
@@ -76,7 +76,7 @@
|
|
|
76
76
|
"lodash": ">=4.18.1"
|
|
77
77
|
},
|
|
78
78
|
"name": "@codyswann/lisa",
|
|
79
|
-
"version": "1.
|
|
79
|
+
"version": "1.80.0",
|
|
80
80
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
81
81
|
"main": "dist/index.js",
|
|
82
82
|
"exports": {
|
|
@@ -182,7 +182,8 @@
|
|
|
182
182
|
"vitest": "^4.1.0"
|
|
183
183
|
},
|
|
184
184
|
"devDependencies": {
|
|
185
|
-
"@codyswann/lisa": "^1.78.2"
|
|
185
|
+
"@codyswann/lisa": "^1.78.2",
|
|
186
|
+
"vite": "^8.0.5"
|
|
186
187
|
},
|
|
187
188
|
"type": "module"
|
|
188
189
|
}
|
|
@@ -29,6 +29,7 @@ Code Quality:
|
|
|
29
29
|
- Use project-relative paths rather than absolute paths in documentation and Markdown.
|
|
30
30
|
- Delete old code completely when replacing it. No deprecation unless specifically requested.
|
|
31
31
|
- Fix bugs and issues properly. Never cover them up or work around them.
|
|
32
|
+
- When a tool or build step fails, never assume the failure is pre-existing and work around it. Investigate the root cause first — check git history, find when it broke and why — before deciding how to proceed.
|
|
32
33
|
- Test empirically to confirm something worked. Never assume.
|
|
33
34
|
- Never assume test expectations before verifying actual implementation behavior. Run tests to learn the behavior, then adjust expectations to match.
|
|
34
35
|
- Always provide a solution. Never dismiss something as "not related to our changes" or "not relevant to this task".
|
|
@@ -54,6 +55,7 @@ JIRA Discipline:
|
|
|
54
55
|
- If working on a JIRA issue, update the issue as you work through it. For example, if working on a Bug Triage, update the issue with your questions/feedback/suggestions.
|
|
55
56
|
- When reading a JIRA issue, always read ALL comments on the ticket — not just the description. Comments contain critical context: stakeholder decisions, scope changes, blockers, triage findings from other repos, and implementation notes. Use the Atlassian MCP or `jira issue view <TICKET_ID> --comments 100` to fetch them.
|
|
56
57
|
- When requesting clarification on a JIRA issue, post the question as a comment using ADF (Atlassian Document Format) and @mention the Reporter so they receive a notification.
|
|
58
|
+
- When creating JIRA tickets, establish issue link relationships (e.g. "is blocked by", "blocks", "relates to", "is duplicated by") between tickets that have dependencies or logical connections. Do not leave related tickets unlinked.
|
|
57
59
|
- When checking for associated pull requests on a JIRA issue, check the **Development panel** — not just comments or description text. The Development panel shows PRs, commits, branches, and builds linked via the GitHub-Jira integration. Query it via the dev-status API:
|
|
58
60
|
```bash
|
|
59
61
|
ISSUE_ID=$(curl -s -u "${JIRA_LOGIN}:${JIRA_API_TOKEN}" \
|
|
@@ -29,6 +29,7 @@ Code Quality:
|
|
|
29
29
|
- Use project-relative paths rather than absolute paths in documentation and Markdown.
|
|
30
30
|
- Delete old code completely when replacing it. No deprecation unless specifically requested.
|
|
31
31
|
- Fix bugs and issues properly. Never cover them up or work around them.
|
|
32
|
+
- When a tool or build step fails, never assume the failure is pre-existing and work around it. Investigate the root cause first — check git history, find when it broke and why — before deciding how to proceed.
|
|
32
33
|
- Test empirically to confirm something worked. Never assume.
|
|
33
34
|
- Never assume test expectations before verifying actual implementation behavior. Run tests to learn the behavior, then adjust expectations to match.
|
|
34
35
|
- Always provide a solution. Never dismiss something as "not related to our changes" or "not relevant to this task".
|
|
@@ -54,6 +55,7 @@ JIRA Discipline:
|
|
|
54
55
|
- If working on a JIRA issue, update the issue as you work through it. For example, if working on a Bug Triage, update the issue with your questions/feedback/suggestions.
|
|
55
56
|
- When reading a JIRA issue, always read ALL comments on the ticket — not just the description. Comments contain critical context: stakeholder decisions, scope changes, blockers, triage findings from other repos, and implementation notes. Use the Atlassian MCP or `jira issue view <TICKET_ID> --comments 100` to fetch them.
|
|
56
57
|
- When requesting clarification on a JIRA issue, post the question as a comment using ADF (Atlassian Document Format) and @mention the Reporter so they receive a notification.
|
|
58
|
+
- When creating JIRA tickets, establish issue link relationships (e.g. "is blocked by", "blocks", "relates to", "is duplicated by") between tickets that have dependencies or logical connections. Do not leave related tickets unlinked.
|
|
57
59
|
- When checking for associated pull requests on a JIRA issue, check the **Development panel** — not just comments or description text. The Development panel shows PRs, commits, branches, and builds linked via the GitHub-Jira integration. Query it via the dev-status API:
|
|
58
60
|
```bash
|
|
59
61
|
ISSUE_ID=$(curl -s -u "${JIRA_LOGIN}:${JIRA_API_TOKEN}" \
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# This file was created by Lisa on first setup.
|
|
2
|
+
# You can customize this file — Lisa will not overwrite it.
|
|
3
|
+
|
|
4
|
+
name: Claude Code Review Response
|
|
5
|
+
|
|
6
|
+
on:
|
|
7
|
+
pull_request_review:
|
|
8
|
+
types: [submitted]
|
|
9
|
+
|
|
10
|
+
permissions:
|
|
11
|
+
actions: write
|
|
12
|
+
checks: write
|
|
13
|
+
contents: write
|
|
14
|
+
issues: write
|
|
15
|
+
pull-requests: write
|
|
16
|
+
id-token: write
|
|
17
|
+
|
|
18
|
+
jobs:
|
|
19
|
+
respond-to-review:
|
|
20
|
+
uses: CodySwannGT/lisa/.github/workflows/reusable-claude-code-review-response.yml@main
|
|
21
|
+
with:
|
|
22
|
+
review_user_login: ${{ github.event.review.user.login }}
|
|
23
|
+
pr_user_login: ${{ github.event.pull_request.user.login }}
|
|
24
|
+
pr_head_ref: ${{ github.event.pull_request.head.ref }}
|
|
25
|
+
pr_number: ${{ github.event.pull_request.number }}
|
|
26
|
+
repo_owner: ${{ github.repository_owner }}
|
|
27
|
+
repo_name: ${{ github.event.repository.name }}
|
|
28
|
+
package_manager: 'none'
|
|
29
|
+
secrets:
|
|
30
|
+
CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
|