@codyswann/lisa 2.60.1 → 2.61.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/package.json +1 -1
- package/plugins/lisa/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa/skills/git-submit-pr/SKILL.md +27 -0
- package/plugins/lisa/skills/implement/SKILL.md +8 -1
- package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
- package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
- package/plugins/src/base/skills/git-submit-pr/SKILL.md +27 -0
- package/plugins/src/base/skills/implement/SKILL.md +8 -1
package/package.json
CHANGED
|
@@ -82,7 +82,7 @@
|
|
|
82
82
|
"lodash": ">=4.18.1"
|
|
83
83
|
},
|
|
84
84
|
"name": "@codyswann/lisa",
|
|
85
|
-
"version": "2.
|
|
85
|
+
"version": "2.61.0",
|
|
86
86
|
"description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
|
|
87
87
|
"main": "dist/index.js",
|
|
88
88
|
"exports": {
|
|
@@ -8,6 +8,12 @@ allowed-tools: ["Bash", "mcp__github__create_pull_request", "mcp__github__get_pu
|
|
|
8
8
|
|
|
9
9
|
Push current branch and create or update a pull request. Optional hint: $ARGUMENTS
|
|
10
10
|
|
|
11
|
+
Recognized optional hints:
|
|
12
|
+
|
|
13
|
+
- `work_item_ref=<ref>` — source tracker item for native development linkage. Examples: `CodySwannGT/lisa#614`, `https://github.com/CodySwannGT/lisa/issues/614`, `ENG-123`, `PROJ-456`.
|
|
14
|
+
- `target_branch=<branch>` or `base=<branch>` — intended PR base branch, used to decide whether a GitHub closing keyword is safe.
|
|
15
|
+
- `tracker_provider=<github|linear|jira|none>` — explicit provider when the ref shape is ambiguous.
|
|
16
|
+
|
|
11
17
|
## Workflow
|
|
12
18
|
|
|
13
19
|
### Check current state
|
|
@@ -24,6 +30,7 @@ Push current branch and create or update a pull request. Optional hint: $ARGUMEN
|
|
|
24
30
|
- Check for existing PR on this branch
|
|
25
31
|
- If exists: Update description with latest changes
|
|
26
32
|
- If not: Create PR with comprehensive description (not a draft)
|
|
33
|
+
- Include native development linkage for the source work item when `work_item_ref` can be inferred from `$ARGUMENTS`, the current branch name, an existing PR body, or the issue/ticket context passed by the caller.
|
|
27
34
|
5. **Auto-merge**: Choose merge strategy by PR type:
|
|
28
35
|
- **Promotion PRs** (env → env, e.g. `dev` → `staging`): use `gh pr merge --auto --merge` (never squash). Squashing flattens the constituent `chore(release): X.Y.Z [skip ci]` commits into one commit titled with the PR title, stripping the `[skip ci]` markers and breaking the release workflow's promotion-detection regex — the destination branch then double-bumps its version. `--merge` keeps each `chore(release)` commit (and its `[skip ci]` marker) intact under a clean merge commit subject the workflow can recognize.
|
|
29
36
|
- **Feature PRs** (anything → `dev`): use `gh pr merge --auto --merge`.
|
|
@@ -35,12 +42,32 @@ Push current branch and create or update a pull request. Optional hint: $ARGUMEN
|
|
|
35
42
|
- **Loop terminal states**: Continue the loop until the PR is `MERGED`, is `CLOSED`, checks fail, the review gate remains blocked by unresolved human feedback, or a sync conflict cannot be resolved locally. On check failures, use the existing PR watch/fix path: inspect logs, fix, commit, push, and resume the loop.
|
|
36
43
|
- **Harness-agnostic commands**: Use plain `gh` and `git` commands for this loop so Claude and Codex agents execute the same behavior from the shared skill.
|
|
37
44
|
|
|
45
|
+
### Native Development Linkage
|
|
46
|
+
|
|
47
|
+
Add provider-appropriate linkage to the PR title and/or body without changing the status lifecycle:
|
|
48
|
+
|
|
49
|
+
- **GitHub Issues**:
|
|
50
|
+
- If `work_item_ref` is a GitHub issue URL, `org/repo#<n>`, or `#<n>`, add a dedicated issue reference line to the PR body.
|
|
51
|
+
- Use a closing keyword such as `Closes #<n>` only when merging this PR to the base branch represents terminal delivery for that issue. This is true when the target branch is the repository default branch or the configured production branch from `.lisa.config.json` `deploy.branches.production`.
|
|
52
|
+
- If the target branch is a non-terminal environment branch such as `dev` or `staging`, use a non-closing reference such as `Refs #<n>` so GitHub links the PR in the issue's Development / linked pull requests surface without prematurely closing the issue.
|
|
53
|
+
- For cross-repo issue refs, use the fully qualified form, for example `Closes CodySwannGT/lisa#614` or `Refs CodySwannGT/lisa#614`.
|
|
54
|
+
- **Linear**:
|
|
55
|
+
- Ensure the Linear issue identifier appears in the branch name when the branch is created upstream by `lisa:implement`.
|
|
56
|
+
- Include the identifier in the PR title or body, for example `Linear: ENG-123`, so Linear's GitHub integration can attach the PR.
|
|
57
|
+
- **JIRA**:
|
|
58
|
+
- Ensure the JIRA issue key appears in the branch name when the branch is created upstream by `lisa:implement`.
|
|
59
|
+
- Include the key in the PR title or body, for example `JIRA: PROJ-456`, so the GitHub-JIRA integration can attach the PR.
|
|
60
|
+
- **No supported provider**: Skip this section without error; do not invent references.
|
|
61
|
+
|
|
62
|
+
When updating an existing PR, preserve any existing linkage line unless the new `work_item_ref` is more specific. Do not duplicate equivalent references.
|
|
63
|
+
|
|
38
64
|
### PR Description Format
|
|
39
65
|
|
|
40
66
|
Include in the PR description:
|
|
41
67
|
|
|
42
68
|
- **Summary**: Brief overview of changes (1-3 bullet points)
|
|
43
69
|
- **Test plan**: How to verify the changes work correctly
|
|
70
|
+
- **Issue / Tracker link**: The provider-specific native linkage line when a source work item is available, placed after the summary and before the test plan.
|
|
44
71
|
|
|
45
72
|
### Never
|
|
46
73
|
|
|
@@ -54,6 +54,13 @@ Using the general-purpose agent in Team Lead session, Determine what branch to u
|
|
|
54
54
|
2. Are we on a feature branch without an open pull request? Use the branch, but ask the human what branch to target for the PR
|
|
55
55
|
3. Are we on an environment branch (dev, staging, main, prod, production)? Check out a feature branch named for this plan and set the target branch of the PR to the environment branch
|
|
56
56
|
|
|
57
|
+
When the request came from a tracker work item, preserve its native identifier for development linkage:
|
|
58
|
+
|
|
59
|
+
- Capture `tracker_provider` and `work_item_ref` from the resolved input before creating or reusing a branch. Examples: `github` + `CodySwannGT/lisa#614`, `linear` + `ENG-123`, `jira` + `ENG-123`.
|
|
60
|
+
- If a new branch is needed and the provider can link branches by identifier, include the identifier in the branch name before the human-readable slug. Linear and JIRA integrations commonly link from branch names; GitHub issue linkage is PR-body driven, but including the issue number in the branch name is still useful. Keep branch names URL-safe, for example `codex/ENG-123-add-checkout-copy` or `codex/614-add-checkout-copy`.
|
|
61
|
+
- Pass the work-item ref and target branch to `lisa:git-submit-pr` when opening or updating the PR, for example `work_item_ref=CodySwannGT/lisa#614 target_branch=main`. The PR workflow owns provider-specific body text and must decide whether to use a closing keyword or a non-closing reference.
|
|
62
|
+
- If the provider has no native branch or PR development-linkage surface, continue without linkage and mention that the provider was skipped.
|
|
63
|
+
|
|
57
64
|
Using the general-purpose agent in Team Lead session, Determine which flow applies:
|
|
58
65
|
1. Research -- needs a PRD (no specification exists)
|
|
59
66
|
2. Plan -- needs decomposition (specification exists but no work items)
|
|
@@ -115,7 +122,7 @@ Before shutting down the team, execute the Verify flow:
|
|
|
115
122
|
3. Write e2e test encoding the verification
|
|
116
123
|
4. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
|
|
117
124
|
5. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not
|
|
118
|
-
6. Open a pull request with auto-merge on
|
|
125
|
+
6. Open a pull request with auto-merge on via `lisa:git-submit-pr`, including the work-item ref when one exists so the PR can be linked natively to the source issue.
|
|
119
126
|
7. PR Watch Loop: Monitor the PR using `git-submit-pr`'s drive-to-merge behavior. Create a task for the agent team to resolve any code review comments by either implementing the suggestions or commenting why they should not be implemented and close the comment. Fix any failing checks and repush. If the PR is `BEHIND`, blocked by stale review state, or cannot enable auto-merge, follow the harness-agnostic `git-submit-pr` re-sync, review-gate, and direct-merge fallback loop until the PR is actually merged or a blocking failure is surfaced.
|
|
120
127
|
8. Merge the PR
|
|
121
128
|
9. Monitor the deploy action that triggers automatically from the successful merge
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.61.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "lisa-openclaw",
|
|
3
|
-
"version": "2.
|
|
3
|
+
"version": "2.61.0",
|
|
4
4
|
"description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Cody Swann"
|
|
@@ -8,6 +8,12 @@ allowed-tools: ["Bash", "mcp__github__create_pull_request", "mcp__github__get_pu
|
|
|
8
8
|
|
|
9
9
|
Push current branch and create or update a pull request. Optional hint: $ARGUMENTS
|
|
10
10
|
|
|
11
|
+
Recognized optional hints:
|
|
12
|
+
|
|
13
|
+
- `work_item_ref=<ref>` — source tracker item for native development linkage. Examples: `CodySwannGT/lisa#614`, `https://github.com/CodySwannGT/lisa/issues/614`, `ENG-123`, `PROJ-456`.
|
|
14
|
+
- `target_branch=<branch>` or `base=<branch>` — intended PR base branch, used to decide whether a GitHub closing keyword is safe.
|
|
15
|
+
- `tracker_provider=<github|linear|jira|none>` — explicit provider when the ref shape is ambiguous.
|
|
16
|
+
|
|
11
17
|
## Workflow
|
|
12
18
|
|
|
13
19
|
### Check current state
|
|
@@ -24,6 +30,7 @@ Push current branch and create or update a pull request. Optional hint: $ARGUMEN
|
|
|
24
30
|
- Check for existing PR on this branch
|
|
25
31
|
- If exists: Update description with latest changes
|
|
26
32
|
- If not: Create PR with comprehensive description (not a draft)
|
|
33
|
+
- Include native development linkage for the source work item when `work_item_ref` can be inferred from `$ARGUMENTS`, the current branch name, an existing PR body, or the issue/ticket context passed by the caller.
|
|
27
34
|
5. **Auto-merge**: Choose merge strategy by PR type:
|
|
28
35
|
- **Promotion PRs** (env → env, e.g. `dev` → `staging`): use `gh pr merge --auto --merge` (never squash). Squashing flattens the constituent `chore(release): X.Y.Z [skip ci]` commits into one commit titled with the PR title, stripping the `[skip ci]` markers and breaking the release workflow's promotion-detection regex — the destination branch then double-bumps its version. `--merge` keeps each `chore(release)` commit (and its `[skip ci]` marker) intact under a clean merge commit subject the workflow can recognize.
|
|
29
36
|
- **Feature PRs** (anything → `dev`): use `gh pr merge --auto --merge`.
|
|
@@ -35,12 +42,32 @@ Push current branch and create or update a pull request. Optional hint: $ARGUMEN
|
|
|
35
42
|
- **Loop terminal states**: Continue the loop until the PR is `MERGED`, is `CLOSED`, checks fail, the review gate remains blocked by unresolved human feedback, or a sync conflict cannot be resolved locally. On check failures, use the existing PR watch/fix path: inspect logs, fix, commit, push, and resume the loop.
|
|
36
43
|
- **Harness-agnostic commands**: Use plain `gh` and `git` commands for this loop so Claude and Codex agents execute the same behavior from the shared skill.
|
|
37
44
|
|
|
45
|
+
### Native Development Linkage
|
|
46
|
+
|
|
47
|
+
Add provider-appropriate linkage to the PR title and/or body without changing the status lifecycle:
|
|
48
|
+
|
|
49
|
+
- **GitHub Issues**:
|
|
50
|
+
- If `work_item_ref` is a GitHub issue URL, `org/repo#<n>`, or `#<n>`, add a dedicated issue reference line to the PR body.
|
|
51
|
+
- Use a closing keyword such as `Closes #<n>` only when merging this PR to the base branch represents terminal delivery for that issue. This is true when the target branch is the repository default branch or the configured production branch from `.lisa.config.json` `deploy.branches.production`.
|
|
52
|
+
- If the target branch is a non-terminal environment branch such as `dev` or `staging`, use a non-closing reference such as `Refs #<n>` so GitHub links the PR in the issue's Development / linked pull requests surface without prematurely closing the issue.
|
|
53
|
+
- For cross-repo issue refs, use the fully qualified form, for example `Closes CodySwannGT/lisa#614` or `Refs CodySwannGT/lisa#614`.
|
|
54
|
+
- **Linear**:
|
|
55
|
+
- Ensure the Linear issue identifier appears in the branch name when the branch is created upstream by `lisa:implement`.
|
|
56
|
+
- Include the identifier in the PR title or body, for example `Linear: ENG-123`, so Linear's GitHub integration can attach the PR.
|
|
57
|
+
- **JIRA**:
|
|
58
|
+
- Ensure the JIRA issue key appears in the branch name when the branch is created upstream by `lisa:implement`.
|
|
59
|
+
- Include the key in the PR title or body, for example `JIRA: PROJ-456`, so the GitHub-JIRA integration can attach the PR.
|
|
60
|
+
- **No supported provider**: Skip this section without error; do not invent references.
|
|
61
|
+
|
|
62
|
+
When updating an existing PR, preserve any existing linkage line unless the new `work_item_ref` is more specific. Do not duplicate equivalent references.
|
|
63
|
+
|
|
38
64
|
### PR Description Format
|
|
39
65
|
|
|
40
66
|
Include in the PR description:
|
|
41
67
|
|
|
42
68
|
- **Summary**: Brief overview of changes (1-3 bullet points)
|
|
43
69
|
- **Test plan**: How to verify the changes work correctly
|
|
70
|
+
- **Issue / Tracker link**: The provider-specific native linkage line when a source work item is available, placed after the summary and before the test plan.
|
|
44
71
|
|
|
45
72
|
### Never
|
|
46
73
|
|
|
@@ -54,6 +54,13 @@ Using the general-purpose agent in Team Lead session, Determine what branch to u
|
|
|
54
54
|
2. Are we on a feature branch without an open pull request? Use the branch, but ask the human what branch to target for the PR
|
|
55
55
|
3. Are we on an environment branch (dev, staging, main, prod, production)? Check out a feature branch named for this plan and set the target branch of the PR to the environment branch
|
|
56
56
|
|
|
57
|
+
When the request came from a tracker work item, preserve its native identifier for development linkage:
|
|
58
|
+
|
|
59
|
+
- Capture `tracker_provider` and `work_item_ref` from the resolved input before creating or reusing a branch. Examples: `github` + `CodySwannGT/lisa#614`, `linear` + `ENG-123`, `jira` + `ENG-123`.
|
|
60
|
+
- If a new branch is needed and the provider can link branches by identifier, include the identifier in the branch name before the human-readable slug. Linear and JIRA integrations commonly link from branch names; GitHub issue linkage is PR-body driven, but including the issue number in the branch name is still useful. Keep branch names URL-safe, for example `codex/ENG-123-add-checkout-copy` or `codex/614-add-checkout-copy`.
|
|
61
|
+
- Pass the work-item ref and target branch to `lisa:git-submit-pr` when opening or updating the PR, for example `work_item_ref=CodySwannGT/lisa#614 target_branch=main`. The PR workflow owns provider-specific body text and must decide whether to use a closing keyword or a non-closing reference.
|
|
62
|
+
- If the provider has no native branch or PR development-linkage surface, continue without linkage and mention that the provider was skipped.
|
|
63
|
+
|
|
57
64
|
Using the general-purpose agent in Team Lead session, Determine which flow applies:
|
|
58
65
|
1. Research -- needs a PRD (no specification exists)
|
|
59
66
|
2. Plan -- needs decomposition (specification exists but no work items)
|
|
@@ -115,7 +122,7 @@ Before shutting down the team, execute the Verify flow:
|
|
|
115
122
|
3. Write e2e test encoding the verification
|
|
116
123
|
4. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
|
|
117
124
|
5. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not
|
|
118
|
-
6. Open a pull request with auto-merge on
|
|
125
|
+
6. Open a pull request with auto-merge on via `lisa:git-submit-pr`, including the work-item ref when one exists so the PR can be linked natively to the source issue.
|
|
119
126
|
7. PR Watch Loop: Monitor the PR using `git-submit-pr`'s drive-to-merge behavior. Create a task for the agent team to resolve any code review comments by either implementing the suggestions or commenting why they should not be implemented and close the comment. Fix any failing checks and repush. If the PR is `BEHIND`, blocked by stale review state, or cannot enable auto-merge, follow the harness-agnostic `git-submit-pr` re-sync, review-gate, and direct-merge fallback loop until the PR is actually merged or a blocking failure is surfaced.
|
|
120
127
|
8. Merge the PR
|
|
121
128
|
9. Monitor the deploy action that triggers automatically from the successful merge
|