@rosetears/aili-pi 0.1.0

package/skills/code-simplification/SKILL.md

@@ -0,0 +1,371 @@
+---
+name: code-simplification
+description: Simplify a bounded code area when the user explicitly requests behavior-preserving refactoring or a named complexity/readability problem is the accepted task; do not trigger automatically after implementation, during every review, for adjacent cleanup, or when behavior may change.
+---
+
+# Code Simplification
+
+> Inspired by the [Claude Code Simplifier plugin](https://github.com/anthropics/claude-plugins-official/blob/main/plugins/code-simplifier/agents/code-simplifier.md). Adapted here as a model-agnostic, process-driven skill for any AI coding agent.
+
+## Overview
+
+Simplify code by reducing complexity while preserving exact behavior. The goal is not fewer lines — it's code that is easier to read, understand, modify, and debug. Every simplification must pass a simple test: "Would a new team member understand this faster than the original?"
+
+## When to Use
+
+- The user explicitly requests a behavior-preserving simplification/refactor
+- A named review finding or accepted task identifies a concrete readability/complexity problem
+- When you encounter deeply nested logic, long functions, or unclear names
+- When refactoring code written under time pressure
+- When consolidating related logic scattered across files
+- A bounded accepted cleanup identifies duplication or inconsistency
+
+**When NOT to use:**
+
+- Code is already clean and readable — don't simplify for the sake of it
+- You don't understand what the code does yet — comprehend before you simplify
+- The code is performance-critical and the "simpler" version would be measurably slower
+- You're about to rewrite the module entirely — simplifying throwaway code wastes effort
+
+ROSE/`aili-delivery-flow` owns scope, material decisions, approvals, Git actions, and verification. This skill runs one bounded simplification loop and does not invoke review, Git, testing, or another process skill. Return `complete`, `need-user`, `need-evidence`, `material-delta`, `blocked`, or `Unverified`; canonical claim-matched verification wins.
+
+## The Five Principles
+
+### 1. Preserve Behavior Exactly
+
+Don't change what the code does — only how it expresses it. All inputs, outputs, side effects, error behavior, and edge cases must remain identical. If you're not sure a simplification preserves behavior, don't make it.
+
+```
+SELF-CHECK EACH CANDIDATE CHANGE:
+→ Does this produce the same output for every input?
+→ Does this maintain the same error behavior?
+→ Does this preserve the same side effects and ordering?
+→ What focused evidence can prove behavior equivalence without changing tests?
+```
+
+### 2. Follow Project Conventions
+
+Simplification means making code more consistent with the codebase, not imposing external preferences. Before simplifying:
+
+```
+1. Read CLAUDE.md / project conventions
+2. Study how neighboring code handles similar patterns
+3. Match the project's style for:
+   - Import ordering and module system
+   - Function declaration style
+   - Naming conventions
+   - Error handling patterns
+   - Type annotation depth
+```
+
+Simplification that breaks project consistency is not simplification — it's churn.
+
+### 3. Prefer Clarity Over Cleverness
+
+Explicit code is better than compact code when the compact version requires a mental pause to parse.
+
+```typescript
+// UNCLEAR: Dense ternary chain
+const label = isNew ? 'New' : isUpdated ? 'Updated' : isArchived ? 'Archived' : 'Active';
+
+// CLEAR: Readable mapping
+function getStatusLabel(item: Item): string {
+  if (item.isNew) return 'New';
+  if (item.isUpdated) return 'Updated';
+  if (item.isArchived) return 'Archived';
+  return 'Active';
+}
+```
+
+```typescript
+// UNCLEAR: Chained reduces with inline logic
+const result = items.reduce((acc, item) => ({
+  ...acc,
+  [item.id]: { ...acc[item.id], count: (acc[item.id]?.count ?? 0) + 1 }
+}), {});
+
+// CLEAR: Named intermediate step
+const countById = new Map<string, number>();
+for (const item of items) {
+  countById.set(item.id, (countById.get(item.id) ?? 0) + 1);
+}
+```
+
+### 4. Maintain Balance
+
+Simplification has a failure mode: over-simplification. Watch for these traps:
+
+- **Inlining too aggressively** — removing a helper that gave a concept a name makes the call site harder to read
+- **Combining unrelated logic** — two simple functions merged into one complex function is not simpler
+- **Removing "unnecessary" abstraction** — some abstractions exist for extensibility or testability, not complexity
+- **Optimizing for line count** — fewer lines is not the goal; easier comprehension is
+
+### Architecture Deepening Checks
+
+Use these terms when deciding whether a simplification should remove, keep, or reshape a boundary:
+
+- **Module:** a unit with a responsibility and callers.
+- **Interface:** the public surface callers depend on.
+- **Implementation:** the hidden complexity behind the interface.
+- **Deep module:** small interface, meaningful hidden implementation.
+- **Shallow module:** public surface is as complex as the thing it wraps.
+- **Seam:** a boundary where alternative implementations or tests can attach.
+- **Adapter:** implementation behind a seam for a concrete external system or variation.
+- **Leverage:** how much caller complexity disappears because the module exists.
+- **Locality:** how much related behavior stays in one place.
+
+Apply the deletion test: if deleting a module makes the complexity disappear, it was probably a pass-through wrapper. If deleting it spreads complexity across callers, the module is earning its keep.
+
+Do not invent interfaces too early. One adapter usually means a hypothetical seam; two real adapters, or a concrete near-term need, can justify a seam.
+
+### 5. Scope to What Changed
+
+Default to simplifying recently modified code. Avoid drive-by refactors of unrelated code unless explicitly asked to broaden scope. Unscoped simplification creates noise in diffs and risks unintended regressions.
+
+## The Simplification Process
+
+### Step 1: Understand Before Touching (Chesterton's Fence)
+
+Before changing or removing anything, understand why it exists. This is Chesterton's Fence: if you see a fence across a road and don't understand why it's there, don't tear it down. First understand the reason, then decide if the reason still applies.
+
+```
+BEFORE SIMPLIFYING, ANSWER:
+- What is this code's responsibility?
+- What calls it? What does it call?
+- What are the edge cases and error paths?
+- Are there tests that define the expected behavior?
+- Why might it have been written this way? (Performance? Platform constraint? Historical reason?)
+- Check git blame: what was the original context for this code?
+```
+
+If you can't answer these, you're not ready to simplify. Read more context first.
+
+### 🔴 CHECKPOINT · Behavior-Risk Gate
+
+🛑 STOP before editing when a simplification would touch any of these behavior-risky areas:
+
+- public interfaces, exported types, API routes, schemas, migrations, auth, permissions, or persistence
+- error handling, retry behavior, ordering, concurrency, caching, validation, or side effects
+- performance-critical paths where the simpler version may change complexity or allocation patterns
+- code without tests or without enough context to prove equivalent behavior
+
+At this gate, either narrow the change to a behavior-neutral refactor with claim-matched verification or return the exact behavior/scope decision to ROSE. Do not treat a behavior-changing cleanup as simplification.
+
+### Step 2: Identify Simplification Opportunities
+
+Scan for these patterns — each one is a concrete signal, not a vague smell:
+
+**Structural complexity:**
+
+| Pattern | Signal | Simplification |
+|---------|--------|----------------|
+| Deep nesting (3+ levels) | Hard to follow control flow | Extract conditions into guard clauses or helper functions |
+| Long functions (50+ lines) | Multiple responsibilities | Split into focused functions with descriptive names |
+| Nested ternaries | Requires mental stack to parse | Replace with if/else chains, switch, or lookup objects |
+| Boolean parameter flags | `doThing(true, false, true)` | Replace with options objects or separate functions |
+| Repeated conditionals | Same `if` check in multiple places | Extract to a well-named predicate function |
+
+**Naming and readability:**
+
+| Pattern | Signal | Simplification |
+|---------|--------|----------------|
+| Generic names | `data`, `result`, `temp`, `val`, `item` | Rename to describe the content: `userProfile`, `validationErrors` |
+| Abbreviated names | `usr`, `cfg`, `btn`, `evt` | Use full words unless the abbreviation is universal (`id`, `url`, `api`) |
+| Misleading names | Function named `get` that also mutates state | Rename to reflect actual behavior |
+| Comments explaining "what" | `// increment counter` above `count++` | Delete the comment — the code is clear enough |
+| Comments explaining "why" | `// Retry because the API is flaky under load` | Keep these — they carry intent the code can't express |
+
+**Redundancy:**
+
+| Pattern | Signal | Simplification |
+|---------|--------|----------------|
+| Duplicated logic | Same 5+ lines in multiple places | Extract to a shared function |
+| Dead code | Unreachable branches, unused variables, commented-out blocks | Remove (after confirming it's truly dead) |
+| Unnecessary abstractions | Wrapper that adds no value | Inline the wrapper, call the underlying function directly |
+| Over-engineered patterns | Factory-for-a-factory, strategy-with-one-strategy | Replace with the simple direct approach |
+| Redundant type assertions | Casting to a type that's already inferred | Remove the assertion |
+
+### Step 3: Apply a Bounded Simplification
+
+Apply the smallest coherent simplification set whose behavior-equivalence evidence can be isolated. Do not add tests, commits, PR splits, or approval checkpoints after each edit; the canonical owner selects one focused check for the resulting claim.
+
+```
+FOR THE BOUNDED SET:
+1. Make only the accepted behavior-preserving edits
+2. Inspect the focused diff and selected equivalence evidence
+3. Run the canonical owner's smallest claim-matched check once
+4. If the check fails, apply at most one targeted repair/recheck or keep the original code and report the blocker
+```
+
+Avoid unrelated cleanup or a broad rewrite. Keep the resulting diff small enough to localize a failed equivalence claim without creating per-edit ceremony.
+
+### Failure and Fallback Table
+
+| Trigger | First response | If still unresolved |
+|---|---|---|
+| Tests fail after a simplification | Revert that one simplification and inspect the failing behavior | Keep the original code and report the simplification as rejected |
+| Behavior equivalence cannot be proven | Stop before editing and gather focused tests, callers, or examples | Return the exact scope/behavior decision to ROSE or leave the code unchanged |
+| Simplification requires changing tests | Treat it as a behavior change, not simplification | Split into a separate feature/bug-fix task |
+| Public interface or schema would change | Stop and return the exact material decision to ROSE | Do not make the change under this skill |
+| The diff grows large or hard to review | Break into smaller independent simplifications | Abandon the broad pass and keep only verified local changes |
+
+**The Rule of 500:** If a refactoring would touch more than 500 lines, invest in automation (codemods, sed scripts, AST transforms) rather than making the changes by hand. Manual edits at that scale are error-prone and exhausting to review.
+
+### Step 4: Verify the Result
+
+After all simplifications, step back and evaluate the whole:
+
+```
+COMPARE BEFORE AND AFTER:
+- Is the simplified version genuinely easier to understand?
+- Did you introduce any new patterns inconsistent with the codebase?
+- Is the diff clean and reviewable?
+- Would a teammate approve this change?
+```
+
+If the "simplified" version is harder to understand or review, revert. Not every simplification attempt succeeds.
+
+## Language-Specific Guidance
+
+### TypeScript / JavaScript
+
+```typescript
+// SIMPLIFY: Unnecessary async wrapper
+// Before
+async function getUser(id: string): Promise<User> {
+  return await userService.findById(id);
+}
+// After
+function getUser(id: string): Promise<User> {
+  return userService.findById(id);
+}
+
+// SIMPLIFY: Verbose conditional assignment
+// Before
+let displayName: string;
+if (user.nickname) {
+  displayName = user.nickname;
+} else {
+  displayName = user.fullName;
+}
+// After
+const displayName = user.nickname || user.fullName;
+
+// SIMPLIFY: Manual array building
+// Before
+const activeUsers: User[] = [];
+for (const user of users) {
+  if (user.isActive) {
+    activeUsers.push(user);
+  }
+}
+// After
+const activeUsers = users.filter((user) => user.isActive);
+
+// SIMPLIFY: Redundant boolean return
+// Before
+function isValid(input: string): boolean {
+  if (input.length > 0 && input.length < 100) {
+    return true;
+  }
+  return false;
+}
+// After
+function isValid(input: string): boolean {
+  return input.length > 0 && input.length < 100;
+}
+```
+
+### Python
+
+```python
+# SIMPLIFY: Verbose dictionary building
+# Before
+result = {}
+for item in items:
+    result[item.id] = item.name
+# After
+result = {item.id: item.name for item in items}
+
+# SIMPLIFY: Nested conditionals with early return
+# Before
+def process(data):
+    if data is not None:
+        if data.is_valid():
+            if data.has_permission():
+                return do_work(data)
+            else:
+                raise PermissionError("No permission")
+        else:
+            raise ValueError("Invalid data")
+    else:
+        raise TypeError("Data is None")
+# After
+def process(data):
+    if data is None:
+        raise TypeError("Data is None")
+    if not data.is_valid():
+        raise ValueError("Invalid data")
+    if not data.has_permission():
+        raise PermissionError("No permission")
+    return do_work(data)
+```
+
+### React / JSX
+
+```tsx
+// SIMPLIFY: Verbose conditional rendering
+// Before
+function UserBadge({ user }: Props) {
+  if (user.isAdmin) {
+    return <Badge variant="admin">Admin</Badge>;
+  } else {
+    return <Badge variant="default">User</Badge>;
+  }
+}
+// After
+function UserBadge({ user }: Props) {
+  const variant = user.isAdmin ? 'admin' : 'default';
+  const label = user.isAdmin ? 'Admin' : 'User';
+  return <Badge variant={variant}>{label}</Badge>;
+}
+
+// SIMPLIFY: Prop drilling through intermediate components
+// Before — consider whether context or composition solves this better.
+// This is a judgment call — flag it, don't auto-refactor.
+```
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It's working, no need to touch it" | Working code that's hard to read will be hard to fix when it breaks. Simplifying now saves time on every future change. |
+| "Fewer lines is always simpler" | A 1-line nested ternary is not simpler than a 5-line if/else. Simplicity is about comprehension speed, not line count. |
+| "I'll just quickly simplify this unrelated code too" | Unscoped simplification creates noisy diffs and risks regressions in code you didn't intend to change. Stay focused. |
+| "The types make it self-documenting" | Types document structure, not intent. A well-named function explains *why* better than a type signature explains *what*. |
+| "This abstraction might be useful later" | Don't preserve speculative abstractions. If it's not used now, it's complexity without value. Remove it and re-add when needed. |
+| "The original author must have had a reason" | Maybe. Check git blame — apply Chesterton's Fence. But accumulated complexity often has no reason; it's just the residue of iteration under pressure. |
+| "I'll refactor while adding this feature" | Separate refactoring from feature work. Mixed changes are harder to review, revert, and understand in history. |
+
+## Red Flags
+
+- Simplification that requires modifying tests to pass (you likely changed behavior)
+- "Simplified" code that is longer and harder to follow than the original
+- Renaming things to match your preferences rather than project conventions
+- Removing error handling because "it makes the code cleaner"
+- Simplifying code you don't fully understand
+- Batching many simplifications into one large, hard-to-review commit
+- Refactoring code outside the scope of the current task without being asked
+
+## Verification
+
+After completing the bounded simplification:
+
+- [ ] The canonical owner's smallest behavior-equivalence check passes without modifying tests to excuse a change
+- [ ] Any broader build/lint/test evidence is run only when required by the exact claim
+- [ ] The simplification is a focused, reviewable change
+- [ ] The diff is clean — no unrelated changes mixed in
+- [ ] Simplified code follows project conventions (checked against CLAUDE.md or equivalent)
+- [ ] No error handling was removed or weakened
+- [ ] No dead code was left behind (unused imports, unreachable branches)
+- [ ] The evidence supports only the reported behavior-preserving claim; no automatic review gate was added

package/skills/comment-accuracy-review/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: comment-accuracy-review
+description: Review comment, JSDoc, TODO, README, and docs-to-code factual consistency, stale or low-value comments, and Chinese comment/variable appropriateness; do not use for general code review, broad documentation rewrites, or auto-editing comments without approval.
+---
+
+# Comment Accuracy Review
+
+Use this skill when ROSE needs a narrow, read-only pass over whether explanatory text still matches the code it describes.
+
+## Trigger
+
+- Comments, JSDoc, TODOs, README snippets, or nearby docs may be stale, misleading, redundant, or contradicted by implementation.
+- A review asks whether docs-to-code claims, examples, parameters, return values, errors, environment notes, or operational steps are factually accurate.
+- Chinese comments, Chinese variable names, or bilingual text need appropriateness checks for clarity, tone, maintainability, and consistency with repository language patterns.
+
+## Near Misses
+
+- General review, large documentation authoring, style-only writing, or implementation are different primary intents. Return the exact mismatch or approved edit need to ROSE; do not invoke another skill or agent here.
+
+## Required Routing
+
+- Owner: ROSE/`aili-delivery-flow`; direct read-only inspection is the default.
+- Optional agent: one fresh code-review or docs-research assignment only when a concrete capability/context gap independently passes the delegation gate.
+- Default mode: read-only; report findings and recommended edits, but do not modify comments automatically.
+
+## Boundaries
+
+- Compare text claims to the current repository evidence, not to intent or stale plans.
+- Flag comments that restate obvious code, describe old behavior, overpromise guarantees, hide uncertainty, or use TODOs as unmanaged task trackers.
+- Preserve useful intent comments that explain non-obvious constraints, trade-offs, invariants, data formats, or external behavior.
+- Treat generated, vendored, third-party, or upstream-copied comments as out of scope unless the task explicitly includes them.
+
+## Verification
+
+- Cite file paths and line anchors for both the questioned text and the code evidence that confirms or contradicts it.
+- Classify each finding as inaccurate, stale, unverifiable, redundant, language/terminology concern, or acceptable.
+- If edits are later approved, require focused diff inspection and any relevant docs/build/typecheck command for the touched surface.

package/skills/consulting-analysis/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: consulting-analysis
+description: Structure source-grounded consulting-style analysis for strategy, market, product, operations, or decision memos. Use for MECE problem framing, hypotheses, options, tradeoffs, executive recommendations, or "consulting analysis" requests; do not use for legal/financial advice, implementation, data computation, chart rendering, or unsourced business claims.
+---
+
+# Consulting Analysis
+
+## Purpose
+
+Convert an ambiguous business or product question into a clear, evidence-backed recommendation with assumptions, options, risks, and next decisions.
+
+## When to Use
+
+Use for:
+
+- strategy memos, product/business case analysis, market-entry framing, operational diagnosis, or option comparison
+- MECE issue trees, hypotheses, criteria, tradeoff tables, and executive summaries
+- turning research notes into a decision-ready recommendation
+
+Do not use for:
+
+- regulated legal, investment, tax, medical, or HR advice
+- numeric analysis of a dataset; use `data-analysis`
+- chart design; use `chart-visualization`
+- implementing the recommendation
+
+## Workflow
+
+1. Clarify the decision owner, decision deadline, success metric, constraints, and non-goals.
+2. Frame the problem as a decision question, then split it into MECE drivers or hypotheses.
+3. Inventory evidence by source type and reliability. Mark assumptions separately from facts.
+4. Compare options against explicit criteria: impact, cost, speed, risk, reversibility, evidence strength, and strategic fit.
+5. Synthesize a recommendation plus alternatives, not just a list of pros/cons.
+6. State what would change the recommendation and what evidence should be gathered next.
+
+## Authenticity Rules
+
+- Do not invent market sizes, competitor facts, customer quotes, financial projections, or benchmark numbers.
+- If the user supplies estimates, label them user-provided unless independently verified.
+- Keep confidence tied to evidence quality; weak evidence can still support a hypothesis, not a final claim.
+
+## Output Contract
+
+```text
+STATUS: ANALYZED | PARTIAL | BLOCKED
+CONFIDENCE: high | medium | low
+
+DECISION QUESTION:
+- <question, owner, timing, constraints>
+
+ISSUE TREE / HYPOTHESES:
+- <driver or hypothesis> - Evidence/assumption:
+
+OPTIONS:
+- <option> | impact | cost | risk | reversibility | evidence strength
+
+RECOMMENDATION:
+- <recommended option and why>
+
+RISKS / WATCHPOINTS:
+- <risk and mitigation>
+
+NEXT EVIDENCE:
+- <source or experiment that would change confidence>
+```
+
+## Provenance
+
+Clean-room AILI/OpenCode adaptation inspired by the public DeerFlow `consulting-analysis` skill pattern. No upstream skill text, runtime paths, tools, generated assets, or provider assumptions are copied. Source family: [bytedance/deer-flow](https://github.com/bytedance/deer-flow), MIT License.