dsh-upstream-customization

Classifies personal DSH customizations for upstream contribution and, after explicit per-feature approval, rebuilds one on upstream master and opens a draft pull request. Use when the user asks to contribute, publish, or upstream a local DSH change, or asks whether one is worth proposing.

インストールへ移動

リポジトリ: huiliyi37/oh-my-tianshu
ソースの最終更新活動: 2026年8月13日 16:37
検出された SKILL.md の言語: 英語
スター: 39
フォーク: 3

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。

npx skills add https://github.com/huiliyi37/oh-my-tianshu --skill dsh-upstream-customization

コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。

ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md

ソースの指示 · 読み取り専用プレビュー

検索に戻るインストールに戻る

editing-cordis-compositions

Use when creating, changing, or validating a Cordis composition for this harness — writing or editing an agent preset, adding or removing a plugin row, deciding whether something belongs to the host composition or to one session, checking whether a preset you authored actually mounts, or diagnosing a row that mounted but contributed nothing.

2026-08-16

dsh-customize

Customize or maintain any dsh source checkout — the one powering the current DSH process, the installed `dsh` command, or a sibling dsh/oh-my-tianshu clone. Use before any requested action that alters such a checkout's files or git state. Read-only questions that only inspect the checkout do not trigger this. Do not edit the personal staging checkout directly.

2026-08-16

create-dsh-sdk-project

Create a Tianshu Harness SDK project non-interactively (headless), driven by an agent instead of the interactive wizard. Use when asked to scaffold a new DSH SDK project without a terminal.

2026-08-13

このリポジトリのすべてを見る

DSH Upstream Customization

Classify and propose personal customizations upstream one feature at a time.

Classify

Definitely propose: bug fixes.

Propose: additive, non-conflicting features implemented as plugins; visual improvements.

Do not propose without maintainer approval: intrusive changes that alter existing architecture, core behavior, or broad contracts.

Explain the classification and upstream value. If unsure whether a change is intrusive, treat it as intrusive.

Classification and a recommendation are not publishing approval. Obtain explicit user approval naming one feature before pushing or opening a PR; approval for another feature, an upgrade, or local integration does not apply.

Publish an approved feature

Fetch current upstream master, then rebuild only the approved feature on a fresh branch and worktree at that exact commit. Never publish the personal staging branch or unrelated customizations.

Follow repository instructions for implementation, review, testing, disclosure, PR writing, and pre-push checks. Fix failures and rerun the affected checks before publishing.

Review the outgoing commits and diff against upstream. Confirm they contain only the approved feature, no credentials or personal data, and a clean worktree.

Reconfirm the approved feature name and publishing target before the first push. Do not infer authorization from earlier local work.

Push only that branch and open only a draft PR. Keep its description synchronized with later changes.

For a Web UI feature, attach a screenshot or GIF from the assembled application after removing credentials and personal data.

Report the upstream base and branch commits, commands and checks run, pushed branch, and draft PR URL.