@groupby/ai-dev 0.4.0 → 0.4.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
CHANGED
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# Fix Review Findings
|
|
2
|
+
|
|
3
|
+
Apply actionable findings from `prompts/review-change.md` to the current changes in `components/`.
|
|
4
|
+
|
|
5
|
+
## Goal
|
|
6
|
+
|
|
7
|
+
Take the review findings/suggestions already produced, implement concrete fixes, run relevant verification, and report
|
|
8
|
+
what was addressed versus what still needs clarification.
|
|
9
|
+
|
|
10
|
+
## Inputs
|
|
11
|
+
|
|
12
|
+
Use the latest review output from this session. If no findings were reported, stop and state that no fix work is needed.
|
|
13
|
+
|
|
14
|
+
If findings are missing required detail (for example no file path, unclear recommendation, or conflicting guidance), ask
|
|
15
|
+
for clarification before editing.
|
|
16
|
+
|
|
17
|
+
## Prioritization Rules
|
|
18
|
+
|
|
19
|
+
Process findings in this order:
|
|
20
|
+
|
|
21
|
+
1. Critical and high-severity correctness/regression issues
|
|
22
|
+
2. Contract/schema/API mismatches
|
|
23
|
+
3. Validation and error-handling gaps
|
|
24
|
+
4. Missing or weak tests
|
|
25
|
+
5. Medium/low maintainability or style items
|
|
26
|
+
|
|
27
|
+
## Implementation Rules
|
|
28
|
+
|
|
29
|
+
- Apply minimal, targeted changes per finding.
|
|
30
|
+
- Keep scope limited to the reviewed change set.
|
|
31
|
+
- Do not perform unrelated refactors.
|
|
32
|
+
- If behavior changes, add or update focused tests.
|
|
33
|
+
- If contract/schema changes are required, update specs/contracts first, then runtime code.
|
|
34
|
+
- If a finding is intentionally not implemented, record why.
|
|
35
|
+
|
|
36
|
+
## Verification
|
|
37
|
+
|
|
38
|
+
Run relevant checks for touched components:
|
|
39
|
+
|
|
40
|
+
```bash
|
|
41
|
+
uv run pytest test/ -v # bc-agent, bc-mcp
|
|
42
|
+
mix test # bc-api
|
|
43
|
+
mix format --check-formatted # bc-api
|
|
44
|
+
./gradlew :bc-pay-core:test # bc-pay
|
|
45
|
+
./gradlew spotlessCheck # bc-pay
|
|
46
|
+
./gradlew test --no-daemon # bc-pay-stripe
|
|
47
|
+
./gradlew spotlessCheck --no-daemon # bc-pay-stripe
|
|
48
|
+
./gradlew test # bc-magento, bc-salesforce, bc-shopify, bc-webhooks
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
If full verification is too expensive, run focused checks for touched areas and state what was not run.
|
|
52
|
+
|
|
53
|
+
## Final Response
|
|
54
|
+
|
|
55
|
+
Lead with outcome and provide:
|
|
56
|
+
|
|
57
|
+
- Findings addressed (mapped to files changed)
|
|
58
|
+
- Findings deferred or blocked (with reason)
|
|
59
|
+
- Checks run and results
|
|
60
|
+
- Remaining risks
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
# Review Brain Checkout Component Change
|
|
2
|
+
|
|
3
|
+
Review the current changes in `components/`.
|
|
4
|
+
|
|
5
|
+
## Review Focus
|
|
6
|
+
|
|
7
|
+
- Correctness and regressions
|
|
8
|
+
- Contract compatibility
|
|
9
|
+
- Producer/consumer alignment for events and APIs
|
|
10
|
+
- Validation and error handling
|
|
11
|
+
- Secret leakage in logs/config/examples
|
|
12
|
+
- Missing or weak tests
|
|
13
|
+
- Build/test risk
|
|
14
|
+
|
|
15
|
+
## Output Format
|
|
16
|
+
|
|
17
|
+
Lead with findings:
|
|
18
|
+
|
|
19
|
+
```markdown
|
|
20
|
+
## Findings
|
|
21
|
+
|
|
22
|
+
- Severity: {critical|high|medium|low}
|
|
23
|
+
File: `{path}:{line}`
|
|
24
|
+
Issue: {specific issue}
|
|
25
|
+
Recommendation: {specific fix}
|
|
26
|
+
|
|
27
|
+
## Open Questions
|
|
28
|
+
|
|
29
|
+
- {question or "None"}
|
|
30
|
+
|
|
31
|
+
## Checks
|
|
32
|
+
|
|
33
|
+
- {command}: {result}
|
|
34
|
+
|
|
35
|
+
## Summary
|
|
36
|
+
|
|
37
|
+
{brief summary}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
If no issues are found, say that clearly and list residual risks.
|
|
41
|
+
|
|
42
|
+
## Optional Next Step
|
|
43
|
+
|
|
44
|
+
If findings or suggestions are reported and code updates are required, run `prompts/fix-review-findings.md`.
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sync-components
|
|
3
|
+
description: Sync a multi-repository component workspace by cloning repositories listed in components.txt with minimal inspection. Use when asked to sync up, clone, or refresh project components.
|
|
4
|
+
license: MIT
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Sync Components
|
|
8
|
+
|
|
9
|
+
Use this skill when the user asks to sync up a project's component repositories.
|
|
10
|
+
|
|
11
|
+
## Goal
|
|
12
|
+
|
|
13
|
+
Populate `components/` from the entries in `components.txt` using `git clone`, and leave each synced component on the `main` branch.
|
|
14
|
+
|
|
15
|
+
Keep this workflow lightweight. Do not inspect component source trees, run builds, run tests, scan every repository, or perform broad Git status checks unless the user explicitly asks.
|
|
16
|
+
|
|
17
|
+
Do not create a shell script, temporary script, generated helper, Makefile target, or wrapper command for this workflow. Running generated scripts often triggers extra approval prompts. Use direct shell commands only.
|
|
18
|
+
|
|
19
|
+
## Source Of Truth
|
|
20
|
+
|
|
21
|
+
Read `components.txt` from the framework or workspace checkout.
|
|
22
|
+
|
|
23
|
+
Each non-empty, non-comment line is either:
|
|
24
|
+
|
|
25
|
+
- A full Git remote URL, used as-is.
|
|
26
|
+
- A repository name. If the file uses bare repository names, infer the Git remote from the project instructions or ask the user for the organization/remote prefix before cloning.
|
|
27
|
+
|
|
28
|
+
The local checkout path for each entry is:
|
|
29
|
+
|
|
30
|
+
```text
|
|
31
|
+
components/<repo-name>
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Derive `<repo-name>` from the entry basename and remove a trailing `.git`.
|
|
35
|
+
|
|
36
|
+
## Workflow
|
|
37
|
+
|
|
38
|
+
1. Confirm the current directory is the framework checkout.
|
|
39
|
+
2. Create `components/` if it does not exist.
|
|
40
|
+
3. Read `components.txt`.
|
|
41
|
+
4. For each component entry:
|
|
42
|
+
- If `components/<repo-name>` does not exist, run:
|
|
43
|
+
|
|
44
|
+
```bash
|
|
45
|
+
git clone <remote> components/<repo-name>
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
- If the directory already exists, keep it and report `exists`.
|
|
49
|
+
- After clone or exists, run:
|
|
50
|
+
|
|
51
|
+
```bash
|
|
52
|
+
git -C components/<repo-name> checkout main
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
- If `main` is not available locally, fetch only the main branch and try again:
|
|
56
|
+
|
|
57
|
+
```bash
|
|
58
|
+
git -C components/<repo-name> fetch origin main
|
|
59
|
+
git -C components/<repo-name> checkout main
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
5. Report only cloned, existing, checked-out-main, skipped, and failed component names.
|
|
63
|
+
|
|
64
|
+
Prefer issuing the `git clone` commands directly from the terminal. It is acceptable to run them one at a time. Do not generate a loop script or ask the user to run a script.
|
|
65
|
+
|
|
66
|
+
## Constraints
|
|
67
|
+
|
|
68
|
+
- Use direct `git clone` commands for this workflow.
|
|
69
|
+
- Do not create, modify, chmod, or execute any sync script.
|
|
70
|
+
- Do not use heredocs, shell redirection, or generated files to automate cloning.
|
|
71
|
+
- Do not delete, reset, clean, or force checkout any component repository.
|
|
72
|
+
- Do not pull existing repositories unless the user asks to update already-cloned components.
|
|
73
|
+
- Do not fetch existing repositories except `git fetch origin main` when needed to make `main` available for checkout.
|
|
74
|
+
- Do not open or validate component-local instruction files during this sync workflow.
|
|
75
|
+
- Do not run dependency installation, tests, formatters, linters, or builds.
|
|
76
|
+
- Keep all cloned repositories directly under `components/`.
|