Back to Details

dev-new-tool

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

New Tool Kickoff

新工具启动流程

A structured workflow for turning a tool idea into a working MVP. Covers the full cycle: research existing solutions, brainstorm approach, write a plan, scaffold the project, build core features, and write documentation.
一套将工具想法转化为可用MVP的结构化工作流，覆盖完整周期：调研现有解决方案、构思实现方案、编写计划、搭建项目框架、开发核心功能以及撰写文档。

When to Use

适用场景

  • User says "I have an idea for a tool/CLI/library"
  • User wants to start a new project from scratch
  • User wants to research feasibility before building
  • Greenfield development of a focused tool or CLI
  • 用户提出“我有一个工具/CLI/库的想法”
  • 用户希望从零开始启动新项目
  • 用户希望在开发前调研可行性
  • 针对特定工具或CLI的全新开发（Greenfield开发）

Workflow

工作流

Phase 1: Research (Stop point: get user approval before Phase 2)

阶段1：调研（停止点：进入阶段2前需获得用户确认）

Goal: Understand the landscape before building.
  1. Clarify the idea: Ask what problem the tool solves, who uses it, and what the core workflow looks like
  2. Search for existing tools: Web search for similar tools, libraries, or CLIs
  3. Evaluate alternatives: For each existing tool found:
    • What does it do well?
    • What gaps or limitations does it have?
    • Is it actively maintained?
  4. API/Integration research: If the tool integrates with external services, research their APIs:
    • Authentication methods
    • Rate limits and pagination
    • Data models and available endpoints
  5. Present findings: Summarize as a brief landscape overview:
    • Existing tools and their limitations
    • API capabilities (if applicable)
    • Recommended approach based on findings
Ask the user: "Based on this research, should we proceed with building? Any adjustments to the concept?"
目标：在开发前了解现有市场格局。
  1. 明确需求：询问该工具解决的问题、目标用户以及核心工作流程
  2. 搜索现有工具：通过网络搜索同类工具、库或CLI
  3. 评估替代方案：针对每个找到的现有工具：
    • 它的优势是什么？
    • 存在哪些缺口或局限性？
    • 是否处于活跃维护状态？
  4. API/集成调研：如果工具需要与外部服务集成，调研其API：
    • 认证方式
    • 速率限制与分页机制
    • 数据模型与可用接口
  5. 呈现调研结果：以简洁的格局概述形式总结：
    • 现有工具及其局限性
    • API能力（如适用）
    • 基于调研结果的推荐方案
询问用户：“基于以上调研结果，我们是否继续推进开发？是否需要调整初始概念？”

Phase 2: Brainstorm & Design (Stop point: get user approval before Phase 3)

阶段2：构思与设计（停止点：进入阶段3前需获得用户确认）

Goal: Nail down the approach before writing code.
  1. Core features: Identify the minimum set of features for a useful v1
  2. Technology choices: Recommend language, frameworks, and key dependencies based on:
    • User's preferences and existing projects
    • Tool requirements (CLI, TUI, web, library)
    • Available ecosystem (Go for CLI tools, TypeScript for Node ecosystem, etc.)
  3. Interface design: Define the user-facing interface:
    • CLI: command structure, flags, arguments
    • Library: public API surface
    • TUI: key bindings, views
  4. Architecture sketch: High-level component breakdown (keep it simple — avoid over-engineering)
  5. Name the project: Suggest a name if the user hasn't chosen one (or invoke the 
    project-namer
    skill)
Ask the user: "Here's the proposed design. What adjustments?"
目标：在编写代码前确定实现方案。
  1. 核心功能：确定v1版本所需的最小可用功能集
  2. 技术选型：基于以下因素推荐编程语言、框架及关键依赖：
    • 用户的偏好与现有项目技术栈
    • 工具需求（CLI、TUI、Web应用、库）
    • 可用生态系统（如Go适用于CLI工具，TypeScript适用于Node生态等）
  3. 界面设计：定义用户交互界面：
    • CLI：命令结构、标志、参数
    • 库：公开API接口
    • TUI：快捷键、视图布局
  4. 架构草图：高层组件拆分（保持简洁，避免过度设计）
  5. 项目命名：如果用户尚未确定名称，建议合适的名称（或调用
    project-namer
    技能）
询问用户：“以上是拟定的设计方案，是否需要调整？”

Phase 3: Plan

阶段3：制定计划

Goal: Create an executable implementation plan.
  1. Write a plan file to the repo (
    .claude/plans/[project-name].md
    or a location the user specifies)
  2. The plan should include:
    • Goal: One-sentence summary
    • Scope: What's in v1, what's deferred
    • Steps: Numbered implementation steps with clear deliverables
    • File structure: Expected project layout
    • Dependencies: Key libraries to use
    • Test strategy: What to test and how
  3. Keep the plan concise — under 100 lines. The plan is a contract, not a design doc.
Ask the user: "Plan is ready. Proceed with implementation?"
目标：创建可执行的实现计划。
  1. 向代码仓库中写入计划文件（路径为
    .claude/plans/[project-name].md
    或用户指定的位置）
  2. 计划应包含以下内容：
    • 目标：一句话总结
    • 范围：v1版本包含的功能，以及延后实现的功能
    • 步骤：带明确交付物的编号实现步骤
    • 文件结构：预期的项目布局
    • 依赖项：将使用的核心库
    • 测试策略：测试内容与方式
  3. 计划需简洁，控制在100行以内。计划是执行契约，而非设计文档。
询问用户：“计划已准备就绪，是否开始实现？”

Phase 4: Scaffold & Build

阶段4：搭建框架与开发

Goal: Get to a working MVP.
  1. Initialize project:
    • Create directory structure
    • Initialize module/package (go mod init, npm init, etc.)
    • Set up linting and formatting config
    • Create .gitignore
  2. Implement core features: Work through plan steps in order
    • Write tests alongside implementation (not after)
    • Commit at logical checkpoints
    • If a step gets complex, break it down further
  3. Verify: Run the full test suite, lint, and build before moving on
目标：完成可用MVP的开发。
  1. 初始化项目：
    • 创建目录结构
    • 初始化模块/包（如go mod init、npm init等）
    • 配置代码检查与格式化工具
    • 创建.gitignore文件
  2. 实现核心功能：按计划步骤依次推进
    • 边实现边编写测试（而非事后补测）
    • 在关键节点提交代码
    • 如果某一步骤过于复杂，进一步拆分细化
  3. 验证：在进入下一阶段前运行完整测试套件、代码检查与构建流程

Phase 5: Polish & Document

阶段5：优化与文档编写

Goal: Make the tool usable by others.
  1. README: Write a README with:
    • Clear description and tagline
    • Installation instructions
    • Quick start / usage examples
    • Configuration reference (if applicable)
  2. CLI help: Ensure all commands have proper help text and examples
  3. License: Add an appropriate license file (default: MIT unless user specifies)
  4. Final review: Run a quick scan: 
    • go vet
      / 
      eslint
      / equivalent for the language
    • Check for hardcoded paths or secrets
    • Verify README matches actual CLI interface
目标：让工具可供他人使用。
  1. README文档：编写包含以下内容的README：
    • 清晰的描述与标语
    • 安装说明
    • 快速开始/使用示例
    • 配置参考（如适用）
  2. CLI帮助文档：确保所有命令都有完善的帮助文本与示例
  3. 许可证：添加合适的许可证文件（默认：MIT，除非用户指定其他类型）
  4. 最终检查：快速扫描以下内容：
    • 对应语言的代码检查工具（如
      go vet
      /
      eslint
      等）
    • 检查是否存在硬编码路径或敏感信息
    • 验证README与实际CLI界面是否一致

Adapting the Workflow

工作流适配

  • If the user already researched: Skip Phase 1, start at Phase 2
  • If the user has a plan: Skip to Phase 4
  • If the user wants just research: Stop after Phase 1
  • If adding to existing project: Skip scaffolding in Phase 4, focus on the new feature
  • 如果用户已完成调研：跳过阶段1，直接从阶段2开始
  • 如果用户已有计划：直接进入阶段4
  • 如果用户仅需要调研：完成阶段1后停止
  • 如果是向现有项目添加功能：跳过阶段4的项目搭建步骤，专注于新功能开发

Tips

小贴士

  • Prefer simplicity in v1. The user can always add features later.
  • For CLI tools, the user prefers Go with cobra/viper patterns.
  • Always verify with web search before recommending libraries — check for maintenance status and compatibility.
  • Use conventional commits during implementation.
  • Don't over-engineer: no feature flags, no plugin systems, no config file formats beyond what's needed for v1.
  • v1版本优先保持简洁，用户可在后续版本添加功能。
  • 对于CLI工具，优先推荐使用Go语言及cobra/viper模式。
  • 在推荐库之前，务必通过网络搜索验证——检查维护状态与兼容性。
  • 实现过程中使用规范的提交信息。
  • 避免过度设计：v1版本无需功能开关、插件系统或超出需求的配置文件格式。

Examples

示例

Example 1: CLI tool from idea
User: "I want to build a CLI tool for Slack using Go"
Action:
1. Research existing Slack CLI tools (slackcli, etc.)
2. Research Slack API capabilities
3. Brainstorm: core commands (messages, channels, search)
4. Plan: write implementation plan
5. Build: scaffold Go project, implement core commands
6. Document: write README with install + usage
Example 2: Research only
User: "I'm thinking of creating some linter. Research if there's anything similar."
Action:
1. Search for existing linters in the relevant space
2. Compare features, limitations, maintenance status
3. Present findings and recommendation
4. Stop — wait for user to decide next steps
Example 3: Tool with external API
User: "I want to create a Fireflies CLI"
Action:
1. Research Fireflies API docs, authentication, endpoints
2. Research existing Fireflies integrations
3. Design: core features (list meetings, get transcript, action items)
4. Plan and build with API client as foundation
示例1：从想法到CLI工具
用户："我想用Go开发一个Slack CLI工具"
行动：
1. 调研现有Slack CLI工具（如slackcli等）
2. 调研Slack API能力
3. 构思：核心命令（消息、频道、搜索）
4. 计划：编写实现计划
5. 开发：搭建Go项目框架，实现核心命令
6. 文档：编写包含安装与使用说明的README
示例2：仅调研
用户："我想开发一个代码检查工具，调研是否有同类产品。"
行动：
1. 搜索相关领域的现有代码检查工具
2. 对比功能、局限性与维护状态
3. 呈现调研结果与推荐方案
4. 停止——等待用户决定下一步行动
示例3：涉及外部API的工具
用户："我想开发一个Fireflies CLI工具"
行动：
1. 调研Fireflies API文档、认证方式与接口
2. 调研现有Fireflies集成工具
3. 设计：核心功能（列出会议、获取转录文本、行动项）
4. 计划并以API客户端为基础进行开发