一键导入
research
Captures checked-in reference comparison in a durable local planning artifact and records wiki follow-up status.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Captures checked-in reference comparison in a durable local planning artifact and records wiki follow-up status.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Bootstraps `.skills/planning.json`, `.skills/execution.json`, and `.skills/conventions.json` for a repository, and can also scaffold a wiki knowledge layer next to the planning feature directory. Use when a user asks to configure a project, initialize `sirius-skills` settings, apply generic defaults, add Jira-oriented conventions, or bootstrap the repo's wiki skeleton.
Canonical workflow for creating and managing durable subfeatures under an existing feature. Use this whenever the user asks to add, create, start, open, or bootstrap a subfeature so downstream planning skills keep the expected metadata and discovery-draft lifecycle.
Reconcile one planning target, optionally execute planning owners in sequence, and persist checkpointed resume context through approval, optional auto-commit handoff, and planning-commit handoff.
Converts repo stories and planning docs into directly executable, dependency-aware work items with traceability and execution handoff.
Closes the active execution slice with validation and records durable closure metadata while invoking shared owner-completion reconciliation.
Produces feature-level system-design.md artifacts before breakdown when a feature needs architecture, interface, constraint, failure-handling, or validation decisions captured durably.
| name | research |
| description | Captures checked-in reference comparison in a durable local planning artifact and records wiki follow-up status. |
Use this skill when a canonical feature or durable subfeature needs explicit reference-project comparison recorded durably in the repository.
<feature_path>/reference-research.md with the chosen borrowing path.index.md and log.md.<feature_path>/reference-research.mdResolve <feature_path> as either:
<planning_dir>/<feature-slug>/
<planning_dir>/<feature-slug>/subfeatures/<subfeature-id>/
If .skills/planning.json defines planning_dir, use that as <planning_dir>.
Otherwise default to docs/features.
reference-research.md.--wiki-status written plus one focused --wiki-page so the helper updates
that page and the wiki index.md / log.md.discover, design, or
review-planning belongs to later workflow steps.sirius research \
docs/features/planning-workflow/subfeatures/reference-research-synthesis \
--question "Which upstream pattern should own durable reference synthesis?" \
--source "references/build-your-own-openclaw/: tutorial baseline" \
--source "references/OpenHarness/: stronger workflow ownership patterns" \
--chosen-reference "references/OpenHarness/" \
--decision "Borrow the explicit skill-and-artifact pattern while keeping wiki updates optional." \
--alternative "references/build-your-own-openclaw/: useful background, but too tutorial-shaped as the primary owner" \
--wiki-status deferred \
--wiki-note "Local artifact is written first; reusable wiki-page mutation lands in a later slice."
If the repository already has a derived wiki root and the reusable synthesis was written there, record that explicitly and let the helper update the wiki page, index, and log:
sirius research \
planning-workflow \
--question "Which proposal-management pattern should we reuse?" \
--source "references/proposals/: current baseline" \
--chosen-reference "references/proposals/" \
--decision "Reuse the existing proposal lifecycle and extend it with local evidence." \
--wiki-status written \
--wiki-page "docs/wiki/concepts/proposal-research-patterns.md"
--scope
when needed.