What makes task-planning notable?

1.7K downloads. Trust evidence available

How should task-planning be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

task-planning

Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation Skill: task-planning Owner: athola Summary: Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:23:22.185Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:43:06.554Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:59:57.477Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.7k

Updated

Oct 10, 2026

Version

1.9.19

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.7K downloads reported by the source. Last updated 10/10/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.7K downloadsadoption · observed Oct 10, 2026
Latest release: 1.9.19release · observed Aug 26, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-spec-kit-task-planning

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/snapshot"

Documentation

CLAWHUB

144,749 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: task-planning
description: |
  Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation
version: 1.9.8
triggers:
  - speckit
  - tasks
  - planning
  - implementation
  - dependencies
metadata: {"openclaw": {"homepage": "https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit", "emoji": "\ud83e\udd9e", "requires": {"config": ["night-market.superpowers:writing-plans", "night-market.superpowers:executing-plans"]}}}
source: claude-night-market
source_plugin: spec-kit
---

> **Night Market Skill** — ported from [claude-night-market/spec-kit](https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit). For the full experience with agents, hooks, and commands, install the Claude Code plugin.


# Task Planning

## Overview

Transforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.

## When To Use

- Converting specifications to implementation tasks
- Planning feature implementation order
- Identifying parallel execution opportunities
- Breaking down complex features into phases

## When NOT To Use

- Writing specifications - use spec-writing

## Task Phases

Tasks follow a 5-phase structure from setup through polish:

- **Phase 0: Setup** - Project initialization, dependencies, configuration
- **Phase 1: Foundation** - Data models, interfaces, test infrastructure
- **Phase 2: Core Implementation** - Business logic, APIs, services
- **Phase 3: Integration** - External services, middleware, logging
- **Phase 4: Polish** - Optimization, documentation, final testing

For detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.

## Task Format

Each task includes:
- **ID**: Unique identifier (TASK-001)
- **Description**: Clear action statement
- **Phase**: Which phase it belongs to
- **Dependencies**: Tasks that must complete first
- **Parallel Marker**: [P] if can run concurrently
- **Files**: Affected file paths
- **Criteria**: How to verify completion

## Dependency Rules

Dependencies define execution order and identify parallelization opportunities:

- **Sequential Tasks**: Execute in strict order when dependencies exist
- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met
- **File Coordination**: Tasks affecting same files MUST run sequentially

**Nonconflicting Criteria for Parallel Execution**:
- ✅ Files: No file overlap between tasks
- ✅ State: No shared configuration or global state
- ✅ Dependencies: All prerequisites satisfied
- ✅ Code paths: No merge conflicts possible
- ✅ Outputs: Tasks don't need each other's results

**Mark tasks with [P] ONLY if they pass ALL criteria above.**

For fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.

## Example Task Entry

```markdown
## Phase 2: Cor

_meta.json

{
  "ownerId": "kn7d107jg9jv602h9ytsegydq184a42s",
  "slug": "nm-spec-kit-task-planning",
  "version": "1.9.19",
  "publishedAt": 1787750602185
}

modules/dependency-patterns.md

# Task Dependency Patterns

## Overview

Dependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.

## Dependency Types

### Sequential Dependencies

**Definition**: Task B cannot start until Task A completes

**When to Use**:
- Task B modifies output from Task A
- Task B requires interfaces/types defined in Task A
- Task B tests functionality implemented in Task A
- Tasks affect the same file(s)

**Example**:
```markdown
### TASK-002 - Define Task data model
**Dependencies**: TASK-001
**Files**: src/models/task.py

### TASK-003 - Implement task validation
**Dependencies**: TASK-002
**Files**: src/models/task.py, src/validators/task.py
```

**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.

### Parallel Dependencies [P]

**Definition**: Tasks can execute concurrently with no conflicts

**When to Use**:
- No shared dependencies beyond a common foundation
- Operate on different files
- Independent feature implementations
- Separate test suites

**Marker**: Suffix task with `[P]`

**Example**:
```markdown
### TASK-004 - Implement user authentication [P]
**Dependencies**: TASK-001
**Files**: src/services/auth.py, tests/test_auth.py

### TASK-005 - Implement task storage [P]
**Dependencies**: TASK-001
**Files**: src/services/storage.py, tests/test_storage.py
```

**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.

### Fan-Out Pattern

**Definition**: Multiple tasks depend on single foundation task

**Pattern**:
```
TASK-001 (Foundation)
    ├─> TASK-002 [P]
    ├─> TASK-003 [P]
    └─> TASK-004 [P]
```

**Use Case**: After creating data models, implement multiple independent services

**Example**:
```markdown
### TASK-001 - Define API schemas
**Dependencies**: None
**Files**: src/types/api.ts

### TASK-002 - Implement user endpoints [P]
**Dependencies**: TASK-001
**Files**: src/routes/users.ts

### TASK-003 - Implement task endpoints [P]
**Dependencies**: TASK-001
**Files**: src/routes/tasks.ts

### TASK-004 - Implement project endpoints [P]
**Dependencies**: TASK-001
**Files**: src/routes/projects.ts
```

### Fan-In Pattern

**Definition**: Single task depends on multiple prerequisites

**Pattern**:
```
TASK-002 [P] ─┐
TASK-003 [P] ─┼─> TASK-005
TASK-004 [P] ─┘
```

**Use Case**: Integration task requiring multiple components

**Example**:
```markdown
### TASK-002 - Implement auth service [P]
**Dependencies**: TASK-001
**Files**: src/services/auth.py

### TASK-003 - Implement storage service [P]
**Dependencies**: TASK-001
**Files**: src/services/storage.py

### TASK-004 - Implement notification service [P]
**Dependencies**: TASK-001
**Files**: src/services/notifications.py

### TASK-005 - Integrate services in workflow
**Dependencies**: TASK-002, TASK-003, TASK-004
**Files**: src/workflow/coordinato

modules/phase-structure.md

# Task Phase Structure

## Overview

Tasks are organized into five phases that follow natural implementation flow. Each phase builds on previous phases, creating a dependency foundation that validates components exist before they're used.

## Phase Definitions

### Phase 0: Setup

**Purpose**: Establish project foundation and development environment

**Typical Tasks**:
- Project initialization (package.json, pyproject.toml, etc.)
- Dependency installation and lock files
- Configuration files (linting, formatting, build tools)
- Development environment setup
- Git repository initialization
- CI/CD pipeline scaffolding

**When to Use**:
- Starting new projects from scratch
- Adding new build tools or development dependencies
- Setting up infrastructure before code implementation

**Example**:
```markdown
### TASK-001 - Initialize Python project with uv
**Dependencies**: None
**Files**: pyproject.toml, uv.lock
**Criteria**: `uv sync` runs successfully
```

### Phase 1: Foundation

**Purpose**: Create core data structures and testing infrastructure

**Typical Tasks**:
- Data models and type definitions
- Core interfaces and protocols
- Database schemas and migrations
- Test infrastructure and fixtures
- Base classes and abstract components
- Shared utilities

**When to Use**:
- Defining data contracts that other code depends on
- Creating type systems for type-safe implementations
- Establishing testing patterns before feature work

**Example**:
```markdown
### TASK-002 - Define Task data model
**Dependencies**: TASK-001
**Files**: src/models/task.py, tests/test_models.py
**Criteria**: All model tests pass, types validate with mypy
```

### Phase 2: Core Implementation

**Purpose**: Implement primary business logic and features

**Typical Tasks**:
- Service layer implementation
- Business logic and algorithms
- API endpoint implementations
- Core feature functionality
- Domain-specific operations
- State management

**When to Use**:
- Building main application features
- Implementing business requirements
- Creating user-facing functionality

**Example**:
```markdown
### TASK-007 - Implement task dependency resolver [P]
**Dependencies**: TASK-002, TASK-003
**Files**: src/services/resolver.py, tests/test_resolver.py
**Criteria**: Resolves complex dependency graphs, handles cycles
```

### Phase 3: Integration

**Purpose**: Connect components and integrate external systems

**Typical Tasks**:
- External API integrations
- Middleware implementation
- Error handling and recovery
- Logging and monitoring
- Database connection pooling
- Message queue integrations
- Authentication/authorization hooks

**When to Use**:
- Connecting to external services
- Adding cross-cutting concerns
- Implementing system-wide error handling

**Example**:
```markdown
### TASK-012 - Add structured logging with context
**Dependencies**: TASK-007, TASK-009
**Files**: src/middleware/logging.py, src/utils/logger.py
**Criteria**: All operations logged with correlation IDs
```

###

modules/tech-stack-patterns.md

---
name: tech-stack-patterns
description: Technology-specific patterns for common stacks, tools, and ignore file configurations
category: patterns
tags: [patterns, tech-stack, configuration, ignore-files]
dependencies: [task-planning]
complexity: beginner
estimated_tokens: 600
---

# Technology Stack Patterns

## Overview

Common patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.

## Universal Ignore Patterns

Patterns that apply to all projects regardless of stack:

```
# OS artifacts
.DS_Store
Thumbs.db
desktop.ini

# IDE/Editor
.vscode/
.idea/
*.swp
*.swo
*~
.project
.classpath
.settings/

# Logs
*.log
logs/
```

## Language-Specific Patterns

### Node.js / JavaScript / TypeScript

```
# Dependencies
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
pnpm-debug.log*

# Build outputs
dist/
build/
out/
.next/
.nuxt/

# Cache
.npm
.eslintcache
.cache/
.parcel-cache/

# Environment
.env
.env.local
.env.*.local
```

### Python

```
# Virtual environments
venv/
env/
.venv/
ENV/
.Python

# Build outputs
__pycache__/
*.py[cod]
*$py.class
*.so
.eggs/
*.egg-info/
dist/
build/

# Testing
.pytest_cache/
.coverage
htmlcov/
.tox/
```

### Rust

```
# Build outputs
target/
Cargo.lock  # (exclude for libraries, include for binaries)

# Debug symbols
*.pdb
```

### Go

```
# Build outputs
*.exe
*.exe~
*.dll
*.so
*.dylib
*.test

# Binary
bin/
vendor/
```

### Java / Kotlin

```
# Build outputs
*.class
*.jar
*.war
*.ear
target/
build/
out/

# IDE
.gradle/
.mvn/
```

### C# / .NET

```
# Build outputs
bin/
obj/
*.dll
*.exe
*.pdb

# User-specific
*.user
*.suo
*.userprefs
```

## Common Tool Configurations

### Docker

```
# Docker
.dockerignore
docker-compose.override.yml
```

### Git

```
# Git
.git/
.gitattributes
```

### Terraform

```
# Terraform
*.tfstate
*.tfstate.*
.terraform/
.terraform.lock.hcl
```

### Linting & Formatting

```
# ESLint
.eslintcache

# Prettier
.prettierignore

# Ruff (Python)
.ruff_cache/
```

## Cloud Provider Artifacts

```
# AWS
.aws/
*.pem

# GCP
.gcloud/
*-key.json

# Azure
.azure/
```

## Usage in Spec-Kit

When generating .gitignore recommendations in planning phase:
1. Start with universal patterns
2. Add language-specific patterns based on tech stack
3. Include tool-specific patterns from implementation plan
4. Add cloud provider patterns if applicable

Github ReposUpdated 15h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.