@codyswann/lisa 1.79.0 → 1.79.2
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/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/rules/base-rules.md +13 -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 +13 -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.
|
|
79
|
+
"version": "1.79.2",
|
|
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": {
|
|
@@ -14,6 +14,7 @@ Do not begin a task if there are any blockers, ambiguities, access requirements,
|
|
|
14
14
|
Project Discovery:
|
|
15
15
|
- Determine the project's package manager before installing or running anything.
|
|
16
16
|
- Read the project manifest (e.g. package.json, pyproject.toml, Cargo.toml, go.mod) to understand available scripts and dependencies.
|
|
17
|
+
- Before defining a verification approach, check the `scripts` section of the project manifest for existing commands to start servers, run tests, seed databases, etc. Use existing scripts rather than inventing ad-hoc commands.
|
|
17
18
|
- Read the project's linting and formatting configuration to understand its standards.
|
|
18
19
|
- Regenerate the lockfile after adding, removing, or updating dependencies.
|
|
19
20
|
- Ignore build output directories (dist, build, out, target, etc.) unless specified otherwise.
|
|
@@ -28,6 +29,7 @@ Code Quality:
|
|
|
28
29
|
- Use project-relative paths rather than absolute paths in documentation and Markdown.
|
|
29
30
|
- Delete old code completely when replacing it. No deprecation unless specifically requested.
|
|
30
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.
|
|
31
33
|
- Test empirically to confirm something worked. Never assume.
|
|
32
34
|
- Never assume test expectations before verifying actual implementation behavior. Run tests to learn the behavior, then adjust expectations to match.
|
|
33
35
|
- Always provide a solution. Never dismiss something as "not related to our changes" or "not relevant to this task".
|
|
@@ -51,6 +53,17 @@ Testing Discipline:
|
|
|
51
53
|
JIRA Discipline:
|
|
52
54
|
- If working on a JIRA issue, make sure the branch you're working on references and is added to the JIRA issue.
|
|
53
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.
|
|
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.
|
|
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.
|
|
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:
|
|
60
|
+
```bash
|
|
61
|
+
ISSUE_ID=$(curl -s -u "${JIRA_LOGIN}:${JIRA_API_TOKEN}" \
|
|
62
|
+
"${JIRA_SERVER}/rest/api/2/issue/${TICKET_ID}?fields=id" | jq -r '.id')
|
|
63
|
+
curl -s -u "${JIRA_LOGIN}:${JIRA_API_TOKEN}" \
|
|
64
|
+
"${JIRA_SERVER}/rest/dev-status/1.0/issue/detail?issueId=${ISSUE_ID}&applicationType=GitHub&dataType=pullrequest" \
|
|
65
|
+
| jq '.detail[].pullRequests[] | {title, status, url, source: .source.branch}'
|
|
66
|
+
```
|
|
54
67
|
|
|
55
68
|
Agent Behavior:
|
|
56
69
|
- Never handle tasks yourself when working in a team of agents. Always delegate to a specialized agent.
|
|
@@ -14,6 +14,7 @@ Do not begin a task if there are any blockers, ambiguities, access requirements,
|
|
|
14
14
|
Project Discovery:
|
|
15
15
|
- Determine the project's package manager before installing or running anything.
|
|
16
16
|
- Read the project manifest (e.g. package.json, pyproject.toml, Cargo.toml, go.mod) to understand available scripts and dependencies.
|
|
17
|
+
- Before defining a verification approach, check the `scripts` section of the project manifest for existing commands to start servers, run tests, seed databases, etc. Use existing scripts rather than inventing ad-hoc commands.
|
|
17
18
|
- Read the project's linting and formatting configuration to understand its standards.
|
|
18
19
|
- Regenerate the lockfile after adding, removing, or updating dependencies.
|
|
19
20
|
- Ignore build output directories (dist, build, out, target, etc.) unless specified otherwise.
|
|
@@ -28,6 +29,7 @@ Code Quality:
|
|
|
28
29
|
- Use project-relative paths rather than absolute paths in documentation and Markdown.
|
|
29
30
|
- Delete old code completely when replacing it. No deprecation unless specifically requested.
|
|
30
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.
|
|
31
33
|
- Test empirically to confirm something worked. Never assume.
|
|
32
34
|
- Never assume test expectations before verifying actual implementation behavior. Run tests to learn the behavior, then adjust expectations to match.
|
|
33
35
|
- Always provide a solution. Never dismiss something as "not related to our changes" or "not relevant to this task".
|
|
@@ -51,6 +53,17 @@ Testing Discipline:
|
|
|
51
53
|
JIRA Discipline:
|
|
52
54
|
- If working on a JIRA issue, make sure the branch you're working on references and is added to the JIRA issue.
|
|
53
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.
|
|
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.
|
|
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.
|
|
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:
|
|
60
|
+
```bash
|
|
61
|
+
ISSUE_ID=$(curl -s -u "${JIRA_LOGIN}:${JIRA_API_TOKEN}" \
|
|
62
|
+
"${JIRA_SERVER}/rest/api/2/issue/${TICKET_ID}?fields=id" | jq -r '.id')
|
|
63
|
+
curl -s -u "${JIRA_LOGIN}:${JIRA_API_TOKEN}" \
|
|
64
|
+
"${JIRA_SERVER}/rest/dev-status/1.0/issue/detail?issueId=${ISSUE_ID}&applicationType=GitHub&dataType=pullrequest" \
|
|
65
|
+
| jq '.detail[].pullRequests[] | {title, status, url, source: .source.branch}'
|
|
66
|
+
```
|
|
54
67
|
|
|
55
68
|
Agent Behavior:
|
|
56
69
|
- Never handle tasks yourself when working in a team of agents. Always delegate to a specialized agent.
|