Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions .agents/skills/check-compiler-errors/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
name: check-compiler-errors
description: "运行并修复编译或类型检查错误。用户提到 compiler/type-check/tsc/类型错误/编译失败/Kotlin native build 失败/CI compile failed 时使用。"
---

# Check Compiler Errors

Use this skill when compile or type-check failures block validation.

## Command Order

Prefer repo scripts over ad hoc commands:

1. TypeScript: `npm run type-check`
2. Lint when relevant: `npm run lint`
3. Unit/package tests when type fixes affect behavior: `npm run test:unit` or `npm run test --workspaces --if-present`
4. Android/native changes: `cd android && ./gradlew assembleDebug --no-daemon`

If a script is missing, inspect `package.json` and use the closest existing command. Do not add a new dependency or script unless the user asks.

## Workflow

1. Run the smallest command that reproduces the compiler failure.
2. Summarize errors by file and category.
3. Fix the highest-confidence error first; prefer the canonical type boundary over casts.
4. Re-run the same command.
5. If one fix reveals the next compiler error, continue until clean or blocked.

## N.E.K.O.-RN Notes

- JS lip sync smoothing belongs in `LipSyncService`; Kotlin `PCMStreamPlayer` handles playback-head time alignment.
- After Kotlin/native Android edits, Metro hot reload is insufficient; run the Gradle debug build.
- For `@project_neko/*` package changes, check whether workspace tests or package sync are needed before declaring clean.

## Guardrails

- Never use `any` or broad casts just to quiet TypeScript unless there is no better local boundary.
- Do not change runtime behavior while fixing a pure type error unless the compiler exposed a real bug.
- Do not edit `.env` files.

## Output

```text
Status: clean | blocked | still failing
Commands: <commands run>
Errors fixed: <files/categories>
Remaining blocker: <only if any>
```
4 changes: 4 additions & 0 deletions .agents/skills/check-compiler-errors/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Check Compiler Errors"
short_description: "Run type checks and summarize compiler failures"
default_prompt: "Run compiler checks and fix high-confidence failures."
39 changes: 39 additions & 0 deletions .agents/skills/deslop/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
---
name: deslop
description: "清理 AI 生成感明显的代码膨胀。用户要求 deslop、去掉 AI 味、清理冗余、提交前简化 diff、删除多余注释/防御式代码/无意义抽象时使用。"
---

# Deslop

Use this skill to clean the current diff while preserving behavior.

## Workflow

1. Inspect `git status --short`, `git diff --staged`, and `git diff`.
2. Limit edits to changed lines or directly adjacent code needed to simplify those lines.
3. Remove only clear slop:
- Comments that restate code or explain obvious behavior.
- TODO/FIXME/HACK comments not explicitly requested by the user.
- Defensive checks, try/catch blocks, or fallbacks inconsistent with trusted local paths.
- `any`, broad casts, or optionality added only to silence TypeScript.
- One-off helpers, wrappers, flags, or configuration added for a single use.
- Nested conditionals that can be made direct with early returns.
- Debug logs or temporary output.
4. Preserve existing local style even if another style would be preferable.
5. Run the smallest relevant verification, usually `npm run type-check`, focused tests, or lint.

## Guardrails

- Keep behavior unchanged unless fixing a clear bug found during cleanup.
- Do not refactor unrelated code.
- Do not introduce new dependencies.
- Do not delete files.
- Do not edit `.env` files.
- If cleanup would become a rewrite, stop and propose the smaller path first.

## Output

Report only:
- What slop was removed.
- Verification run and result.
- Any remaining risk or skipped check.
4 changes: 4 additions & 0 deletions .agents/skills/deslop/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Deslop"
short_description: "Remove AI-style code slop from a diff"
default_prompt: "Clean up AI-generated slop in the current diff."
53 changes: 53 additions & 0 deletions .agents/skills/make-pr-easy-to-review/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
name: make-pr-easy-to-review
description: "让当前 diff 或 PR 更容易审查。用户说 make this easy to review、整理 PR、写 reviewer notes、拆分说明、审查前清理提交信息/描述时使用。"
---

# Make PR Easy To Review

Use this skill to improve reviewability without changing product behavior.

## Workflow

1. Inspect context:
- `git status --short`
- `git diff --stat`
- `git diff --staged --stat`
- PR metadata with `gh pr view` only if a PR exists and the user asks about it.
2. Identify reviewability issues:
- Mixed mechanical and behavioral edits.
- Stale or missing PR description.
- Generated files mixed with hand-written files.
- Large files where the reviewer needs an entry point.
- Missing test notes.
3. Prefer non-code improvements first:
- Concise TL;DR.
- Changed-file map.
- Risk notes.
- Verification notes.
4. If code cleanup is needed, use the `deslop` standard and keep behavior unchanged.

## Guardrails

- Do not rewrite history, squash commits, force-push, push, or open PRs without explicit approval.
- Do not hide behavior changes under "cleanup".
- Do not edit unrelated files.
- If the PR is too large to make reviewable with notes, recommend splitting it instead of polishing around the problem.

## Output

Produce reviewer-ready notes:

```markdown
## TL;DR
<one paragraph>

## Reviewer Entry Points
- <file>: <why it matters>

## Risk
- <risk or "Low">

## Verification
- <commands/results>
```
4 changes: 4 additions & 0 deletions .agents/skills/make-pr-easy-to-review/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Make PR Easy To Review"
short_description: "Prepare a diff for easier review without changing behavior"
default_prompt: "Make the current PR easier to review."
47 changes: 47 additions & 0 deletions .agents/skills/run-smoke-tests/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
name: run-smoke-tests
description: "运行冒烟测试或最小端到端验证。用户要求 smoke test、跑一下关键路径、验证改动没有破坏主流程、改完跑测试时使用。"
---

# Run Smoke Tests

Use this skill to validate the smallest meaningful user path after a change.

## Test Selection

Pick the narrowest check that can catch the likely regression:

- Type-only change: `npm run type-check`
- Shared TS behavior: `npm run test:unit`
- Package behavior: `npm run test --workspaces --if-present`
- Lint-sensitive edit: `npm run lint`
- Android/native edit: `cd android && ./gradlew assembleDebug --no-daemon`
- Mobile dev stack behavior: `npm run dev:mobile-stack` only when the user asks for interactive stack validation.

Use `npm test` only when broad validation is warranted; it can be slower than a focused check.

## Workflow

1. Identify the changed behavior and the smoke surface.
2. Run prerequisites only when required.
3. Run the focused command.
4. If failing, inspect the first actionable failure and apply a minimal fix.
5. Re-run the same command. Broaden only if the fix touches a shared path.

## Guardrails

- Prefer deterministic assertions over waiting or manual inspection.
- Do not add Playwright, Detox, or other test dependencies without explicit approval.
- Do not start an emulator unless explicitly requested.
- Do not edit `.env` files.

## Output

Keep the result short:

```text
Smoke surface: <why this check was chosen>
Result: passed | failed | blocked
Command: <command>
Failure/fix: <only if relevant>
```
4 changes: 4 additions & 0 deletions .agents/skills/run-smoke-tests/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Run Smoke Tests"
short_description: "Run focused smoke validation and triage failures"
default_prompt: "Run the relevant smoke tests and report failures."
53 changes: 53 additions & 0 deletions .agents/skills/thermo-nuclear-code-quality-review/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
name: thermo-nuclear-code-quality-review
description: "极严格的可维护性审查。用户要求 thermo-nuclear review、严厉代码质量审查、深度 maintainability audit、检查抽象/大文件/复杂度/意大利面式条件分支时使用。"
---

# Thermo-Nuclear Code Quality Review

Use this skill for a strict maintainability review of a diff or branch. Findings come first.

## Review Standard

Be ambitious about simplification. Do not accept "it works" if the change makes the system harder to reason about.

Check for:

- A simpler structure that removes whole branches, helpers, flags, or modes.
- Files pushed toward or past 1,000 lines without a strong reason.
- New one-off conditionals inserted into unrelated flows.
- Business logic leaking into UI, hooks, or shared plumbing.
- Service-layer code depending on React lifecycle or hooks.
- Hook code containing business logic instead of event-to-state mapping.
- Components importing service instances directly instead of consuming hooks.
- `any`, `unknown`, broad casts, or optionality that hide unclear boundaries.
- Sequential orchestration where independent work should be parallel or atomic.
- Thin abstractions that add indirection without reducing complexity.

## Workflow

1. Collect `git status --short`, `git diff --stat`, and the relevant diff.
2. Read changed files enough to understand boundaries and local style.
3. Review by severity, not by file order.
4. Report only actionable issues grounded in file/line references.
5. If there are no issues, say so and name remaining test gaps.

## Guardrails

- Do not nitpick formatting while structural issues exist.
- Do not request broad refactors unless the diff introduced or exposed the complexity.
- Do not propose new dependencies.
- Do not rewrite code during review unless the user asks for fixes.

## Output

```text
Findings
- [P0/P1/P2/P3] file:line - issue, impact, recommended fix

Open questions
- <only if blocking>

Test gaps / residual risk
- <only if relevant>
```
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Thermo Nuclear Review"
short_description: "Run a strict maintainability review"
default_prompt: "Run a strict maintainability review of the current diff."
44 changes: 44 additions & 0 deletions .agents/skills/verify-this/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
---
name: verify-this
description: "验证一个具体声明是否成立。用户说“verify this / 证明它好了 / 看看是否修复 / 给证据 / 是否真的变快”等需要 before/after、本地测试、日志、截图或构建产物证据时使用。"
---

# Verify This

Use this skill to prove or disprove a falsifiable claim with local evidence. Do not turn it into a recap.

## Workflow

1. Restate the claim in measurable form: condition, expected behavior, and pass/fail threshold.
2. Pick the smallest local surface that can disprove it:
- TypeScript behavior: focused unit test, `npm run test:unit`, or a small repro.
- Workspace packages: `npm run test --workspaces --if-present`.
- Compile safety: `npm run type-check`.
- Lint safety: `npm run lint`.
- Android/native behavior: `cd android && ./gradlew assembleDebug --no-daemon`.
- UI behavior: local screenshot or browser/app interaction evidence when applicable.
3. Capture baseline and treatment with the same command, input, environment, and threshold.
4. If a real baseline is unavailable without reverting user changes, say so and use `INCONCLUSIVE`; do not reset or overwrite user work.
5. Compare raw artifacts, not impressions.
6. Return exactly one verdict: `VERIFIED`, `NOT VERIFIED`, or `INCONCLUSIVE`.

## Guardrails

- Never modify `.env` files.
- Never run destructive git commands to create a baseline.
- Keep artifacts minimal; prefer terminal output snippets unless screenshots/logs are necessary.
- If writing artifacts, use `/tmp/verify-this/<claim-slug>/`, not the repo, unless the user asks.
- Do not soften a negative result. A clear `NOT VERIFIED` is useful.

## Output

```text
VERIFIED | NOT VERIFIED | INCONCLUSIVE
Claim: <falsifiable claim>

Evidence:
- <command/artifact>: baseline=<...>, treatment=<...>, delta=<...>, threshold=<...>

Reasoning:
<one concise paragraph naming evidence and confounds>
```
4 changes: 4 additions & 0 deletions .agents/skills/verify-this/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Verify This"
short_description: "Verify a claim with before/after evidence"
default_prompt: "Verify this claim with local evidence."
47 changes: 47 additions & 0 deletions .agents/skills/workflow-from-chats/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
name: workflow-from-chats
description: "从用户反馈或近期对话中沉淀可复用工作流。用户要求记住偏好、把经验写成 skill/rule/AGENTS.md、以后按这个方式做、从聊天中总结工作习惯时使用。"
---

# Workflow From Chats

Use this skill to turn repeated user feedback into durable instructions.

## Workflow

1. Define the target surface: communication, review, debugging, validation, shipping, simplification, or repo-specific workflow.
2. Extract preference atoms from the current conversation and available repo instructions:
- trigger
- decision rule
- required checks
- stop condition
- examples of what to avoid
- confidence
3. Classify confidence:
- strong: explicit user rule or repeated correction
- medium: accepted workflow with clear evidence
- weak: one-off inference
- contradicted: ask before writing
4. Choose the artifact:
- Skill: recurring multi-step workflow.
- AGENTS.md rule: broad behavior preference.
- Existing skill edit: refinement of a known command.
- No file change: situational or low-confidence note.
5. Write only reusable guidance. Remove anecdotes and private details.

## Guardrails

- Do not expose local transcript paths, secrets, private messages, or credentials.
- Do not rewrite global preferences from weak evidence.
- Do not create broad rules from a one-off task.
- Prefer editing existing project guidance over adding a new file when the behavior is already covered.

## Output

```text
Target workflow: <surface>
Adopt: <strong guidance to write>
Consider: <medium-confidence guidance>
Dismissed: <weak or task-specific observations>
Artifact: <skill/rule/doc/no change>
```
4 changes: 4 additions & 0 deletions .agents/skills/workflow-from-chats/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Workflow From Chats"
short_description: "Turn repeated preferences into durable guidance"
default_prompt: "Extract reusable workflow guidance from recent feedback."
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -26,6 +26,7 @@ npm-debug.*
yarn-debug.*
yarn-error.*
.npm-cache/
.devlogs/

# macOS
.DS_Store
Expand Down
Loading
Loading