You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit fcf9fe0
Browse filesBrowse the repository at this point in the historyBrowse files
Merge main; Claude history is windowed by memory, not 200 messages
main now reads long Claude sessions through a window of the latest 200
messages (#29183). Keep that window but bound it by the 32 MiB history
budget instead, so sessions that fit import in full and longer ones drop
their oldest messages, with the truncation notice, instead of being skipped.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Copy file name to clipboardExpand all lines: .agents/skills/contribution-triage/SKILL.md
+31-30Lines changed: 31 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,13 +71,12 @@ from evidence you could not access. Do not run untrusted PR code merely to decid
71
71
Read the guide's linked sections before applying these checks. Inspect enough source to substantiate
72
72
scope and behavioral claims; leave the full correctness, security, and performance audit to code review.
73
73
74
-
- Under [prior approval](../../../CONTRIBUTING.md#prior-approval), identify the actual failure and
75
-
intended behavior. Inspect maintainer responses in the linked issue or discussion, including what
76
-
direction and scope they approved. A link, label, or acknowledgment alone is not approval. Judge a
77
-
claimed obvious-bug exception by purpose, impact, and necessary changes, without numeric cutoffs.
78
-
Separately assess focused configuration of an established capability: identify what already exists,
79
-
what the option controls, and its effects and necessary scope. This route does not require a proven
80
-
obvious bug. Adding a setting alone establishes neither a new feature nor an approval exemption.
74
+
- Under [fix a bug](../../../CONTRIBUTING.md#prior-approval), identify the actual failure and
75
+
intended behavior. A feature, or anything on the guide's not-interested list, warrants closure
76
+
unless a maintainer in the trusted exemption list asked for that PR. Inspect the request and the
77
+
direction and scope it covers. A link, label, or acknowledgment alone is not a request. Judge a
78
+
claimed bug fix by purpose, impact, and necessary changes, without numeric cutoffs. A setting that
79
+
adds a workflow or changes a default is a feature.
81
80
Check whether an alleged fix intentionally changes product behavior or overlooks an existing workflow.
82
81
Preserve any useful documentation, onboarding, or discoverability problem when declining the solution.
83
82
- Under [one problem](../../../CONTRIBUTING.md#one-problem), trace how each material change contributes
@@ -90,27 +89,18 @@ scope and behavioral claims; leave the full correctness, security, and performan
90
89
as the guide requires them. Do not demand unrelated evidence or repo-wide tests. An unavailable local
91
90
platform does not defeat adequate contributor evidence. Do not infer fabrication or AI authorship
92
91
from writing style, suspicion, or a check you cannot reproduce.
92
+
- Under [models](../../../CONTRIBUTING.md#models), use only the model and harness the PR names,
93
+
usually in its closing attribution line.
93
94
94
-
### Configuration and workflow examples
95
-
96
-
- Hosting CLI-path configuration in [#11653](https://github.com/pingdotgg/t3code/pull/11653) is eligible
97
-
for deeper review under the maintainer's ruling: it makes an existing capability configurable.
98
-
It need not qualify as an obvious-bug repair or obtain prior feature approval on that basis.
99
-
Still assess one underlying problem, necessary scope and credible verification. Deeper review can
100
-
reject the configuration mechanism or its implementation.
101
-
- Preserving Files as an independent tab in [#14436](https://github.com/pingdotgg/t3code/pull/14436)
102
-
changes tab lifetime and navigation. The maintainer classified it as a broader workflow change
103
-
requiring prior product-direction approval, which is absent. Propose closure for missing approval
104
-
in a dry run, or carry out closure in authorized enforcement. Its good evidence does not make it
105
-
eligible or justify keeping it pending after that ruling. The remedy is to obtain scope approval.
106
-
107
-
Use these examples to distinguish effects, not to exempt every configuration option. Apply current
108
-
trusted policy and reassess changed submission evidence; neither example grants permanent eligibility.
95
+
Bans in the guide are a maintainer decision. Report suspected spam to maintainers; do not ban or
96
+
threaten a ban.
109
97
110
98
## Apply the outcome
111
99
112
100
Do not automatically close a PR if a maintainer in the trusted `TRIAGE_EXEMPTIONS.td` list has
113
101
commented or submitted a review, including on earlier heads, or if `triage:keep-open` is present.
102
+
Comments that triage itself posted, such as an earlier notice or question, are not maintainer
103
+
involvement, even when they were posted from a maintainer's account on that maintainer's behalf.
114
104
Leave protected PRs open for maintainer decision. This does not grant an author exemption,
115
105
eligibility, or review approval.
116
106
@@ -126,20 +116,30 @@ comment text but do not write to GitHub. Keep the eligibility finding separate f
126
116
This is a routing exception, not a claim that the PR passed eligibility or correctness review.
127
117
-**Closure warranted.** The assessment is complete and establishes a specific policy violation.
128
118
Prepare a clear explanation under [closure and reconsideration](../../../CONTRIBUTING.md#closure-and-reconsideration),
129
-
post it, and close the PR. Verify that the explanation is present and the PR is closed. The comment
119
+
post it, then read the repository variable `PR_LIMITS_ENFORCE`
120
+
(`gh variable get PR_LIMITS_ENFORCE -R pingdotgg/t3code`). When it prints `true`, apply
121
+
`triage:closing` as the last thing you do to the PR, verify that the explanation and the label
122
+
are present, and do not close the PR yourself:
123
+
[pr-limits.yml](../../../.github/workflows/pr-limits.yml) closes it 72 hours after the label. Any
124
+
activity on the PR after the label, including a further comment or label from you, removes the
125
+
label; treat an author's reply or push as new evidence, reassess, and apply the label again only
126
+
if the finding still holds. When the command prints any other value, or fails saying the variable
127
+
was not found, the variable is off and nothing would close a labeled PR: close it yourself and
128
+
verify that the explanation is present and the PR is closed. Only another failure, such as a
129
+
permission error, means the variable cannot be read; then report the closure as incomplete. The comment
130
130
must name the violated rule, cite supporting submission evidence, link the maintained guide section,
131
131
and give a concrete remedy. Missing contributor evidence can warrant closure; explain what must be
132
-
established. Missing product approval calls for maintainer discussion, not an agent's product decision.
132
+
established. The remedy for a feature is an Ideas discussion, not an agent's product decision.
133
133
Close for multiple problems only when the independence of those changes is supported. Closing a PR
134
134
does not require a configured Macroscope label.
135
135
-**Needs explanation or maintainer decision.** Name the unresolved question and who can resolve it.
136
136
Post the specific question on the PR when commenting is within the authorized scope, and verify it
137
137
was posted. If tracing the source leaves an extra diff's necessity unclear, request the causal
138
138
explanation needed. If established facts leave a product-direction choice to maintainers, identify
139
139
that choice. Leave the PR open and pending that answer; do not mark it eligible. Do not substitute
140
-
"the agent was uncertain" for a violated rule. Once maintainers establish that a workflow change
141
-
requires approval and that approval is absent, apply the closure outcome instead of retaining a
142
-
pending classification. Good verification does not cure missing approval.
140
+
"the agent was uncertain" for a violated rule. Once a change is established as a feature with no
141
+
maintainer request, apply the closure outcome instead of retaining a pending classification. Good
142
+
verification does not make a feature eligible.
143
143
-**Incomplete; retry required.** State the failed retrieval, missing access, truncated diff, or unfinished
144
144
assessment and what is needed to resume. Do not convert operational failures into policy violations
145
145
or hand the PR off as having passed. An inaccessible artifact is different from an omitted artifact.
0 commit comments