@seanyao/roll 3.620.1 → 3.624.1

package/skills/roll-notes/SKILL.md

@@ -1,107 +0,0 @@
----
-name: roll-notes
-license: MIT
-allowed-tools: "Read, Edit, Write, Bash(date:*)"
-description: "Load when recording a development moment, decision, discovery, success, or failure into Roll chronological project diary."
----
-# roll-notes
-
-## Gotchas
-
-- Notes are chronological memory, not backlog commitments or release notes.
-- Record concrete observations with date context; avoid turning notes into hidden task lists.
-
-> 项目日记技能。记录开发过程中的成功、失败、感受和任何值得记住的事情。
-> Append-only, timeline-driven, no fixed format.
-
-## Trigger
-
-- User says "记一下"、"写进日记"、"append 到日记"
-- User asks to record a feeling, finding, or moment
-- A project milestone is reached and worth capturing
-
-```
-$roll-notes 终于搞定了那个 WebSocket 断线重连的 bug
-$roll-notes 今天的 code review 给了很好的反馈
-```
-
-## When Not to Use
-
-- Capturing a bug or feature idea into BACKLOG (use `$roll-idea`)
-- Generating the user-facing changelog (use `$roll-.changelog`)
-- Writing design documents or AC (use `$roll-design`)
-
-## Behavior
-
-1. **Determine file path**: `.roll/notes/YYYY-MM-DD.md` relative to project root (parallel to `.roll/dream/` and `.roll/briefs/` — notes is project metadata, not source)
-2. **Get current time**: Use `Asia/Shanghai` timezone (`TZ=Asia/Shanghai date`)
-3. **Read existing entries for style**: Before writing, read the last 2–3 entries
-   in the same file. Analyze their style: heading format, voice/tone,
-   paragraph structure, emoji usage, code block conventions, sign-off pattern.
-   New entries must continue this style — do not invent new structural patterns.
-4. **Append**: Add new entry at end of file — never overwrite existing content
-5. **Create if missing**: If file doesn't exist, create with a `# YYYY-MM-DD — <one-line summary>` header
-6. **Free format**: Paragraph, list, code block — whatever fits the moment
-
-## File format
-
-```markdown
-# YYYY-MM-DD — 一句话概括今天
-
-> 时间：北京时间 HH:MM
-
----
-
-## HH:MM — 事件标题
-
-发生了什么、怎么解决的、什么感受。
-
----
-
-## HH:MM — 另一个事件
-
-...
-```
-
-## 写作风格（强制）
-
-**禁止干巴巴的 checklist。禁止只有结论没有过程。必须有人的声音。**
-
-### 叙事驱动
-以时间线和事件推进为主线，像讲故事一样记录。不是 `补了功能，pytest 绿`，而是 `"电池剩余电量在哪里看？"我一愣，US-PLAT-003 的 AC 明明写了...`
-
-### 技术细节嵌入叙事
-代码、数据、命令行是故事的一部分，自然插入，不是附录。
-
-### 对话与互动
-记录用户的反馈、提问、情绪。日记是对话记录，不是独白。
-
-### 诚实记录错误
-失败、困惑、教训比成功更值得记录。
-
-### 标题有画面感
-不是功能清单。如 `每秒 20 行的噪音`、`22 个文件挤在一个抽屉里`。
-
-### 结尾有收束
-最后一段回到人的状态。如 `"值了"。"睡了"。push。`
-
-## Rules
-
-- **Style continuity**: Match the EXACT style, tone, and formatting of previous
-  entries in the same file. Do not invent new structural patterns or section
-  headers. If the file already has entries, analyze them first and confirm your
-  understanding of their style before writing.
-- **No planning**: Never write "明日待办" or "下一步"
-- **No summaries**: Never write "今日收获" or "经验教训"
-- **Pure record**: What happened, as-is — honest, immediate, rough is fine
-- **Append freely**: Multiple entries per day is normal
-
-## File location
-
-```
-.roll/
-  └── notes/
-        └── YYYY-MM-DD.md
-```
-
-注：notes 是项目元数据（与 `.roll/dream/` / `.roll/briefs/` 同级），不入 git；由 dream/brief 等下游 skill 跨日聚合。

package/skills/roll-onboard/SKILL.md

@@ -1,238 +0,0 @@
----
-name: roll-onboard
-license: MIT
-description: "Load when bringing a legacy project into Roll through interactive discovery questions and generation of .roll/onboard-plan.yaml for roll init --apply."
----
-# Roll Onboard
-
-## Gotchas
-
-- Onboard gathers a contract for roll init --apply; it should not mutate the project before the plan is reviewed.
-- Respect privacy/scope answers from the interactive questions as hard constraints.
-
-> Follows the Architecture Constraints, Development Discipline, and Engineering Common Sense defined in the project AGENTS.md.
-
-Interactive onboarding flow for **legacy projects**: existing code that needs to adopt the Roll convention without disrupting how the team already works.
-
-## Trigger
-
-This skill runs when:
-
-- `roll init` detected a legacy project (≥10 source files, no `AGENTS.md`)
-- The CLI told the user to open an AI agent and run `$roll-onboard`
-- The user has now invoked you here
-
-## Hard responsibility boundary
-
-You are the **认知 (cognition) layer**. Your job ends with writing a plan file.
-
-| You do | You do NOT |
-|--------|------------|
-| Read project code, infer type/domains/modules | Modify any source file |
-| Call `roll-doc-audit --dry-run` to get a gap report | Call `roll-doc-audit` (write mode) |
-| Ask the user 9 questions across 3 groups | Decide for the user |
-| Produce `.roll/onboard-plan.yaml` | Write `.gitignore` |
-| Produce `.roll/onboard-plan.yaml` | Run `roll init --apply` |
-
-Hard constraint: **AI cannot create files in the user's project other than `.roll/onboard-plan.yaml`.** Anything else is `bash`'s job (`roll init --apply`).
-
-## Inputs you must read
-
-1. The repository tree (use the project's own structure to infer technologies)
-2. Any existing `README.md` / `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` etc. as evidence
-3. `roll-doc-audit --dry-run` output → identifies what documentation gaps exist
-4. The path-audit pattern: scan for legacy structure markers (`BACKLOG.md`, `docs/features/`, etc.) — if any are present, REFUSE and tell the user to run `npx @seanyao/roll@2 migrate` first
-
-## Workflow
-
-### Step 0 — Pre-flight
-
-1. Check that you're in a legacy project root (no `AGENTS.md`, has source code)
-2. If `BACKLOG.md` or `docs/features/` already present → STOP, tell user to run `npx @seanyao/roll@2 migrate` first (this is a partial-migration project, not legacy)
-3. Check `.roll/onboard-plan.yaml` doesn't already exist; if it does, ask user whether to overwrite
-
-### Step 1 — Read code, build understanding
-
-Walk the repo. Identify:
-- **type**: one of `backend-service` / `frontend-only` / `fullstack` / `cli`
-- **description**: 1-2 sentence summary of what this project does
-- **domains**: top business/technical domains (e.g., "auth", "billing", "search")
-- **key_modules**: top 3-5 modules that hold most of the logic
-
-### Step 1b — Phase 2 analysis: business model, tech, tests (US-ONBOARD-016)
-
-A single onboard now produces three structured analysis sections in the plan
-(`domain_model`, `tech_analysis`, `test_assessment`). Build them here so Step 4
-can serialise them.
-
-**`domain_model`** — from the code you read, identify the bounded contexts. For
-each: a `name`, its `aggregates` (the entities that own consistency), and its
-`ubiquitous_language` (the domain terms the code/docs actually use). If you
-genuinely cannot infer contexts from the code, emit an empty
-`bounded_contexts: []` — do NOT invent contexts that aren't in the code.
-
-**`tech_analysis`** — `stack` (languages/frameworks evidenced by manifests),
-`dependencies` (from `package.json` / `pyproject.toml` / `go.mod` / `Cargo.toml`
-etc.), `architecture_notes` (observed structure, not aspirational), and `risks`
-(each a mapping with a `description`; optionally `severity: LOW|MEDIUM|HIGH` and
-an `evidence: detected|inferred` tag).
-
-**`test_assessment`** — this section is under a **hard anti-hallucination
-constraint** (next sub-step). Do NOT write it from intuition.
-
-#### The verifiable test scan (ANTI-HALLUCINATION HARD CONSTRAINT)
-
-Every `test_assessment` claim must be backed by a real filesystem scan you run
-here — never by "what a project like this usually needs". Run these probes and
-record the raw counts/paths:
-
-1. **Count test files** by the conventional patterns:
-   - `*.test.*` / `*.spec.*` (JS/TS), `*_test.go` (Go), `test_*.py` / `*_test.py` (Python), `*_spec.rb` (Ruby), `*Test.java` (Java)
-   - e.g. `git ls-files | grep -cE '\.(test|spec)\.[jt]sx?$'` and similar per pattern
-2. **Probe for runner configs**: `jest.config.*`, `pytest.ini` (or `[tool.pytest]` in `pyproject.toml`), `.mocharc.*`, `vitest.config.*`, `karma.conf.*`, `phpunit.xml`, `go test` (implied by `*_test.go`)
-3. **Probe for a `coverage/` directory** (and `.coverage` / `coverage.xml` artifacts)
-
-Then turn the raw findings into claims, each a **mapping** carrying a `claim`
-string plus an `evidence` tag:
-
-- `evidence: detected` — the scan directly found it (e.g. "42 `*.test.ts` files detected", "vitest.config.ts present", "coverage/ directory present").
-- `evidence: inferred` — a judgement you derived FROM the detected facts (e.g. "unit layer present but no E2E config — integration coverage likely thin"). The inference must trace back to something the scan detected.
-
-**"none detected" rule**: when a probe finds nothing, you MUST say so explicitly
-with a tagged claim — `{claim: "none detected", evidence: detected}` (a scan that
-ran and returned zero is a genuine `detected` finding). You must NOT silently
-omit the dimension, and you must NOT invent generic filler like "needs more E2E
-tests" / "consider adding integration tests" with no detected basis. The plan
-validator (`lib/roll-plan-validate.py`) rejects any untagged free-text claim, so
-filler will fail `roll init --apply`.
-
-Map the findings into the three buckets:
-- `current_layers`: what test layers actually exist (each tagged `detected`)
-- `gaps`: dimensions where the scan found nothing (`none detected`, tagged `detected`) or thin coverage you can justify (`inferred`)
-- `recommended_actions`: actions that trace to a detected gap (tag `inferred`); if nothing is missing, this bucket may be `[]`
-
-### Step 2 — Get gap report
-
-Run `roll-doc-audit --dry-run` (READ-ONLY mode). This reports:
-- Which standard Roll artifacts (BACKLOG, features, domain models) are missing
-- Which existing docs Roll could `include` rather than regenerate
-
-### Step 3 — Three groups of nine questions
-
-Present these in chat. **Aim for total time ≤ 3 minutes.** Group 1 confirms your understanding; group 2 scopes the work; group 3 handles privacy and next steps.
-
-**$(msg onboard.questions_group1)**
-
-1. $(msg onboard.q1 "[type]" "[description]")
-2. $(msg onboard.q2 "[domain A, domain B, …]")
-3. $(msg onboard.q3 "[X, Y, Z]")
-
-**$(msg onboard.questions_group2)**
-
-4. $(msg onboard.q4) Multi-select:
-   - `backlog` — initial BACKLOG with seeded stories
-   - `features` — features index + per-feature spec stubs
-   - `domain` — DDD context map
-   - `briefs` — directory for `$roll-brief` outputs
-5. Of these existing docs, which should I `include` rather than regenerate?
-   - (list candidates: README.md, docs/architecture.md, etc.)
-6. Put drafts inside `.roll/`? (default: yes; "no" means use the legacy `docs/` layout — not recommended for new adoption)
-
-**Group 3 — Privacy & next steps**
-
-7. Add `.roll/` to `.gitignore`? (yes = keep project management private; no = commit it like Roll itself does)
-8. Sync Roll conventions to which AI tools? Multi-select from detected agents (claude / cursor / codex / kimi / deepseek / pi / opencode / agy / trae)
-9. Enable `roll loop` autonomous execution after init?
-
-### Step 4 — Write plan file
-
-Write `.roll/onboard-plan.yaml` with this exact schema (validated by `lib/roll-plan-validate.py`):
-
-```yaml
-version: 1
-generated_at: "2026-05-19T14:30:00+08:00"   # current ISO 8601, your timezone OK
-
-project_understanding:
-  type: cli                                  # one of: backend-service / frontend-only / fullstack / cli
-  description: "..."
-  domains: [...]
-  key_modules: [...]
-
-scope:
-  approved: [backlog, features, domain]      # user's Q4 multi-select
-  declined: [briefs]                         # what they said no to
-
-include_existing:
-  - README.md                                # user's Q5 selections
-  - docs/architecture.md
-
-privacy:
-  gitignore_dot_roll: true                   # user's Q7
-
-sync_targets: [claude, cursor]               # user's Q8
-enable_loop: false                            # user's Q9
-agent_routes_template: default                # user's Q10 — agent routing preset
-                                              # one of: default / minimal / heavy / skip
-                                              # default = pi/deepseek/claude + history (US-AGENT-002)
-                                              # minimal = single agent (pi), no history
-                                              # heavy   = pi/deepseek/claude/kimi + larger window
-                                              # skip    = don't seed .roll/agent-routes.yaml
-
-# ── US-ONBOARD-016: Phase 2 analysis sections (optional, but emit all three) ──
-# All three are validated only when present, so they are backward-compatible,
-# but a normal onboard should produce them from Step 1b.
-
-domain_model:
-  bounded_contexts:                          # [] if none can be inferred — never invent
-    - name: auth
-      aggregates: [User, Session]
-      ubiquitous_language: [login, token, refresh]
-
-tech_analysis:
-  stack: [bash, python3]                     # evidenced by manifests
-  dependencies: [pyyaml]                     # from package.json / pyproject / go.mod / ...
-  architecture_notes: ["single-binary CLI + python helpers in lib/"]
-  risks:
-    - description: "no automated test run on macOS bash 3.2"
-      severity: HIGH                         # optional: LOW | MEDIUM | HIGH
-      evidence: detected                     # optional: detected | inferred
-
-# test_assessment — ANTI-HALLUCINATION: every claim is a mapping with an
-# `evidence` tag (detected | inferred). A zero-result scan is `none detected`
-# tagged `detected`. Untagged free-text is REJECTED by the validator.
-test_assessment:
-  current_layers:
-    - claim: "112 bats files detected under tests/"   # evidence: a real scan count
-      evidence: detected
-  gaps:
-    - claim: "none detected"                 # e.g. no coverage/ dir found
-      evidence: detected
-  recommended_actions:                       # [] if nothing is missing
-    - claim: "add a macOS CI runner (inferred from launchd-only test skips)"
-      evidence: inferred                     # an inference traceable to a detected fact
-```
-
-Then tell the user:
-
-> Onboard conversation done. Plan saved to `.roll/onboard-plan.yaml`.
-> Return to your terminal and run:
->
->     roll init --apply
->
-> The plan expires in 24 hours.
-
-### Step 5 — Stop
-
-Do NOT run `roll init --apply` yourself. Do NOT modify other project files. Your job is done.
-
-## When NOT to use
-
-- **Not a legacy project**: empty dir or fresh project → use plain `roll init` instead
-- **Has BACKLOG.md or docs/features/**: this is a pre-2.0 Roll project → run `npx @seanyao/roll@2 migrate` first
-- **Has .roll/ already**: already onboarded → don't re-run
-
-## Failure modes
-
-- User aborts mid-conversation → don't write partial plan; tell user to re-run from scratch
-- User answers contradict the gap report (e.g., declines `features` but has lots of code) → ask the contradictory question once more before accepting; if they confirm, respect the choice
-- You can't read enough code to fill `project_understanding` (e.g., binary repo) → write a placeholder plan but ask user to fill in `type` and `description` manually before applying

package/skills/roll-peer/SKILL.md

@@ -1,47 +0,0 @@
----
-name: roll-peer
-license: MIT
-allowed-tools: "Read, Bash, Write, Edit"
-description: "Load when the user explicitly asks for peer review, cross-agent negotiation, /peer, or a high-risk decision needs an external agent perspective."
----
-# Roll Peer
-
-This hub keeps the routing boundary, hard gates, and execution skeleton in the initial context. Load the heavier runbook only when the task actually needs the detailed contract.
-
-## Load
-
-Load when the user explicitly asks for peer review, cross-agent negotiation, /peer, or a high-risk decision needs an external agent perspective.
-
-## When Not to Use
-
-- Local self-review; load roll-.review.
-- PR-only review; load roll-review-pr.
-
-## Read On Demand
-
-- Read [the full contract](references/full-contract.md) before executing the workflow end to end, recovering from failures, or checking exact output templates.
-- Keep this hub in context for trigger boundaries and hard gates.
-
-## Workflow Skeleton
-
-1. Confirm peer review is explicitly requested or required by a documented gate.
-2. Route to an appropriate external agent.
-3. Run bounded negotiation rounds.
-4. Record consensus, disagreement, and unresolved questions.
-5. Escalate to human when consensus fails.
-
-## Hard Gates
-
-- Do not spawn subagents without explicit permission/tool availability.
-- Peer output is advisory unless local gates accept it.
-
-## Gotchas
-
-- Only invoke cross-agent work when explicitly requested or at documented gates; do not surprise the user with extra delegation.
-- Consensus does not override local evidence, tests, or the owner decision.
-
-## Maintenance
-
-- Description changes require updates in `route-cases/skills.json`.
-- New observed failures should add a gotcha and the matching positive or negative route case.
-- Heavy examples, templates, recovery paths, and deterministic snippets belong in `references/`, `assets/`, or `scripts/`, not in this hub.