@xn-intenton-z2a/agentic-lib 7.1.68 → 7.1.69
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/.github/workflows/agentic-lib-workflow.yml +22 -2
- package/package.json +1 -1
- package/src/agents/agent-apply-fix.md +6 -6
- package/src/agents/agent-issue-resolution.md +18 -7
- package/src/agents/agent-maintain-features.md +2 -2
- package/src/agents/agent-maintain-library.md +13 -14
- package/src/agents/agent-ready-issue.md +7 -7
- package/src/agents/agent-review-issue.md +9 -2
- package/src/agents/agent-supervisor.md +3 -3
- package/src/seeds/zero-package.json +1 -1
|
@@ -721,15 +721,35 @@ jobs:
|
|
|
721
721
|
run: |
|
|
722
722
|
npm run build:web 2>/dev/null || echo "No build:web script"
|
|
723
723
|
|
|
724
|
+
- name: Run tests before committing
|
|
725
|
+
id: pre-commit-test
|
|
726
|
+
if: steps.issue.outputs.issue-number != ''
|
|
727
|
+
run: |
|
|
728
|
+
CONFIG="${{ needs.params.outputs.config-path }}"
|
|
729
|
+
TEST_CMD=$(grep -E '^\s*test\s*=' "$CONFIG" 2>/dev/null | sed 's/.*=\s*"\(.*\)"/\1/' | head -1)
|
|
730
|
+
TEST_CMD="${TEST_CMD:-npm ci && npm test}"
|
|
731
|
+
echo "Running: $TEST_CMD"
|
|
732
|
+
set +e
|
|
733
|
+
eval "$TEST_CMD" 2>&1 | tail -30
|
|
734
|
+
EXIT_CODE=$?
|
|
735
|
+
set -e
|
|
736
|
+
if [ $EXIT_CODE -ne 0 ]; then
|
|
737
|
+
echo "tests-passed=false" >> $GITHUB_OUTPUT
|
|
738
|
+
echo "WARNING: Tests failed (exit $EXIT_CODE) — skipping commit and PR"
|
|
739
|
+
else
|
|
740
|
+
echo "tests-passed=true" >> $GITHUB_OUTPUT
|
|
741
|
+
echo "Tests passed"
|
|
742
|
+
fi
|
|
743
|
+
|
|
724
744
|
- name: Commit and push
|
|
725
|
-
if: github.repository != 'xn-intenton-z2a/agentic-lib' && steps.issue.outputs.issue-number != '' && needs.params.outputs.dry-run != 'true'
|
|
745
|
+
if: github.repository != 'xn-intenton-z2a/agentic-lib' && steps.issue.outputs.issue-number != '' && needs.params.outputs.dry-run != 'true' && steps.pre-commit-test.outputs.tests-passed == 'true'
|
|
726
746
|
uses: ./.github/agentic-lib/actions/commit-if-changed
|
|
727
747
|
with:
|
|
728
748
|
commit-message: "agentic-step: transform issue #${{ steps.issue.outputs.issue-number }}"
|
|
729
749
|
push-ref: ${{ steps.branch.outputs.branchName }}
|
|
730
750
|
|
|
731
751
|
- name: Create PR and attempt merge
|
|
732
|
-
if: github.repository != 'xn-intenton-z2a/agentic-lib' && steps.issue.outputs.issue-number != '' && needs.params.outputs.dry-run != 'true'
|
|
752
|
+
if: github.repository != 'xn-intenton-z2a/agentic-lib' && steps.issue.outputs.issue-number != '' && needs.params.outputs.dry-run != 'true' && steps.pre-commit-test.outputs.tests-passed == 'true'
|
|
733
753
|
uses: actions/github-script@v8
|
|
734
754
|
with:
|
|
735
755
|
script: |
|
package/package.json
CHANGED
|
@@ -1,17 +1,17 @@
|
|
|
1
1
|
You are providing the entire new content of source files, test files, documentation files,
|
|
2
2
|
and other necessary files with all necessary changes applied to resolve a possible build or test
|
|
3
|
-
problem.
|
|
4
|
-
|
|
5
|
-
value you may re-implement it or remove it.
|
|
3
|
+
problem. Fix the root cause. If the problem is in an area of the code with little
|
|
4
|
+
relevance to the mission you may re-implement it or remove it.
|
|
6
5
|
|
|
7
|
-
Apply the contributing guidelines to your response
|
|
8
|
-
and direction of the contributing guidelines. Prioritize changes that deliver substantial user value
|
|
9
|
-
and maintain the integrity of the codebase's primary purpose.
|
|
6
|
+
Apply the contributing guidelines to your response.
|
|
10
7
|
|
|
11
8
|
You may complete the implementation of a feature and/or bring the code output in line with the README
|
|
12
9
|
or other documentation. Do as much as you can all at once so that the build runs (even with nothing
|
|
13
10
|
to build) and the tests pass and the main at least doesn't output an error.
|
|
14
11
|
|
|
12
|
+
Your goal is mission complete — if the mission can be fully accomplished while fixing this issue,
|
|
13
|
+
do it. Don't limit yourself to the minimal fix when you can deliver the whole mission in one pass.
|
|
14
|
+
|
|
15
15
|
The repository has a website in `src/web/` that uses the JS library. If a fix affects library
|
|
16
16
|
exports or behaviour, also update the website files to stay in sync.
|
|
17
17
|
|
|
@@ -1,14 +1,25 @@
|
|
|
1
1
|
You are providing the entire new content of source files, test files, documentation files, and other necessary
|
|
2
|
-
files with all necessary changes applied to deliver the resolution to an issue.
|
|
3
|
-
|
|
4
|
-
Implement as much as you can and refer to the projects features and mission statement when expanding the code
|
|
2
|
+
files with all necessary changes applied to deliver the resolution to an issue.
|
|
3
|
+
Implement as much as you can and refer to the project's features and mission statement when expanding the code
|
|
5
4
|
beyond the scope of the original issue. Implement whole features and do not leave stubbed out or pretended code.
|
|
6
5
|
|
|
7
|
-
Apply the contributing guidelines to your response
|
|
8
|
-
of the contributing guidelines. Prioritize changes that deliver user value and maintain the integrity
|
|
9
|
-
of the codebase's primary purpose.
|
|
6
|
+
Apply the contributing guidelines to your response.
|
|
10
7
|
|
|
11
|
-
Do as much as you can all at once.
|
|
8
|
+
Do as much as you can all at once. Your goal is mission complete — if the mission can be fully
|
|
9
|
+
accomplished in this single transform, it should be. Deliver all acceptance criteria, tests, website,
|
|
10
|
+
docs, and README in one pass. Only leave work for a follow-up if it genuinely cannot fit.
|
|
11
|
+
|
|
12
|
+
## Tests Must Pass
|
|
13
|
+
|
|
14
|
+
Your changes MUST leave all existing tests passing. If you change function signatures, return values, or
|
|
15
|
+
output formats, you MUST also update the corresponding tests. The mission's acceptance criteria are the
|
|
16
|
+
source of truth for expected values — if tests and acceptance criteria disagree, fix the tests to match
|
|
17
|
+
the acceptance criteria and fix the code to pass those tests.
|
|
18
|
+
|
|
19
|
+
When writing both tests and implementation:
|
|
20
|
+
- Write tests that match the acceptance criteria in MISSION.md exactly (casing, types, error classes)
|
|
21
|
+
- Ensure the implementation passes those tests before delivering
|
|
22
|
+
- Do not write tests with different expectations than the implementation produces
|
|
12
23
|
|
|
13
24
|
Follow the linting guidelines and the formatting guidelines from the included config.
|
|
14
25
|
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
Please generate the name and specification for a software feature which will be added or updated to action the supplied feature prompt.
|
|
2
|
-
|
|
2
|
+
Features must advance the mission stated in MISSION.md. Aim for achievable outcomes within a single repository, not a grandiose vision or bloated feature set.
|
|
3
3
|
|
|
4
4
|
You may only create features to only change the source file, test file, README file, dependencies file, and examples directory content. You may not create features that request new files, delete existing files, or change the other files provided in the prompt context.
|
|
5
5
|
If there are more than the maximum number of features in the repository, you may delete a feature but preferably, you should identify an existing feature that is most similar or related to the new feature and modify it to incorporate aspects of the new feature.
|
|
@@ -12,7 +12,7 @@ Don't use any quote escape sequences in the feature text.
|
|
|
12
12
|
Generally, the whole document might need to be extracted and stored as JSON so be careful to avoid any JSON escape
|
|
13
13
|
sequences in any part of the document. Use spacing to make it readable and avoid complex Markdown formatting.
|
|
14
14
|
|
|
15
|
-
The feature will be iterated upon to incrementally
|
|
15
|
+
The feature will be iterated upon to incrementally advance the mission. New features should be thematically distinct from other features.
|
|
16
16
|
If a significant feature of the repository is not present in the current feature set, please add it either to a new feature or an existing feature.
|
|
17
17
|
Before adding a new feature ensure that this feature is distinct from any other feature in the repository, otherwise update an existing feature.
|
|
18
18
|
When updating an existing feature, ensure that the existing aspects are not omitted in the response, provide the full feature spec.
|
|
@@ -1,19 +1,19 @@
|
|
|
1
|
-
Extract and condense the
|
|
2
|
-
Before adding a new document, ensure that this document is distinct from any other document in the library, otherwise update an existing document.
|
|
1
|
+
Extract and condense the technical details from the supplied crawl result that are relevant to the mission.
|
|
2
|
+
Before adding a new document, ensure that this document is distinct from any other document in the library, otherwise update an existing document.
|
|
3
3
|
The document name should be one or two words in SCREAMING_SNAKECASE.
|
|
4
4
|
|
|
5
|
-
You should extract a section from the sources file to create the document. Each document should contain
|
|
5
|
+
You should extract a section from the sources file to create the document. Each document should contain actionable technical content. Focus on:
|
|
6
6
|
|
|
7
7
|
1. A normalised extract of the crawled content containing:
|
|
8
|
-
a. The
|
|
9
|
-
b. A focused table of contents listing the specific technical topics
|
|
10
|
-
c. The actual detailed information for each item in the table of contents
|
|
11
|
-
2. A supplementary details section containing the
|
|
8
|
+
a. The key technical points that directly enable implementation, not summaries of them
|
|
9
|
+
b. A focused table of contents listing the specific technical topics covered
|
|
10
|
+
c. The actual detailed information for each item in the table of contents
|
|
11
|
+
2. A supplementary details section containing the technical specifications and implementation details that complement the crawled content
|
|
12
12
|
3. A reference details section containing the critical API specifications, complete SDK method signatures with parameters
|
|
13
13
|
and return types, exact implementation patterns, specific configuration options with their values
|
|
14
14
|
and effects, concrete best practices with implementation examples, step-by-step troubleshooting procedures, and
|
|
15
|
-
detailed instructional material.
|
|
16
|
-
4. A detailed digest containing the
|
|
15
|
+
detailed instructional material. Do not describe what specifications exist, include the actual specifications themselves.
|
|
16
|
+
4. A detailed digest containing the technical content from the source section in SOURCES.md and the date when the
|
|
17
17
|
content was retrieved (current date)
|
|
18
18
|
5. Attribution information and data size obtained during crawling
|
|
19
19
|
|
|
@@ -24,8 +24,7 @@ Don't use any quote escape sequences in the normalised extract.
|
|
|
24
24
|
Generally, the whole document might need to be extracted and stored as JSON so be careful to avoid any JSON escape
|
|
25
25
|
sequences in any part of the document. Use spacing to make it readable and avoid complex Markdown formatting.
|
|
26
26
|
|
|
27
|
-
For the normalised extract, extract the
|
|
28
|
-
directly usable format
|
|
29
|
-
Do not describe what information exists, include the actual information itself. The content must be specific
|
|
30
|
-
|
|
31
|
-
technical details that thoroughly explain the implementation while prioritizing content that delivers substantial user value.
|
|
27
|
+
For the normalised extract, extract the technical information from the crawled data and present it in a condensed,
|
|
28
|
+
directly usable format.
|
|
29
|
+
Do not describe what information exists, include the actual information itself. The content must be specific and technical.
|
|
30
|
+
Each item in the table of contents must have the technical details that thoroughly explain the implementation.
|
|
@@ -1,13 +1,13 @@
|
|
|
1
|
-
Please review the GitHub issue and determine if it should be enhanced, closed or if no operation is needed.
|
|
1
|
+
Please review the GitHub issue and determine if it should be enhanced, closed or if no operation is needed.
|
|
2
2
|
|
|
3
|
-
If the issue is relevant to the mission statement and features
|
|
3
|
+
If the issue is relevant to the mission statement and features:
|
|
4
4
|
|
|
5
5
|
1. Decide if the issue should be refined, closed or if no operation is needed.
|
|
6
|
-
2. Update the issue description with testable acceptance criteria
|
|
7
|
-
3. Enhance the issue by adding relevant library documents as issue comments that support implementation
|
|
6
|
+
2. Update the issue description with testable acceptance criteria derived from MISSION.md. Include ALL of: implementation, tests matching MISSION.md acceptance criteria, website updates, docs/evidence, and README. The issue should ask for mission complete — if the entire mission can be accomplished in a single transform, the acceptance criteria should cover everything. Only scope down if the mission is genuinely too large for one pass.
|
|
7
|
+
3. Enhance the issue by adding relevant library documents as issue comments that support implementation.
|
|
8
8
|
|
|
9
|
-
If the issue is irrelevant to the mission statement or features
|
|
9
|
+
If the issue is irrelevant to the mission statement or features:
|
|
10
10
|
|
|
11
|
-
1. Set the action to close the issue and supply an appropriate comment explaining why it doesn't
|
|
11
|
+
1. Set the action to close the issue and supply an appropriate comment explaining why it doesn't advance the mission.
|
|
12
12
|
|
|
13
|
-
Input validation issues that don't
|
|
13
|
+
Input validation issues that don't advance the mission should be closed, and in particular, issues mentioning handling of NaN are probably worthless and should be closed.
|
|
@@ -1,5 +1,12 @@
|
|
|
1
|
-
Does the combination source file, test file, website files, README file and dependencies file
|
|
2
|
-
|
|
1
|
+
Does the combination source file, test file, website files, README file and dependencies file resolve the following issue? Check that the solution satisfies the issue's acceptance criteria and moves the mission toward complete.
|
|
2
|
+
|
|
3
|
+
If the mission could have been fully accomplished in this transform but the solution only partially addresses it, note this gap and suggest a follow-up issue for the remaining work.
|
|
4
|
+
|
|
5
|
+
When reviewing, check that:
|
|
6
|
+
- Tests and implementation are consistent — test expectations must match what the code actually returns (casing, types, formats)
|
|
7
|
+
- Tests match the acceptance criteria in MISSION.md — the mission is the source of truth
|
|
8
|
+
- If tests expect different values than the code produces, create an issue to fix the mismatch
|
|
9
|
+
|
|
3
10
|
Note: The repository has a website in `src/web/` that uses the JS library. When reviewing, check that website files are updated alongside library changes.
|
|
4
11
|
|
|
5
12
|
When reviewing, also check that evidence artifacts exist under `docs/` for implemented features.
|
|
@@ -2,7 +2,7 @@ You are the supervisor of an autonomous coding repository. Your job is to advanc
|
|
|
2
2
|
|
|
3
3
|
## Priority Order
|
|
4
4
|
|
|
5
|
-
1. **
|
|
5
|
+
1. **Always strive for mission complete** — every action you take should aim to finish the mission. Create one comprehensive issue that targets the entire mission (all acceptance criteria, tests, website, docs, README). Only create a second issue if the first transform couldn't complete everything, and scope it to the remaining work. Do not create issues just to fill a quota.
|
|
6
6
|
2. **Dispatch transform when ready issues exist** — transform is where code gets written. Always prefer it over maintain when there are open issues with the `ready` label.
|
|
7
7
|
3. **Dispatch review after transform** — when recent workflow runs show a transform completion, dispatch review to close resolved issues and add `ready` labels to new issues. This keeps the pipeline flowing.
|
|
8
8
|
4. **Fix failing PRs** — dispatch fix-code for any PR with failing checks (include pr-number).
|
|
@@ -12,12 +12,12 @@ You are the supervisor of an autonomous coding repository. Your job is to advanc
|
|
|
12
12
|
|
|
13
13
|
1. **Check what's already in progress** — don't duplicate work. If the workflow is already running, don't dispatch another.
|
|
14
14
|
2. **Prioritise code generation** — the goal is working code. Prefer actions that produce code (dev-only, fix) over metadata (maintain, label).
|
|
15
|
-
3. **
|
|
15
|
+
3. **Right-size the work** — break the mission into chunks just big enough to reliably deliver. One comprehensive issue is better than many small ones. Only create a follow-up issue when the previous transform has landed and gaps remain.
|
|
16
16
|
4. **Respect limits** — don't create issues beyond the WIP limit shown in the context. Don't dispatch workflows that will fail due to missing prerequisites.
|
|
17
17
|
|
|
18
18
|
## When to use each action
|
|
19
19
|
|
|
20
|
-
- **github:create-issue** — When open issues < WIP limit.
|
|
20
|
+
- **github:create-issue** — When open issues < WIP limit. Create comprehensive issues that ask for maximum implementation in a single transform. Each issue should request: implementation code, matching tests, website updates, docs/evidence, and README changes. The first issue should aim to deliver the entire mission (all acceptance criteria, tests, website, docs). If a follow-up issue is needed, it should address whatever the first transform didn't complete. Always include relevant labels (`automated`, `enhancement`).
|
|
21
21
|
- **dispatch:agentic-lib-workflow | mode: dev-only | issue-number: \<N\>** — When there are open issues with the `ready` label and no workflow is currently running.
|
|
22
22
|
- **dispatch:agentic-lib-workflow | mode: review-only** — After observing a recent transform completion, or when there are unenhanced issues needing the `ready` label.
|
|
23
23
|
- **dispatch:agentic-lib-workflow | mode: maintain-only** — When features are below their limit AND no maintain appears in the last 3 workflow runs.
|