feat(pi): Babysit foundations — shared PR/push extraction, five GitHub tools, sandbox lifetime

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

@@ -0,0 +1,139 @@
+# Implementation Mode
+
+Implement the requested change completely, validate it in proportion to risk,
+and subject the current result to repeated independent review before delivery.
+
+## 1. Confirm the implementation contract
+
+Read the accepted plan, current user request, relevant repository instructions,
+and current branch state. Establish:
+
+- Objective, scope, non-goals, and definition of done.
+- Files and systems expected to change.
+- Tests, rollout, documentation, and manual acceptance required.
+- Whether commit, push, branch, or PR operations were explicitly authorized.
+- Existing user changes that must be preserved.
+
+If the plan has become stale, verify the current repository and adapt it
+carefully. Escalate only decisions that materially change product behavior,
+risk, or destructive outcomes.
+
+## 2. Re-ground in current code
+
+Inspect the implementation paths and nearest established patterns before
+editing. Do not rely solely on summaries or the plan's file list. Check for
+changes made since planning, hidden coupling, generated artifacts, migration
+rules, and repository-specific validation commands.
+
+Create a concise execution checklist for substantial work. Implement in
+coherent phases, keeping only one phase actively changing the repository at a
+time.
+
+## 3. Implement the smallest complete solution
+
+- Follow existing architecture, naming, contracts, and ownership boundaries.
+- Address root causes instead of suppressing failures or adding broad
+  workarounds.
+- Keep security, authorization, data integrity, secret handling, and cleanup
+  fail-closed.
+- Preserve backward compatibility and safe rollout ordering where versions can
+  overlap.
+- Avoid unrelated cleanup, speculative abstraction, duplicate helpers, and
+  infrastructure without a demonstrated need.
+- Update tests and documentation alongside the behavior they protect.
+
+Do not weaken invariants or tests merely to obtain a passing result.
+
+## 4. Verify continuously
+
+After each meaningful phase, run the cheapest relevant proof. Before review,
+run the complete validation justified by the change, such as:
+
+- Focused unit and integration tests.
+- Type checking, linting, formatting, generated-file, and boundary checks.
+- Migration, deployment, or compatibility verification.
+- Browser or end-to-end tests through the project's supported orchestrator.
+- Manual checks that cannot be automated.
+
+Read failures as evidence. Fix introduced problems, distinguish unrelated
+baseline failures explicitly, and do not report a check as passed unless it
+actually ran successfully.
+
+## 5. Self-review the current diff
+
+Before commissioning reviewers:
+
+- Compare the implementation with every plan requirement.
+- Inspect the full diff, including generated and staged files.
+- Check edge cases, negative paths, concurrency, partial failure, and cleanup.
+- Confirm tests prove observable behavior rather than implementation details.
+- Remove accidental duplication, debugging output, dead code, and unnecessary
+  complexity.
+- Verify no credentials, local artifacts, or unrelated user changes entered the
+  diff.
+
+## 6. Commission independent reviews
+
+Generate two complete, neutral prompts from the current task, plan, repository,
+implementation, diff, and verification evidence according to the
+independent-review protocol. Launch two fresh reviewers concurrently when
+possible.
+
+Do not ask reviewers to validate the parent's preferred approach. Ask for their
+genuine assessment of correctness, security, pattern fit, test quality,
+maintainability, redundancy, overengineering, operational safety, and complete
+coverage of the user's objective.
+
+Reviewers must inspect the repository directly and remain read-only.
+
+## 7. Triage, fix, and re-verify
+
+Independently verify every finding:
+
+- Fix valid issues with the smallest clean solution that matches repository
+  patterns.
+- Push back on false positives or harmful suggestions with concrete evidence.
+- Resolve contradictions by examining code and requirements, not by choosing
+  the more confident reviewer.
+- Re-run all checks affected by substantive changes.
+- Resume each reviewer separately with the current implementation and the
+  response to its findings. Continue until it accepts the resolution or the
+  protocol's unresolved-disagreement stop condition applies.
+
+Do not tell the other reviewer or reviewers in later cycles what an earlier
+agent found.
+
+## 8. Re-review the current implementation
+
+Generate fresh prompts describing only the current objective, code, diff, and
+evidence. Begin another independent review cycle with an entirely new pair.
+Never reuse reviewers from an earlier cycle.
+
+If this review causes substantive edits, reviewers disagree materially, or
+meaningful uncertainty remains, run one additional fresh pair after
+re-verification, subject to the protocol's three-cycle cap. The final accepted
+review must apply to the implementation being delivered.
+
+## 9. Delivery gate
+
+Do not declare completion until:
+
+- The implementation satisfies the current plan and definition of done.
+- Relevant automated checks pass, with manual-only checks identified.
+- No Critical, High, or Medium concern remains unresolved without an explicit,
+  evidence-backed decision.
+- The final substantive revision has been independently reviewed.
+- The diff is scoped, clean, and free of secrets or temporary artifacts.
+
+Commit, push, or create a PR only if the user's request authorized those
+mutations. Follow repository-specific git and PR procedures rather than
+inventing a generic release flow.
+
+Report concisely:
+
+- What changed and why.
+- Verification performed and outcomes.
+- Material issues found and corrected.
+- Evidence-backed pushbacks.
+- Remaining manual actions or known limitations.
+- Commit, branch, or PR details when delivery was authorized.

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

@@ -0,0 +1,133 @@
+# Independent Review Protocol
+
+This protocol defines how the working model commissions independent reviews. It
+is not a reviewer prompt template.
+
+Every reviewer in this protocol is a separate subagent launched by the working
+model, not a perspective role-played in the parent conversation. In Cursor, use
+the `Subagent` tool. A fresh reviewer means a new subagent invocation and agent
+ID; a follow-up within the same review cycle resumes that subagent's existing
+conversation.
+
+## Generate prompts from the current task
+
+Generate each reviewer prompt after inspecting the current repository and
+artifact. The prompt must be self-contained because a fresh reviewer has no
+access to the parent conversation.
+
+Include the context that materially affects the review:
+
+- A concise overview of the relevant codebase and architecture.
+- The user's actual objective, constraints, non-goals, and definition of done.
+- The current plan, diff, branch, or exact files to inspect.
+- Established local patterns and sources of truth the work should follow.
+- Important data, security, migration, deployment, or compatibility boundaries.
+- Verification already performed, with exact commands and outcomes when useful.
+- The areas changed and the behavior they are intended to provide.
+
+Generate the prompt for the task at hand. Do not copy a fixed generic prompt or
+fill a mechanical template with shallow substitutions.
+
+## Keep every review independent
+
+- Begin each independent review cycle with two fresh reviewers, preferably from
+  different model families with strong reasoning capability. Honor models
+  requested by the user.
+- During that cycle, resume each reviewer separately to resolve its findings.
+  Never reuse either conversation in a later independent review cycle.
+- Do not tell a reviewer whether it belongs to the first, second, final, or any
+  other review pass.
+- The initial prompt in a cycle must not include findings, verdicts, responses,
+  or changes from earlier cycles.
+- Do not tell reviewers what conclusion to reach or imply that defects must
+  exist. Acceptance is a valid result.
+- Use the same generated prompt for both reviewers by default. Differ only when
+  a model requires different technical context or tooling instructions, while
+  keeping both reviews broad and neutral.
+- Ask reviewers to inspect repository evidence directly rather than trusting the
+  implementation summary.
+- Keep reviewers read-only unless the user explicitly requested a separate
+  implementation attempt.
+
+## Ask for a genuine broad review
+
+Ask each reviewer to judge the artifact as a whole and report anything it
+genuinely dislikes. The review should consider, where relevant:
+
+- Correctness, requirement coverage, and edge cases.
+- Security, privacy, data integrity, authorization, and secret handling.
+- Concurrency, failure recovery, cleanup, and partial-success behavior.
+- Compatibility with existing architecture, conventions, and nearby patterns.
+- Missing, brittle, redundant, or misleading tests.
+- Unnecessary complexity, duplicated logic, speculative abstraction, and
+  overengineering.
+- Performance, operational, migration, rollout, and CI consequences.
+- Documentation and manual steps required for safe ownership after merge.
+
+This is a review surface, not a quota. Explicitly tell reviewers that acceptance,
+many findings, or anything between are valid outcomes. They must not optimize
+for finding count or manufacture criticism.
+
+## Severity and response format
+
+Require an explicit verdict and order concrete findings by severity:
+
+- **Critical**: credible security compromise, data loss, destructive rollout,
+  or another issue that makes proceeding unsafe.
+- **High**: likely correctness failure, unmet core requirement, serious
+  architectural mismatch, or major operational risk.
+- **Medium**: material robustness, maintainability, test, performance, or
+  pattern-consistency issue that should be resolved.
+- **Small**: non-blocking polish or a narrowly scoped improvement.
+
+Each finding must include:
+
+- Concrete repository evidence, preferably a file and line or exact behavior.
+- Why it matters and when it can fail.
+- The smallest appropriate correction or decision needed.
+
+If no substantive defect exists, the reviewer should say that plainly rather
+than manufacture criticism.
+
+## Triage without deference
+
+The working model owns the result. For every finding:
+
+1. Verify it against the repository and the user's objective.
+2. Fix it when it is correct and within scope.
+3. Push back when it is incorrect, conflicts with requirements, or would add
+   unjustified complexity; retain the evidence for the final summary.
+4. Re-run affected verification after substantive changes.
+5. Resume that reviewer with the current artifact and an evidence-based account
+   of what changed or why the finding was rejected.
+
+Handle each reviewer independently; do not use one reviewer's opinion to steer
+the other. Continue the exchange until the reviewer accepts the resolution or
+has no substantive concern. Ask it to re-inspect the current artifact rather
+than merely approve the parent's explanation.
+
+Agreement does not mean obeying the reviewer. A valid endpoint may be a fix or
+an evidence-backed pushback that the reviewer accepts. Follow-ups within a
+review cycle are not capped: continue the separate exchange with each reviewer
+until the concern is resolved. The three-cycle cap limits newly created reviewer
+pairs, not follow-up messages in an active cycle.
+
+Do not forward this cycle's triage history to reviewers in later cycles. Their
+initial prompts describe only the current artifact and current evidence.
+
+## Review completion
+
+Run two independent review cycles by default. Each cycle begins with exactly two
+newly created reviewers, and each reviewer reaches resolution through the
+follow-up process above. Track cycle count only in the working session; never
+expose it in reviewer prompts.
+
+Run one additional cycle only when the later cycle causes substantive changes,
+reviewers disagree on a material issue, or meaningful uncertainty remains.
+Never exceed three cycles or six fresh reviewers for one planning or
+implementation task.
+
+After the third cycle, stop even if a reviewer still disagrees. Report the
+unresolved concern, evidence, attempted resolution, and available decision to
+the user rather than launching more reviewers. The final reviewed artifact must
+be the artifact being presented or shipped, not an earlier revision.

.agents/skills/reviewed-development/PLANNING.md

@@ -0,0 +1,118 @@
+# Planning Mode
+
+Create a plan that is grounded in the current repository, independently
+challenged, and ready for another agent or engineer to implement. End with the
+reviewed plan; do not implement product changes.
+
+## 1. Establish the real objective
+
+Derive or confirm:
+
+- The user-visible or operational outcome.
+- Scope, non-goals, constraints, and compatibility requirements.
+- Definition of done, including executable proof and any manual acceptance.
+- Delivery boundaries such as migrations, rollout order, CI, documentation,
+  deployment configuration, or branch strategy.
+- Decisions that genuinely belong to the user.
+
+Do not mechanically accept assumptions in the request. Verify claims where the
+repository can answer them, and ask only for choices that materially alter the
+result.
+
+## 2. Explore before designing
+
+Inspect enough of the repository to understand:
+
+- Current architecture and data flow.
+- Canonical sources of truth and nearby implementations.
+- Existing tests, fixtures, validation, observability, and deployment patterns.
+- Historical compatibility surfaces that cannot be changed atomically.
+- Work already present on the branch and unrelated changes that must remain
+  untouched.
+
+Use parallel exploration when areas are independent. The parent model remains
+responsible for synthesis; do not delegate the entire planning task to one
+subagent.
+
+## 3. Draft an implementation-ready plan
+
+Write the plan for the actual task rather than forcing a universal template.
+Include the following when relevant:
+
+- Goal and definition of done.
+- Current behavior and evidence.
+- Technical direction and why it fits existing patterns.
+- Concrete files, modules, interfaces, and data flows to change.
+- Sequenced implementation phases and dependencies.
+- Authorization, security, privacy, secret, and trust boundaries.
+- Schema, migration, compatibility, rollout, and rollback considerations.
+- Test strategy at unit, integration, browser, CI, and manual levels.
+- Diagnostics and cleanup behavior.
+- Documentation and ownership updates.
+- Explicit non-goals, assumptions, risks, and unresolved user decisions.
+
+Prefer the smallest complete design. Avoid speculative frameworks, duplicated
+sources of truth, compatibility layers without a consumer, and cleanup unrelated
+to the objective.
+
+## 4. Commission independent reviews
+
+Generate self-contained prompts from the current repository and plan according
+to the independent-review protocol. Launch two fresh reviewers concurrently
+when possible. Do not assign one a desired conclusion or narrow each reviewer
+to a concern chosen by the parent; both should be free to assess the whole plan, and should be asked for their genuine opinion, whether this is that everything is perfect, we 're almost there, or everything is terrible and the direction should be completely changed.
+
+Ask reviewers to verify the proposed design against real code and identify
+mistakes, missing requirements, pattern mismatches, unsafe assumptions,
+overengineering, redundancy, weak proof, and anything else they genuinely
+dislike.
+
+## 5. Triage and refine
+
+For each finding:
+
+- Confirm the evidence yourself.
+- Improve the plan when the concern is valid.
+- Push back with concrete technical reasoning when it is not.
+- Ask the user only when the finding exposes a real product or risk decision
+  that the repository cannot resolve.
+- Resume each reviewer separately with the revised plan and the response to its
+  findings. Continue until it accepts the resolution or the protocol's
+  unresolved-disagreement stop condition applies.
+
+Preserve useful dissent in the working notes, but do not bias later reviewers
+with earlier opinions or describe the plan as already corrected.
+
+## 6. Re-review the current plan
+
+After refinement, generate new neutral context from the current repository and
+current plan. Begin another independent review cycle with an entirely new pair.
+Never reuse reviewers from an earlier cycle.
+
+If this review leads to substantive plan changes, material disagreement, or
+unresolved uncertainty, repeat once with another fresh pair, subject to the
+protocol's three-cycle cap. Each reviewer sees only the present task and
+artifact, never the review sequence.
+
+## 7. Finalize without implementing
+
+Before presenting or saving the plan, ensure:
+
+- Every core requirement maps to a concrete change and proof.
+- File and architecture references match the current repository.
+- Migration and rollout ordering is safe.
+- Tests cover allowed, denied, failure, and cleanup behavior where applicable.
+- No Critical, High, or Medium concern remains unresolved without an explicit,
+  evidence-backed decision.
+- The final substantive revision has been independently reviewed.
+
+Save the plan only where the user or project convention requires. Report:
+
+- The finalized plan location or plan itself.
+- Important decisions and tradeoffs.
+- Material reviewer-driven changes.
+- Evidence-backed pushbacks.
+- User-owned or manual steps that remain.
+
+Stop there. Implementation requires a separate request using this skill's
+implementation mode.