You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Always check whether an issue has native sub-issues. The `trackedIssues` / `trackedInIssues` GraphQL fields only cover older markdown task-list tracking and will miss native sub-issues.
16
+
17
+
```bash
18
+
gh api graphql -f query='query {
19
+
repository(owner:"<owner>", name:"<repo>") {
20
+
issue(number: <issue_number>) {
21
+
subIssues(first: 50) { nodes { number title state url } }
22
+
parent { number title state url }
23
+
}
24
+
}
25
+
}'
26
+
```
27
+
13
28
## Analyze context
14
29
- Extract the problem statement and acceptance criteria
15
30
- Summarize discussion history and blockers
16
31
- Identify affected files/modules
32
+
- Review sub-issues (if any) for work breakdown and progress
Copy file name to clipboardExpand all lines: .github/skills/github-issues/reference/parent-child-issues.md
+18-1Lines changed: 18 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -91,7 +91,24 @@ gh api graphql \
91
91
-f sub='<CHILD_NODE_ID>'
92
92
```
93
93
94
-
## 6) Verify links rendered correctly
94
+
## 6) Discover existing sub-issues
95
+
96
+
When evaluating an issue that may already have sub-issues, always use the `subIssues` GraphQL field. Do **not** use `trackedIssues` / `trackedInIssues` -- those only cover older markdown task-list tracking and will miss native sub-issues.
Copy file name to clipboardExpand all lines: .github/skills/python-environment/SKILL.md
+47-4Lines changed: 47 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,32 @@
1
1
---
2
2
name: python-environment
3
-
description: Detectand configure a conda-compatible tool, create the CausalPy environment, and run commands inside it. Use before any task that requires Python execution.
3
+
description: Detect, configure, and use a conda-compatible tool. Use before tasks that need the project environment, such as importing project code, running tests, building docs, or invoking repo tooling.
4
4
---
5
5
6
6
# Python Environment
7
7
8
8
Set up and run commands inside the CausalPy conda environment.
9
9
10
+
## Decide whether the env is required
11
+
12
+
Use the `CausalPy` env when the command:
13
+
14
+
- imports project code (for example `import causalpy` or project modules)
15
+
- runs tests
16
+
- builds docs
17
+
- invokes repo tooling such as `make`, `prek`, or notebook execution
18
+
19
+
For simple inspection helpers that only read local text/JSON or use the Python standard library, any Python on `PATH` is acceptable.
20
+
21
+
## Reuse before creating
22
+
23
+
Do the least work that will get the task done:
24
+
25
+
1. Reuse an existing `CausalPy` env if one is already available.
26
+
2. If `run -n CausalPy` cannot resolve the env, check whether it exists under a different prefix and use `run -p`.
27
+
3. Only create the env if no suitable existing env is available.
28
+
4. Only update the env or rerun `make setup` when dependencies changed, the editable install is stale, or the current checkout has not been installed into that env yet.
29
+
10
30
## Detect the conda tool
11
31
12
32
Use whichever of `mamba`, `micromamba`, or `conda` is available (checked in that order):
@@ -24,21 +44,25 @@ If `CONDA_EXE` is empty, no conda-compatible tool was found. Propose installing
24
44
25
45
After installation, set `CONDA_EXE=micromamba`.
26
46
27
-
## Create the environment
47
+
## Create the environment only if needed
48
+
49
+
If no suitable existing env can be reused, create it:
28
50
29
51
```bash
30
52
$CONDA_EXE env create -f environment.yml
31
53
```
32
54
33
-
## Install the package (required after creating or updating the environment)
55
+
## Install the package only when needed
56
+
57
+
Run `make setup` after creating or updating the env. Also rerun it when using a different git worktree if that env has not been installed against the current checkout yet.
34
58
35
59
```bash
36
60
$CONDA_EXE run -n CausalPy make setup
37
61
```
38
62
39
63
## Run commands
40
64
41
-
Always use `run -n` instead of `activate`:
65
+
Never use `$CONDA_EXE activate`, instead use `$CONDA_EXE run -n CausalPy <command>`.
If `$CONDA_EXE run -n CausalPy ...` fails with errors such as `The given prefix does not exist`:
84
+
85
+
```bash
86
+
$CONDA_EXE env list
87
+
$CONDA_EXE run -p "/full/path/to/CausalPy"<command>
88
+
```
89
+
90
+
Keep using `run -p` with that full prefix for the rest of the session.
91
+
92
+
### Git worktrees and remote machines
93
+
94
+
Git worktrees do not require a fresh env per agent session. Prefer reusing an existing env to save time. The main caveat is that this repo uses editable installs, so one shared env can point at whichever checkout most recently ran `make setup`.
95
+
96
+
- For ordinary local work on one checkout, reuse the existing env.
97
+
- For long-lived parallel worktrees, one env per worktree is the safest option, but do not create one unless needed.
98
+
- On a fresh remote machine or ephemeral container, create the env once. On a persistent remote machine with an existing env, reuse it.
99
+
57
100
If you hit issues with an outdated tool, update it:
0 commit comments