Agent设计
- 作者仓库星标 3,406
- 作者更新于 实时读取
- 作者仓库 claude-octopus
- 领域
- 设计与多媒体
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @nyldn · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-design-lineage
description: Persist design documents with branch tracking, revision chains, and cross-session discovery Pers…
category: 设计与多媒体
runtime: 无特殊运行时
---
# skill-design-lineage 输出预览
## PART A: 任务判断
- 适用问题:视觉内容、演示材料、信息图或设计交付。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Overview / Storage Location / Filename Format”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于视觉内容、演示材料、信息图或设计交付,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Overview / Storage Location / Filename Format”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/octo` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Overview / Storage Location / Filename Format”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: skill-design-lineage
description: Persist design documents with branch tracking, revision chains, and cross-session discovery Pers…
category: 设计与多媒体
source: nyldn/claude-octopus
---
# skill-design-lineage
## 什么时候使用
- 把设计与视觉方向的常用动作沉淀成 Agent 可调用的技能 适合处理界面、视觉、封面、信息图或演示材料交付,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤…
- 面向视觉内容、演示材料、信息图或设计交付,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Overview / Storage Location / Filename Format」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "skill-design-lineage" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Overview / Storage Location / Filename Format
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than
/octo:*slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, seeskills/blocks/codex-host-adapter.md.
Design Document Lineage
Overview
Persist design documents from brainstorming and planning sessions with branch tracking, revision chains, and cross-session discoverability. Design docs are immutable after creation -- new revisions supersede prior versions rather than editing in place.
Storage Location
All design documents are stored under:
~/.claude-octopus/designs/<project-slug>/
The project slug is derived from the current git repository name or working directory basename:
SLUG=$(basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
DESIGNS_DIR="${HOME}/.claude-octopus/designs/${SLUG}"
mkdir -p "$DESIGNS_DIR"
Filename Format
Design documents follow a strict naming convention:
{user}-{branch}-design-{datetime}.md
Where:
{user}-- the current OS username ($USERorwhoami){branch}-- the current git branch, sanitized (slashes replaced with dashes){datetime}-- ISO 8601 compact timestamp (YYYYMMDD-HHmmss)
Example:
chris-feature-auth-refactor-design-20260321-143022.md
Resolution:
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo "no-branch")
DATETIME=$(date -u +"%Y%m%d-%H%M%S")
FILENAME="${USER}-${BRANCH}-design-${DATETIME}.md"
Design Document Template
Each design document contains YAML frontmatter followed by structured sections.
Frontmatter Metadata
branch: feature/auth-refactor
user: chris
created: 2026-03-21T14:30:22Z
supersedes: chris-feature-auth-refactor-design-20260320-091500.md
Fields:
branch-- the git branch at time of creationuser-- the OS username who created the documentcreated-- ISO 8601 timestamp of creationsupersedes-- filename of the prior design document this revision replaces (omitted if this is the first design for the branch)
Document Sections
# Design: [Title]
## Problem Statement
[What problem does this design solve? Why does it matter?]
## Constraints
[Technical, timeline, resource, or organizational constraints that bound the solution space.]
## Approaches Considered
[List each approach evaluated, with brief pros/cons for each.]
### Approach A: [Name]
- **Pros:** ...
- **Cons:** ...
### Approach B: [Name]
- **Pros:** ...
- **Cons:** ...
## Recommendation
[Which approach is recommended and why. Include the key trade-off that drove the decision.]
## Open Questions
[Unresolved questions that may affect implementation or require follow-up.]
Step 1: Save Design
After a brainstorm, planning, or define workflow produces design output, save it to the standard location with metadata.
SLUG=$(basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
DESIGNS_DIR="${HOME}/.claude-octopus/designs/${SLUG}"
mkdir -p "$DESIGNS_DIR"
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo "no-branch")
DATETIME=$(date -u +"%Y%m%d-%H%M%S")
FILENAME="${USER}-${BRANCH}-design-${DATETIME}.md"
FILEPATH="${DESIGNS_DIR}/${FILENAME}"
cat > "$FILEPATH" <<EOF
branch: $(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "no-branch")
user: ${USER}
created: $(date -u +"%Y-%m-%dT%H:%M:%SZ")
${SUPERSEDES:+supersedes: ${SUPERSEDES}}
# Design: [Title]
## Problem Statement
[Content from brainstorm/planning session]
## Constraints
[Identified constraints]
## Approaches Considered
[Evaluated approaches]
## Recommendation
[Selected approach and rationale]
## Open Questions
[Unresolved items]
EOF
Design docs are read-only after creation. To revise a design, create a new document with a supersedes reference to the prior version.
Step 2: Discover Prior Designs
Before writing a new design, search for related prior designs using keyword matching.
SLUG=$(basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
DESIGNS_DIR="${HOME}/.claude-octopus/designs/${SLUG}"
# Search for designs matching keywords (case-insensitive)
KEYWORDS="auth refactor"
grep -li "$KEYWORDS" "${DESIGNS_DIR}"/*.md 2>/dev/null | head -10
Constraints:
- Keyword search is limited to 10 results to avoid overwhelming context
- Search is case-insensitive via
grep -li - Only searches within the current project slug's directory
When prior designs are found, present them to the user:
Found 2 prior designs related to "auth refactor":
1. chris-feature-auth-refactor-design-20260320-091500.md (2026-03-20)
2. chris-main-design-20260315-140000.md (2026-03-15)
Would you like to review any of these before creating a new design?
Step 3: Link Revision Chain
If a prior design exists for the same branch, the new design document includes a supersedes field in its frontmatter pointing to the prior filename.
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo "no-branch")
# Find the most recent design for this branch
PRIOR=$(ls -t "${DESIGNS_DIR}"/*-${BRANCH}-design-*.md 2>/dev/null | head -1)
if [[ -n "$PRIOR" ]]; then
SUPERSEDES=$(basename "$PRIOR")
fi
This creates a linked chain of revisions:
v3 (supersedes: v2) -> v2 (supersedes: v1) -> v1 (no supersedes)
To walk the full revision history for a branch:
current="$FILENAME"
while [[ -n "$current" ]]; do
echo "$current"
current=$(grep '^supersedes:' "${DESIGNS_DIR}/${current}" 2>/dev/null | sed 's/supersedes: *//' || true)
done
Step 4: Cross-Session Discovery
Downstream commands (deliver, review, develop) auto-discover design context by checking the designs directory before starting work.
SLUG=$(basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
DESIGNS_DIR="${HOME}/.claude-octopus/designs/${SLUG}"
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo "no-branch")
# Find designs for current branch
BRANCH_DESIGNS=$(ls -t "${DESIGNS_DIR}"/*-${BRANCH}-design-*.md 2>/dev/null | head -3)
if [[ -n "$BRANCH_DESIGNS" ]]; then
echo "Design context found for branch ${BRANCH}:"
for design in $BRANCH_DESIGNS; do
echo " - $(basename "$design")"
done
# Read the most recent design for context
LATEST_DESIGN=$(echo "$BRANCH_DESIGNS" | head -1)
DESIGN_CONTEXT=$(<"$LATEST_DESIGN")
fi
Downstream skills should check for designs before starting work:
- flow-discover: Check for existing designs to avoid duplicate research
- flow-define: Incorporate prior design constraints into requirements
- flow-develop: Read the recommended approach from the latest design
- skill-brainstorm: Surface prior designs as starting context
Caps and Limits
- Max 50 design docs per project slug -- when the limit is reached, warn the user and suggest archiving old designs
- Keyword search limited to 10 results -- prevents context overload
- Design doc template max 500 lines -- encourages concise, actionable designs
Cap enforcement:
DOC_COUNT=$(ls "${DESIGNS_DIR}"/*.md 2>/dev/null | wc -l | tr -d ' ')
if [[ "$DOC_COUNT" -ge 50 ]]; then
echo "Warning: ${DOC_COUNT} design docs in ${DESIGNS_DIR}. Consider archiving old designs."
fi
Integration Notes
Works With
- flow-discover -- Design docs capture research findings for persistence
- flow-define -- Design constraints feed into requirement definitions
- skill-brainstorm -- Brainstorm output can be saved as a design document
- skill-thought-partner -- Exploration sessions can produce design artifacts
Downstream Discovery
- flow-develop -- Reads latest design before implementation
- flow-deliver -- References design decisions during review
- skill-code-review -- Checks implementation against design recommendations
Immutability Rule
Design docs are read-only after creation. To update a design:
- Create a new design document
- Set
supersedesto the prior document's filename - The prior document remains unchanged for audit trail
This ensures a complete history of design evolution is always available.
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核