Agent写作
- 作者仓库星标 3,406
- 作者更新于 实时读取
- 作者仓库 claude-octopus
- 领域
- 写作
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @nyldn · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS · Linux · Windows
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-writing-plans
description: Create zero-context implementation plans with bite-sized tasks — use for multi-step feature plan…
category: 写作
runtime: 无特殊运行时
---
# skill-writing-plans 输出预览
## PART A: 任务判断
- 适用问题:文章、文案、发言稿、润色或结构化表达。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“MANDATORY COMPLIANCE — DO NOT SKIP / Overview / Plan Document Structure”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于文章、文案、发言稿、润色或结构化表达,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“MANDATORY COMPLIANCE — DO NOT SKIP / Overview / Plan Document Structure”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/octo` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“MANDATORY COMPLIANCE — DO NOT SKIP / Overview / Plan Document Structure”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: skill-writing-plans
description: Create zero-context implementation plans with bite-sized tasks — use for multi-step feature plan…
category: 写作
source: nyldn/claude-octopus
---
# skill-writing-plans
## 什么时候使用
- 用于组织测试、定位失败并形成修复闭环 适合处理文章、文案、润色、翻译、总结和结构化表达,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤;通常不需要额外 AP…
- 面向文章、文案、发言稿、润色或结构化表达,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「MANDATORY COMPLIANCE — DO NOT SKIP / Overview / Plan Document Structure」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "skill-writing-plans" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> MANDATORY COMPLIANCE — DO NOT SKIP / Overview / Plan Document Structure
规则层 -> 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.
Writing Plans
MANDATORY COMPLIANCE — DO NOT SKIP
When this skill is invoked, you MUST produce a full implementation plan following the structure below. You are PROHIBITED from:
- Skipping the plan and jumping straight to implementation
- Producing a vague outline instead of the zero-context plan format
- Deciding the task is "simple enough" to not need a plan
- Omitting file paths, complete code, test instructions, or verification steps
The user asked for a plan, not an implementation. Write the plan first.
Your first output line MUST be: 🐙 **CLAUDE OCTOPUS ACTIVATED** - Implementation Planning
Overview
Write comprehensive implementation plans assuming the engineer has zero context for the codebase and questionable taste.
Document everything: which files to touch, complete code, how to test, how to verify.
Principles: DRY. YAGNI. TDD. Frequent commits.
Plan Document Structure
Header (Required)
# [Feature Name] Implementation Plan
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
**Estimated Time:** [X tasks × 5 min = Y minutes]
## Prerequisites
- [ ] [Any setup needed before starting]
- [ ] [Dependencies to install]
- [ ] [Files that must exist]
Task Granularity
Each task is ONE action (2-5 minutes):
| Good (Single Action) | Bad (Multiple Actions) |
|---|---|
| "Write the failing test" | "Write tests and implement" |
| "Run test to verify it fails" | "Make it work" |
| "Implement minimal code to pass" | "Add the feature" |
| "Commit with message" | "Finish the feature" |
Task Template
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/new-file.ts`
- Modify: `exact/path/to/existing.ts` (lines 45-67)
- Test: `tests/exact/path/to/test.spec.ts`
**Step 1: Write failing test**
```typescript
// tests/exact/path/to/test.spec.ts
describe('ComponentName', () => {
it('should do specific thing', () => {
const result = functionName(input);
expect(result).toBe(expected);
});
});
Step 2: Run test to verify it fails
npm test tests/exact/path/to/test.spec.ts
Expected output:
FAIL: expected 'expected' but got undefined
Step 3: Implement minimal code
// exact/path/to/new-file.ts
export function functionName(input: InputType): OutputType {
// Minimal implementation
return expected;
}
Step 4: Run test to verify it passes
npm test tests/exact/path/to/test.spec.ts
Expected output:
PASS: 1/1 tests passed
Step 5: Commit
git add tests/exact/path/to/test.spec.ts exact/path/to/new-file.ts
git commit -m "feat(component): add specific functionality"
## Example: Complete Task
```markdown
### Task 3: Add Email Validation
**Files:**
- Create: `src/validators/email.ts`
- Test: `tests/validators/email.spec.ts`
**Step 1: Write failing test**
```typescript
// tests/validators/email.spec.ts
import { validateEmail } from '../src/validators/email';
describe('validateEmail', () => {
it('returns error for empty email', () => {
const result = validateEmail('');
expect(result).toEqual({ valid: false, error: 'Email required' });
});
it('returns error for invalid format', () => {
const result = validateEmail('not-an-email');
expect(result).toEqual({ valid: false, error: 'Invalid email format' });
});
it('returns valid for correct email', () => {
const result = validateEmail('user@example.com');
expect(result).toEqual({ valid: true });
});
});
Step 2: Run test to verify it fails
npm test tests/validators/email.spec.ts
Expected: Cannot find module '../src/validators/email'
Step 3: Implement minimal code
// src/validators/email.ts
interface ValidationResult {
valid: boolean;
error?: string;
}
export function validateEmail(email: string): ValidationResult {
if (!email || !email.trim()) {
return { valid: false, error: 'Email required' };
}
const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
if (!emailRegex.test(email)) {
return { valid: false, error: 'Invalid email format' };
}
return { valid: true };
}
Step 4: Run test to verify it passes
npm test tests/validators/email.spec.ts
Expected: PASS: 3/3 tests passed
Step 5: Commit
git add src/validators/email.ts tests/validators/email.spec.ts
git commit -m "feat(validators): add email validation with tests"
## Integration with Claude Octopus
### Using Octopus for Plan Execution
After creating a plan, offer execution options:
```markdown
## Execution Options
**1. Sequential (this session)**
Execute tasks one by one with verification between each.
**2. Parallel (octopus tangle)**
Use Claude Octopus to parallelize independent tasks:
```bash
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh tangle "Execute implementation plan for [feature]"
3. Full workflow (octopus embrace) Research → Define → Implement → Deliver:
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh embrace "Implement [feature] per plan"
### Plan Storage (Claude Code v2.1.10)
Claude Octopus uses session-aware plan storage. Plans are automatically saved to:
~/.claude-octopus/plans/${CLAUDE_SESSION_ID}/YYYY-MM-DD-feature-name.md
This integrates with Claude Code's `plansDirectory` setting. To customize:
```json
// settings.json
{
"plansDirectory": "~/.claude-octopus/plans"
}
For project-local plans, save to docs/plans/:
mkdir -p docs/plans
# docs/plans/2026-01-17-user-authentication.md
Checklist for Good Plans
- Each task is 2-5 minutes (single action)
- Exact file paths (not "in the utils folder")
- Complete code (not "add validation logic")
- Exact commands with expected output
- TDD: test before implementation
- Commit after each task
Common Mistakes
| Mistake | Fix |
|---|---|
| "Add the validation" | Show exact code |
| "Update the tests" | Show exact test code |
| "In the config file" | config/app.config.ts line 23 |
| "Run the tests" | npm test path/to/specific.spec.ts |
| Large tasks (30+ min) | Break into 2-5 min steps |
| No verification | Add "Run X, expect Y" |
When to Create Plans
| Scenario | Use Plan? |
|---|---|
| Multi-step feature (3+ tasks) | Yes |
| Simple bug fix (1 task) | No, just do it |
| Uncertain scope | Yes (clarifies thinking) |
| Delegation to subagent | Yes (zero-context execution) |
| Complex refactoring | Yes |
| Config change | No |
Related Skills
- test-driven-development - Each task follows TDD cycle
- verification-before-completion - Verify each step
- finishing-branch - After all tasks complete
The Bottom Line
Plan exists → Engineer with zero context can execute
Otherwise → Not a complete plan
Exact paths. Complete code. Verification steps. No assumptions.
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核