Skip to content

Commit ee20cbc

Browse files
Bill Leoutsakoscursoragent
authored and
Bill Leoutsakos
committed
chore(e2e): finalize staging handoff
Replace milestone-only records with evergreen maintenance guidance, add the reviewed development workflow, and restore CI and Greptile targets to protected branches. Co-authored-by: Cursor <cursoragent@cursor.com>
1 parent fea201b commit ee20cbc

14 files changed

Lines changed: 543 additions & 249 deletions

File tree

‎.agents/skills/add-settings-e2e-test/SKILL.md‎

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -14,11 +14,9 @@ or spec owns the behavior.
1414

1515
1. `apps/sim/e2e/MAINTENANCE.md` — change type to contract/spec ownership.
1616
2. `apps/sim/e2e/README.md` — orchestrator, project boundaries, focused commands,
17-
diagnostics, and CI policy.
18-
3. `apps/sim/e2e/STABILIZATION.md` — non-waivable acceptance and security
19-
boundaries.
17+
diagnostics, acceptance and security boundaries, and CI policy.
2018

21-
Those files are canonical. This skill is the authoring procedure, not a second
19+
Both files are canonical. This skill is the authoring procedure, not a second
2220
copy of their inventories or commands. If this procedure ever conflicts with a
2321
canonical document, the canonical document wins.
2422

‎.agents/skills/reviewed-development/IMPLEMENTATION.md‎

Lines changed: 139 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,139 @@
1+
# Implementation Mode
2+
3+
Implement the requested change completely, validate it in proportion to risk,
4+
and subject the current result to repeated independent review before delivery.
5+
6+
## 1. Confirm the implementation contract
7+
8+
Read the accepted plan, current user request, relevant repository instructions,
9+
and current branch state. Establish:
10+
11+
- Objective, scope, non-goals, and definition of done.
12+
- Files and systems expected to change.
13+
- Tests, rollout, documentation, and manual acceptance required.
14+
- Whether commit, push, branch, or PR operations were explicitly authorized.
15+
- Existing user changes that must be preserved.
16+
17+
If the plan has become stale, verify the current repository and adapt it
18+
carefully. Escalate only decisions that materially change product behavior,
19+
risk, or destructive outcomes.
20+
21+
## 2. Re-ground in current code
22+
23+
Inspect the implementation paths and nearest established patterns before
24+
editing. Do not rely solely on summaries or the plan's file list. Check for
25+
changes made since planning, hidden coupling, generated artifacts, migration
26+
rules, and repository-specific validation commands.
27+
28+
Create a concise execution checklist for substantial work. Implement in
29+
coherent phases, keeping only one phase actively changing the repository at a
30+
time.
31+
32+
## 3. Implement the smallest complete solution
33+
34+
- Follow existing architecture, naming, contracts, and ownership boundaries.
35+
- Address root causes instead of suppressing failures or adding broad
36+
workarounds.
37+
- Keep security, authorization, data integrity, secret handling, and cleanup
38+
fail-closed.
39+
- Preserve backward compatibility and safe rollout ordering where versions can
40+
overlap.
41+
- Avoid unrelated cleanup, speculative abstraction, duplicate helpers, and
42+
infrastructure without a demonstrated need.
43+
- Update tests and documentation alongside the behavior they protect.
44+
45+
Do not weaken invariants or tests merely to obtain a passing result.
46+
47+
## 4. Verify continuously
48+
49+
After each meaningful phase, run the cheapest relevant proof. Before review,
50+
run the complete validation justified by the change, such as:
51+
52+
- Focused unit and integration tests.
53+
- Type checking, linting, formatting, generated-file, and boundary checks.
54+
- Migration, deployment, or compatibility verification.
55+
- Browser or end-to-end tests through the project's supported orchestrator.
56+
- Manual checks that cannot be automated.
57+
58+
Read failures as evidence. Fix introduced problems, distinguish unrelated
59+
baseline failures explicitly, and do not report a check as passed unless it
60+
actually ran successfully.
61+
62+
## 5. Self-review the current diff
63+
64+
Before commissioning reviewers:
65+
66+
- Compare the implementation with every plan requirement.
67+
- Inspect the full diff, including generated and staged files.
68+
- Check edge cases, negative paths, concurrency, partial failure, and cleanup.
69+
- Confirm tests prove observable behavior rather than implementation details.
70+
- Remove accidental duplication, debugging output, dead code, and unnecessary
71+
complexity.
72+
- Verify no credentials, local artifacts, or unrelated user changes entered the
73+
diff.
74+
75+
## 6. Commission independent reviews
76+
77+
Generate two complete, neutral prompts from the current task, plan, repository,
78+
implementation, diff, and verification evidence according to the
79+
independent-review protocol. Launch two fresh reviewers concurrently when
80+
possible.
81+
82+
Do not ask reviewers to validate the parent's preferred approach. Ask for their
83+
genuine assessment of correctness, security, pattern fit, test quality,
84+
maintainability, redundancy, overengineering, operational safety, and complete
85+
coverage of the user's objective.
86+
87+
Reviewers must inspect the repository directly and remain read-only.
88+
89+
## 7. Triage, fix, and re-verify
90+
91+
Independently verify every finding:
92+
93+
- Fix valid issues with the smallest clean solution that matches repository
94+
patterns.
95+
- Push back on false positives or harmful suggestions with concrete evidence.
96+
- Resolve contradictions by examining code and requirements, not by choosing
97+
the more confident reviewer.
98+
- Re-run all checks affected by substantive changes.
99+
- Resume each reviewer separately with the current implementation and the
100+
response to its findings. Continue until it accepts the resolution or the
101+
protocol's unresolved-disagreement stop condition applies.
102+
103+
Do not tell the other reviewer or reviewers in later cycles what an earlier
104+
agent found.
105+
106+
## 8. Re-review the current implementation
107+
108+
Generate fresh prompts describing only the current objective, code, diff, and
109+
evidence. Begin another independent review cycle with an entirely new pair.
110+
Never reuse reviewers from an earlier cycle.
111+
112+
If this review causes substantive edits, reviewers disagree materially, or
113+
meaningful uncertainty remains, run one additional fresh pair after
114+
re-verification, subject to the protocol's three-cycle cap. The final accepted
115+
review must apply to the implementation being delivered.
116+
117+
## 9. Delivery gate
118+
119+
Do not declare completion until:
120+
121+
- The implementation satisfies the current plan and definition of done.
122+
- Relevant automated checks pass, with manual-only checks identified.
123+
- No Critical, High, or Medium concern remains unresolved without an explicit,
124+
evidence-backed decision.
125+
- The final substantive revision has been independently reviewed.
126+
- The diff is scoped, clean, and free of secrets or temporary artifacts.
127+
128+
Commit, push, or create a PR only if the user's request authorized those
129+
mutations. Follow repository-specific git and PR procedures rather than
130+
inventing a generic release flow.
131+
132+
Report concisely:
133+
134+
- What changed and why.
135+
- Verification performed and outcomes.
136+
- Material issues found and corrected.
137+
- Evidence-backed pushbacks.
138+
- Remaining manual actions or known limitations.
139+
- Commit, branch, or PR details when delivery was authorized.

‎.agents/skills/reviewed-development/INDEPENDENT_REVIEW.md‎

Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
# Independent Review Protocol
2+
3+
This protocol defines how the working model commissions independent reviews. It
4+
is not a reviewer prompt template.
5+
6+
Every reviewer in this protocol is a separate subagent launched by the working
7+
model, not a perspective role-played in the parent conversation. In Cursor, use
8+
the `Subagent` tool. A fresh reviewer means a new subagent invocation and agent
9+
ID; a follow-up within the same review cycle resumes that subagent's existing
10+
conversation.
11+
12+
## Generate prompts from the current task
13+
14+
Generate each reviewer prompt after inspecting the current repository and
15+
artifact. The prompt must be self-contained because a fresh reviewer has no
16+
access to the parent conversation.
17+
18+
Include the context that materially affects the review:
19+
20+
- A concise overview of the relevant codebase and architecture.
21+
- The user's actual objective, constraints, non-goals, and definition of done.
22+
- The current plan, diff, branch, or exact files to inspect.
23+
- Established local patterns and sources of truth the work should follow.
24+
- Important data, security, migration, deployment, or compatibility boundaries.
25+
- Verification already performed, with exact commands and outcomes when useful.
26+
- The areas changed and the behavior they are intended to provide.
27+
28+
Generate the prompt for the task at hand. Do not copy a fixed generic prompt or
29+
fill a mechanical template with shallow substitutions.
30+
31+
## Keep every review independent
32+
33+
- Begin each independent review cycle with two fresh reviewers, preferably from
34+
different model families with strong reasoning capability. Honor models
35+
requested by the user.
36+
- During that cycle, resume each reviewer separately to resolve its findings.
37+
Never reuse either conversation in a later independent review cycle.
38+
- Do not tell a reviewer whether it belongs to the first, second, final, or any
39+
other review pass.
40+
- The initial prompt in a cycle must not include findings, verdicts, responses,
41+
or changes from earlier cycles.
42+
- Do not tell reviewers what conclusion to reach or imply that defects must
43+
exist. Acceptance is a valid result.
44+
- Use the same generated prompt for both reviewers by default. Differ only when
45+
a model requires different technical context or tooling instructions, while
46+
keeping both reviews broad and neutral.
47+
- Ask reviewers to inspect repository evidence directly rather than trusting the
48+
implementation summary.
49+
- Keep reviewers read-only unless the user explicitly requested a separate
50+
implementation attempt.
51+
52+
## Ask for a genuine broad review
53+
54+
Ask each reviewer to judge the artifact as a whole and report anything it
55+
genuinely dislikes. The review should consider, where relevant:
56+
57+
- Correctness, requirement coverage, and edge cases.
58+
- Security, privacy, data integrity, authorization, and secret handling.
59+
- Concurrency, failure recovery, cleanup, and partial-success behavior.
60+
- Compatibility with existing architecture, conventions, and nearby patterns.
61+
- Missing, brittle, redundant, or misleading tests.
62+
- Unnecessary complexity, duplicated logic, speculative abstraction, and
63+
overengineering.
64+
- Performance, operational, migration, rollout, and CI consequences.
65+
- Documentation and manual steps required for safe ownership after merge.
66+
67+
This is a review surface, not a quota. Explicitly tell reviewers that acceptance,
68+
many findings, or anything between are valid outcomes. They must not optimize
69+
for finding count or manufacture criticism.
70+
71+
## Severity and response format
72+
73+
Require an explicit verdict and order concrete findings by severity:
74+
75+
- **Critical**: credible security compromise, data loss, destructive rollout,
76+
or another issue that makes proceeding unsafe.
77+
- **High**: likely correctness failure, unmet core requirement, serious
78+
architectural mismatch, or major operational risk.
79+
- **Medium**: material robustness, maintainability, test, performance, or
80+
pattern-consistency issue that should be resolved.
81+
- **Small**: non-blocking polish or a narrowly scoped improvement.
82+
83+
Each finding must include:
84+
85+
- Concrete repository evidence, preferably a file and line or exact behavior.
86+
- Why it matters and when it can fail.
87+
- The smallest appropriate correction or decision needed.
88+
89+
If no substantive defect exists, the reviewer should say that plainly rather
90+
than manufacture criticism.
91+
92+
## Triage without deference
93+
94+
The working model owns the result. For every finding:
95+
96+
1. Verify it against the repository and the user's objective.
97+
2. Fix it when it is correct and within scope.
98+
3. Push back when it is incorrect, conflicts with requirements, or would add
99+
unjustified complexity; retain the evidence for the final summary.
100+
4. Re-run affected verification after substantive changes.
101+
5. Resume that reviewer with the current artifact and an evidence-based account
102+
of what changed or why the finding was rejected.
103+
104+
Handle each reviewer independently; do not use one reviewer's opinion to steer
105+
the other. Continue the exchange until the reviewer accepts the resolution or
106+
has no substantive concern. Ask it to re-inspect the current artifact rather
107+
than merely approve the parent's explanation.
108+
109+
Agreement does not mean obeying the reviewer. A valid endpoint may be a fix or
110+
an evidence-backed pushback that the reviewer accepts. Follow-ups within a
111+
review cycle are not capped: continue the separate exchange with each reviewer
112+
until the concern is resolved. The three-cycle cap limits newly created reviewer
113+
pairs, not follow-up messages in an active cycle.
114+
115+
Do not forward this cycle's triage history to reviewers in later cycles. Their
116+
initial prompts describe only the current artifact and current evidence.
117+
118+
## Review completion
119+
120+
Run two independent review cycles by default. Each cycle begins with exactly two
121+
newly created reviewers, and each reviewer reaches resolution through the
122+
follow-up process above. Track cycle count only in the working session; never
123+
expose it in reviewer prompts.
124+
125+
Run one additional cycle only when the later cycle causes substantive changes,
126+
reviewers disagree on a material issue, or meaningful uncertainty remains.
127+
Never exceed three cycles or six fresh reviewers for one planning or
128+
implementation task.
129+
130+
After the third cycle, stop even if a reviewer still disagrees. Report the
131+
unresolved concern, evidence, attempted resolution, and available decision to
132+
the user rather than launching more reviewers. The final reviewed artifact must
133+
be the artifact being presented or shipped, not an earlier revision.

0 commit comments

Comments
 (0)