Plugin-authoring guidance caps skill length at 500 lines but sets no maximum line length
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- ドキュメント
- 明瞭さ
- 説明が足りない
- 活発さ
- 静か
調査の方向性
Start by comparing the 500-line guidance in progressive-disclosure.md and cowork-specific-skill-instructions.md with agent-building-guidelines/agent-description-length.md. Decide whether to use line, character, or token limits, which files they cover, and whether they are enforced or recommended. Done means the guidance has a consistent, explicit policy for skills, agents, and references.
索引モデルが issue の本文から書いたものです。
説明
Summary
The plugin-authoring guidance caps SKILL.md length at 500 lines but sets no maximum line length. Agent guidance is looser still: it has no body line-count cap or line-length rule at all, only a frontmatter description character budget.
Where the cap lives
han-plugin-builder/skills/guidance/references/skill-building-guidance/progressive-disclosure.md(line 36) — "keep the SKILL.md body under 500 lines... Treat 500 lines as the ceiling, not the target." No line-length rule.han-plugin-builder/skills/guidance/references/skill-building-guidance/cowork-specific-skill-instructions.md(lines 167, 249) — repeats the 500-line cap. No line-length rule.han-plugin-builder/skills/guidance/references/agent-building-guidelines/— the only length guidance isagent-description-length.md(description char budget: 1024 target, ~1500 hard signal). No body line-count or line-length rule for agents.
Why it matters
The 500-line cap exists to bound how much content a skill loads into the model's context window and to keep bloaty skills from distracting agents. But a line is unbounded in length, so a line-count cap alone is a leaky proxy for content volume: 500 very long lines can blow past the intended budget. Without a line-length bound (or a more direct measure), the 500-line ceiling doesn't reliably do the job it exists for.
Open question
Not just "what max line length" — the real question is which lever is right:
- a per-line character cap (e.g. 80 / 100 / 120, or semantic line breaks / one sentence per line), or
- a total character or token budget that measures content volume directly, or
- keeping the line-count cap and adding a line-length bound so it stops being a leaky proxy.
Scope to decide alongside it: does it apply to agent bodies and references/ files too, not just SKILL.md? Hard cap or recommendation? A judgment call, or something a formatter/linter enforces?
- 主要言語
- Shell
- スター
- 275
- フォーク
- 23
- 平均マージ
- 1日 8時間
- マージ済み PR（30日）
- 12
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
testdouble/han のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
testdouble/han#215 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 45/100
testdouble/han#217 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
testdouble/han#216 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 45/100
testdouble/han#203 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
testdouble/han#202 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
unixorn/awesome-zsh-plugins#2285 ·
メンテナーはふだん 1 日以内に返信
-
documentation priority: low
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
snapotter-hq/SnapOtter#1863 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
nasa-jpl/bespokebpv7#51 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
area/rules
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
usnistgov/macos_security#836 ·
メンテナーはふだん 1 日以内に返信