Sync Carried Fleet Skills#69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ptr727 merged 3 commits into from
Aug 18, 2026
Merged

Sync Carried Fleet Skills #69

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e633b3f
Sync Carried Fleet Skills
ptr727 Aug 18, 2026
21c4cae
Clarify Carried Review Helper Location
ptr727 Aug 18, 2026
734fa68
Combine Carried Review Wait Steps
ptr727 Aug 18, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 26 additions & 15 deletions .github/skills/pr-review-conduct/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -4,10 +4,11 @@ description: >-
Governs opening, driving, and merging a pull request review loop in a ptr727/ProjectTemplate
fleet repo: requesting a review after a push, triaging findings (including suppressed
low-confidence ones), replying and resolving threads, and deciding whether a PR is actually
mergeable. Use this whenever about to merge a PR, enable auto-merge, ask the maintainer for
merge permission, push a fix and move on without re-checking review state, or judge a PR
"green" or "clean" from CI or mergeStateStatus alone. Triggers even when the request sounds
routine, such as "merge this" or "it's all green, go ahead," because mergeStateStatus: CLEAN
mergeable. Use this whenever about to open a PR, immediately after creating one, about to merge
a PR, enable auto-merge, ask the maintainer for merge permission, push a fix and move on without
re-checking review state, or judge a PR "green" or "clean" from CI or mergeStateStatus alone.
Triggers even when the request sounds routine, such as "open a PR," "merge this," or "it's all
green, go ahead," because PR creation starts the review loop and mergeStateStatus: CLEAN
can go clean once checks pass and every known thread is resolved, while still saying nothing
about whether the review that resolved those threads covered the current head SHA, read the
full diff, or left a suppressed low-confidence finding, which opens no thread at all,
Expand DownExpand Up@@ -56,21 +57,31 @@ full stop, whatever the merge-state field says.

## Expected review loop

1. Push changes to the PR branch.
2. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
Opening a pull request starts this loop by default. Creating the PR is not a terminal handoff.
Only an explicit maintainer instruction may stop, defer, or alter the loop. A draft state, silence,
or a request that says only "open a PR" is not such an instruction.

Run every `scripts/pr_review.py` command below from a hub checkout. The script is hosted there and
is never carried into a downstream repository.

1. Push changes to the PR branch and open the pull request when it does not exist.
2. Run `scripts/pr_review.py status` once in the foreground and read its output.
3. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
explicitly (mechanics in the Copilot runbook). The UI is a fallback only.
3. Wait for review activity on that head. A completed review raising **no findings** is a valid
terminal outcome, so don't re-trigger it or read silence as a missing review. A review whose
body says it declined to review is the one exception, and it is terminal the other way:
nothing follows it, and re-requesting the same head just repeats the decline.
4. Triage findings (see below).
5. Apply fixes or write a rationale for declines.
6. Reply to each thread and resolve what was addressed.
7. Re-run the loop after every fix push until no actionable finding remains.
4. Run a bounded `scripts/pr_review.py wait` in a background process and read its terminal output.
Comment thread
ptr727 marked this conversation as resolved.
A completed review raising **no findings** is a valid terminal outcome, so do not re-trigger it
or read silence as a missing review. A review whose body says it declined to review is the one
exception, and it is terminal the other way. Nothing follows it, and re-requesting the same
head only repeats the decline.
5. Triage findings (see below).
6. Apply fixes or write a rationale for declines.
7. Reply to each thread and resolve what was addressed.
8. Re-run the loop after every fix push until the checks are green and no finding remains open.

Drive to green, a review confirmed on the latest head SHA and every actionable finding closed,
then apply the Merge Gate above. **Never exit the loop early.** A round count is not a stopping
condition, and neither is patience running out.
condition, and neither is patience running out. Reporting only that the PR was opened is an early
exit unless the maintainer explicitly instructed the agent not to monitor or drive its review.

## Every finding ends in one of five outcomes

Expand Down
22 changes: 13 additions & 9 deletions .github/skills/python-codestyle/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -5,13 +5,14 @@ description: >-
profile split, the uv/ruff/pyright/mypy/pytest toolchain, src layout, formatting and linting,
comment and docstring conventions, type hints, naming, imports, patterns to avoid, test
conventions, and versioning. Use this whenever writing, reviewing, or editing a .py file, a
pyproject.toml, or a uv.lock, whenever deciding whether a Python subtree is a shippable project
or a lint-only scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or
whenever writing or reviewing a pytest test. Triggers even when the task looks like a small
local fix ("just add a helper function", "silence this lint warning", "add a dependency"),
because the profile split, the ruff-is-authoritative rule, and the ban on backward-compat
shims or impossible-case error handling are each easy to violate one file at a time. Applies
only to a repo's Python side, a repo with no Python has no use for this Skill.
pyproject.toml, or a uv.lock, whenever running or choosing a Python formatting, lint, type-check,
or test command, whenever deciding whether a Python subtree is a shippable project or a lint-only
scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or whenever writing or
reviewing a Python test. Triggers even when the task looks like a small local fix ("just add a
helper function", "silence this lint warning", "add a dependency") or verification step ("run
the tests"), because choosing pytest before reading the profile turns an intentional unittest
suite into a false missing-dependency diagnosis. Applies only to a repo's Python side, a repo
with no Python has no use for this Skill.
---

# Python Codestyle
Expand All@@ -26,11 +27,14 @@ profiles, the toolchain, layout, and the language-level conventions.

## Two profiles

Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
Read the repo's `OPERATIONS.md` local-verification commands before substituting a generic command.
Then read the `pyproject.toml` shape and pick the profile before running Python tooling or tests:

- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
pyright strict (or mypy where the repo requires it).
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx` for third-party tools, unittest
for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
defect. Use the repository's exact coverage command and unittest scope from `OPERATIONS.md`.

For the full profile specification and per-repo adaptation axes (type checker, dependency
declaration, versioning, VS Code config), see `references/profiles.md`.
Expand Down
34 changes: 27 additions & 7 deletions .github/skills/repo-worktree/SKILL.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -8,13 +8,14 @@ description: >-
branch a tool defaulted to), with a standalone-clone fallback when an executor cannot write
both the standard worktree and its Git metadata. Also wraps the mechanics:
creating a worktree with git worktree add, the fleet layout convention, listing what is in
flight, and removing a worktree and its branch after merge. Use this whenever about to create
or edit files in a fleet repo, whenever starting or resuming a task, whenever the task's
branch is already checked out in a shared checkout, and whenever creating, listing, or
removing a worktree. Triggers even when the session was launched in the primary checkout or
the change looks like a one-line fix, because the primary checkout is the maintainer's own
surface and the incident this guards against was two sessions sharing one checkout, each
session's blanket add committing the other's uncommitted files.
flight, preparing Husky.Net or Python pre-commit hooks in the new tree, and removing a
worktree and its branch after merge. Use this whenever about to create or edit files in a
fleet repo, whenever starting or resuming a task, whenever the task's branch is already
checked out in a shared checkout, and whenever creating, listing, or removing a worktree.
Triggers even when the session was launched in the primary checkout or the change looks like
a one-line fix, because the primary checkout is the maintainer's own surface and the incident
this guards against was two sessions sharing one checkout, each session's blanket add
committing the other's uncommitted files.
---

# Repo Worktree
Expand DownExpand Up@@ -150,6 +151,25 @@ a `name`, it creates the worktree under `.claude/worktrees/` inside the repo and
GitHub default branch, which is the wrong path and the wrong base here. Create the worktree with
`git worktree add` as above, then attach with `EnterWorktree` `path:`, not `name:`.

## Preparing Git Hooks

A new worktree holds tracked hook configuration but not every generated hook runtime. Prepare
the hooks immediately after creating or attaching the worktree, before the first commit. A
shared `core.hooksPath` value does not make generated files such as `.husky/_/husky.sh` appear
in the new tree.

- **Husky.Net:** When `.husky/pre-commit` sources `.husky/_/husky.sh` and the local .NET tool
manifest declares Husky.Net, run `dotnet tool restore`, then `dotnet husky install` from the
worktree root.
- **Python pre-commit:** When `.pre-commit-config.yaml` exists, install the repository's declared
Python environment, then run `pre-commit install` through that environment. A uv project runs
`uv sync --frozen`, then `uv run pre-commit install`.
- **Repository override:** Follow a repository's explicit hook-setup instructions when they
differ from these standard cases. Do not infer a replacement command from the language alone.

Treat hook preparation as worktree setup, not as recovery after a rejected commit. If setup
fails, report that boundary and fix the setup. Never bypass the hook to make the commit succeed.

## Listing and Cleanup

- `git worktree list`, run in any checkout of a repo, names that repo's base clone and every
Expand Down
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
Sync Carried Fleet Skills#69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

ptr727
merged 3 commits into

from

Aug 18, 2026
 Merged


Sync Carried Fleet Skills
#69
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


3 commits


Select commit
Hold shift + click to select a range
e633b3f

Sync Carried Fleet Skills


ptr727 Aug 18, 2026
21c4cae

Clarify Carried Review Helper Location


ptr727 Aug 18, 2026
734fa68

Combine Carried Review Wait Steps


ptr727 Aug 18, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


41 changes: 26 additions & 15 deletions
.github/skills/pr-review-conduct/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4,10 +4,11 @@ description: >-
 Governs opening, driving, and merging a pull request review loop in a ptr727/ProjectTemplate
 fleet repo: requesting a review after a push, triaging findings (including suppressed
 low-confidence ones), replying and resolving threads, and deciding whether a PR is actually
 mergeable. Use this whenever about to merge a PR, enable auto-merge, ask the maintainer for
 merge permission, push a fix and move on without re-checking review state, or judge a PR
 "green" or "clean" from CI or mergeStateStatus alone. Triggers even when the request sounds
 routine, such as "merge this" or "it's all green, go ahead," because mergeStateStatus: CLEAN
 mergeable. Use this whenever about to open a PR, immediately after creating one, about to merge
 a PR, enable auto-merge, ask the maintainer for merge permission, push a fix and move on without
 re-checking review state, or judge a PR "green" or "clean" from CI or mergeStateStatus alone.
 Triggers even when the request sounds routine, such as "open a PR," "merge this," or "it's all
 green, go ahead," because PR creation starts the review loop and mergeStateStatus: CLEAN
 can go clean once checks pass and every known thread is resolved, while still saying nothing
 about whether the review that resolved those threads covered the current head SHA, read the
 full diff, or left a suppressed low-confidence finding, which opens no thread at all,
Expand DownExpand Up@@ -56,21 +57,31 @@ full stop, whatever the merge-state field says.

## Expected review loop

1. Push changes to the PR branch.
2. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
Opening a pull request starts this loop by default. Creating the PR is not a terminal handoff.
Only an explicit maintainer instruction may stop, defer, or alter the loop. A draft state, silence,
or a request that says only "open a PR" is not such an instruction.

Run every `scripts/pr_review.py` command below from a hub checkout. The script is hosted there and
is never carried into a downstream repository.

1. Push changes to the PR branch and open the pull request when it does not exist.
2. Run `scripts/pr_review.py status` once in the foreground and read its output.
3. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
 explicitly (mechanics in the Copilot runbook). The UI is a fallback only.
3. Wait for review activity on that head. A completed review raising **no findings** is a valid
 terminal outcome, so don't re-trigger it or read silence as a missing review. A review whose
 body says it declined to review is the one exception, and it is terminal the other way:
 nothing follows it, and re-requesting the same head just repeats the decline.
4. Triage findings (see below).
5. Apply fixes or write a rationale for declines.
6. Reply to each thread and resolve what was addressed.
7. Re-run the loop after every fix push until no actionable finding remains.
4. Run a bounded `scripts/pr_review.py wait` in a background process and read its terminal output.
Comment thread
ptr727 marked this conversation as resolved.

 A completed review raising **no findings** is a valid terminal outcome, so do not re-trigger it
 or read silence as a missing review. A review whose body says it declined to review is the one
 exception, and it is terminal the other way. Nothing follows it, and re-requesting the same
 head only repeats the decline.
5. Triage findings (see below).
6. Apply fixes or write a rationale for declines.
7. Reply to each thread and resolve what was addressed.
8. Re-run the loop after every fix push until the checks are green and no finding remains open.

Drive to green, a review confirmed on the latest head SHA and every actionable finding closed,
then apply the Merge Gate above. **Never exit the loop early.** A round count is not a stopping
condition, and neither is patience running out.
condition, and neither is patience running out. Reporting only that the PR was opened is an early
exit unless the maintainer explicitly instructed the agent not to monitor or drive its review.

## Every finding ends in one of five outcomes

Expand Down

22 changes: 13 additions & 9 deletions
.github/skills/python-codestyle/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -5,13 +5,14 @@ description: >-
 profile split, the uv/ruff/pyright/mypy/pytest toolchain, src layout, formatting and linting,
 comment and docstring conventions, type hints, naming, imports, patterns to avoid, test
 conventions, and versioning. Use this whenever writing, reviewing, or editing a .py file, a
 pyproject.toml, or a uv.lock, whenever deciding whether a Python subtree is a shippable project
 or a lint-only scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or
 whenever writing or reviewing a pytest test. Triggers even when the task looks like a small
 local fix ("just add a helper function", "silence this lint warning", "add a dependency"),
 because the profile split, the ruff-is-authoritative rule, and the ban on backward-compat
 shims or impossible-case error handling are each easy to violate one file at a time. Applies
 only to a repo's Python side, a repo with no Python has no use for this Skill.
 pyproject.toml, or a uv.lock, whenever running or choosing a Python formatting, lint, type-check,
 or test command, whenever deciding whether a Python subtree is a shippable project or a lint-only
 scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or whenever writing or
 reviewing a Python test. Triggers even when the task looks like a small local fix ("just add a
 helper function", "silence this lint warning", "add a dependency") or verification step ("run
 the tests"), because choosing pytest before reading the profile turns an intentional unittest
 suite into a false missing-dependency diagnosis. Applies only to a repo's Python side, a repo
 with no Python has no use for this Skill.
---

# Python Codestyle
Expand All@@ -26,11 +27,14 @@ profiles, the toolchain, layout, and the language-level conventions.

## Two profiles

Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
Read the repo's `OPERATIONS.md` local-verification commands before substituting a generic command.
Then read the `pyproject.toml` shape and pick the profile before running Python tooling or tests:

- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
 pyright strict (or mypy where the repo requires it).
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx` for third-party tools, unittest
 for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
 defect. Use the repository's exact coverage command and unittest scope from `OPERATIONS.md`.

For the full profile specification and per-repo adaptation axes (type checker, dependency
declaration, versioning, VS Code config), see `references/profiles.md`.
Expand Down

34 changes: 27 additions & 7 deletions
.github/skills/repo-worktree/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -8,13 +8,14 @@ description: >-
 branch a tool defaulted to), with a standalone-clone fallback when an executor cannot write
 both the standard worktree and its Git metadata. Also wraps the mechanics:
 creating a worktree with git worktree add, the fleet layout convention, listing what is in
 flight, and removing a worktree and its branch after merge. Use this whenever about to create
 or edit files in a fleet repo, whenever starting or resuming a task, whenever the task's
 branch is already checked out in a shared checkout, and whenever creating, listing, or
 removing a worktree. Triggers even when the session was launched in the primary checkout or
 the change looks like a one-line fix, because the primary checkout is the maintainer's own
 surface and the incident this guards against was two sessions sharing one checkout, each
 session's blanket add committing the other's uncommitted files.
 flight, preparing Husky.Net or Python pre-commit hooks in the new tree, and removing a
 worktree and its branch after merge. Use this whenever about to create or edit files in a
 fleet repo, whenever starting or resuming a task, whenever the task's branch is already
 checked out in a shared checkout, and whenever creating, listing, or removing a worktree.
 Triggers even when the session was launched in the primary checkout or the change looks like
 a one-line fix, because the primary checkout is the maintainer's own surface and the incident
 this guards against was two sessions sharing one checkout, each session's blanket add
 committing the other's uncommitted files.
---

# Repo Worktree
Expand DownExpand Up@@ -150,6 +151,25 @@ a `name`, it creates the worktree under `.claude/worktrees/` inside the repo and
GitHub default branch, which is the wrong path and the wrong base here. Create the worktree with
`git worktree add` as above, then attach with `EnterWorktree` `path:`, not `name:`.

## Preparing Git Hooks

A new worktree holds tracked hook configuration but not every generated hook runtime. Prepare
the hooks immediately after creating or attaching the worktree, before the first commit. A
shared `core.hooksPath` value does not make generated files such as `.husky/_/husky.sh` appear
in the new tree.

- **Husky.Net:** When `.husky/pre-commit` sources `.husky/_/husky.sh` and the local .NET tool
 manifest declares Husky.Net, run `dotnet tool restore`, then `dotnet husky install` from the
 worktree root.
- **Python pre-commit:** When `.pre-commit-config.yaml` exists, install the repository's declared
 Python environment, then run `pre-commit install` through that environment. A uv project runs
 `uv sync --frozen`, then `uv run pre-commit install`.
- **Repository override:** Follow a repository's explicit hook-setup instructions when they
 differ from these standard cases. Do not infer a replacement command from the language alone.

Treat hook preparation as worktree setup, not as recovery after a rejected commit. If setup
fails, report that boundary and fix the setup. Never bypass the hook to make the commit succeed.

## Listing and Cleanup

- `git worktree list`, run in any checkout of a repo, names that repo's base clone and every
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Sync Carried Fleet Skills#69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

ptr727
merged 3 commits into

from

Aug 18, 2026
 Merged


Sync Carried Fleet Skills
#69
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


3 commits


Select commit
Hold shift + click to select a range
e633b3f

Sync Carried Fleet Skills


ptr727 Aug 18, 2026
21c4cae

Clarify Carried Review Helper Location


ptr727 Aug 18, 2026
734fa68

Combine Carried Review Wait Steps


ptr727 Aug 18, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


41 changes: 26 additions & 15 deletions
.github/skills/pr-review-conduct/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4,10 +4,11 @@ description: >-
 Governs opening, driving, and merging a pull request review loop in a ptr727/ProjectTemplate
 fleet repo: requesting a review after a push, triaging findings (including suppressed
 low-confidence ones), replying and resolving threads, and deciding whether a PR is actually
 mergeable. Use this whenever about to merge a PR, enable auto-merge, ask the maintainer for
 merge permission, push a fix and move on without re-checking review state, or judge a PR
 "green" or "clean" from CI or mergeStateStatus alone. Triggers even when the request sounds
 routine, such as "merge this" or "it's all green, go ahead," because mergeStateStatus: CLEAN
 mergeable. Use this whenever about to open a PR, immediately after creating one, about to merge
 a PR, enable auto-merge, ask the maintainer for merge permission, push a fix and move on without
 re-checking review state, or judge a PR "green" or "clean" from CI or mergeStateStatus alone.
 Triggers even when the request sounds routine, such as "open a PR," "merge this," or "it's all
 green, go ahead," because PR creation starts the review loop and mergeStateStatus: CLEAN
 can go clean once checks pass and every known thread is resolved, while still saying nothing
 about whether the review that resolved those threads covered the current head SHA, read the
 full diff, or left a suppressed low-confidence finding, which opens no thread at all,
Expand DownExpand Up@@ -56,21 +57,31 @@ full stop, whatever the merge-state field says.

## Expected review loop

1. Push changes to the PR branch.
2. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
Opening a pull request starts this loop by default. Creating the PR is not a terminal handoff.
Only an explicit maintainer instruction may stop, defer, or alter the loop. A draft state, silence,
or a request that says only "open a PR" is not such an instruction.

Run every `scripts/pr_review.py` command below from a hub checkout. The script is hosted there and
is never carried into a downstream repository.

1. Push changes to the PR branch and open the pull request when it does not exist.
2. Run `scripts/pr_review.py status` once in the foreground and read its output.
3. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
 explicitly (mechanics in the Copilot runbook). The UI is a fallback only.
3. Wait for review activity on that head. A completed review raising **no findings** is a valid
 terminal outcome, so don't re-trigger it or read silence as a missing review. A review whose
 body says it declined to review is the one exception, and it is terminal the other way:
 nothing follows it, and re-requesting the same head just repeats the decline.
4. Triage findings (see below).
5. Apply fixes or write a rationale for declines.
6. Reply to each thread and resolve what was addressed.
7. Re-run the loop after every fix push until no actionable finding remains.
4. Run a bounded `scripts/pr_review.py wait` in a background process and read its terminal output.
Comment thread
ptr727 marked this conversation as resolved.

 A completed review raising **no findings** is a valid terminal outcome, so do not re-trigger it
 or read silence as a missing review. A review whose body says it declined to review is the one
 exception, and it is terminal the other way. Nothing follows it, and re-requesting the same
 head only repeats the decline.
5. Triage findings (see below).
6. Apply fixes or write a rationale for declines.
7. Reply to each thread and resolve what was addressed.
8. Re-run the loop after every fix push until the checks are green and no finding remains open.

Drive to green, a review confirmed on the latest head SHA and every actionable finding closed,
then apply the Merge Gate above. **Never exit the loop early.** A round count is not a stopping
condition, and neither is patience running out.
condition, and neither is patience running out. Reporting only that the PR was opened is an early
exit unless the maintainer explicitly instructed the agent not to monitor or drive its review.

## Every finding ends in one of five outcomes

Expand Down

22 changes: 13 additions & 9 deletions
.github/skills/python-codestyle/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -5,13 +5,14 @@ description: >-
 profile split, the uv/ruff/pyright/mypy/pytest toolchain, src layout, formatting and linting,
 comment and docstring conventions, type hints, naming, imports, patterns to avoid, test
 conventions, and versioning. Use this whenever writing, reviewing, or editing a .py file, a
 pyproject.toml, or a uv.lock, whenever deciding whether a Python subtree is a shippable project
 or a lint-only scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or
 whenever writing or reviewing a pytest test. Triggers even when the task looks like a small
 local fix ("just add a helper function", "silence this lint warning", "add a dependency"),
 because the profile split, the ruff-is-authoritative rule, and the ban on backward-compat
 shims or impossible-case error handling are each easy to violate one file at a time. Applies
 only to a repo's Python side, a repo with no Python has no use for this Skill.
 pyproject.toml, or a uv.lock, whenever running or choosing a Python formatting, lint, type-check,
 or test command, whenever deciding whether a Python subtree is a shippable project or a lint-only
 scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or whenever writing or
 reviewing a Python test. Triggers even when the task looks like a small local fix ("just add a
 helper function", "silence this lint warning", "add a dependency") or verification step ("run
 the tests"), because choosing pytest before reading the profile turns an intentional unittest
 suite into a false missing-dependency diagnosis. Applies only to a repo's Python side, a repo
 with no Python has no use for this Skill.
---

# Python Codestyle
Expand All@@ -26,11 +27,14 @@ profiles, the toolchain, layout, and the language-level conventions.

## Two profiles

Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
Read the repo's `OPERATIONS.md` local-verification commands before substituting a generic command.
Then read the `pyproject.toml` shape and pick the profile before running Python tooling or tests:

- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
 pyright strict (or mypy where the repo requires it).
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx` for third-party tools, unittest
 for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
 defect. Use the repository's exact coverage command and unittest scope from `OPERATIONS.md`.

For the full profile specification and per-repo adaptation axes (type checker, dependency
declaration, versioning, VS Code config), see `references/profiles.md`.
Expand Down

34 changes: 27 additions & 7 deletions
.github/skills/repo-worktree/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -8,13 +8,14 @@ description: >-
 branch a tool defaulted to), with a standalone-clone fallback when an executor cannot write
 both the standard worktree and its Git metadata. Also wraps the mechanics:
 creating a worktree with git worktree add, the fleet layout convention, listing what is in
 flight, and removing a worktree and its branch after merge. Use this whenever about to create
 or edit files in a fleet repo, whenever starting or resuming a task, whenever the task's
 branch is already checked out in a shared checkout, and whenever creating, listing, or
 removing a worktree. Triggers even when the session was launched in the primary checkout or
 the change looks like a one-line fix, because the primary checkout is the maintainer's own
 surface and the incident this guards against was two sessions sharing one checkout, each
 session's blanket add committing the other's uncommitted files.
 flight, preparing Husky.Net or Python pre-commit hooks in the new tree, and removing a
 worktree and its branch after merge. Use this whenever about to create or edit files in a
 fleet repo, whenever starting or resuming a task, whenever the task's branch is already
 checked out in a shared checkout, and whenever creating, listing, or removing a worktree.
 Triggers even when the session was launched in the primary checkout or the change looks like
 a one-line fix, because the primary checkout is the maintainer's own surface and the incident
 this guards against was two sessions sharing one checkout, each session's blanket add
 committing the other's uncommitted files.
---

# Repo Worktree
Expand DownExpand Up@@ -150,6 +151,25 @@ a `name`, it creates the worktree under `.claude/worktrees/` inside the repo and
GitHub default branch, which is the wrong path and the wrong base here. Create the worktree with
`git worktree add` as above, then attach with `EnterWorktree` `path:`, not `name:`.

## Preparing Git Hooks

A new worktree holds tracked hook configuration but not every generated hook runtime. Prepare
the hooks immediately after creating or attaching the worktree, before the first commit. A
shared `core.hooksPath` value does not make generated files such as `.husky/_/husky.sh` appear
in the new tree.

- **Husky.Net:** When `.husky/pre-commit` sources `.husky/_/husky.sh` and the local .NET tool
 manifest declares Husky.Net, run `dotnet tool restore`, then `dotnet husky install` from the
 worktree root.
- **Python pre-commit:** When `.pre-commit-config.yaml` exists, install the repository's declared
 Python environment, then run `pre-commit install` through that environment. A uv project runs
 `uv sync --frozen`, then `uv run pre-commit install`.
- **Repository override:** Follow a repository's explicit hook-setup instructions when they
 differ from these standard cases. Do not infer a replacement command from the language alone.

Treat hook preparation as worktree setup, not as recovery after a rejected commit. If setup
fails, report that boundary and fix the setup. Never bypass the hook to make the commit succeed.

## Listing and Cleanup

- `git worktree list`, run in any checkout of a repo, names that repo's base clone and every
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Sync Carried Fleet Skills#69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

ptr727
merged 3 commits into

from

Aug 18, 2026
 Merged


Sync Carried Fleet Skills
#69
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


3 commits


Select commit
Hold shift + click to select a range
e633b3f

Sync Carried Fleet Skills


ptr727 Aug 18, 2026
21c4cae

Clarify Carried Review Helper Location


ptr727 Aug 18, 2026
734fa68

Combine Carried Review Wait Steps


ptr727 Aug 18, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


41 changes: 26 additions & 15 deletions
.github/skills/pr-review-conduct/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4,10 +4,11 @@ description: >-
 Governs opening, driving, and merging a pull request review loop in a ptr727/ProjectTemplate
 fleet repo: requesting a review after a push, triaging findings (including suppressed
 low-confidence ones), replying and resolving threads, and deciding whether a PR is actually
 mergeable. Use this whenever about to merge a PR, enable auto-merge, ask the maintainer for
 merge permission, push a fix and move on without re-checking review state, or judge a PR
 "green" or "clean" from CI or mergeStateStatus alone. Triggers even when the request sounds
 routine, such as "merge this" or "it's all green, go ahead," because mergeStateStatus: CLEAN
 mergeable. Use this whenever about to open a PR, immediately after creating one, about to merge
 a PR, enable auto-merge, ask the maintainer for merge permission, push a fix and move on without
 re-checking review state, or judge a PR "green" or "clean" from CI or mergeStateStatus alone.
 Triggers even when the request sounds routine, such as "open a PR," "merge this," or "it's all
 green, go ahead," because PR creation starts the review loop and mergeStateStatus: CLEAN
 can go clean once checks pass and every known thread is resolved, while still saying nothing
 about whether the review that resolved those threads covered the current head SHA, read the
 full diff, or left a suppressed low-confidence finding, which opens no thread at all,
Expand DownExpand Up@@ -56,21 +57,31 @@ full stop, whatever the merge-state field says.

## Expected review loop

1. Push changes to the PR branch.
2. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
Opening a pull request starts this loop by default. Creating the PR is not a terminal handoff.
Only an explicit maintainer instruction may stop, defer, or alter the loop. A draft state, silence,
or a request that says only "open a PR" is not such an instruction.

Run every `scripts/pr_review.py` command below from a hub checkout. The script is hosted there and
is never carried into a downstream repository.

1. Push changes to the PR branch and open the pull request when it does not exist.
2. Run `scripts/pr_review.py status` once in the foreground and read its output.
3. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
 explicitly (mechanics in the Copilot runbook). The UI is a fallback only.
3. Wait for review activity on that head. A completed review raising **no findings** is a valid
 terminal outcome, so don't re-trigger it or read silence as a missing review. A review whose
 body says it declined to review is the one exception, and it is terminal the other way:
 nothing follows it, and re-requesting the same head just repeats the decline.
4. Triage findings (see below).
5. Apply fixes or write a rationale for declines.
6. Reply to each thread and resolve what was addressed.
7. Re-run the loop after every fix push until no actionable finding remains.
4. Run a bounded `scripts/pr_review.py wait` in a background process and read its terminal output.
Comment thread
ptr727 marked this conversation as resolved.

 A completed review raising **no findings** is a valid terminal outcome, so do not re-trigger it
 or read silence as a missing review. A review whose body says it declined to review is the one
 exception, and it is terminal the other way. Nothing follows it, and re-requesting the same
 head only repeats the decline.
5. Triage findings (see below).
6. Apply fixes or write a rationale for declines.
7. Reply to each thread and resolve what was addressed.
8. Re-run the loop after every fix push until the checks are green and no finding remains open.

Drive to green, a review confirmed on the latest head SHA and every actionable finding closed,
then apply the Merge Gate above. **Never exit the loop early.** A round count is not a stopping
condition, and neither is patience running out.
condition, and neither is patience running out. Reporting only that the PR was opened is an early
exit unless the maintainer explicitly instructed the agent not to monitor or drive its review.

## Every finding ends in one of five outcomes

Expand Down

22 changes: 13 additions & 9 deletions
.github/skills/python-codestyle/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -5,13 +5,14 @@ description: >-
 profile split, the uv/ruff/pyright/mypy/pytest toolchain, src layout, formatting and linting,
 comment and docstring conventions, type hints, naming, imports, patterns to avoid, test
 conventions, and versioning. Use this whenever writing, reviewing, or editing a .py file, a
 pyproject.toml, or a uv.lock, whenever deciding whether a Python subtree is a shippable project
 or a lint-only scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or
 whenever writing or reviewing a pytest test. Triggers even when the task looks like a small
 local fix ("just add a helper function", "silence this lint warning", "add a dependency"),
 because the profile split, the ruff-is-authoritative rule, and the ban on backward-compat
 shims or impossible-case error handling are each easy to violate one file at a time. Applies
 only to a repo's Python side, a repo with no Python has no use for this Skill.
 pyproject.toml, or a uv.lock, whenever running or choosing a Python formatting, lint, type-check,
 or test command, whenever deciding whether a Python subtree is a shippable project or a lint-only
 scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or whenever writing or
 reviewing a Python test. Triggers even when the task looks like a small local fix ("just add a
 helper function", "silence this lint warning", "add a dependency") or verification step ("run
 the tests"), because choosing pytest before reading the profile turns an intentional unittest
 suite into a false missing-dependency diagnosis. Applies only to a repo's Python side, a repo
 with no Python has no use for this Skill.
---

# Python Codestyle
Expand All@@ -26,11 +27,14 @@ profiles, the toolchain, layout, and the language-level conventions.

## Two profiles

Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
Read the repo's `OPERATIONS.md` local-verification commands before substituting a generic command.
Then read the `pyproject.toml` shape and pick the profile before running Python tooling or tests:

- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
 pyright strict (or mypy where the repo requires it).
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx` for third-party tools, unittest
 for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
 defect. Use the repository's exact coverage command and unittest scope from `OPERATIONS.md`.

For the full profile specification and per-repo adaptation axes (type checker, dependency
declaration, versioning, VS Code config), see `references/profiles.md`.
Expand Down

34 changes: 27 additions & 7 deletions
.github/skills/repo-worktree/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -8,13 +8,14 @@ description: >-
 branch a tool defaulted to), with a standalone-clone fallback when an executor cannot write
 both the standard worktree and its Git metadata. Also wraps the mechanics:
 creating a worktree with git worktree add, the fleet layout convention, listing what is in
 flight, and removing a worktree and its branch after merge. Use this whenever about to create
 or edit files in a fleet repo, whenever starting or resuming a task, whenever the task's
 branch is already checked out in a shared checkout, and whenever creating, listing, or
 removing a worktree. Triggers even when the session was launched in the primary checkout or
 the change looks like a one-line fix, because the primary checkout is the maintainer's own
 surface and the incident this guards against was two sessions sharing one checkout, each
 session's blanket add committing the other's uncommitted files.
 flight, preparing Husky.Net or Python pre-commit hooks in the new tree, and removing a
 worktree and its branch after merge. Use this whenever about to create or edit files in a
 fleet repo, whenever starting or resuming a task, whenever the task's branch is already
 checked out in a shared checkout, and whenever creating, listing, or removing a worktree.
 Triggers even when the session was launched in the primary checkout or the change looks like
 a one-line fix, because the primary checkout is the maintainer's own surface and the incident
 this guards against was two sessions sharing one checkout, each session's blanket add
 committing the other's uncommitted files.
---

# Repo Worktree
Expand DownExpand Up@@ -150,6 +151,25 @@ a `name`, it creates the worktree under `.claude/worktrees/` inside the repo and
GitHub default branch, which is the wrong path and the wrong base here. Create the worktree with
`git worktree add` as above, then attach with `EnterWorktree` `path:`, not `name:`.

## Preparing Git Hooks

A new worktree holds tracked hook configuration but not every generated hook runtime. Prepare
the hooks immediately after creating or attaching the worktree, before the first commit. A
shared `core.hooksPath` value does not make generated files such as `.husky/_/husky.sh` appear
in the new tree.

- **Husky.Net:** When `.husky/pre-commit` sources `.husky/_/husky.sh` and the local .NET tool
 manifest declares Husky.Net, run `dotnet tool restore`, then `dotnet husky install` from the
 worktree root.
- **Python pre-commit:** When `.pre-commit-config.yaml` exists, install the repository's declared
 Python environment, then run `pre-commit install` through that environment. A uv project runs
 `uv sync --frozen`, then `uv run pre-commit install`.
- **Repository override:** Follow a repository's explicit hook-setup instructions when they
 differ from these standard cases. Do not infer a replacement command from the language alone.

Treat hook preparation as worktree setup, not as recovery after a rejected commit. If setup
fails, report that boundary and fix the setup. Never bypass the hook to make the commit succeed.

## Listing and Cleanup

- `git worktree list`, run in any checkout of a repo, names that repo's base clone and every
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
Sync Carried Fleet Skills#69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

ptr727
merged 3 commits into

from

Aug 18, 2026
 Merged


Sync Carried Fleet Skills
#69
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


3 commits


Select commit
Hold shift + click to select a range
e633b3f

Sync Carried Fleet Skills


ptr727 Aug 18, 2026
21c4cae

Clarify Carried Review Helper Location


ptr727 Aug 18, 2026
734fa68

Combine Carried Review Wait Steps


ptr727 Aug 18, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


41 changes: 26 additions & 15 deletions
.github/skills/pr-review-conduct/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4,10 +4,11 @@ description: >-
 Governs opening, driving, and merging a pull request review loop in a ptr727/ProjectTemplate
 fleet repo: requesting a review after a push, triaging findings (including suppressed
 low-confidence ones), replying and resolving threads, and deciding whether a PR is actually
 mergeable. Use this whenever about to merge a PR, enable auto-merge, ask the maintainer for
 merge permission, push a fix and move on without re-checking review state, or judge a PR
 "green" or "clean" from CI or mergeStateStatus alone. Triggers even when the request sounds
 routine, such as "merge this" or "it's all green, go ahead," because mergeStateStatus: CLEAN
 mergeable. Use this whenever about to open a PR, immediately after creating one, about to merge
 a PR, enable auto-merge, ask the maintainer for merge permission, push a fix and move on without
 re-checking review state, or judge a PR "green" or "clean" from CI or mergeStateStatus alone.
 Triggers even when the request sounds routine, such as "open a PR," "merge this," or "it's all
 green, go ahead," because PR creation starts the review loop and mergeStateStatus: CLEAN
 can go clean once checks pass and every known thread is resolved, while still saying nothing
 about whether the review that resolved those threads covered the current head SHA, read the
 full diff, or left a suppressed low-confidence finding, which opens no thread at all,
Expand DownExpand Up@@ -56,21 +57,31 @@ full stop, whatever the merge-state field says.

## Expected review loop

1. Push changes to the PR branch.
2. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
Opening a pull request starts this loop by default. Creating the PR is not a terminal handoff.
Only an explicit maintainer instruction may stop, defer, or alter the loop. A draft state, silence,
or a request that says only "open a PR" is not such an instruction.

Run every `scripts/pr_review.py` command below from a hub checkout. The script is hosted there and
is never carried into a downstream repository.

1. Push changes to the PR branch and open the pull request when it does not exist.
2. Run `scripts/pr_review.py status` once in the foreground and read its output.
3. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
 explicitly (mechanics in the Copilot runbook). The UI is a fallback only.
3. Wait for review activity on that head. A completed review raising **no findings** is a valid
 terminal outcome, so don't re-trigger it or read silence as a missing review. A review whose
 body says it declined to review is the one exception, and it is terminal the other way:
 nothing follows it, and re-requesting the same head just repeats the decline.
4. Triage findings (see below).
5. Apply fixes or write a rationale for declines.
6. Reply to each thread and resolve what was addressed.
7. Re-run the loop after every fix push until no actionable finding remains.
4. Run a bounded `scripts/pr_review.py wait` in a background process and read its terminal output.
Comment thread
ptr727 marked this conversation as resolved.

 A completed review raising **no findings** is a valid terminal outcome, so do not re-trigger it
 or read silence as a missing review. A review whose body says it declined to review is the one
 exception, and it is terminal the other way. Nothing follows it, and re-requesting the same
 head only repeats the decline.
5. Triage findings (see below).
6. Apply fixes or write a rationale for declines.
7. Reply to each thread and resolve what was addressed.
8. Re-run the loop after every fix push until the checks are green and no finding remains open.

Drive to green, a review confirmed on the latest head SHA and every actionable finding closed,
then apply the Merge Gate above. **Never exit the loop early.** A round count is not a stopping
condition, and neither is patience running out.
condition, and neither is patience running out. Reporting only that the PR was opened is an early
exit unless the maintainer explicitly instructed the agent not to monitor or drive its review.

## Every finding ends in one of five outcomes

Expand Down

22 changes: 13 additions & 9 deletions
.github/skills/python-codestyle/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -5,13 +5,14 @@ description: >-
 profile split, the uv/ruff/pyright/mypy/pytest toolchain, src layout, formatting and linting,
 comment and docstring conventions, type hints, naming, imports, patterns to avoid, test
 conventions, and versioning. Use this whenever writing, reviewing, or editing a .py file, a
 pyproject.toml, or a uv.lock, whenever deciding whether a Python subtree is a shippable project
 or a lint-only scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or
 whenever writing or reviewing a pytest test. Triggers even when the task looks like a small
 local fix ("just add a helper function", "silence this lint warning", "add a dependency"),
 because the profile split, the ruff-is-authoritative rule, and the ban on backward-compat
 shims or impossible-case error handling are each easy to violate one file at a time. Applies
 only to a repo's Python side, a repo with no Python has no use for this Skill.
 pyproject.toml, or a uv.lock, whenever running or choosing a Python formatting, lint, type-check,
 or test command, whenever deciding whether a Python subtree is a shippable project or a lint-only
 scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or whenever writing or
 reviewing a Python test. Triggers even when the task looks like a small local fix ("just add a
 helper function", "silence this lint warning", "add a dependency") or verification step ("run
 the tests"), because choosing pytest before reading the profile turns an intentional unittest
 suite into a false missing-dependency diagnosis. Applies only to a repo's Python side, a repo
 with no Python has no use for this Skill.
---

# Python Codestyle
Expand All@@ -26,11 +27,14 @@ profiles, the toolchain, layout, and the language-level conventions.

## Two profiles

Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
Read the repo's `OPERATIONS.md` local-verification commands before substituting a generic command.
Then read the `pyproject.toml` shape and pick the profile before running Python tooling or tests:

- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
 pyright strict (or mypy where the repo requires it).
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx` for third-party tools, unittest
 for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
 defect. Use the repository's exact coverage command and unittest scope from `OPERATIONS.md`.

For the full profile specification and per-repo adaptation axes (type checker, dependency
declaration, versioning, VS Code config), see `references/profiles.md`.
Expand Down

34 changes: 27 additions & 7 deletions
.github/skills/repo-worktree/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -8,13 +8,14 @@ description: >-
 branch a tool defaulted to), with a standalone-clone fallback when an executor cannot write
 both the standard worktree and its Git metadata. Also wraps the mechanics:
 creating a worktree with git worktree add, the fleet layout convention, listing what is in
 flight, and removing a worktree and its branch after merge. Use this whenever about to create
 or edit files in a fleet repo, whenever starting or resuming a task, whenever the task's
 branch is already checked out in a shared checkout, and whenever creating, listing, or
 removing a worktree. Triggers even when the session was launched in the primary checkout or
 the change looks like a one-line fix, because the primary checkout is the maintainer's own
 surface and the incident this guards against was two sessions sharing one checkout, each
 session's blanket add committing the other's uncommitted files.
 flight, preparing Husky.Net or Python pre-commit hooks in the new tree, and removing a
 worktree and its branch after merge. Use this whenever about to create or edit files in a
 fleet repo, whenever starting or resuming a task, whenever the task's branch is already
 checked out in a shared checkout, and whenever creating, listing, or removing a worktree.
 Triggers even when the session was launched in the primary checkout or the change looks like
 a one-line fix, because the primary checkout is the maintainer's own surface and the incident
 this guards against was two sessions sharing one checkout, each session's blanket add
 committing the other's uncommitted files.
---

# Repo Worktree
Expand DownExpand Up@@ -150,6 +151,25 @@ a `name`, it creates the worktree under `.claude/worktrees/` inside the repo and
GitHub default branch, which is the wrong path and the wrong base here. Create the worktree with
`git worktree add` as above, then attach with `EnterWorktree` `path:`, not `name:`.

## Preparing Git Hooks

A new worktree holds tracked hook configuration but not every generated hook runtime. Prepare
the hooks immediately after creating or attaching the worktree, before the first commit. A
shared `core.hooksPath` value does not make generated files such as `.husky/_/husky.sh` appear
in the new tree.

- **Husky.Net:** When `.husky/pre-commit` sources `.husky/_/husky.sh` and the local .NET tool
 manifest declares Husky.Net, run `dotnet tool restore`, then `dotnet husky install` from the
 worktree root.
- **Python pre-commit:** When `.pre-commit-config.yaml` exists, install the repository's declared
 Python environment, then run `pre-commit install` through that environment. A uv project runs
 `uv sync --frozen`, then `uv run pre-commit install`.
- **Repository override:** Follow a repository's explicit hook-setup instructions when they
 differ from these standard cases. Do not infer a replacement command from the language alone.

Treat hook preparation as worktree setup, not as recovery after a rejected commit. If setup
fails, report that boundary and fix the setup. Never bypass the hook to make the commit succeed.

## Listing and Cleanup

- `git worktree list`, run in any checkout of a repo, names that repo's base clone and every
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Sync Carried Fleet Skills#69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

ptr727
merged 3 commits into

from

Aug 18, 2026
 Merged


Sync Carried Fleet Skills
#69
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


3 commits


Select commit
Hold shift + click to select a range
e633b3f

Sync Carried Fleet Skills


ptr727 Aug 18, 2026
21c4cae

Clarify Carried Review Helper Location


ptr727 Aug 18, 2026
734fa68

Combine Carried Review Wait Steps


ptr727 Aug 18, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


41 changes: 26 additions & 15 deletions
.github/skills/pr-review-conduct/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4,10 +4,11 @@ description: >-
 Governs opening, driving, and merging a pull request review loop in a ptr727/ProjectTemplate
 fleet repo: requesting a review after a push, triaging findings (including suppressed
 low-confidence ones), replying and resolving threads, and deciding whether a PR is actually
 mergeable. Use this whenever about to merge a PR, enable auto-merge, ask the maintainer for
 merge permission, push a fix and move on without re-checking review state, or judge a PR
 "green" or "clean" from CI or mergeStateStatus alone. Triggers even when the request sounds
 routine, such as "merge this" or "it's all green, go ahead," because mergeStateStatus: CLEAN
 mergeable. Use this whenever about to open a PR, immediately after creating one, about to merge
 a PR, enable auto-merge, ask the maintainer for merge permission, push a fix and move on without
 re-checking review state, or judge a PR "green" or "clean" from CI or mergeStateStatus alone.
 Triggers even when the request sounds routine, such as "open a PR," "merge this," or "it's all
 green, go ahead," because PR creation starts the review loop and mergeStateStatus: CLEAN
 can go clean once checks pass and every known thread is resolved, while still saying nothing
 about whether the review that resolved those threads covered the current head SHA, read the
 full diff, or left a suppressed low-confidence finding, which opens no thread at all,
Expand DownExpand Up@@ -56,21 +57,31 @@ full stop, whatever the merge-state field says.

## Expected review loop

1. Push changes to the PR branch.
2. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
Opening a pull request starts this loop by default. Creating the PR is not a terminal handoff.
Only an explicit maintainer instruction may stop, defer, or alter the loop. A draft state, silence,
or a request that says only "open a PR" is not such an instruction.

Run every `scripts/pr_review.py` command below from a hub checkout. The script is hosted there and
is never carried into a downstream repository.

1. Push changes to the PR branch and open the pull request when it does not exist.
2. Run `scripts/pr_review.py status` once in the foreground and read its output.
3. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
 explicitly (mechanics in the Copilot runbook). The UI is a fallback only.
3. Wait for review activity on that head. A completed review raising **no findings** is a valid
 terminal outcome, so don't re-trigger it or read silence as a missing review. A review whose
 body says it declined to review is the one exception, and it is terminal the other way:
 nothing follows it, and re-requesting the same head just repeats the decline.
4. Triage findings (see below).
5. Apply fixes or write a rationale for declines.
6. Reply to each thread and resolve what was addressed.
7. Re-run the loop after every fix push until no actionable finding remains.
4. Run a bounded `scripts/pr_review.py wait` in a background process and read its terminal output.
Comment thread
ptr727 marked this conversation as resolved.

 A completed review raising **no findings** is a valid terminal outcome, so do not re-trigger it
 or read silence as a missing review. A review whose body says it declined to review is the one
 exception, and it is terminal the other way. Nothing follows it, and re-requesting the same
 head only repeats the decline.
5. Triage findings (see below).
6. Apply fixes or write a rationale for declines.
7. Reply to each thread and resolve what was addressed.
8. Re-run the loop after every fix push until the checks are green and no finding remains open.

Drive to green, a review confirmed on the latest head SHA and every actionable finding closed,
then apply the Merge Gate above. **Never exit the loop early.** A round count is not a stopping
condition, and neither is patience running out.
condition, and neither is patience running out. Reporting only that the PR was opened is an early
exit unless the maintainer explicitly instructed the agent not to monitor or drive its review.

## Every finding ends in one of five outcomes

Expand Down

22 changes: 13 additions & 9 deletions
.github/skills/python-codestyle/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -5,13 +5,14 @@ description: >-
 profile split, the uv/ruff/pyright/mypy/pytest toolchain, src layout, formatting and linting,
 comment and docstring conventions, type hints, naming, imports, patterns to avoid, test
 conventions, and versioning. Use this whenever writing, reviewing, or editing a .py file, a
 pyproject.toml, or a uv.lock, whenever deciding whether a Python subtree is a shippable project
 or a lint-only scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or
 whenever writing or reviewing a pytest test. Triggers even when the task looks like a small
 local fix ("just add a helper function", "silence this lint warning", "add a dependency"),
 because the profile split, the ruff-is-authoritative rule, and the ban on backward-compat
 shims or impossible-case error handling are each easy to violate one file at a time. Applies
 only to a repo's Python side, a repo with no Python has no use for this Skill.
 pyproject.toml, or a uv.lock, whenever running or choosing a Python formatting, lint, type-check,
 or test command, whenever deciding whether a Python subtree is a shippable project or a lint-only
 scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or whenever writing or
 reviewing a Python test. Triggers even when the task looks like a small local fix ("just add a
 helper function", "silence this lint warning", "add a dependency") or verification step ("run
 the tests"), because choosing pytest before reading the profile turns an intentional unittest
 suite into a false missing-dependency diagnosis. Applies only to a repo's Python side, a repo
 with no Python has no use for this Skill.
---

# Python Codestyle
Expand All@@ -26,11 +27,14 @@ profiles, the toolchain, layout, and the language-level conventions.

## Two profiles

Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
Read the repo's `OPERATIONS.md` local-verification commands before substituting a generic command.
Then read the `pyproject.toml` shape and pick the profile before running Python tooling or tests:

- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
 pyright strict (or mypy where the repo requires it).
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx` for third-party tools, unittest
 for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
 defect. Use the repository's exact coverage command and unittest scope from `OPERATIONS.md`.

For the full profile specification and per-repo adaptation axes (type checker, dependency
declaration, versioning, VS Code config), see `references/profiles.md`.
Expand Down

34 changes: 27 additions & 7 deletions
.github/skills/repo-worktree/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -8,13 +8,14 @@ description: >-
 branch a tool defaulted to), with a standalone-clone fallback when an executor cannot write
 both the standard worktree and its Git metadata. Also wraps the mechanics:
 creating a worktree with git worktree add, the fleet layout convention, listing what is in
 flight, and removing a worktree and its branch after merge. Use this whenever about to create
 or edit files in a fleet repo, whenever starting or resuming a task, whenever the task's
 branch is already checked out in a shared checkout, and whenever creating, listing, or
 removing a worktree. Triggers even when the session was launched in the primary checkout or
 the change looks like a one-line fix, because the primary checkout is the maintainer's own
 surface and the incident this guards against was two sessions sharing one checkout, each
 session's blanket add committing the other's uncommitted files.
 flight, preparing Husky.Net or Python pre-commit hooks in the new tree, and removing a
 worktree and its branch after merge. Use this whenever about to create or edit files in a
 fleet repo, whenever starting or resuming a task, whenever the task's branch is already
 checked out in a shared checkout, and whenever creating, listing, or removing a worktree.
 Triggers even when the session was launched in the primary checkout or the change looks like
 a one-line fix, because the primary checkout is the maintainer's own surface and the incident
 this guards against was two sessions sharing one checkout, each session's blanket add
 committing the other's uncommitted files.
---

# Repo Worktree
Expand DownExpand Up@@ -150,6 +151,25 @@ a `name`, it creates the worktree under `.claude/worktrees/` inside the repo and
GitHub default branch, which is the wrong path and the wrong base here. Create the worktree with
`git worktree add` as above, then attach with `EnterWorktree` `path:`, not `name:`.

## Preparing Git Hooks

A new worktree holds tracked hook configuration but not every generated hook runtime. Prepare
the hooks immediately after creating or attaching the worktree, before the first commit. A
shared `core.hooksPath` value does not make generated files such as `.husky/_/husky.sh` appear
in the new tree.

- **Husky.Net:** When `.husky/pre-commit` sources `.husky/_/husky.sh` and the local .NET tool
 manifest declares Husky.Net, run `dotnet tool restore`, then `dotnet husky install` from the
 worktree root.
- **Python pre-commit:** When `.pre-commit-config.yaml` exists, install the repository's declared
 Python environment, then run `pre-commit install` through that environment. A uv project runs
 `uv sync --frozen`, then `uv run pre-commit install`.
- **Repository override:** Follow a repository's explicit hook-setup instructions when they
 differ from these standard cases. Do not infer a replacement command from the language alone.

Treat hook preparation as worktree setup, not as recovery after a rejected commit. If setup
fails, report that boundary and fix the setup. Never bypass the hook to make the commit succeed.

## Listing and Cleanup

- `git worktree list`, run in any checkout of a repo, names that repo's base clone and every
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
Sync Carried Fleet Skills#69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

ptr727
merged 3 commits into

from

Aug 18, 2026
 Merged


Sync Carried Fleet Skills
#69
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


3 commits


Select commit
Hold shift + click to select a range
e633b3f

Sync Carried Fleet Skills


ptr727 Aug 18, 2026
21c4cae

Clarify Carried Review Helper Location


ptr727 Aug 18, 2026
734fa68

Combine Carried Review Wait Steps


ptr727 Aug 18, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


41 changes: 26 additions & 15 deletions
.github/skills/pr-review-conduct/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4,10 +4,11 @@ description: >-
 Governs opening, driving, and merging a pull request review loop in a ptr727/ProjectTemplate
 fleet repo: requesting a review after a push, triaging findings (including suppressed
 low-confidence ones), replying and resolving threads, and deciding whether a PR is actually
 mergeable. Use this whenever about to merge a PR, enable auto-merge, ask the maintainer for
 merge permission, push a fix and move on without re-checking review state, or judge a PR
 "green" or "clean" from CI or mergeStateStatus alone. Triggers even when the request sounds
 routine, such as "merge this" or "it's all green, go ahead," because mergeStateStatus: CLEAN
 mergeable. Use this whenever about to open a PR, immediately after creating one, about to merge
 a PR, enable auto-merge, ask the maintainer for merge permission, push a fix and move on without
 re-checking review state, or judge a PR "green" or "clean" from CI or mergeStateStatus alone.
 Triggers even when the request sounds routine, such as "open a PR," "merge this," or "it's all
 green, go ahead," because PR creation starts the review loop and mergeStateStatus: CLEAN
 can go clean once checks pass and every known thread is resolved, while still saying nothing
 about whether the review that resolved those threads covered the current head SHA, read the
 full diff, or left a suppressed low-confidence finding, which opens no thread at all,
Expand DownExpand Up@@ -56,21 +57,31 @@ full stop, whatever the merge-state field says.

## Expected review loop

1. Push changes to the PR branch.
2. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
Opening a pull request starts this loop by default. Creating the PR is not a terminal handoff.
Only an explicit maintainer instruction may stop, defer, or alter the loop. A draft state, silence,
or a request that says only "open a PR" is not such an instruction.

Run every `scripts/pr_review.py` command below from a hub checkout. The script is hosted there and
is never carried into a downstream repository.

1. Push changes to the PR branch and open the pull request when it does not exist.
2. Run `scripts/pr_review.py status` once in the foreground and read its output.
3. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
 explicitly (mechanics in the Copilot runbook). The UI is a fallback only.
3. Wait for review activity on that head. A completed review raising **no findings** is a valid
 terminal outcome, so don't re-trigger it or read silence as a missing review. A review whose
 body says it declined to review is the one exception, and it is terminal the other way:
 nothing follows it, and re-requesting the same head just repeats the decline.
4. Triage findings (see below).
5. Apply fixes or write a rationale for declines.
6. Reply to each thread and resolve what was addressed.
7. Re-run the loop after every fix push until no actionable finding remains.
4. Run a bounded `scripts/pr_review.py wait` in a background process and read its terminal output.
Comment thread
ptr727 marked this conversation as resolved.

 A completed review raising **no findings** is a valid terminal outcome, so do not re-trigger it
 or read silence as a missing review. A review whose body says it declined to review is the one
 exception, and it is terminal the other way. Nothing follows it, and re-requesting the same
 head only repeats the decline.
5. Triage findings (see below).
6. Apply fixes or write a rationale for declines.
7. Reply to each thread and resolve what was addressed.
8. Re-run the loop after every fix push until the checks are green and no finding remains open.

Drive to green, a review confirmed on the latest head SHA and every actionable finding closed,
then apply the Merge Gate above. **Never exit the loop early.** A round count is not a stopping
condition, and neither is patience running out.
condition, and neither is patience running out. Reporting only that the PR was opened is an early
exit unless the maintainer explicitly instructed the agent not to monitor or drive its review.

## Every finding ends in one of five outcomes

Expand Down

22 changes: 13 additions & 9 deletions
.github/skills/python-codestyle/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -5,13 +5,14 @@ description: >-
 profile split, the uv/ruff/pyright/mypy/pytest toolchain, src layout, formatting and linting,
 comment and docstring conventions, type hints, naming, imports, patterns to avoid, test
 conventions, and versioning. Use this whenever writing, reviewing, or editing a .py file, a
 pyproject.toml, or a uv.lock, whenever deciding whether a Python subtree is a shippable project
 or a lint-only scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or
 whenever writing or reviewing a pytest test. Triggers even when the task looks like a small
 local fix ("just add a helper function", "silence this lint warning", "add a dependency"),
 because the profile split, the ruff-is-authoritative rule, and the ban on backward-compat
 shims or impossible-case error handling are each easy to violate one file at a time. Applies
 only to a repo's Python side, a repo with no Python has no use for this Skill.
 pyproject.toml, or a uv.lock, whenever running or choosing a Python formatting, lint, type-check,
 or test command, whenever deciding whether a Python subtree is a shippable project or a lint-only
 scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or whenever writing or
 reviewing a Python test. Triggers even when the task looks like a small local fix ("just add a
 helper function", "silence this lint warning", "add a dependency") or verification step ("run
 the tests"), because choosing pytest before reading the profile turns an intentional unittest
 suite into a false missing-dependency diagnosis. Applies only to a repo's Python side, a repo
 with no Python has no use for this Skill.
---

# Python Codestyle
Expand All@@ -26,11 +27,14 @@ profiles, the toolchain, layout, and the language-level conventions.

## Two profiles

Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
Read the repo's `OPERATIONS.md` local-verification commands before substituting a generic command.
Then read the `pyproject.toml` shape and pick the profile before running Python tooling or tests:

- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
 pyright strict (or mypy where the repo requires it).
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx` for third-party tools, unittest
 for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
 defect. Use the repository's exact coverage command and unittest scope from `OPERATIONS.md`.

For the full profile specification and per-repo adaptation axes (type checker, dependency
declaration, versioning, VS Code config), see `references/profiles.md`.
Expand Down

34 changes: 27 additions & 7 deletions
.github/skills/repo-worktree/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -8,13 +8,14 @@ description: >-
 branch a tool defaulted to), with a standalone-clone fallback when an executor cannot write
 both the standard worktree and its Git metadata. Also wraps the mechanics:
 creating a worktree with git worktree add, the fleet layout convention, listing what is in
 flight, and removing a worktree and its branch after merge. Use this whenever about to create
 or edit files in a fleet repo, whenever starting or resuming a task, whenever the task's
 branch is already checked out in a shared checkout, and whenever creating, listing, or
 removing a worktree. Triggers even when the session was launched in the primary checkout or
 the change looks like a one-line fix, because the primary checkout is the maintainer's own
 surface and the incident this guards against was two sessions sharing one checkout, each
 session's blanket add committing the other's uncommitted files.
 flight, preparing Husky.Net or Python pre-commit hooks in the new tree, and removing a
 worktree and its branch after merge. Use this whenever about to create or edit files in a
 fleet repo, whenever starting or resuming a task, whenever the task's branch is already
 checked out in a shared checkout, and whenever creating, listing, or removing a worktree.
 Triggers even when the session was launched in the primary checkout or the change looks like
 a one-line fix, because the primary checkout is the maintainer's own surface and the incident
 this guards against was two sessions sharing one checkout, each session's blanket add
 committing the other's uncommitted files.
---

# Repo Worktree
Expand DownExpand Up@@ -150,6 +151,25 @@ a `name`, it creates the worktree under `.claude/worktrees/` inside the repo and
GitHub default branch, which is the wrong path and the wrong base here. Create the worktree with
`git worktree add` as above, then attach with `EnterWorktree` `path:`, not `name:`.

## Preparing Git Hooks

A new worktree holds tracked hook configuration but not every generated hook runtime. Prepare
the hooks immediately after creating or attaching the worktree, before the first commit. A
shared `core.hooksPath` value does not make generated files such as `.husky/_/husky.sh` appear
in the new tree.

- **Husky.Net:** When `.husky/pre-commit` sources `.husky/_/husky.sh` and the local .NET tool
 manifest declares Husky.Net, run `dotnet tool restore`, then `dotnet husky install` from the
 worktree root.
- **Python pre-commit:** When `.pre-commit-config.yaml` exists, install the repository's declared
 Python environment, then run `pre-commit install` through that environment. A uv project runs
 `uv sync --frozen`, then `uv run pre-commit install`.
- **Repository override:** Follow a repository's explicit hook-setup instructions when they
 differ from these standard cases. Do not infer a replacement command from the language alone.

Treat hook preparation as worktree setup, not as recovery after a rejected commit. If setup
fails, report that boundary and fix the setup. Never bypass the hook to make the commit succeed.

## Listing and Cleanup

- `git worktree list`, run in any checkout of a repo, names that repo's base clone and every
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
Sync Carried Fleet Skills#69

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Merged

ptr727
merged 3 commits into

from

Aug 18, 2026
 Merged


Sync Carried Fleet Skills
#69
Show file tree
Hide file tree
 Changes from all commits
Commits

Show all changes


3 commits


Select commit
Hold shift + click to select a range
e633b3f

Sync Carried Fleet Skills


ptr727 Aug 18, 2026
21c4cae

Clarify Carried Review Helper Location


ptr727 Aug 18, 2026
734fa68

Combine Carried Review Wait Steps


ptr727 Aug 18, 2026

File filter

Filter by extension
Filter by extension
Conversations

Failed to load comments. 
Loading
Jump to

Jump to file


Failed to load files. 
Loading
 Diff view

 Diff view


41 changes: 26 additions & 15 deletions
.github/skills/pr-review-conduct/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -4,10 +4,11 @@ description: >-
 Governs opening, driving, and merging a pull request review loop in a ptr727/ProjectTemplate
 fleet repo: requesting a review after a push, triaging findings (including suppressed
 low-confidence ones), replying and resolving threads, and deciding whether a PR is actually
 mergeable. Use this whenever about to merge a PR, enable auto-merge, ask the maintainer for
 merge permission, push a fix and move on without re-checking review state, or judge a PR
 "green" or "clean" from CI or mergeStateStatus alone. Triggers even when the request sounds
 routine, such as "merge this" or "it's all green, go ahead," because mergeStateStatus: CLEAN
 mergeable. Use this whenever about to open a PR, immediately after creating one, about to merge
 a PR, enable auto-merge, ask the maintainer for merge permission, push a fix and move on without
 re-checking review state, or judge a PR "green" or "clean" from CI or mergeStateStatus alone.
 Triggers even when the request sounds routine, such as "open a PR," "merge this," or "it's all
 green, go ahead," because PR creation starts the review loop and mergeStateStatus: CLEAN
 can go clean once checks pass and every known thread is resolved, while still saying nothing
 about whether the review that resolved those threads covered the current head SHA, read the
 full diff, or left a suppressed low-confidence finding, which opens no thread at all,
Expand DownExpand Up@@ -56,21 +57,31 @@ full stop, whatever the merge-state field says.

## Expected review loop

1. Push changes to the PR branch.
2. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
Opening a pull request starts this loop by default. Creating the PR is not a terminal handoff.
Only an explicit maintainer instruction may stop, defer, or alter the loop. A draft state, silence,
or a request that says only "open a PR" is not such an instruction.

Run every `scripts/pr_review.py` command below from a hub checkout. The script is hosted there and
is never carried into a downstream repository.

1. Push changes to the PR branch and open the pull request when it does not exist.
2. Run `scripts/pr_review.py status` once in the foreground and read its output.
3. Re-request a review for the **current head SHA**. Auto-trigger is unreliable, so request it
 explicitly (mechanics in the Copilot runbook). The UI is a fallback only.
3. Wait for review activity on that head. A completed review raising **no findings** is a valid
 terminal outcome, so don't re-trigger it or read silence as a missing review. A review whose
 body says it declined to review is the one exception, and it is terminal the other way:
 nothing follows it, and re-requesting the same head just repeats the decline.
4. Triage findings (see below).
5. Apply fixes or write a rationale for declines.
6. Reply to each thread and resolve what was addressed.
7. Re-run the loop after every fix push until no actionable finding remains.
4. Run a bounded `scripts/pr_review.py wait` in a background process and read its terminal output.
Comment thread
ptr727 marked this conversation as resolved.

 A completed review raising **no findings** is a valid terminal outcome, so do not re-trigger it
 or read silence as a missing review. A review whose body says it declined to review is the one
 exception, and it is terminal the other way. Nothing follows it, and re-requesting the same
 head only repeats the decline.
5. Triage findings (see below).
6. Apply fixes or write a rationale for declines.
7. Reply to each thread and resolve what was addressed.
8. Re-run the loop after every fix push until the checks are green and no finding remains open.

Drive to green, a review confirmed on the latest head SHA and every actionable finding closed,
then apply the Merge Gate above. **Never exit the loop early.** A round count is not a stopping
condition, and neither is patience running out.
condition, and neither is patience running out. Reporting only that the PR was opened is an early
exit unless the maintainer explicitly instructed the agent not to monitor or drive its review.

## Every finding ends in one of five outcomes

Expand Down

22 changes: 13 additions & 9 deletions
.github/skills/python-codestyle/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -5,13 +5,14 @@ description: >-
 profile split, the uv/ruff/pyright/mypy/pytest toolchain, src layout, formatting and linting,
 comment and docstring conventions, type hints, naming, imports, patterns to avoid, test
 conventions, and versioning. Use this whenever writing, reviewing, or editing a .py file, a
 pyproject.toml, or a uv.lock, whenever deciding whether a Python subtree is a shippable project
 or a lint-only scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or
 whenever writing or reviewing a pytest test. Triggers even when the task looks like a small
 local fix ("just add a helper function", "silence this lint warning", "add a dependency"),
 because the profile split, the ruff-is-authoritative rule, and the ban on backward-compat
 shims or impossible-case error handling are each easy to violate one file at a time. Applies
 only to a repo's Python side, a repo with no Python has no use for this Skill.
 pyproject.toml, or a uv.lock, whenever running or choosing a Python formatting, lint, type-check,
 or test command, whenever deciding whether a Python subtree is a shippable project or a lint-only
 scripts tree, whenever choosing pyright versus mypy for a repo's CI gate, or whenever writing or
 reviewing a Python test. Triggers even when the task looks like a small local fix ("just add a
 helper function", "silence this lint warning", "add a dependency") or verification step ("run
 the tests"), because choosing pytest before reading the profile turns an intentional unittest
 suite into a false missing-dependency diagnosis. Applies only to a repo's Python side, a repo
 with no Python has no use for this Skill.
---

# Python Codestyle
Expand All@@ -26,11 +27,14 @@ profiles, the toolchain, layout, and the language-level conventions.

## Two profiles

Read the repo's `pyproject.toml` shape and pick the profile before applying any other rule:
Read the repo's `OPERATIONS.md` local-verification commands before substituting a generic command.
Then read the `pyproject.toml` shape and pick the profile before running Python tooling or tests:

- **build** (Project): `[project]` + `[build-system]` + committed `uv.lock`. Uses `uv run`, pytest,
 pyright strict (or mypy where the repo requires it).
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx`, unittest, mypy as CI gate.
- **lint-only** (Scripts): no `[project]`, no lockfile. Uses `uvx` for third-party tools, unittest
 for tests, and mypy as the CI gate. Do not run pytest or diagnose its absence as an environment
 defect. Use the repository's exact coverage command and unittest scope from `OPERATIONS.md`.

For the full profile specification and per-repo adaptation axes (type checker, dependency
declaration, versioning, VS Code config), see `references/profiles.md`.
Expand Down

34 changes: 27 additions & 7 deletions
.github/skills/repo-worktree/SKILL.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -8,13 +8,14 @@ description: >-
 branch a tool defaulted to), with a standalone-clone fallback when an executor cannot write
 both the standard worktree and its Git metadata. Also wraps the mechanics:
 creating a worktree with git worktree add, the fleet layout convention, listing what is in
 flight, and removing a worktree and its branch after merge. Use this whenever about to create
 or edit files in a fleet repo, whenever starting or resuming a task, whenever the task's
 branch is already checked out in a shared checkout, and whenever creating, listing, or
 removing a worktree. Triggers even when the session was launched in the primary checkout or
 the change looks like a one-line fix, because the primary checkout is the maintainer's own
 surface and the incident this guards against was two sessions sharing one checkout, each
 session's blanket add committing the other's uncommitted files.
 flight, preparing Husky.Net or Python pre-commit hooks in the new tree, and removing a
 worktree and its branch after merge. Use this whenever about to create or edit files in a
 fleet repo, whenever starting or resuming a task, whenever the task's branch is already
 checked out in a shared checkout, and whenever creating, listing, or removing a worktree.
 Triggers even when the session was launched in the primary checkout or the change looks like
 a one-line fix, because the primary checkout is the maintainer's own surface and the incident
 this guards against was two sessions sharing one checkout, each session's blanket add
 committing the other's uncommitted files.
---

# Repo Worktree
Expand DownExpand Up@@ -150,6 +151,25 @@ a `name`, it creates the worktree under `.claude/worktrees/` inside the repo and
GitHub default branch, which is the wrong path and the wrong base here. Create the worktree with
`git worktree add` as above, then attach with `EnterWorktree` `path:`, not `name:`.

## Preparing Git Hooks

A new worktree holds tracked hook configuration but not every generated hook runtime. Prepare
the hooks immediately after creating or attaching the worktree, before the first commit. A
shared `core.hooksPath` value does not make generated files such as `.husky/_/husky.sh` appear
in the new tree.

- **Husky.Net:** When `.husky/pre-commit` sources `.husky/_/husky.sh` and the local .NET tool
 manifest declares Husky.Net, run `dotnet tool restore`, then `dotnet husky install` from the
 worktree root.
- **Python pre-commit:** When `.pre-commit-config.yaml` exists, install the repository's declared
 Python environment, then run `pre-commit install` through that environment. A uv project runs
 `uv sync --frozen`, then `uv run pre-commit install`.
- **Repository override:** Follow a repository's explicit hook-setup instructions when they
 differ from these standard cases. Do not infer a replacement command from the language alone.

Treat hook preparation as worktree setup, not as recovery after a rejected commit. If setup
fails, report that boundary and fix the setup. Never bypass the hook to make the commit succeed.

## Listing and Cleanup

- `git worktree list`, run in any checkout of a repo, names that repo's base clone and every
Expand Down