@codyswann/lisa 1.76.5 → 1.77.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/all/deletions.json +5 -1
- package/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +21 -1
- package/plugins/lisa/hooks/inject-rules.sh +22 -0
- package/{all/copy-overwrite/.claude → plugins/lisa}/rules/base-rules.md +4 -3
- package/{all/copy-overwrite/.claude → plugins/lisa}/rules/verification.md +10 -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 +23 -1
- package/plugins/lisa-rails/hooks/inject-rules.sh +22 -0
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/hooks/lint-on-edit.sh +3 -1
- package/plugins/src/base/.claude-plugin/plugin.json +4 -0
- package/plugins/src/base/hooks/inject-rules.sh +22 -0
- package/plugins/src/base/rules/base-rules.md +89 -0
- package/plugins/src/base/rules/coding-philosophy.md +428 -0
- package/plugins/src/base/rules/intent-routing.md +126 -0
- package/plugins/src/base/rules/security-audit-handling.md +30 -0
- package/plugins/src/base/rules/verification.md +93 -0
- package/plugins/src/rails/.claude-plugin/plugin.json +6 -0
- package/plugins/src/rails/hooks/inject-rules.sh +22 -0
- package/plugins/src/rails/rules/rails-conventions.md +176 -0
- package/plugins/src/typescript/hooks/lint-on-edit.sh +3 -1
- package/rails/deletions.json +2 -1
- package/plugins/lisa/hooks/enforce-plan-rules.sh +0 -15
- package/plugins/lisa/hooks/sync-tasks.sh +0 -107
- package/plugins/src/base/hooks/enforce-plan-rules.sh +0 -15
- package/plugins/src/base/hooks/sync-tasks.sh +0 -107
- /package/{all/copy-overwrite/.claude → plugins/lisa}/rules/coding-philosophy.md +0 -0
- /package/{all/copy-overwrite/.claude → plugins/lisa}/rules/intent-routing.md +0 -0
- /package/{all/copy-overwrite/.claude → plugins/lisa}/rules/security-audit-handling.md +0 -0
- /package/{rails/copy-overwrite/.claude → plugins/lisa-rails}/rules/rails-conventions.md +0 -0
package/all/deletions.json
CHANGED
|
@@ -125,12 +125,16 @@
|
|
|
125
125
|
".claude/hooks/track-plan-sessions.sh",
|
|
126
126
|
".claude/hooks/verify-completion.sh",
|
|
127
127
|
".claude/hooks/README.md",
|
|
128
|
-
".claude/rules/coding-philosophy.md",
|
|
129
128
|
".claude/rules/verfication.md",
|
|
130
129
|
".coderabbit.yml",
|
|
131
130
|
"scripts/setup-deploy-key.sh",
|
|
132
131
|
"HUMAN.md",
|
|
133
132
|
".claude/rules/lisa.md",
|
|
133
|
+
".claude/rules/base-rules.md",
|
|
134
|
+
".claude/rules/coding-philosophy.md",
|
|
135
|
+
".claude/rules/intent-routing.md",
|
|
136
|
+
".claude/rules/security-audit-handling.md",
|
|
137
|
+
".claude/rules/verification.md",
|
|
134
138
|
".lisa-manifest"
|
|
135
139
|
],
|
|
136
140
|
"keep": [
|
package/package.json
CHANGED
|
@@ -74,7 +74,7 @@
|
|
|
74
74
|
"flatted": "^3.4.2"
|
|
75
75
|
},
|
|
76
76
|
"name": "@codyswann/lisa",
|
|
77
|
-
"version": "1.
|
|
77
|
+
"version": "1.77.0",
|
|
78
78
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
79
79
|
"main": "dist/index.js",
|
|
80
80
|
"exports": {
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.77.0",
|
|
4
4
|
"description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -96,6 +96,15 @@
|
|
|
96
96
|
}
|
|
97
97
|
]
|
|
98
98
|
},
|
|
99
|
+
{
|
|
100
|
+
"matcher": "",
|
|
101
|
+
"hooks": [
|
|
102
|
+
{
|
|
103
|
+
"type": "command",
|
|
104
|
+
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-rules.sh"
|
|
105
|
+
}
|
|
106
|
+
]
|
|
107
|
+
},
|
|
99
108
|
{
|
|
100
109
|
"matcher": "",
|
|
101
110
|
"hooks": [
|
|
@@ -115,6 +124,17 @@
|
|
|
115
124
|
]
|
|
116
125
|
}
|
|
117
126
|
],
|
|
127
|
+
"SubagentStart": [
|
|
128
|
+
{
|
|
129
|
+
"matcher": "",
|
|
130
|
+
"hooks": [
|
|
131
|
+
{
|
|
132
|
+
"type": "command",
|
|
133
|
+
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-rules.sh"
|
|
134
|
+
}
|
|
135
|
+
]
|
|
136
|
+
}
|
|
137
|
+
],
|
|
118
138
|
"SessionEnd": [
|
|
119
139
|
{
|
|
120
140
|
"matcher": "",
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# Reads all .md files from the plugin's rules/ directory and injects them
|
|
3
|
+
# into the session context via additionalContext.
|
|
4
|
+
# Used by SessionStart and SubagentStart hooks.
|
|
5
|
+
set -euo pipefail
|
|
6
|
+
|
|
7
|
+
RULES_DIR="${CLAUDE_PLUGIN_ROOT}/rules"
|
|
8
|
+
|
|
9
|
+
# Bail silently if no rules directory
|
|
10
|
+
[ -d "$RULES_DIR" ] || exit 0
|
|
11
|
+
|
|
12
|
+
CONTEXT=""
|
|
13
|
+
for file in "$RULES_DIR"/*.md; do
|
|
14
|
+
[ -f "$file" ] || continue
|
|
15
|
+
CONTEXT+="$(cat "$file")"$'\n\n'
|
|
16
|
+
done
|
|
17
|
+
|
|
18
|
+
# Bail if no rules found
|
|
19
|
+
[ -n "$CONTEXT" ] || exit 0
|
|
20
|
+
|
|
21
|
+
# Output as JSON — jq handles escaping
|
|
22
|
+
jq -n --arg ctx "$CONTEXT" '{"additionalContext": $ctx}'
|
|
@@ -2,9 +2,10 @@ Requirement Verification:
|
|
|
2
2
|
|
|
3
3
|
Never assume the person providing instructions has given you complete, correct, or technically precise requirements. Treat every request as potentially underspecified. Before starting any work:
|
|
4
4
|
|
|
5
|
-
1.
|
|
6
|
-
2.
|
|
7
|
-
3.
|
|
5
|
+
1. Identify any ambiguities in the request that would prevent you from completing the work. If any exist, stop and ask for clarification.
|
|
6
|
+
2. Identify any open questions whose answers would change your approach. If any exist, stop and ask.
|
|
7
|
+
3. Define how you will empirically verify the work is complete — not by running tests or linters, but by using the resulting software the way a user would. If you cannot define this, stop and ask for clarification.
|
|
8
|
+
4. If a request contradicts existing code, architecture, or conventions, do not silently comply. Raise the contradiction and confirm intent before proceeding.
|
|
8
9
|
|
|
9
10
|
DO NOT START WORK if any of the above are unclear. Asking a clarifying question is always cheaper than implementing the wrong thing.
|
|
10
11
|
|
|
@@ -16,6 +16,16 @@ No agent may claim success without evidence from runtime verification.
|
|
|
16
16
|
|
|
17
17
|
Never assume something works because the code "looks correct." Run a command, observe the output, compare to expected result.
|
|
18
18
|
|
|
19
|
+
**Verification is not linting, typechecking, or testing.** Those are quality checks. Verification is using the resulting software the way a user would — interacting with the UI, calling the API, running the CLI command, observing the behavior. Tests pass in isolation; verification proves the system works as a whole. Passing tests, linting, and typechecking does not constitute verification.
|
|
20
|
+
|
|
21
|
+
Verification is mandatory. Never skip it, defer it, or claim it was unnecessary. Every task must be verified before claiming completion.
|
|
22
|
+
|
|
23
|
+
Before starting implementation, state your verification plan — how you will use the resulting software to prove it works. Do not begin implementation until the plan is confirmed.
|
|
24
|
+
|
|
25
|
+
After verifying a change empirically, encode that verification as automated tests. The manual proof that something works should become a repeatable regression test that catches future regressions. Every verification should answer: "How do I turn this into a test?"
|
|
26
|
+
|
|
27
|
+
Every pull request must include step-by-step instructions for reviewers to independently replicate the verification. These are not test commands — they are the exact steps a human would follow to use the software and confirm the change works. If a reviewer cannot reproduce your verification from the PR description alone, the PR is incomplete.
|
|
28
|
+
|
|
19
29
|
---
|
|
20
30
|
|
|
21
31
|
## Roles
|
|
@@ -1,11 +1,33 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-rails",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.77.0",
|
|
4
4
|
"description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
7
7
|
},
|
|
8
8
|
"hooks": {
|
|
9
|
+
"SessionStart": [
|
|
10
|
+
{
|
|
11
|
+
"matcher": "",
|
|
12
|
+
"hooks": [
|
|
13
|
+
{
|
|
14
|
+
"type": "command",
|
|
15
|
+
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-rules.sh"
|
|
16
|
+
}
|
|
17
|
+
]
|
|
18
|
+
}
|
|
19
|
+
],
|
|
20
|
+
"SubagentStart": [
|
|
21
|
+
{
|
|
22
|
+
"matcher": "",
|
|
23
|
+
"hooks": [
|
|
24
|
+
{
|
|
25
|
+
"type": "command",
|
|
26
|
+
"command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-rules.sh"
|
|
27
|
+
}
|
|
28
|
+
]
|
|
29
|
+
}
|
|
30
|
+
],
|
|
9
31
|
"PostToolUse": [
|
|
10
32
|
{
|
|
11
33
|
"matcher": "Write|Edit",
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# Reads all .md files from the plugin's rules/ directory and injects them
|
|
3
|
+
# into the session context via additionalContext.
|
|
4
|
+
# Used by SessionStart and SubagentStart hooks.
|
|
5
|
+
set -euo pipefail
|
|
6
|
+
|
|
7
|
+
RULES_DIR="${CLAUDE_PLUGIN_ROOT}/rules"
|
|
8
|
+
|
|
9
|
+
# Bail silently if no rules directory
|
|
10
|
+
[ -d "$RULES_DIR" ] || exit 0
|
|
11
|
+
|
|
12
|
+
CONTEXT=""
|
|
13
|
+
for file in "$RULES_DIR"/*.md; do
|
|
14
|
+
[ -f "$file" ] || continue
|
|
15
|
+
CONTEXT+="$(cat "$file")"$'\n\n'
|
|
16
|
+
done
|
|
17
|
+
|
|
18
|
+
# Bail if no rules found
|
|
19
|
+
[ -n "$CONTEXT" ] || exit 0
|
|
20
|
+
|
|
21
|
+
# Output as JSON — jq handles escaping
|
|
22
|
+
jq -n --arg ctx "$CONTEXT" '{"additionalContext": $ctx}'
|
|
@@ -55,10 +55,12 @@ fi
|
|
|
55
55
|
# Run ESLint with --fix --quiet --cache on the specific file
|
|
56
56
|
# --quiet: suppress warnings, only show errors
|
|
57
57
|
# --cache: use ESLint cache for performance
|
|
58
|
+
# --rule: disable no-unused-vars auto-fix to prevent removing imports that Claude
|
|
59
|
+
# plans to use in a subsequent edit (pre-commit hook still catches them)
|
|
58
60
|
echo "Running ESLint --fix on: $FILE_PATH"
|
|
59
61
|
|
|
60
62
|
# First pass: attempt auto-fix
|
|
61
|
-
OUTPUT=$($PKG_MANAGER eslint --fix --quiet --cache "$FILE_PATH" 2>&1)
|
|
63
|
+
OUTPUT=$($PKG_MANAGER eslint --fix --quiet --cache --rule '@typescript-eslint/no-unused-vars: off' "$FILE_PATH" 2>&1)
|
|
62
64
|
FIX_EXIT=$?
|
|
63
65
|
|
|
64
66
|
if [ $FIX_EXIT -eq 0 ]; then
|
|
@@ -58,9 +58,13 @@
|
|
|
58
58
|
],
|
|
59
59
|
"SessionStart": [
|
|
60
60
|
{ "matcher": "startup", "hooks": [{ "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/install-pkgs.sh" }] },
|
|
61
|
+
{ "matcher": "", "hooks": [{ "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-rules.sh" }] },
|
|
61
62
|
{ "matcher": "", "hooks": [{ "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/setup-jira-cli.sh" }] },
|
|
62
63
|
{ "matcher": "", "hooks": [{ "type": "command", "command": "command -v entire >/dev/null 2>&1 && entire hooks claude-code session-start || true" }] }
|
|
63
64
|
],
|
|
65
|
+
"SubagentStart": [
|
|
66
|
+
{ "matcher": "", "hooks": [{ "type": "command", "command": "${CLAUDE_PLUGIN_ROOT}/hooks/inject-rules.sh" }] }
|
|
67
|
+
],
|
|
64
68
|
"SessionEnd": [
|
|
65
69
|
{ "matcher": "", "hooks": [{ "type": "command", "command": "command -v entire >/dev/null 2>&1 && entire hooks claude-code session-end || true" }] }
|
|
66
70
|
]
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
#!/usr/bin/env bash
|
|
2
|
+
# Reads all .md files from the plugin's rules/ directory and injects them
|
|
3
|
+
# into the session context via additionalContext.
|
|
4
|
+
# Used by SessionStart and SubagentStart hooks.
|
|
5
|
+
set -euo pipefail
|
|
6
|
+
|
|
7
|
+
RULES_DIR="${CLAUDE_PLUGIN_ROOT}/rules"
|
|
8
|
+
|
|
9
|
+
# Bail silently if no rules directory
|
|
10
|
+
[ -d "$RULES_DIR" ] || exit 0
|
|
11
|
+
|
|
12
|
+
CONTEXT=""
|
|
13
|
+
for file in "$RULES_DIR"/*.md; do
|
|
14
|
+
[ -f "$file" ] || continue
|
|
15
|
+
CONTEXT+="$(cat "$file")"$'\n\n'
|
|
16
|
+
done
|
|
17
|
+
|
|
18
|
+
# Bail if no rules found
|
|
19
|
+
[ -n "$CONTEXT" ] || exit 0
|
|
20
|
+
|
|
21
|
+
# Output as JSON — jq handles escaping
|
|
22
|
+
jq -n --arg ctx "$CONTEXT" '{"additionalContext": $ctx}'
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
Requirement Verification:
|
|
2
|
+
|
|
3
|
+
Never assume the person providing instructions has given you complete, correct, or technically precise requirements. Treat every request as potentially underspecified. Before starting any work:
|
|
4
|
+
|
|
5
|
+
1. Identify any ambiguities in the request that would prevent you from completing the work. If any exist, stop and ask for clarification.
|
|
6
|
+
2. Identify any open questions whose answers would change your approach. If any exist, stop and ask.
|
|
7
|
+
3. Define how you will empirically verify the work is complete — not by running tests or linters, but by using the resulting software the way a user would. If you cannot define this, stop and ask for clarification.
|
|
8
|
+
4. If a request contradicts existing code, architecture, or conventions, do not silently comply. Raise the contradiction and confirm intent before proceeding.
|
|
9
|
+
|
|
10
|
+
DO NOT START WORK if any of the above are unclear. Asking a clarifying question is always cheaper than implementing the wrong thing.
|
|
11
|
+
|
|
12
|
+
Project Discovery:
|
|
13
|
+
- Determine the project's package manager before installing or running anything.
|
|
14
|
+
- Read the project manifest (e.g. package.json, pyproject.toml, Cargo.toml, go.mod) to understand available scripts and dependencies.
|
|
15
|
+
- Read the project's linting and formatting configuration to understand its standards.
|
|
16
|
+
- Regenerate the lockfile after adding, removing, or updating dependencies.
|
|
17
|
+
- Ignore build output directories (dist, build, out, target, etc.) unless specified otherwise.
|
|
18
|
+
- Ignore configuration linter hints/warnings — only fix actual unused exports/dependencies reported as errors.
|
|
19
|
+
|
|
20
|
+
Code Quality:
|
|
21
|
+
- Make atomic commits with clear conventional commit messages.
|
|
22
|
+
- Create clear documentation preambles for new code. Update preambles when modifying existing code.
|
|
23
|
+
- Document the "why", not the "what". Code explains what it does; documentation explains why it exists.
|
|
24
|
+
- Always add new imports and their first usage in the same edit. The lint-on-edit hook runs `eslint --fix` after every Edit, which auto-removes unused imports. If you add an import in one edit and plan to use it in a second edit, the hook will strip the import before the second edit runs.
|
|
25
|
+
- Add language specifiers to fenced code blocks in Markdown.
|
|
26
|
+
- Use project-relative paths rather than absolute paths in documentation and Markdown.
|
|
27
|
+
- Delete old code completely when replacing it. No deprecation unless specifically requested.
|
|
28
|
+
- Fix bugs and issues properly. Never cover them up or work around them.
|
|
29
|
+
- Test empirically to confirm something worked. Never assume.
|
|
30
|
+
- Never assume test expectations before verifying actual implementation behavior. Run tests to learn the behavior, then adjust expectations to match.
|
|
31
|
+
- Always provide a solution. Never dismiss something as "not related to our changes" or "not relevant to this task".
|
|
32
|
+
|
|
33
|
+
Git Discipline:
|
|
34
|
+
- Prefix git push with `GIT_SSH_COMMAND="ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=5"`.
|
|
35
|
+
- Never commit directly to an environment branch (dev, staging, main).
|
|
36
|
+
- Never use --no-verify or attempt to bypass a git hook.
|
|
37
|
+
- Never stash changes you cannot commit. Either fix whatever is preventing the commit or fail out and let the human know why.
|
|
38
|
+
- Never add "BREAKING CHANGE" to a commit message unless there is actually a breaking change.
|
|
39
|
+
- When opening a PR, watch the PR. If any status checks fail, fix them. For all bot code reviews, if the feedback is valid, implement it and push the change to the PR. Then resolve the feedback. If the feedback is not valid, reply to the feedback explaining why it's not valid and then resolve the feedback. Do this in a loop until the PR is able to be merged and then merge it.
|
|
40
|
+
- When merging a PR into an environment branch (dev, staging, main), watch the resultant deploy until it fully succeeds. If it fails for any reason, fix the failure and then open a new PR with the fix.
|
|
41
|
+
- When referencing a PR in a response, always include the url
|
|
42
|
+
|
|
43
|
+
Testing Discipline:
|
|
44
|
+
- Never skip or disable any tests or quality checks.
|
|
45
|
+
- Never add skip directives to a test unless explicitly asked to.
|
|
46
|
+
- Never lower thresholds to pass a pre-push hook. Increase test coverage to make it pass.
|
|
47
|
+
- Never duplicate test helper functions without appropriate lint suppression when duplication is intentional for test isolation.
|
|
48
|
+
|
|
49
|
+
JIRA Discipline:
|
|
50
|
+
- If working on a JIRA issue, make sure the branch you're working on references and is added to the JIRA issue.
|
|
51
|
+
- 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.
|
|
52
|
+
|
|
53
|
+
Agent Behavior:
|
|
54
|
+
- Never handle tasks yourself when working in a team of agents. Always delegate to a specialized agent.
|
|
55
|
+
|
|
56
|
+
NEVER:
|
|
57
|
+
- Modify this file directly. To add a memory or learning, use the project's rules file or create a skill.
|
|
58
|
+
- Directly modify files inside dependency directories (e.g. node_modules, .venv, vendor, target).
|
|
59
|
+
- Delete anything that is not tracked in git.
|
|
60
|
+
- Delete anything outside of this project's directory.
|
|
61
|
+
- Create placeholder implementations.
|
|
62
|
+
- Create TODOs.
|
|
63
|
+
- Create versioned copies of files or functions (e.g. V2, Optimized, processNew, handleOld).
|
|
64
|
+
- Write migration code unless explicitly requested.
|
|
65
|
+
- Write functions or methods unless they are needed.
|
|
66
|
+
- Write unhelpful comments like "removed code" or "old implementation".
|
|
67
|
+
- Update CHANGELOG.
|
|
68
|
+
|
|
69
|
+
ASK FIRST:
|
|
70
|
+
- Before adding a lint suppression comment (e.g. eslint-disable, noqa, #[allow(...)], @SuppressWarnings). These should be a last resort.
|
|
71
|
+
- Before adding a type-checking suppression comment (e.g. ts-ignore, ts-expect-error, ts-nocheck, type: ignore).
|
|
72
|
+
- Lint suppression in test files is acceptable without asking only when comprehensive test coverage requires it (e.g. file length limits) or when intentional duplication improves test isolation. Include matching re-enable comments where applicable.
|
|
73
|
+
|
|
74
|
+
Multi-Repository Awareness:
|
|
75
|
+
|
|
76
|
+
When working in a microservices architecture, the code you need may span multiple repositories. Watch for these signals that you're missing context:
|
|
77
|
+
|
|
78
|
+
1. Import paths or package references that don't resolve in the current repository
|
|
79
|
+
2. API calls to internal services where you can't find the contract, schema, or handler
|
|
80
|
+
3. Shared libraries, SDKs, or proto/OpenAPI definitions referenced but not present
|
|
81
|
+
4. Environment variables or config referencing service names you don't have code for
|
|
82
|
+
5. Error messages or stack traces pointing to code outside the current repo
|
|
83
|
+
6. JIRA issues or documentation referencing components in other repositories
|
|
84
|
+
|
|
85
|
+
When you detect any of the above:
|
|
86
|
+
1. Do NOT guess or make assumptions about what the external code does
|
|
87
|
+
2. Identify which repository contains the missing code
|
|
88
|
+
3. Add that repository to your current session before proceeding
|
|
89
|
+
4. If you cannot determine which repository contains the code, ask — do not proceed without it
|