Token导航 LogoToken导航TokenDH.com
效率需要联网clawhub未标认证来源可访问clear审计通过

nm-attune-project-planningnm attune 项目规划

Agent Skill

nm-attune-project-planning 用于补充效率相关能力,适合在 OpenClaw 中需要让 Agent 承接效率相关任务时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

5,184

周安装

216

GitHub Stars

公开资料未说明

下载量

1,728
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:nm-attune-project-planning(nm attune 项目规划)
来源仓库:https://github.com/athola/nm-attune-project-planning
安装命令:
openclaw skills install nm-attune-project-planning
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install nm-attune-project-planning

简介

将项目规范转换为带依赖关系的阶段性实施计划。

  • 适合在 OpenClaw 中拆解复杂任务并识别并行工作时使用。
  • 核心能力是建立任务间的前后依赖与资源分配。
  • 通过 clawhub 安装,建议输入清晰的需求描述。
  • 注意评估对上下文窗口的占用情况。nm-attune-project-planning 属于效率类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

name
project-planning
description
|
version
1.8.2
triggers
metadata
{"openclaw": {"homepage": "https://github.com/athola/claude-night-market/tree/master/plugins/attune", "emoji": "\�\�"}}
source
claude-night-market
source_plugin
attune
Night Market Skill — ported from claude-night-market/attune. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

Table of Contents

Project Planning Skill

Transform specification into implementation plan with architecture design and dependency-ordered tasks.

Delegation

For detailed task planning workflows, this skill delegates to spec-kit:task-planning as the canonical implementation. Use this skill for quick planning needs; use spec-kit for comprehensive project plans.

When To Use

  • After specification phase completes
  • Need to design system architecture
  • Need task breakdown for implementation
  • Planning sprints and resource allocation
  • Converting requirements into actionable tasks
  • Defining component interfaces and dependencies

When NOT To Use

  • No specification exists yet (use Skill(attune:project-specification) first)
  • Still exploring problem space (use Skill(attune:project-brainstorming) instead)
  • Ready to execute existing plan (use Skill(attune:project-execution) instead)
  • Need to adjust running project (update plan incrementally, don't restart)

Integration

With superpowers:

  • Uses Skill(superpowers:writing-plans) for structured planning
  • Applies checkpoint-based execution patterns
  • Uses dependency analysis framework

Without superpowers:

  • Standalone planning methodology
  • Task breakdown templates
  • Dependency tracking patterns

Planning Phases

Phase 1: Architecture Design

Activities:

  1. Identify system components
  2. Define component responsibilities
  3. Design interfaces between components
  4. Map data flows
  5. Select technologies

Output: Architecture documentation with diagrams

Phase 1.5: File Structure (REQUIRED)

Activities:

  1. Map which files will be created or modified
  2. Assign one-line purpose to each file
  3. Verify each file has a single clear responsibility
  4. Lock in decomposition decisions before task breakdown

This phase MUST complete before Phase 2 begins. Tasks reference files declared here; undeclared files require revisiting this phase.

Output: File structure table

Template:

FileActionPurpose
path/to/file.pyCreateOne-line purpose
path/to/existing.pyModifyWhat changes
path/to/obsolete.pyDeleteWhy removed

Validation:

  • Every file in the plan appears in this table
  • Every file has exactly one Action (Create/Modify/Delete)
  • No file appears twice with different actions
  • Purpose describes WHAT, not HOW

Phase 2: Task Breakdown

Activities:

  1. Decompose FRs into implementation tasks
  2. Add testing tasks for each FR
  3. Add infrastructure tasks
  4. Add documentation tasks
  5. Estimate each task

Output: Task list with estimates

Phase 3: Dependency Analysis

Activities:

  1. Identify task dependencies
  2. Create dependency graph
  3. Identify critical path
  4. Detect circular dependencies
  5. Optimize for parallelization

Output: Dependency-ordered task execution plan

Phase 4: Sprint Planning

Activities:

  1. Group tasks into sprints
  2. Balance sprint workload
  3. Identify milestones
  4. Plan releases
  5. Allocate resources

Output: Sprint schedule with milestones

Architecture Design Patterns

Component Identification

Questions:

  • What are the major functional areas?
  • What concerns should be separated?
  • What components can be developed independently?
  • What components can be reused?

Common Patterns:

  • Frontend/Backend: Separate UI from business logic
  • API Layer: Separate interface from implementation
  • Data Layer: Separate data access from business logic
  • Integration Layer: Isolate external dependencies

Component Template

### Component: [Name]

**Responsibility**: [What this component does]

**Technology**: [Stack and tools]

**Interfaces**:
- [Interface 1]: [Description]
- [Interface 2]: [Description]

**Dependencies**:
- [Component 1]: [What's needed]
- [Component 2]: [What's needed]

**Data**:
- [Data structure 1]
- [Data structure 2]

**Configuration**:
- [Config param 1]
- [Config param 2]

Task Breakdown Template

### TASK-[XXX]: [Task Name]

**Description**: [What needs to be done]

**Type**: Implementation | Testing | Documentation | Infrastructure | Deployment
**Priority**: P0 (Critical) | P1 (High) | P2 (Medium) | P3 (Low)
**Estimate**: [Story points or hours]
**Dependencies**: TASK-XXX, TASK-YYY
**Sprint**: Sprint N
**Assignee**: [Name or TBD]

**Linked Requirements**: FR-XXX, NFR-YYY

**Acceptance Criteria**:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] Tests passing
- [ ] Documentation updated

**Technical Notes**:
- [Implementation detail 1]
- [Implementation detail 2]

**Testing Requirements**:
- Unit tests: [What to test]
- Integration tests: [What to test]
- E2E tests: [What to test]

**Definition of Done**:
- [ ] Code complete
- [ ] Tests passing
- [ ] Code reviewed
- [ ] Documentation updated
- [ ] Deployed to staging

Task Estimation Guidelines

Story Points (Fibonacci):

  • 1 point: < 2 hours, trivial, well-understood
  • 2 points: 2-4 hours, straightforward
  • 3 points: 4-8 hours, some complexity
  • 5 points: 1-2 days, moderate complexity
  • 8 points: 2-3 days, significant complexity
  • 13 points: 3-5 days, high complexity (consider breaking down)
  • 21 points: > 5 days, very complex (MUST break down)

Factors to consider:

  • Technical complexity
  • Uncertainty/unknowns
  • Dependencies on other work
  • Testing requirements
  • Documentation needs

Dependency Graph

Notation:

TASK-001 (Foundation)
    ├─▶ TASK-002 (Database schema)
    │       ├─▶ TASK-003 (Models)
    │       └─▶ TASK-011 (Data import)
    └─▶ TASK-004 (Authentication)
            └─▶ TASK-005 (Auth middleware)
                    └─▶ TASK-010 (Protected endpoints)

Validation:

  • No circular dependencies (A depends on B, B depends on A)
  • Critical path identified
  • Parallel work opportunities identified
  • Blocking tasks highlighted

Sprint Structure

Sprint Template:

## Sprint [N]: [Focus Area]

**Dates**: [Start] - [End]
**Goal**: [Sprint objective]
**Capacity**: [Team capacity in story points]

### Planned Tasks ([X] story points)
- TASK-XXX ([N] points)
- TASK-YYY ([M] points)
- ...

### Deliverable
[What will be demonstrable at sprint end]

### Risks
- [Risk 1 with mitigation]
- [Risk 2 with mitigation]

### Dependencies
- [External dependency 1]
- [External dependency 2]

Risk Assessment

Risk Template:

| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| [Risk description] | High/Med/Low | High/Med/Low | [How to address] |

Common Risks:

  • Technology unknowns
  • Third-party API dependencies
  • Resource availability
  • Scope creep
  • Performance issues
  • Security vulnerabilities

Output Format

Save to docs/implementation-plan.md:

# [Project Name] - Implementation Plan v[version]

**Author**: [Name]
**Date**: [YYYY-MM-DD]
**Sprint Length**: [Duration]
**Team Size**: [Number]
**Target Completion**: [Date]

## Architecture

### System Overview
[High-level architecture description]

### Component Diagram
[ASCII or markdown diagram]

### Components
[Component details using template above]

### Data Flow
[How data moves through system]

## File Structure

| File | Action | Purpose |
|------|--------|---------|
| [path] | Create/Modify/Delete | [purpose] |

## Task Breakdown

### Phase 1: [Name] (Sprint [N]) - TASK-001 through TASK-010

[Tasks using template above]

### Phase 2: [Name] (Sprint [M]) - TASK-011 through TASK-020

[Tasks using template above]

## Dependency Graph

[Dependency visualization]

## Sprint Schedule

[Sprint details using template above]

## Risk Assessment

[Risk table]

## Success Metrics

- [ ] [Metric 1]
- [ ] [Metric 2]

## Timeline

| Sprint | Dates | Focus | Deliverable |
|--------|-------|-------|-------------|
| 1 | Jan 3-16 | Foundation | Dev environment |
| 2 | Jan 17-30 | Core | Feature X working |

## Next Steps

1. Review plan with team
2. Initialize project with `/attune:project-init`
3. Start execution with `/attune:execute`

Quality Checks

Before completing plan:

  • ✅ All architecture components documented
  • ✅ File Structure section present before tasks
  • ✅ All task files appear in File Structure table
  • ✅ All FRs mapped to tasks
  • ✅ All tasks have acceptance criteria
  • ✅ Dependencies are acyclic
  • ✅ Effort estimates provided
  • ✅ Critical path identified
  • ✅ Risks assessed with mitigations
  • ✅ Sprints balanced by capacity

Post-Completion: Workflow Continuation (REQUIRED)

Automatic Trigger: After Quality Checks pass and docs/implementation-plan.md is saved, MUST auto-invoke the next phase.

When continuation is invoked:

  1. Verify docs/implementation-plan.md exists and is non-empty
  2. Display checkpoint message to user:
   Implementation plan complete. Saved to docs/implementation-plan.md.
   Proceeding to execution phase...
  1. Invoke next phase:
   Skill(attune:project-execution)

Bypass Conditions (ONLY skip continuation if ANY true):

  • --standalone flag was provided by the user
  • docs/implementation-plan.md does not exist or is empty (phase failed)
  • User explicitly requests to stop after planning

Do NOT prompt the user for confirmation — this is a lightweight checkpoint, not an interactive gate. The user can always interrupt if needed.

Related Skills

  • Skill(superpowers:writing-plans) - Planning methodology (if available)
  • Skill(spec-kit:task-planning) - Task breakdown (if available)
  • Skill(attune:project-specification) - Previous phase
  • Skill(attune:project-execution) - AUTO-INVOKED next phase after planning
  • Skill(attune:mission-orchestrator) - Full lifecycle orchestration

Related Commands

  • /attune:blueprint - Invoke this skill
  • /attune:execute - Next step in workflow

Examples

See /attune:blueprint command documentation for complete examples.

Troubleshooting

Common Issues

If you find circular dependencies in your task graph, break one of the tasks into smaller sub-tasks. If sprint capacity is consistently exceeded, re-estimate tasks using the Fibonacci scale or reduce sprint scope.

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

78%
按下载量换算1,348

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills