@hienlh/ppm 0.9.81 → 0.9.83

package/.opencode/skills/code-review/references/code-review-reception.md

@@ -1,209 +0,0 @@
----
-name: receiving-code-review
-description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
----
-
-# Code Review Reception
-
-## Overview
-
-Code review requires technical evaluation, not emotional performance.
-
-**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.
-
-## The Response Pattern
-
-```
-WHEN receiving code review feedback:
-
-1. READ: Complete feedback without reacting
-2. UNDERSTAND: Restate requirement in own words (or ask)
-3. VERIFY: Check against codebase reality
-4. EVALUATE: Technically sound for THIS codebase?
-5. RESPOND: Technical acknowledgment or reasoned pushback
-6. IMPLEMENT: One item at a time, test each
-```
-
-## Forbidden Responses
-
-**NEVER:**
-- "You're absolutely right!" (explicit CLAUDE.md violation)
-- "Great point!" / "Excellent feedback!" (performative)
-- "Let me implement that now" (before verification)
-
-**INSTEAD:**
-- Restate the technical requirement
-- Ask clarifying questions
-- Push back with technical reasoning if wrong
-- Just start working (actions > words)
-
-## Handling Unclear Feedback
-
-```
-IF any item is unclear:
-  STOP - do not implement anything yet
-  ASK for clarification on unclear items
-
-WHY: Items may be related. Partial understanding = wrong implementation.
-```
-
-**Example:**
-```
-your human partner: "Fix 1-6"
-You understand 1,2,3,6. Unclear on 4,5.
-
-❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later
-✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding."
-```
-
-## Source-Specific Handling
-
-### From your human partner
-- **Trusted** - implement after understanding
-- **Still ask** if scope unclear
-- **No performative agreement**
-- **Skip to action** or technical acknowledgment
-
-### From External Reviewers
-```
-BEFORE implementing:
-  1. Check: Technically correct for THIS codebase?
-  2. Check: Breaks existing functionality?
-  3. Check: Reason for current implementation?
-  4. Check: Works on all platforms/versions?
-  5. Check: Does reviewer understand full context?
-
-IF suggestion seems wrong:
-  Push back with technical reasoning
-
-IF can't easily verify:
-  Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?"
-
-IF conflicts with your human partner's prior decisions:
-  Stop and discuss with your human partner first
-```
-
-**your human partner's rule:** "External feedback - be skeptical, but check carefully"
-
-## YAGNI Check for "Professional" Features
-
-```
-IF reviewer suggests "implementing properly":
-  grep codebase for actual usage
-
-  IF unused: "This endpoint isn't called. Remove it (YAGNI)?"
-  IF used: Then implement properly
-```
-
-**your human partner's rule:** "You and reviewer both report to me. If we don't need this feature, don't add it."
-
-## Implementation Order
-
-```
-FOR multi-item feedback:
-  1. Clarify anything unclear FIRST
-  2. Then implement in this order:
-     - Blocking issues (breaks, security)
-     - Simple fixes (typos, imports)
-     - Complex fixes (refactoring, logic)
-  3. Test each fix individually
-  4. Verify no regressions
-```
-
-## When To Push Back
-
-Push back when:
-- Suggestion breaks existing functionality
-- Reviewer lacks full context
-- Violates YAGNI (unused feature)
-- Technically incorrect for this stack
-- Legacy/compatibility reasons exist
-- Conflicts with your human partner's architectural decisions
-
-**How to push back:**
-- Use technical reasoning, not defensiveness
-- Ask specific questions
-- Reference working tests/code
-- Involve your human partner if architectural
-
-**Signal if uncomfortable pushing back out loud:** "Strange things are afoot at the Circle K"
-
-## Acknowledging Correct Feedback
-
-When feedback IS correct:
-```
-✅ "Fixed. [Brief description of what changed]"
-✅ "Good catch - [specific issue]. Fixed in [location]."
-✅ [Just fix it and show in the code]
-
-❌ "You're absolutely right!"
-❌ "Great point!"
-❌ "Thanks for catching that!"
-❌ "Thanks for [anything]"
-❌ ANY gratitude expression
-```
-
-**Why no thanks:** Actions speak. Just fix it. The code itself shows you heard the feedback.
-
-**If you catch yourself about to write "Thanks":** DELETE IT. State the fix instead.
-
-## Gracefully Correcting Your Pushback
-
-If you pushed back and were wrong:
-```
-✅ "You were right - I checked [X] and it does [Y]. Implementing now."
-✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing."
-
-❌ Long apology
-❌ Defending why you pushed back
-❌ Over-explaining
-```
-
-State the correction factually and move on.
-
-## Common Mistakes
-
-| Mistake | Fix |
-|---------|-----|
-| Performative agreement | State requirement or just act |
-| Blind implementation | Verify against codebase first |
-| Batch without testing | One at a time, test each |
-| Assuming reviewer is right | Check if breaks things |
-| Avoiding pushback | Technical correctness > comfort |
-| Partial implementation | Clarify all items first |
-| Can't verify, proceed anyway | State limitation, ask for direction |
-
-## Real Examples
-
-**Performative Agreement (Bad):**
-```
-Reviewer: "Remove legacy code"
-❌ "You're absolutely right! Let me remove that..."
-```
-
-**Technical Verification (Good):**
-```
-Reviewer: "Remove legacy code"
-✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?"
-```
-
-**YAGNI (Good):**
-```
-Reviewer: "Implement proper metrics tracking with database, date filters, CSV export"
-✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?"
-```
-
-**Unclear Item (Good):**
-```
-your human partner: "Fix items 1-6"
-You understand 1,2,3,6. Unclear on 4,5.
-✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing."
-```
-
-## The Bottom Line
-
-**External feedback = suggestions to evaluate, not orders to follow.**
-
-Verify. Question. Then implement.
-
-No performative agreement. Technical rigor always.

package/.opencode/skills/code-review/references/codebase-scan-workflow.md

@@ -1,30 +0,0 @@
-# Codebase Scan Workflow
-
-Think harder to scan the codebase and analyze it follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules:
-<tasks>$ARGUMENTS</tasks>
-
-## Role Responsibilities
-- You are an elite software engineering expert who specializes in system architecture design and technical decision-making.
-- You operate by: **YAGNI**, **KISS**, and **DRY**.
-- Sacrifice grammar for concision. List unresolved questions at end.
-
-## Workflow
-
-### Research
-* Use 2 `researcher` subagents in parallel to search up to 5 sources
-* Keep every research report concise (≤150 lines)
-* Use `/ck:scout` skill invocation to search the codebase
-
-### Code Review
-* Use multiple `code-reviewer` subagents in parallel to review code
-* If issues found, ask main agent to improve and repeat until tests pass
-* When complete, run adversarial review (see `adversarial-review.md`) — always-on, no exceptions
-* Report combined quality + adversarial findings to user
-
-### Plan
-* Use `planner` subagent to analyze reports and create improvement plan
-* Save overview at `plan.md`, phase files as `phase-XX-phase-name.md`
-
-### Final Report
-* Summary of changes, guide user to get started, suggest next steps
-* Ask user if they want to commit and push

package/.opencode/skills/code-review/references/edge-case-scouting.md

@@ -1,119 +0,0 @@
----
-name: edge-case-scouting
-description: Use after implementation, before code review to proactively find edge cases, side effects, and potential issues via scout skill - catches problems code-reviewer might miss
----
-
-# Edge Case Scouting
-
-Proactive detection of edge cases, side effects, and potential issues before code review.
-
-## Purpose
-
-Code reviews catch obvious issues but miss subtle side effects. Scout detects:
-- Files affected by changes reviewer might not check
-- Data flow paths that could break
-- Boundary conditions and error paths
-- Integration issues across modules
-
-## When to Use
-
-**Mandatory:** Multi-file features, shared utility refactors, complex bug fixes
-**Optional:** Single-file changes, docs, config
-
-## Process
-
-### 1. Identify Changed Files
-```bash
-git diff --name-only HEAD~1
-```
-
-### 2. Invoke Scout
-```
-/ck:scout edge cases for recent changes.
-
-Changed: {files from git diff}
-
-Find:
-1. Files importing/depending on changed modules
-2. Data flow paths through modified functions
-3. Error handling paths not tested
-4. Boundary conditions (null, empty, max)
-5. Race conditions in async code
-6. State management side effects
-```
-
-### 3. Analyze & Act
-
-| Finding | Action |
-|---------|--------|
-| Affected file not in scope | Add to review |
-| Data flow risk | Verify or add test |
-| Edge case | Add test or verify |
-| Missing test | Add before review |
-
-### 4. Document for Review
-```
-Scout findings:
-- {issues found}
-- Verified: {what checked}
-- Addressed: {what fixed}
-- Needs review: {remaining}
-```
-
-## Scout Prompts
-
-**Feature:**
-```
-Scout edge cases for {feature}.
-Changed: {files}
-Find: consumers, error states, untested inputs, performance, compatibility
-```
-
-**Bug fix:**
-```
-Scout side effects of fix in {file}.
-Bug: {description}, Fix: {approach}
-Find: other paths using logic, dependent features, similar bugs
-```
-
-**Refactor:**
-```
-Scout breaking changes in {module}.
-Before: {old}, After: {new}
-Find: importers, behavior diffs, removed functionality
-```
-
-## What Scout Catches
-
-| Issue | Why Missed | Scout Detects |
-|-------|------------|---------------|
-| Indirect deps | Not in diff | Traces imports |
-| Race conditions | Hard static review | Analyzes flow |
-| State mutations | Hidden side effects | Tracks data |
-| Missing null checks | Assumed safe | Boundary analysis |
-| Integration breaks | Out of scope | Cross-module search |
-
-## Red Flags
-
-- Shared utility changed but only one caller tested
-- Error path leads to unhandled rejection
-- State modified in place without notification
-- Breaking change without migration
-
-## Example
-
-```
-1. Done: Add cache to UserService.getUser()
-2. Diff: src/services/user-service.ts
-3. Scout: "edge cases for caching in getUser()"
-4. Report:
-   - ProfileComponent expects fresh data on edit
-   - AdminPanel loops getUser() (memory risk)
-   - No cache clear on updateUser()
-5. Fix: Add invalidation, maxSize
-6. Document for code-reviewer
-```
-
-## Bottom Line
-
-Scout before review. Don't trust "simple changes" - scout them anyway.

package/.opencode/skills/code-review/references/input-mode-resolution.md

@@ -1,135 +0,0 @@
----
-name: input-mode-resolution
-description: How to parse code-review arguments and resolve PR number, commit hash, pending changes, or default context into a reviewable diff
----
-
-# Input Mode Resolution
-
-Resolve `/code-review` arguments into a diff for the review pipeline.
-
-## Auto-Detection Rules
-
-Parse arguments left-to-right. First match wins.
-
-| Pattern | Mode | Example |
-|---------|------|---------|
-| `#\d+` | PR | `#123`, `#45` |
-| GitHub PR URL | PR | `https://github.com/org/repo/pull/123` |
-| `[0-9a-f]{7,40}` | Commit | `abc1234`, full SHA |
-| `--pending` | Pending | explicit flag |
-| `codebase` | Codebase | existing mode |
-| *(none + context)* | Default | recent changes |
-| *(none + no context)* | Prompt | ask user via `AskUserQuestion` |
-
-## Resolution Commands
-
-### PR Mode
-
-```bash
-# Extract PR number from argument
-PR_NUM=$(echo "$ARG" | grep -oE '[0-9]+$')
-
-# Fetch PR metadata
-gh pr view "$PR_NUM" --json title,body,files,additions,deletions,baseRefName,headRefName
-
-# Get the diff
-gh pr diff "$PR_NUM"
-
-# Get changed file list
-gh pr diff "$PR_NUM" --name-only
-```
-
-**Context passed to reviewers:**
-- PR title and description (intent)
-- Base branch (what it merges into)
-- Full diff
-- Changed file list for scout
-
-### Commit Mode
-
-```bash
-# Validate commit exists
-git cat-file -t "$COMMIT_HASH"
-
-# Get commit metadata
-git log -1 --format="%H%n%s%n%b" "$COMMIT_HASH"
-
-# Get the diff
-git show "$COMMIT_HASH" --stat
-git show "$COMMIT_HASH" -- # full diff
-
-# Changed files
-git show "$COMMIT_HASH" --name-only --format=""
-```
-
-**Context passed to reviewers:**
-- Commit message (intent)
-- Parent commit (what it changed from)
-- Full diff
-- Changed file list for scout
-
-### Pending Mode
-
-```bash
-# Staged changes
-git diff --cached
-
-# Unstaged changes
-git diff
-
-# Combined (staged + unstaged vs HEAD)
-git diff HEAD
-
-# Changed files
-git diff HEAD --name-only
-
-# Status overview
-git status --short
-```
-
-**Context passed to reviewers:**
-- No commit message yet — ask user for brief intent description
-- Combined diff (staged + unstaged)
-- Changed file list for scout
-
-### Default Mode
-
-Use recent changes already in conversation context. If no changes apparent, fall back to Prompt mode.
-
-### Prompt Mode
-
-When no arguments and no recent context, use `AskUserQuestion`:
-- Header: "Review Target"
-- Question: "What would you like to review?"
-- Options: Pending changes, Enter PR number, Enter commit hash, Full codebase scan, Parallel codebase audit
-
-For PR/commit options, follow up with second `AskUserQuestion` to get the number/hash.
-
-### Codebase Mode
-
-Codebase modes bypass diff resolution — they scan the full codebase instead.
-- `codebase` → hand off to `references/codebase-scan-workflow.md`
-- `codebase parallel` → hand off to `references/parallel-review-workflow.md`
-
-Both workflows include adversarial review (always-on).
-
-## Pipeline Handoff
-
-After resolving the diff, pass to the review pipeline:
-
-```
-Resolved diff
-  ├─ Changed files → Edge case scout
-  ├─ Full diff → Stage 1 (Spec compliance, if plan exists)
-  ├─ Full diff → Stage 2 (Code quality review)
-  └─ Full diff + findings → Stage 3 (Adversarial review)
-```
-
-## Error Handling
-
-| Error | Action |
-|-------|--------|
-| PR not found | `gh pr view` fails → report "PR #N not found in this repo" |
-| Commit not found | `git cat-file` fails → report "Commit not found — is it pushed?" |
-| No pending changes | `git diff HEAD` empty → report "No pending changes to review" |
-| Ambiguous input | Could be PR or commit → prefer PR (more common), note assumption |

package/.opencode/skills/code-review/references/parallel-review-workflow.md

@@ -1,76 +0,0 @@
-# Parallel Review Workflow
-
-**Ultrathink** to exhaustively list ALL potential edge cases, then dispatch parallel `code-reviewer` agents to verify: <scope>$ARGUMENTS</scope>
-
-**IMPORTANT:** Activate needed skills. Ensure token efficiency. Sacrifice grammar for concision.
-
-## Workflow
-
-### 1. Ultrathink Edge Cases
-
-Main agent deeply analyzes the scope to LIST all potential edge cases FIRST:
-- Read `codebase-summary.md` for context
-- Use `/ck:scout` to find relevant files
-- **Think exhaustively** about what could go wrong:
-  - Null/undefined scenarios
-  - Boundary conditions (off-by-one, empty, max values)
-  - Error handling gaps
-  - Race conditions, async edge cases
-  - Input validation holes
-  - Security vulnerabilities
-  - Resource leaks
-  - Untested code paths
-
-**Output format:**
-```markdown
-## Edge Cases Identified
-
-### Category: [scope-area]
-1. [edge case description] → files: [file1, file2]
-```
-
-### 2. Categorize & Assign
-
-Group edge cases by similar scope for parallel verification:
-- Each category → one `code-reviewer` agent
-- Max 6 categories (merge small ones)
-- Each reviewer gets specific edge cases to VERIFY, not discover
-
-### 3. Parallel Verification
-
-Launch N `code-reviewer` subagents simultaneously:
-- Pass: category name, list of edge cases, relevant files
-- Task: **VERIFY** if each edge case is properly handled in code
-- Report: which edge cases are handled vs unhandled
-
-### 4. Aggregate Results
-
-```markdown
-## Edge Case Verification Report
-
-### Summary
-- Total edge cases: X
-- Handled: Y
-- Unhandled: Z
-- Partial: W
-
-### Unhandled Edge Cases (Need Fix)
-| # | Edge Case | File | Status |
-|---|-----------|------|--------|
-```
-
-### 5. Adversarial Review (Always-On)
-
-After aggregation, spawn adversarial reviewer (see `adversarial-review.md`) on the full scope:
-- Adversarial reviewer receives aggregated findings + unhandled edge cases as context
-- Actively tries to break the code beyond what edge case verification found
-- Adjudicate findings: Accept / Reject / Defer
-
-### 6. Auto-Fix Pipeline
-
-**IF** unhandled/partial edge cases found:
-- Ask: "Found N unhandled edge cases. Fix with /ck:fix --parallel? [Y/n]"
-
-### 7. Final Report
-- Summary of verification
-- Ask: "Commit? [Y/n]" → use `git-manager`

package/.opencode/skills/code-review/references/requesting-code-review.md

@@ -1,105 +0,0 @@
----
-name: requesting-code-review
-description: Use when completing tasks, implementing major features, or before merging to verify work meets requirements - dispatches code-reviewer subagent to review implementation against plan or requirements before proceeding
----
-
-# Requesting Code Review
-
-Dispatch code-reviewer subagent to catch issues before they cascade.
-
-**Core principle:** Review early, review often.
-
-## When to Request Review
-
-**Mandatory:**
-- After each task in subagent-driven development
-- After completing major feature
-- Before merge to main
-
-**Optional but valuable:**
-- When stuck (fresh perspective)
-- Before refactoring (baseline check)
-- After fixing complex bug
-
-## How to Request
-
-**1. Get git SHAs:**
-```bash
-BASE_SHA=$(git rev-parse HEAD~1)  # or origin/main
-HEAD_SHA=$(git rev-parse HEAD)
-```
-
-**2. Dispatch code-reviewer subagent:**
-
-Use Task tool with `code-reviewer` type, fill template at `code-reviewer.md`
-
-**Placeholders:**
-- `{WHAT_WAS_IMPLEMENTED}` - What you just built
-- `{PLAN_OR_REQUIREMENTS}` - What it should do
-- `{BASE_SHA}` - Starting commit
-- `{HEAD_SHA}` - Ending commit
-- `{DESCRIPTION}` - Brief summary
-
-**3. Act on feedback:**
-- Fix Critical issues immediately
-- Fix Important issues before proceeding
-- Note Minor issues for later
-- Push back if reviewer is wrong (with reasoning)
-
-## Example
-
-```
-[Just completed Task 2: Add verification function]
-
-You: Let me request code review before proceeding.
-
-BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}')
-HEAD_SHA=$(git rev-parse HEAD)
-
-[Dispatch code-reviewer subagent]
-  WHAT_WAS_IMPLEMENTED: Verification and repair functions for conversation index
-  PLAN_OR_REQUIREMENTS: Task 2 from docs/plans/deployment-plan.md
-  BASE_SHA: a7981ec
-  HEAD_SHA: 3df7661
-  DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types
-
-[Subagent returns]:
-  Strengths: Clean architecture, real tests
-  Issues:
-    Important: Missing progress indicators
-    Minor: Magic number (100) for reporting interval
-  Assessment: Ready to proceed
-
-You: [Fix progress indicators]
-[Continue to Task 3]
-```
-
-## Integration with Workflows
-
-**Subagent-Driven Development:**
-- Review after EACH task
-- Catch issues before they compound
-- Fix before moving to next task
-
-**Executing Plans:**
-- Review after each batch (3 tasks)
-- Get feedback, apply, continue
-
-**Ad-Hoc Development:**
-- Review before merge
-- Review when stuck
-
-## Red Flags
-
-**Never:**
-- Skip review because "it's simple"
-- Ignore Critical issues
-- Proceed with unfixed Important issues
-- Argue with valid technical feedback
-
-**If reviewer wrong:**
-- Push back with technical reasoning
-- Show code/tests that prove it works
-- Request clarification
-
-See template at: requesting-code-review/code-reviewer.md