{"id":"fc1da0ce-92e9-4d5b-a72b-48bb3f78d635","entityType":"agent","slug":"clawhub-athola-nm-spec-kit-task-planning","name":"task-planning","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-spec-kit-task-planning","canonicalPath":"/agent/clawhub-athola-nm-spec-kit-task-planning","generatedAt":"2026-10-10T10:44:39.942Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T05:25:04.852Z","emptyReason":null},"description":"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:","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.7K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-spec-kit-task-planning","sourceUrl":"https://clawhub.ai/athola/nm-spec-kit-task-planning","homepage":"https://clawhub.ai/athola/skills/nm-spec-kit-task-planning","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-spec-kit-task-planning","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-spec-kit-task-planning","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":64,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation Skill: task-plannin"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T05:25:04.852Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T05:25:04.852Z","emptyReason":null},"stars":null,"forks":null,"downloads":1656,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.7K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T05:25:04.851Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T05:25:04.852Z","lastCrawledAt":"2026-10-10T05:25:04.851Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T05:25:04.851Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:23:22.185Z","changelog":"Release v1.9.19","fileCount":6,"zipByteSize":9035},{"version":"1.9.17","createdAt":"2026-07-30T05:43:06.554Z","changelog":"Release v1.9.17","fileCount":6,"zipByteSize":8977},{"version":"1.9.16","createdAt":"2026-07-14T19:59:57.477Z","changelog":"Release v1.9.16","fileCount":6,"zipByteSize":9011},{"version":"1.9.14","createdAt":"2026-06-30T18:07:18.198Z","changelog":"Release v1.9.14","fileCount":6,"zipByteSize":8984},{"version":"1.9.13","createdAt":"2026-06-27T16:25:07.145Z","changelog":"Release v1.9.13","fileCount":6,"zipByteSize":8911},{"version":"1.9.12","createdAt":"2026-06-19T03:20:57.742Z","changelog":"Release v1.9.12","fileCount":6,"zipByteSize":8843},{"version":"1.0.2","createdAt":"2026-05-09T02:20:48.979Z","changelog":"Release v1.9.5","fileCount":6,"zipByteSize":9046},{"version":"1.0.1","createdAt":"2026-05-06T14:22:19.618Z","changelog":"Release v1.9.4","fileCount":5,"zipByteSize":7879}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-spec-kit-task-planning","setupComplexity":"low","setupSteps":["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":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T10:44:39.938Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-spec-kit-task-planning/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T05:25:04.852Z","emptyReason":null},"readme":"Skill: task-planning\n\nOwner: athola\n\nSummary: Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:23:22.185Z | user\n\nRelease v1.9.19\n\nv1.9.17 | 2026-07-30T05:43:06.554Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:59:57.477Z | user\n\nRelease v1.9.16\n\nv1.9.14 | 2026-06-30T18:07:18.198Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:25:07.145Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:20:57.742Z | user\n\nRelease v1.9.12\n\nv1.0.2 | 2026-05-09T02:20:48.979Z | user\n\nRelease v1.9.5\n\nv1.0.1 | 2026-05-06T14:22:19.618Z | user\n\nRelease v1.9.4\n\nv1.0.0 | 2026-04-20T16:01:56.205Z | auto\n\n- Initial release of the task-planning skill.\n- Converts implementation plans into phased, dependency-ordered tasks.\n- Identifies parallel execution opportunities based on file and state isolation.\n- Tasks structured into 5 clear phases: Setup, Foundation, Core Implementation, Integration, and Polish.\n- Each task entry includes dependencies, parallelizability, files affected, and completion criteria.\n- Designed for use with agents, hooks, and commands in the Claude Night Market plugin system.\n\nArchive index:\n\nArchive v1.9.19: 6 files, 9035 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), skill-card.md (2422b), SKILL.md (3638b), _meta.json (145b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: task-planning\ndescription: |\n  Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation\nversion: 1.9.8\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in strict order when dependencies exist\n- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met\n- **File Coordination**: Tasks affecting same files MUST run sequentially\n\n**Nonconflicting Criteria for Parallel Execution**:\n- ✅ Files: No file overlap between tasks\n- ✅ State: No shared configuration or global state\n- ✅ Dependencies: All prerequisites satisfied\n- ✅ Code paths: No merge conflicts possible\n- ✅ Outputs: Tasks don't need each other's results\n\n**Mark tasks with [P] ONLY if they pass ALL criteria above.**\n\nFor fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.\n\n## Example Task Entry\n\n```markdown\n## Phase 2: Core Implementation\n\n### TASK-007 - Implement user authentication service [P]\n**Dependencies**: TASK-003, TASK-004\n**Files**: src/services/auth.ts, src/types/user.ts\n**Criteria**: All auth tests pass, tokens are valid JWT\n```\n**Verification:** Run `pytest -v` to verify tests pass.\n\n## Quality Checklist\n\n- [ ] All requirements mapped to tasks\n- [ ] Dependencies are explicit\n- [ ] Parallel opportunities identified\n- [ ] Tasks are right-sized (not too large/small)\n- [ ] Each task has clear completion criteria\n\n## Related Skills\n\n- `spec-writing`: Creating source specifications\n- `speckit-orchestrator`: Workflow coordination\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-spec-kit-task-planning\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787750602185\n}\n\nFile v1.9.19:modules/dependency-patterns.md\n\n# Task Dependency Patterns\n\n## Overview\n\nDependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.\n\n## Dependency Types\n\n### Sequential Dependencies\n\n**Definition**: Task B cannot start until Task A completes\n\n**When to Use**:\n- Task B modifies output from Task A\n- Task B requires interfaces/types defined in Task A\n- Task B tests functionality implemented in Task A\n- Tasks affect the same file(s)\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py\n```\n\n**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.\n\n### Parallel Dependencies [P]\n\n**Definition**: Tasks can execute concurrently with no conflicts\n\n**When to Use**:\n- No shared dependencies beyond a common foundation\n- Operate on different files\n- Independent feature implementations\n- Separate test suites\n\n**Marker**: Suffix task with `[P]`\n\n**Example**:\n```markdown\n### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py\n```\n\n**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.\n\n### Fan-Out Pattern\n\n**Definition**: Multiple tasks depend on single foundation task\n\n**Pattern**:\n```\nTASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\n\n**Use Case**: After creating data models, implement multiple independent services\n\n**Example**:\n```markdown\n### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts\n```\n\n### Fan-In Pattern\n\n**Definition**: Single task depends on multiple prerequisites\n\n**Pattern**:\n```\nTASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘\n```\n\n**Use Case**: Integration task requiring multiple components\n\n**Example**:\n```markdown\n### TASK-002 - Implement auth service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py\n\n### TASK-003 - Implement storage service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py\n\n### TASK-004 - Implement notification service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/notifications.py\n\n### TASK-005 - Integrate services in workflow\n**Dependencies**: TASK-002, TASK-003, TASK-004\n**Files**: src/workflow/coordinator.py\n```\n\n## File Coordination Rules\n\n### Same-File Modification\n\n**Rule**: Tasks modifying the same file must execute sequentially\n\n**Example**:\n```markdown\n### TASK-006 - Add base Task class\n**Files**: src/models/task.py\n\n### TASK-007 - Add Task validation methods\n**Dependencies**: TASK-006\n**Files**: src/models/task.py\n```\n\n**Reasoning**: Prevents merge conflicts and validates clean incremental changes.\n\n### Same-Directory Independence\n\n**Rule**: Tasks creating different files in same directory can run in parallel\n\n**Example**:\n```markdown\n### TASK-008 - Create user model [P]\n**Files**: src/models/user.py\n\n### TASK-009 - Create task model [P]\n**Files**: src/models/task.py\n```\n\n**Reasoning**: No file conflicts, different models, independent implementations.\n\n### Test-Implementation Pairing\n\n**Rule**: Implementation and its tests are typically sequential\n\n**Example**:\n```markdown\n### TASK-010 - Implement resolver logic\n**Files**: src/services/resolver.py\n\n### TASK-011 - Add resolver integration tests\n**Dependencies**: TASK-010\n**Files**: tests/integration/test_resolver.py\n```\n\n**Reasoning**: Can't test what doesn't exist yet.\n\n**Exception**: TDD approach might reverse this (write test first).\n\n## Task ID Conventions\n\n### Numbering Format\n\n**Pattern**: `TASK-NNN` where NNN is zero-padded number\n\n**Examples**:\n- `TASK-001` - First task\n- `TASK-023` - Twenty-third task\n- `TASK-100` - Hundredth task\n\n**Rules**:\n- Always zero-pad to 3 digits minimum\n- Sequential numbering across phases\n- No gaps in sequence\n- Don't reuse IDs\n\n### Ordering Strategy\n\n**By Phase First**:\n```markdown\nTASK-001 through TASK-003: Phase 0\nTASK-004 through TASK-010: Phase 1\nTASK-011 through TASK-025: Phase 2\nTASK-026 through TASK-030: Phase 3\nTASK-031 through TASK-035: Phase 4\n```\n\n**Benefit**: Clear phase boundaries, easy to identify task phase\n\n## Dependency Declaration Format\n\n### Single Dependency\n```markdown\n**Dependencies**: TASK-001\n```\n\n### Multiple Dependencies\n```markdown\n**Dependencies**: TASK-001, TASK-003, TASK-007\n```\n\n### No Dependencies\n```markdown\n**Dependencies**: None\n```\n\n## Common Dependency Patterns\n\n### Linear Chain\n```\nTASK-001 -> TASK-002 -> TASK-003 -> TASK-004\n```\nUse when each task builds directly on previous task.\n\n### Independent Parallel\n```\nTASK-001\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\nUse when multiple features share only initial setup.\n\n### Diamond Pattern\n```\n        TASK-001\n       /          \\\nTASK-002 [P]    TASK-003 [P]\n       \\          /\n        TASK-004\n```\nUse when parallel work converges for integration.\n\n### Layered Dependencies\n```\nPhase 1: TASK-001, TASK-002, TASK-003\n           ↓         ↓         ↓\nPhase 2: TASK-004 depends on all Phase 1\n```\nUse when foundation must be complete before next phase.\n\n## Validation Rules\n\n- [ ] Every task has explicit dependency field\n- [ ] No circular dependencies\n- [ ] Parallel tasks [P] have no file conflicts\n- [ ] Sequential tasks on same file are ordered\n- [ ] All referenced task IDs exist\n- [ ] Tasks reference dependencies from earlier phases\n\nFile v1.9.19:modules/phase-structure.md\n\n# Task Phase Structure\n\n## Overview\n\nTasks 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.\n\n## Phase Definitions\n\n### Phase 0: Setup\n\n**Purpose**: Establish project foundation and development environment\n\n**Typical Tasks**:\n- Project initialization (package.json, pyproject.toml, etc.)\n- Dependency installation and lock files\n- Configuration files (linting, formatting, build tools)\n- Development environment setup\n- Git repository initialization\n- CI/CD pipeline scaffolding\n\n**When to Use**:\n- Starting new projects from scratch\n- Adding new build tools or development dependencies\n- Setting up infrastructure before code implementation\n\n**Example**:\n```markdown\n### TASK-001 - Initialize Python project with uv\n**Dependencies**: None\n**Files**: pyproject.toml, uv.lock\n**Criteria**: `uv sync` runs successfully\n```\n\n### Phase 1: Foundation\n\n**Purpose**: Create core data structures and testing infrastructure\n\n**Typical Tasks**:\n- Data models and type definitions\n- Core interfaces and protocols\n- Database schemas and migrations\n- Test infrastructure and fixtures\n- Base classes and abstract components\n- Shared utilities\n\n**When to Use**:\n- Defining data contracts that other code depends on\n- Creating type systems for type-safe implementations\n- Establishing testing patterns before feature work\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py, tests/test_models.py\n**Criteria**: All model tests pass, types validate with mypy\n```\n\n### Phase 2: Core Implementation\n\n**Purpose**: Implement primary business logic and features\n\n**Typical Tasks**:\n- Service layer implementation\n- Business logic and algorithms\n- API endpoint implementations\n- Core feature functionality\n- Domain-specific operations\n- State management\n\n**When to Use**:\n- Building main application features\n- Implementing business requirements\n- Creating user-facing functionality\n\n**Example**:\n```markdown\n### TASK-007 - Implement task dependency resolver [P]\n**Dependencies**: TASK-002, TASK-003\n**Files**: src/services/resolver.py, tests/test_resolver.py\n**Criteria**: Resolves complex dependency graphs, handles cycles\n```\n\n### Phase 3: Integration\n\n**Purpose**: Connect components and integrate external systems\n\n**Typical Tasks**:\n- External API integrations\n- Middleware implementation\n- Error handling and recovery\n- Logging and monitoring\n- Database connection pooling\n- Message queue integrations\n- Authentication/authorization hooks\n\n**When to Use**:\n- Connecting to external services\n- Adding cross-cutting concerns\n- Implementing system-wide error handling\n\n**Example**:\n```markdown\n### TASK-012 - Add structured logging with context\n**Dependencies**: TASK-007, TASK-009\n**Files**: src/middleware/logging.py, src/utils/logger.py\n**Criteria**: All operations logged with correlation IDs\n```\n\n### Phase 4: Polish\n\n**Purpose**: Optimize, document, and finalize for production\n\n**Typical Tasks**:\n- Performance optimization and profiling\n- detailed documentation\n- End-to-end testing\n- Security hardening\n- Code cleanup and refactoring\n- Production readiness checks\n\n**When to Use**:\n- After core functionality is complete\n- Preparing for production deployment\n- Addressing technical debt before release\n\n**Example**:\n```markdown\n### TASK-015 - Add API documentation with examples\n**Dependencies**: TASK-007, TASK-010\n**Files**: docs/api.md, examples/quickstart.py\n**Criteria**: All endpoints documented, examples run successfully\n```\n\n## Phase Selection Guidelines\n\n### Moving Between Phases\n\n- **Complete phase foundations before advancing**: Don't jump to Phase 3 if Phase 1 models are incomplete\n- **Parallel work within phases**: Multiple Phase 2 tasks can run concurrently if dependencies allow\n- **Return to earlier phases sparingly**: Indicates incomplete planning or new requirements\n\n### Common Patterns\n\n**Small Features** (5-10 tasks):\n- Phase 0: Usually skipped (project exists)\n- Phase 1: 1-2 tasks (data models)\n- Phase 2: 3-5 tasks (core logic)\n- Phase 3: 1-2 tasks (integration)\n- Phase 4: 1-2 tasks (docs, tests)\n\n**Medium Features** (10-20 tasks):\n- Phase 0: 1-2 tasks (new dependencies)\n- Phase 1: 3-4 tasks (multiple models, test infrastructure)\n- Phase 2: 6-10 tasks (multiple services)\n- Phase 3: 2-4 tasks (several integrations)\n- Phase 4: 2-3 tasks (optimization, detailed docs)\n\n**Large Features** (20+ tasks):\n- Consider breaking into multiple features\n- Each phase may have 5+ tasks\n- Requires careful dependency management\n- May benefit from sub-phases\n\n## Anti-Patterns to Avoid\n\n- **Phase jumping**: Implementing Phase 2 features before Phase 1 models exist\n- **Phase mixing**: Putting setup tasks in Phase 2 or implementation tasks in Phase 1\n- **Skipping phases**: Every feature needs at least Phase 1 (models) and Phase 2 (logic)\n- **Over-granular phases**: Creating sub-phases or custom phase numbers\n\nFile v1.9.19:modules/tech-stack-patterns.md\n\n---\nname: tech-stack-patterns\ndescription: Technology-specific patterns for common stacks, tools, and ignore file configurations\ncategory: patterns\ntags: [patterns, tech-stack, configuration, ignore-files]\ndependencies: [task-planning]\ncomplexity: beginner\nestimated_tokens: 600\n---\n\n# Technology Stack Patterns\n\n## Overview\n\nCommon patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.\n\n## Universal Ignore Patterns\n\nPatterns that apply to all projects regardless of stack:\n\n```\n# OS artifacts\n.DS_Store\nThumbs.db\ndesktop.ini\n\n# IDE/Editor\n.vscode/\n.idea/\n*.swp\n*.swo\n*~\n.project\n.classpath\n.settings/\n\n# Logs\n*.log\nlogs/\n```\n\n## Language-Specific Patterns\n\n### Node.js / JavaScript / TypeScript\n\n```\n# Dependencies\nnode_modules/\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\n\n# Build outputs\ndist/\nbuild/\nout/\n.next/\n.nuxt/\n\n# Cache\n.npm\n.eslintcache\n.cache/\n.parcel-cache/\n\n# Environment\n.env\n.env.local\n.env.*.local\n```\n\n### Python\n\n```\n# Virtual environments\nvenv/\nenv/\n.venv/\nENV/\n.Python\n\n# Build outputs\n__pycache__/\n*.py[cod]\n*$py.class\n*.so\n.eggs/\n*.egg-info/\ndist/\nbuild/\n\n# Testing\n.pytest_cache/\n.coverage\nhtmlcov/\n.tox/\n```\n\n### Rust\n\n```\n# Build outputs\ntarget/\nCargo.lock  # (exclude for libraries, include for binaries)\n\n# Debug symbols\n*.pdb\n```\n\n### Go\n\n```\n# Build outputs\n*.exe\n*.exe~\n*.dll\n*.so\n*.dylib\n*.test\n\n# Binary\nbin/\nvendor/\n```\n\n### Java / Kotlin\n\n```\n# Build outputs\n*.class\n*.jar\n*.war\n*.ear\ntarget/\nbuild/\nout/\n\n# IDE\n.gradle/\n.mvn/\n```\n\n### C# / .NET\n\n```\n# Build outputs\nbin/\nobj/\n*.dll\n*.exe\n*.pdb\n\n# User-specific\n*.user\n*.suo\n*.userprefs\n```\n\n## Common Tool Configurations\n\n### Docker\n\n```\n# Docker\n.dockerignore\ndocker-compose.override.yml\n```\n\n### Git\n\n```\n# Git\n.git/\n.gitattributes\n```\n\n### Terraform\n\n```\n# Terraform\n*.tfstate\n*.tfstate.*\n.terraform/\n.terraform.lock.hcl\n```\n\n### Linting & Formatting\n\n```\n# ESLint\n.eslintcache\n\n# Prettier\n.prettierignore\n\n# Ruff (Python)\n.ruff_cache/\n```\n\n## Cloud Provider Artifacts\n\n```\n# AWS\n.aws/\n*.pem\n\n# GCP\n.gcloud/\n*-key.json\n\n# Azure\n.azure/\n```\n\n## Usage in Spec-Kit\n\nWhen generating .gitignore recommendations in planning phase:\n1. Start with universal patterns\n2. Add language-specific patterns based on tech stack\n3. Include tool-specific patterns from implementation plan\n4. Add cloud provider patterns if applicable\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nGenerates phased, dependency-ordered implementation tasks from completed specifications before implementation starts.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to convert completed specifications and implementation plans into phased task lists with dependencies, parallel markers, affected files, and completion criteria.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can activate on general planning or task-related prompts.\n\nMitigation: Use it after the specification is complete and review the generated task breakdown before treating it as an implementation plan.\n\nRisk: Generated dependencies or [P] parallel markers may be incorrect for a specific codebase.\n\nMitigation: Check shared files, global state, prerequisites, and expected outputs before executing tasks concurrently.\n\nRisk: The related upstream plugin includes a broader agents, hooks, and commands experience outside this documentation-only skill.\n\nMitigation: Review the upstream plugin separately before installing that fuller experience.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-spec-kit-task-planning)\n- [Metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit)\n- [Task phase structure](modules/phase-structure.md)\n- [Task dependency patterns](modules/dependency-patterns.md)\n- [Technology stack patterns](modules/tech-stack-patterns.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown task lists with task IDs, phases, dependencies, file targets, criteria, and occasional inline shell commands.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Tasks are organized from setup through polish and use [P] markers only when dependency and file-conflict checks allow parallel execution.]\n\n## Skill Version(s):\n\n1.9.19 (source: server release metadata; artifact frontmatter lists 1.9.8)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 6 files, 8977 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), skill-card.md (2457b), SKILL.md (3638b), _meta.json (145b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: task-planning\ndescription: |\n  Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation\nversion: 1.9.8\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in strict order when dependencies exist\n- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met\n- **File Coordination**: Tasks affecting same files MUST run sequentially\n\n**Nonconflicting Criteria for Parallel Execution**:\n- ✅ Files: No file overlap between tasks\n- ✅ State: No shared configuration or global state\n- ✅ Dependencies: All prerequisites satisfied\n- ✅ Code paths: No merge conflicts possible\n- ✅ Outputs: Tasks don't need each other's results\n\n**Mark tasks with [P] ONLY if they pass ALL criteria above.**\n\nFor fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.\n\n## Example Task Entry\n\n```markdown\n## Phase 2: Core Implementation\n\n### TASK-007 - Implement user authentication service [P]\n**Dependencies**: TASK-003, TASK-004\n**Files**: src/services/auth.ts, src/types/user.ts\n**Criteria**: All auth tests pass, tokens are valid JWT\n```\n**Verification:** Run `pytest -v` to verify tests pass.\n\n## Quality Checklist\n\n- [ ] All requirements mapped to tasks\n- [ ] Dependencies are explicit\n- [ ] Parallel opportunities identified\n- [ ] Tasks are right-sized (not too large/small)\n- [ ] Each task has clear completion criteria\n\n## Related Skills\n\n- `spec-writing`: Creating source specifications\n- `speckit-orchestrator`: Workflow coordination\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-spec-kit-task-planning\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785390186554\n}\n\nFile v1.9.17:modules/dependency-patterns.md\n\n# Task Dependency Patterns\n\n## Overview\n\nDependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.\n\n## Dependency Types\n\n### Sequential Dependencies\n\n**Definition**: Task B cannot start until Task A completes\n\n**When to Use**:\n- Task B modifies output from Task A\n- Task B requires interfaces/types defined in Task A\n- Task B tests functionality implemented in Task A\n- Tasks affect the same file(s)\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py\n```\n\n**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.\n\n### Parallel Dependencies [P]\n\n**Definition**: Tasks can execute concurrently with no conflicts\n\n**When to Use**:\n- No shared dependencies beyond a common foundation\n- Operate on different files\n- Independent feature implementations\n- Separate test suites\n\n**Marker**: Suffix task with `[P]`\n\n**Example**:\n```markdown\n### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py\n```\n\n**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.\n\n### Fan-Out Pattern\n\n**Definition**: Multiple tasks depend on single foundation task\n\n**Pattern**:\n```\nTASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\n\n**Use Case**: After creating data models, implement multiple independent services\n\n**Example**:\n```markdown\n### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts\n```\n\n### Fan-In Pattern\n\n**Definition**: Single task depends on multiple prerequisites\n\n**Pattern**:\n```\nTASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘\n```\n\n**Use Case**: Integration task requiring multiple components\n\n**Example**:\n```markdown\n### TASK-002 - Implement auth service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py\n\n### TASK-003 - Implement storage service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py\n\n### TASK-004 - Implement notification service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/notifications.py\n\n### TASK-005 - Integrate services in workflow\n**Dependencies**: TASK-002, TASK-003, TASK-004\n**Files**: src/workflow/coordinator.py\n```\n\n## File Coordination Rules\n\n### Same-File Modification\n\n**Rule**: Tasks modifying the same file must execute sequentially\n\n**Example**:\n```markdown\n### TASK-006 - Add base Task class\n**Files**: src/models/task.py\n\n### TASK-007 - Add Task validation methods\n**Dependencies**: TASK-006\n**Files**: src/models/task.py\n```\n\n**Reasoning**: Prevents merge conflicts and validates clean incremental changes.\n\n### Same-Directory Independence\n\n**Rule**: Tasks creating different files in same directory can run in parallel\n\n**Example**:\n```markdown\n### TASK-008 - Create user model [P]\n**Files**: src/models/user.py\n\n### TASK-009 - Create task model [P]\n**Files**: src/models/task.py\n```\n\n**Reasoning**: No file conflicts, different models, independent implementations.\n\n### Test-Implementation Pairing\n\n**Rule**: Implementation and its tests are typically sequential\n\n**Example**:\n```markdown\n### TASK-010 - Implement resolver logic\n**Files**: src/services/resolver.py\n\n### TASK-011 - Add resolver integration tests\n**Dependencies**: TASK-010\n**Files**: tests/integration/test_resolver.py\n```\n\n**Reasoning**: Can't test what doesn't exist yet.\n\n**Exception**: TDD approach might reverse this (write test first).\n\n## Task ID Conventions\n\n### Numbering Format\n\n**Pattern**: `TASK-NNN` where NNN is zero-padded number\n\n**Examples**:\n- `TASK-001` - First task\n- `TASK-023` - Twenty-third task\n- `TASK-100` - Hundredth task\n\n**Rules**:\n- Always zero-pad to 3 digits minimum\n- Sequential numbering across phases\n- No gaps in sequence\n- Don't reuse IDs\n\n### Ordering Strategy\n\n**By Phase First**:\n```markdown\nTASK-001 through TASK-003: Phase 0\nTASK-004 through TASK-010: Phase 1\nTASK-011 through TASK-025: Phase 2\nTASK-026 through TASK-030: Phase 3\nTASK-031 through TASK-035: Phase 4\n```\n\n**Benefit**: Clear phase boundaries, easy to identify task phase\n\n## Dependency Declaration Format\n\n### Single Dependency\n```markdown\n**Dependencies**: TASK-001\n```\n\n### Multiple Dependencies\n```markdown\n**Dependencies**: TASK-001, TASK-003, TASK-007\n```\n\n### No Dependencies\n```markdown\n**Dependencies**: None\n```\n\n## Common Dependency Patterns\n\n### Linear Chain\n```\nTASK-001 -> TASK-002 -> TASK-003 -> TASK-004\n```\nUse when each task builds directly on previous task.\n\n### Independent Parallel\n```\nTASK-001\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\nUse when multiple features share only initial setup.\n\n### Diamond Pattern\n```\n        TASK-001\n       /          \\\nTASK-002 [P]    TASK-003 [P]\n       \\          /\n        TASK-004\n```\nUse when parallel work converges for integration.\n\n### Layered Dependencies\n```\nPhase 1: TASK-001, TASK-002, TASK-003\n           ↓         ↓         ↓\nPhase 2: TASK-004 depends on all Phase 1\n```\nUse when foundation must be complete before next phase.\n\n## Validation Rules\n\n- [ ] Every task has explicit dependency field\n- [ ] No circular dependencies\n- [ ] Parallel tasks [P] have no file conflicts\n- [ ] Sequential tasks on same file are ordered\n- [ ] All referenced task IDs exist\n- [ ] Tasks reference dependencies from earlier phases\n\nFile v1.9.17:modules/phase-structure.md\n\n# Task Phase Structure\n\n## Overview\n\nTasks 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.\n\n## Phase Definitions\n\n### Phase 0: Setup\n\n**Purpose**: Establish project foundation and development environment\n\n**Typical Tasks**:\n- Project initialization (package.json, pyproject.toml, etc.)\n- Dependency installation and lock files\n- Configuration files (linting, formatting, build tools)\n- Development environment setup\n- Git repository initialization\n- CI/CD pipeline scaffolding\n\n**When to Use**:\n- Starting new projects from scratch\n- Adding new build tools or development dependencies\n- Setting up infrastructure before code implementation\n\n**Example**:\n```markdown\n### TASK-001 - Initialize Python project with uv\n**Dependencies**: None\n**Files**: pyproject.toml, uv.lock\n**Criteria**: `uv sync` runs successfully\n```\n\n### Phase 1: Foundation\n\n**Purpose**: Create core data structures and testing infrastructure\n\n**Typical Tasks**:\n- Data models and type definitions\n- Core interfaces and protocols\n- Database schemas and migrations\n- Test infrastructure and fixtures\n- Base classes and abstract components\n- Shared utilities\n\n**When to Use**:\n- Defining data contracts that other code depends on\n- Creating type systems for type-safe implementations\n- Establishing testing patterns before feature work\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py, tests/test_models.py\n**Criteria**: All model tests pass, types validate with mypy\n```\n\n### Phase 2: Core Implementation\n\n**Purpose**: Implement primary business logic and features\n\n**Typical Tasks**:\n- Service layer implementation\n- Business logic and algorithms\n- API endpoint implementations\n- Core feature functionality\n- Domain-specific operations\n- State management\n\n**When to Use**:\n- Building main application features\n- Implementing business requirements\n- Creating user-facing functionality\n\n**Example**:\n```markdown\n### TASK-007 - Implement task dependency resolver [P]\n**Dependencies**: TASK-002, TASK-003\n**Files**: src/services/resolver.py, tests/test_resolver.py\n**Criteria**: Resolves complex dependency graphs, handles cycles\n```\n\n### Phase 3: Integration\n\n**Purpose**: Connect components and integrate external systems\n\n**Typical Tasks**:\n- External API integrations\n- Middleware implementation\n- Error handling and recovery\n- Logging and monitoring\n- Database connection pooling\n- Message queue integrations\n- Authentication/authorization hooks\n\n**When to Use**:\n- Connecting to external services\n- Adding cross-cutting concerns\n- Implementing system-wide error handling\n\n**Example**:\n```markdown\n### TASK-012 - Add structured logging with context\n**Dependencies**: TASK-007, TASK-009\n**Files**: src/middleware/logging.py, src/utils/logger.py\n**Criteria**: All operations logged with correlation IDs\n```\n\n### Phase 4: Polish\n\n**Purpose**: Optimize, document, and finalize for production\n\n**Typical Tasks**:\n- Performance optimization and profiling\n- detailed documentation\n- End-to-end testing\n- Security hardening\n- Code cleanup and refactoring\n- Production readiness checks\n\n**When to Use**:\n- After core functionality is complete\n- Preparing for production deployment\n- Addressing technical debt before release\n\n**Example**:\n```markdown\n### TASK-015 - Add API documentation with examples\n**Dependencies**: TASK-007, TASK-010\n**Files**: docs/api.md, examples/quickstart.py\n**Criteria**: All endpoints documented, examples run successfully\n```\n\n## Phase Selection Guidelines\n\n### Moving Between Phases\n\n- **Complete phase foundations before advancing**: Don't jump to Phase 3 if Phase 1 models are incomplete\n- **Parallel work within phases**: Multiple Phase 2 tasks can run concurrently if dependencies allow\n- **Return to earlier phases sparingly**: Indicates incomplete planning or new requirements\n\n### Common Patterns\n\n**Small Features** (5-10 tasks):\n- Phase 0: Usually skipped (project exists)\n- Phase 1: 1-2 tasks (data models)\n- Phase 2: 3-5 tasks (core logic)\n- Phase 3: 1-2 tasks (integration)\n- Phase 4: 1-2 tasks (docs, tests)\n\n**Medium Features** (10-20 tasks):\n- Phase 0: 1-2 tasks (new dependencies)\n- Phase 1: 3-4 tasks (multiple models, test infrastructure)\n- Phase 2: 6-10 tasks (multiple services)\n- Phase 3: 2-4 tasks (several integrations)\n- Phase 4: 2-3 tasks (optimization, detailed docs)\n\n**Large Features** (20+ tasks):\n- Consider breaking into multiple features\n- Each phase may have 5+ tasks\n- Requires careful dependency management\n- May benefit from sub-phases\n\n## Anti-Patterns to Avoid\n\n- **Phase jumping**: Implementing Phase 2 features before Phase 1 models exist\n- **Phase mixing**: Putting setup tasks in Phase 2 or implementation tasks in Phase 1\n- **Skipping phases**: Every feature needs at least Phase 1 (models) and Phase 2 (logic)\n- **Over-granular phases**: Creating sub-phases or custom phase numbers\n\nFile v1.9.17:modules/tech-stack-patterns.md\n\n---\nname: tech-stack-patterns\ndescription: Technology-specific patterns for common stacks, tools, and ignore file configurations\ncategory: patterns\ntags: [patterns, tech-stack, configuration, ignore-files]\ndependencies: [task-planning]\ncomplexity: beginner\nestimated_tokens: 600\n---\n\n# Technology Stack Patterns\n\n## Overview\n\nCommon patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.\n\n## Universal Ignore Patterns\n\nPatterns that apply to all projects regardless of stack:\n\n```\n# OS artifacts\n.DS_Store\nThumbs.db\ndesktop.ini\n\n# IDE/Editor\n.vscode/\n.idea/\n*.swp\n*.swo\n*~\n.project\n.classpath\n.settings/\n\n# Logs\n*.log\nlogs/\n```\n\n## Language-Specific Patterns\n\n### Node.js / JavaScript / TypeScript\n\n```\n# Dependencies\nnode_modules/\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\n\n# Build outputs\ndist/\nbuild/\nout/\n.next/\n.nuxt/\n\n# Cache\n.npm\n.eslintcache\n.cache/\n.parcel-cache/\n\n# Environment\n.env\n.env.local\n.env.*.local\n```\n\n### Python\n\n```\n# Virtual environments\nvenv/\nenv/\n.venv/\nENV/\n.Python\n\n# Build outputs\n__pycache__/\n*.py[cod]\n*$py.class\n*.so\n.eggs/\n*.egg-info/\ndist/\nbuild/\n\n# Testing\n.pytest_cache/\n.coverage\nhtmlcov/\n.tox/\n```\n\n### Rust\n\n```\n# Build outputs\ntarget/\nCargo.lock  # (exclude for libraries, include for binaries)\n\n# Debug symbols\n*.pdb\n```\n\n### Go\n\n```\n# Build outputs\n*.exe\n*.exe~\n*.dll\n*.so\n*.dylib\n*.test\n\n# Binary\nbin/\nvendor/\n```\n\n### Java / Kotlin\n\n```\n# Build outputs\n*.class\n*.jar\n*.war\n*.ear\ntarget/\nbuild/\nout/\n\n# IDE\n.gradle/\n.mvn/\n```\n\n### C# / .NET\n\n```\n# Build outputs\nbin/\nobj/\n*.dll\n*.exe\n*.pdb\n\n# User-specific\n*.user\n*.suo\n*.userprefs\n```\n\n## Common Tool Configurations\n\n### Docker\n\n```\n# Docker\n.dockerignore\ndocker-compose.override.yml\n```\n\n### Git\n\n```\n# Git\n.git/\n.gitattributes\n```\n\n### Terraform\n\n```\n# Terraform\n*.tfstate\n*.tfstate.*\n.terraform/\n.terraform.lock.hcl\n```\n\n### Linting & Formatting\n\n```\n# ESLint\n.eslintcache\n\n# Prettier\n.prettierignore\n\n# Ruff (Python)\n.ruff_cache/\n```\n\n## Cloud Provider Artifacts\n\n```\n# AWS\n.aws/\n*.pem\n\n# GCP\n.gcloud/\n*-key.json\n\n# Azure\n.azure/\n```\n\n## Usage in Spec-Kit\n\nWhen generating .gitignore recommendations in planning phase:\n1. Start with universal patterns\n2. Add language-specific patterns based on tech stack\n3. Include tool-specific patterns from implementation plan\n4. Add cloud provider patterns if applicable\n\nFile v1.9.17:skill-card.md\n\n## Description: <br>\nGenerates phased, dependency-ordered implementation tasks from specifications after the specification is complete and before implementation begins. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineering agents use this skill to convert completed specifications and implementation plans into phased task lists with explicit dependencies, file coordination, parallelization markers, and completion criteria. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad trigger terms may activate the skill in general planning or implementation discussions. <br>\nMitigation: Confirm the user is asking for implementation task planning from a completed specification before applying the generated breakdown. <br>\nRisk: Generated task plans may contain incorrect sequencing, unsafe parallelization, or incomplete file coordination. <br>\nMitigation: Review dependencies, same-file edits, parallel markers, and completion criteria before executing the plan. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-spec-kit-task-planning) <br>\n- [OpenClaw homepage metadata](https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit) <br>\n- [Task phase structure](artifact/modules/phase-structure.md) <br>\n- [Task dependency patterns](artifact/modules/dependency-patterns.md) <br>\n- [Technology stack patterns](artifact/modules/tech-stack-patterns.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Shell commands, Configuration, Guidance] <br>\n**Output Format:** [Markdown task plan with phased task entries, dependency fields, affected files, and verification criteria] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May mark parallelizable tasks with [P] and include concrete file paths, configuration suggestions, and verification commands.] <br>\n\n## Skill Version(s): <br>\n1.9.17 (source: server release metadata; artifact frontmatter is 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.16: 6 files, 9011 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), skill-card.md (2462b), SKILL.md (3638b), _meta.json (145b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: task-planning\ndescription: |\n  Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation\nversion: 1.9.8\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in strict order when dependencies exist\n- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met\n- **File Coordination**: Tasks affecting same files MUST run sequentially\n\n**Nonconflicting Criteria for Parallel Execution**:\n- ✅ Files: No file overlap between tasks\n- ✅ State: No shared configuration or global state\n- ✅ Dependencies: All prerequisites satisfied\n- ✅ Code paths: No merge conflicts possible\n- ✅ Outputs: Tasks don't need each other's results\n\n**Mark tasks with [P] ONLY if they pass ALL criteria above.**\n\nFor fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.\n\n## Example Task Entry\n\n```markdown\n## Phase 2: Core Implementation\n\n### TASK-007 - Implement user authentication service [P]\n**Dependencies**: TASK-003, TASK-004\n**Files**: src/services/auth.ts, src/types/user.ts\n**Criteria**: All auth tests pass, tokens are valid JWT\n```\n**Verification:** Run `pytest -v` to verify tests pass.\n\n## Quality Checklist\n\n- [ ] All requirements mapped to tasks\n- [ ] Dependencies are explicit\n- [ ] Parallel opportunities identified\n- [ ] Tasks are right-sized (not too large/small)\n- [ ] Each task has clear completion criteria\n\n## Related Skills\n\n- `spec-writing`: Creating source specifications\n- `speckit-orchestrator`: Workflow coordination\n\nFile v1.9.16:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-spec-kit-task-planning\",\n  \"version\": \"1.9.16\",\n  \"publishedAt\": 1784059197477\n}\n\nFile v1.9.16:modules/dependency-patterns.md\n\n# Task Dependency Patterns\n\n## Overview\n\nDependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.\n\n## Dependency Types\n\n### Sequential Dependencies\n\n**Definition**: Task B cannot start until Task A completes\n\n**When to Use**:\n- Task B modifies output from Task A\n- Task B requires interfaces/types defined in Task A\n- Task B tests functionality implemented in Task A\n- Tasks affect the same file(s)\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py\n```\n\n**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.\n\n### Parallel Dependencies [P]\n\n**Definition**: Tasks can execute concurrently with no conflicts\n\n**When to Use**:\n- No shared dependencies beyond a common foundation\n- Operate on different files\n- Independent feature implementations\n- Separate test suites\n\n**Marker**: Suffix task with `[P]`\n\n**Example**:\n```markdown\n### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py\n```\n\n**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.\n\n### Fan-Out Pattern\n\n**Definition**: Multiple tasks depend on single foundation task\n\n**Pattern**:\n```\nTASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\n\n**Use Case**: After creating data models, implement multiple independent services\n\n**Example**:\n```markdown\n### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts\n```\n\n### Fan-In Pattern\n\n**Definition**: Single task depends on multiple prerequisites\n\n**Pattern**:\n```\nTASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘\n```\n\n**Use Case**: Integration task requiring multiple components\n\n**Example**:\n```markdown\n### TASK-002 - Implement auth service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py\n\n### TASK-003 - Implement storage service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py\n\n### TASK-004 - Implement notification service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/notifications.py\n\n### TASK-005 - Integrate services in workflow\n**Dependencies**: TASK-002, TASK-003, TASK-004\n**Files**: src/workflow/coordinator.py\n```\n\n## File Coordination Rules\n\n### Same-File Modification\n\n**Rule**: Tasks modifying the same file must execute sequentially\n\n**Example**:\n```markdown\n### TASK-006 - Add base Task class\n**Files**: src/models/task.py\n\n### TASK-007 - Add Task validation methods\n**Dependencies**: TASK-006\n**Files**: src/models/task.py\n```\n\n**Reasoning**: Prevents merge conflicts and validates clean incremental changes.\n\n### Same-Directory Independence\n\n**Rule**: Tasks creating different files in same directory can run in parallel\n\n**Example**:\n```markdown\n### TASK-008 - Create user model [P]\n**Files**: src/models/user.py\n\n### TASK-009 - Create task model [P]\n**Files**: src/models/task.py\n```\n\n**Reasoning**: No file conflicts, different models, independent implementations.\n\n### Test-Implementation Pairing\n\n**Rule**: Implementation and its tests are typically sequential\n\n**Example**:\n```markdown\n### TASK-010 - Implement resolver logic\n**Files**: src/services/resolver.py\n\n### TASK-011 - Add resolver integration tests\n**Dependencies**: TASK-010\n**Files**: tests/integration/test_resolver.py\n```\n\n**Reasoning**: Can't test what doesn't exist yet.\n\n**Exception**: TDD approach might reverse this (write test first).\n\n## Task ID Conventions\n\n### Numbering Format\n\n**Pattern**: `TASK-NNN` where NNN is zero-padded number\n\n**Examples**:\n- `TASK-001` - First task\n- `TASK-023` - Twenty-third task\n- `TASK-100` - Hundredth task\n\n**Rules**:\n- Always zero-pad to 3 digits minimum\n- Sequential numbering across phases\n- No gaps in sequence\n- Don't reuse IDs\n\n### Ordering Strategy\n\n**By Phase First**:\n```markdown\nTASK-001 through TASK-003: Phase 0\nTASK-004 through TASK-010: Phase 1\nTASK-011 through TASK-025: Phase 2\nTASK-026 through TASK-030: Phase 3\nTASK-031 through TASK-035: Phase 4\n```\n\n**Benefit**: Clear phase boundaries, easy to identify task phase\n\n## Dependency Declaration Format\n\n### Single Dependency\n```markdown\n**Dependencies**: TASK-001\n```\n\n### Multiple Dependencies\n```markdown\n**Dependencies**: TASK-001, TASK-003, TASK-007\n```\n\n### No Dependencies\n```markdown\n**Dependencies**: None\n```\n\n## Common Dependency Patterns\n\n### Linear Chain\n```\nTASK-001 -> TASK-002 -> TASK-003 -> TASK-004\n```\nUse when each task builds directly on previous task.\n\n### Independent Parallel\n```\nTASK-001\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\nUse when multiple features share only initial setup.\n\n### Diamond Pattern\n```\n        TASK-001\n       /          \\\nTASK-002 [P]    TASK-003 [P]\n       \\          /\n        TASK-004\n```\nUse when parallel work converges for integration.\n\n### Layered Dependencies\n```\nPhase 1: TASK-001, TASK-002, TASK-003\n           ↓         ↓         ↓\nPhase 2: TASK-004 depends on all Phase 1\n```\nUse when foundation must be complete before next phase.\n\n## Validation Rules\n\n- [ ] Every task has explicit dependency field\n- [ ] No circular dependencies\n- [ ] Parallel tasks [P] have no file conflicts\n- [ ] Sequential tasks on same file are ordered\n- [ ] All referenced task IDs exist\n- [ ] Tasks reference dependencies from earlier phases\n\nFile v1.9.16:modules/phase-structure.md\n\n# Task Phase Structure\n\n## Overview\n\nTasks 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.\n\n## Phase Definitions\n\n### Phase 0: Setup\n\n**Purpose**: Establish project foundation and development environment\n\n**Typical Tasks**:\n- Project initialization (package.json, pyproject.toml, etc.)\n- Dependency installation and lock files\n- Configuration files (linting, formatting, build tools)\n- Development environment setup\n- Git repository initialization\n- CI/CD pipeline scaffolding\n\n**When to Use**:\n- Starting new projects from scratch\n- Adding new build tools or development dependencies\n- Setting up infrastructure before code implementation\n\n**Example**:\n```markdown\n### TASK-001 - Initialize Python project with uv\n**Dependencies**: None\n**Files**: pyproject.toml, uv.lock\n**Criteria**: `uv sync` runs successfully\n```\n\n### Phase 1: Foundation\n\n**Purpose**: Create core data structures and testing infrastructure\n\n**Typical Tasks**:\n- Data models and type definitions\n- Core interfaces and protocols\n- Database schemas and migrations\n- Test infrastructure and fixtures\n- Base classes and abstract components\n- Shared utilities\n\n**When to Use**:\n- Defining data contracts that other code depends on\n- Creating type systems for type-safe implementations\n- Establishing testing patterns before feature work\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py, tests/test_models.py\n**Criteria**: All model tests pass, types validate with mypy\n```\n\n### Phase 2: Core Implementation\n\n**Purpose**: Implement primary business logic and features\n\n**Typical Tasks**:\n- Service layer implementation\n- Business logic and algorithms\n- API endpoint implementations\n- Core feature functionality\n- Domain-specific operations\n- State management\n\n**When to Use**:\n- Building main application features\n- Implementing business requirements\n- Creating user-facing functionality\n\n**Example**:\n```markdown\n### TASK-007 - Implement task dependency resolver [P]\n**Dependencies**: TASK-002, TASK-003\n**Files**: src/services/resolver.py, tests/test_resolver.py\n**Criteria**: Resolves complex dependency graphs, handles cycles\n```\n\n### Phase 3: Integration\n\n**Purpose**: Connect components and integrate external systems\n\n**Typical Tasks**:\n- External API integrations\n- Middleware implementation\n- Error handling and recovery\n- Logging and monitoring\n- Database connection pooling\n- Message queue integrations\n- Authentication/authorization hooks\n\n**When to Use**:\n- Connecting to external services\n- Adding cross-cutting concerns\n- Implementing system-wide error handling\n\n**Example**:\n```markdown\n### TASK-012 - Add structured logging with context\n**Dependencies**: TASK-007, TASK-009\n**Files**: src/middleware/logging.py, src/utils/logger.py\n**Criteria**: All operations logged with correlation IDs\n```\n\n### Phase 4: Polish\n\n**Purpose**: Optimize, document, and finalize for production\n\n**Typical Tasks**:\n- Performance optimization and profiling\n- detailed documentation\n- End-to-end testing\n- Security hardening\n- Code cleanup and refactoring\n- Production readiness checks\n\n**When to Use**:\n- After core functionality is complete\n- Preparing for production deployment\n- Addressing technical debt before release\n\n**Example**:\n```markdown\n### TASK-015 - Add API documentation with examples\n**Dependencies**: TASK-007, TASK-010\n**Files**: docs/api.md, examples/quickstart.py\n**Criteria**: All endpoints documented, examples run successfully\n```\n\n## Phase Selection Guidelines\n\n### Moving Between Phases\n\n- **Complete phase foundations before advancing**: Don't jump to Phase 3 if Phase 1 models are incomplete\n- **Parallel work within phases**: Multiple Phase 2 tasks can run concurrently if dependencies allow\n- **Return to earlier phases sparingly**: Indicates incomplete planning or new requirements\n\n### Common Patterns\n\n**Small Features** (5-10 tasks):\n- Phase 0: Usually skipped (project exists)\n- Phase 1: 1-2 tasks (data models)\n- Phase 2: 3-5 tasks (core logic)\n- Phase 3: 1-2 tasks (integration)\n- Phase 4: 1-2 tasks (docs, tests)\n\n**Medium Features** (10-20 tasks):\n- Phase 0: 1-2 tasks (new dependencies)\n- Phase 1: 3-4 tasks (multiple models, test infrastructure)\n- Phase 2: 6-10 tasks (multiple services)\n- Phase 3: 2-4 tasks (several integrations)\n- Phase 4: 2-3 tasks (optimization, detailed docs)\n\n**Large Features** (20+ tasks):\n- Consider breaking into multiple features\n- Each phase may have 5+ tasks\n- Requires careful dependency management\n- May benefit from sub-phases\n\n## Anti-Patterns to Avoid\n\n- **Phase jumping**: Implementing Phase 2 features before Phase 1 models exist\n- **Phase mixing**: Putting setup tasks in Phase 2 or implementation tasks in Phase 1\n- **Skipping phases**: Every feature needs at least Phase 1 (models) and Phase 2 (logic)\n- **Over-granular phases**: Creating sub-phases or custom phase numbers\n\nFile v1.9.16:modules/tech-stack-patterns.md\n\n---\nname: tech-stack-patterns\ndescription: Technology-specific patterns for common stacks, tools, and ignore file configurations\ncategory: patterns\ntags: [patterns, tech-stack, configuration, ignore-files]\ndependencies: [task-planning]\ncomplexity: beginner\nestimated_tokens: 600\n---\n\n# Technology Stack Patterns\n\n## Overview\n\nCommon patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.\n\n## Universal Ignore Patterns\n\nPatterns that apply to all projects regardless of stack:\n\n```\n# OS artifacts\n.DS_Store\nThumbs.db\ndesktop.ini\n\n# IDE/Editor\n.vscode/\n.idea/\n*.swp\n*.swo\n*~\n.project\n.classpath\n.settings/\n\n# Logs\n*.log\nlogs/\n```\n\n## Language-Specific Patterns\n\n### Node.js / JavaScript / TypeScript\n\n```\n# Dependencies\nnode_modules/\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\n\n# Build outputs\ndist/\nbuild/\nout/\n.next/\n.nuxt/\n\n# Cache\n.npm\n.eslintcache\n.cache/\n.parcel-cache/\n\n# Environment\n.env\n.env.local\n.env.*.local\n```\n\n### Python\n\n```\n# Virtual environments\nvenv/\nenv/\n.venv/\nENV/\n.Python\n\n# Build outputs\n__pycache__/\n*.py[cod]\n*$py.class\n*.so\n.eggs/\n*.egg-info/\ndist/\nbuild/\n\n# Testing\n.pytest_cache/\n.coverage\nhtmlcov/\n.tox/\n```\n\n### Rust\n\n```\n# Build outputs\ntarget/\nCargo.lock  # (exclude for libraries, include for binaries)\n\n# Debug symbols\n*.pdb\n```\n\n### Go\n\n```\n# Build outputs\n*.exe\n*.exe~\n*.dll\n*.so\n*.dylib\n*.test\n\n# Binary\nbin/\nvendor/\n```\n\n### Java / Kotlin\n\n```\n# Build outputs\n*.class\n*.jar\n*.war\n*.ear\ntarget/\nbuild/\nout/\n\n# IDE\n.gradle/\n.mvn/\n```\n\n### C# / .NET\n\n```\n# Build outputs\nbin/\nobj/\n*.dll\n*.exe\n*.pdb\n\n# User-specific\n*.user\n*.suo\n*.userprefs\n```\n\n## Common Tool Configurations\n\n### Docker\n\n```\n# Docker\n.dockerignore\ndocker-compose.override.yml\n```\n\n### Git\n\n```\n# Git\n.git/\n.gitattributes\n```\n\n### Terraform\n\n```\n# Terraform\n*.tfstate\n*.tfstate.*\n.terraform/\n.terraform.lock.hcl\n```\n\n### Linting & Formatting\n\n```\n# ESLint\n.eslintcache\n\n# Prettier\n.prettierignore\n\n# Ruff (Python)\n.ruff_cache/\n```\n\n## Cloud Provider Artifacts\n\n```\n# AWS\n.aws/\n*.pem\n\n# GCP\n.gcloud/\n*-key.json\n\n# Azure\n.azure/\n```\n\n## Usage in Spec-Kit\n\nWhen generating .gitignore recommendations in planning phase:\n1. Start with universal patterns\n2. Add language-specific patterns based on tech stack\n3. Include tool-specific patterns from implementation plan\n4. Add cloud provider patterns if applicable\n\nFile v1.9.16:skill-card.md\n\n## Description: <br>\nGenerates phased, dependency-ordered implementation tasks from specifications after a spec is complete and before implementation begins. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineers use this skill to turn specifications and implementation plans into phased task lists with explicit dependencies, file ownership, verification criteria, and safe parallelization markers. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may be invoked by generic planning-related terms, so an agent could apply it when a user did not intend a full implementation task breakdown. <br>\nMitigation: Confirm the user wants task planning before generating or acting on a phased task list. <br>\nRisk: Generated task lists can include installs, git operations, or production changes that carry operational risk if executed without review. <br>\nMitigation: Review generated tasks and commands before execution, especially for dependency installation, repository changes, or production-impacting work. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-spec-kit-task-planning) <br>\n- [OpenClaw metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit) <br>\n- [Task phase structure](artifact/modules/phase-structure.md) <br>\n- [Task dependency patterns](artifact/modules/dependency-patterns.md) <br>\n- [Technology stack patterns](artifact/modules/tech-stack-patterns.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, shell commands, guidance] <br>\n**Output Format:** [Markdown task plan with task IDs, phases, dependencies, file paths, criteria, and optional inline shell commands] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include parallel markers for independent tasks and quality checklist items for review.] <br>\n\n## Skill Version(s): <br>\n1.9.16 (source: ClawHub release metadata; skill frontmatter lists 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.14: 6 files, 8984 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), skill-card.md (2488b), SKILL.md (3638b), _meta.json (145b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: task-planning\ndescription: |\n  Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation\nversion: 1.9.8\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in strict order when dependencies exist\n- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met\n- **File Coordination**: Tasks affecting same files MUST run sequentially\n\n**Nonconflicting Criteria for Parallel Execution**:\n- ✅ Files: No file overlap between tasks\n- ✅ State: No shared configuration or global state\n- ✅ Dependencies: All prerequisites satisfied\n- ✅ Code paths: No merge conflicts possible\n- ✅ Outputs: Tasks don't need each other's results\n\n**Mark tasks with [P] ONLY if they pass ALL criteria above.**\n\nFor fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.\n\n## Example Task Entry\n\n```markdown\n## Phase 2: Core Implementation\n\n### TASK-007 - Implement user authentication service [P]\n**Dependencies**: TASK-003, TASK-004\n**Files**: src/services/auth.ts, src/types/user.ts\n**Criteria**: All auth tests pass, tokens are valid JWT\n```\n**Verification:** Run `pytest -v` to verify tests pass.\n\n## Quality Checklist\n\n- [ ] All requirements mapped to tasks\n- [ ] Dependencies are explicit\n- [ ] Parallel opportunities identified\n- [ ] Tasks are right-sized (not too large/small)\n- [ ] Each task has clear completion criteria\n\n## Related Skills\n\n- `spec-writing`: Creating source specifications\n- `speckit-orchestrator`: Workflow coordination\n\nFile v1.9.14:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-spec-kit-task-planning\",\n  \"version\": \"1.9.14\",\n  \"publishedAt\": 1782842838198\n}\n\nFile v1.9.14:modules/dependency-patterns.md\n\n# Task Dependency Patterns\n\n## Overview\n\nDependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.\n\n## Dependency Types\n\n### Sequential Dependencies\n\n**Definition**: Task B cannot start until Task A completes\n\n**When to Use**:\n- Task B modifies output from Task A\n- Task B requires interfaces/types defined in Task A\n- Task B tests functionality implemented in Task A\n- Tasks affect the same file(s)\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py\n```\n\n**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.\n\n### Parallel Dependencies [P]\n\n**Definition**: Tasks can execute concurrently with no conflicts\n\n**When to Use**:\n- No shared dependencies beyond a common foundation\n- Operate on different files\n- Independent feature implementations\n- Separate test suites\n\n**Marker**: Suffix task with `[P]`\n\n**Example**:\n```markdown\n### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py\n```\n\n**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.\n\n### Fan-Out Pattern\n\n**Definition**: Multiple tasks depend on single foundation task\n\n**Pattern**:\n```\nTASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\n\n**Use Case**: After creating data models, implement multiple independent services\n\n**Example**:\n```markdown\n### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts\n```\n\n### Fan-In Pattern\n\n**Definition**: Single task depends on multiple prerequisites\n\n**Pattern**:\n```\nTASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘\n```\n\n**Use Case**: Integration task requiring multiple components\n\n**Example**:\n```markdown\n### TASK-002 - Implement auth service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py\n\n### TASK-003 - Implement storage service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py\n\n### TASK-004 - Implement notification service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/notifications.py\n\n### TASK-005 - Integrate services in workflow\n**Dependencies**: TASK-002, TASK-003, TASK-004\n**Files**: src/workflow/coordinator.py\n```\n\n## File Coordination Rules\n\n### Same-File Modification\n\n**Rule**: Tasks modifying the same file must execute sequentially\n\n**Example**:\n```markdown\n### TASK-006 - Add base Task class\n**Files**: src/models/task.py\n\n### TASK-007 - Add Task validation methods\n**Dependencies**: TASK-006\n**Files**: src/models/task.py\n```\n\n**Reasoning**: Prevents merge conflicts and validates clean incremental changes.\n\n### Same-Directory Independence\n\n**Rule**: Tasks creating different files in same directory can run in parallel\n\n**Example**:\n```markdown\n### TASK-008 - Create user model [P]\n**Files**: src/models/user.py\n\n### TASK-009 - Create task model [P]\n**Files**: src/models/task.py\n```\n\n**Reasoning**: No file conflicts, different models, independent implementations.\n\n### Test-Implementation Pairing\n\n**Rule**: Implementation and its tests are typically sequential\n\n**Example**:\n```markdown\n### TASK-010 - Implement resolver logic\n**Files**: src/services/resolver.py\n\n### TASK-011 - Add resolver integration tests\n**Dependencies**: TASK-010\n**Files**: tests/integration/test_resolver.py\n```\n\n**Reasoning**: Can't test what doesn't exist yet.\n\n**Exception**: TDD approach might reverse this (write test first).\n\n## Task ID Conventions\n\n### Numbering Format\n\n**Pattern**: `TASK-NNN` where NNN is zero-padded number\n\n**Examples**:\n- `TASK-001` - First task\n- `TASK-023` - Twenty-third task\n- `TASK-100` - Hundredth task\n\n**Rules**:\n- Always zero-pad to 3 digits minimum\n- Sequential numbering across phases\n- No gaps in sequence\n- Don't reuse IDs\n\n### Ordering Strategy\n\n**By Phase First**:\n```markdown\nTASK-001 through TASK-003: Phase 0\nTASK-004 through TASK-010: Phase 1\nTASK-011 through TASK-025: Phase 2\nTASK-026 through TASK-030: Phase 3\nTASK-031 through TASK-035: Phase 4\n```\n\n**Benefit**: Clear phase boundaries, easy to identify task phase\n\n## Dependency Declaration Format\n\n### Single Dependency\n```markdown\n**Dependencies**: TASK-001\n```\n\n### Multiple Dependencies\n```markdown\n**Dependencies**: TASK-001, TASK-003, TASK-007\n```\n\n### No Dependencies\n```markdown\n**Dependencies**: None\n```\n\n## Common Dependency Patterns\n\n### Linear Chain\n```\nTASK-001 -> TASK-002 -> TASK-003 -> TASK-004\n```\nUse when each task builds directly on previous task.\n\n### Independent Parallel\n```\nTASK-001\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\nUse when multiple features share only initial setup.\n\n### Diamond Pattern\n```\n        TASK-001\n       /          \\\nTASK-002 [P]    TASK-003 [P]\n       \\          /\n        TASK-004\n```\nUse when parallel work converges for integration.\n\n### Layered Dependencies\n```\nPhase 1: TASK-001, TASK-002, TASK-003\n           ↓         ↓         ↓\nPhase 2: TASK-004 depends on all Phase 1\n```\nUse when foundation must be complete before next phase.\n\n## Validation Rules\n\n- [ ] Every task has explicit dependency field\n- [ ] No circular dependencies\n- [ ] Parallel tasks [P] have no file conflicts\n- [ ] Sequential tasks on same file are ordered\n- [ ] All referenced task IDs exist\n- [ ] Tasks reference dependencies from earlier phases\n\nFile v1.9.14:modules/phase-structure.md\n\n# Task Phase Structure\n\n## Overview\n\nTasks 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.\n\n## Phase Definitions\n\n### Phase 0: Setup\n\n**Purpose**: Establish project foundation and development environment\n\n**Typical Tasks**:\n- Project initialization (package.json, pyproject.toml, etc.)\n- Dependency installation and lock files\n- Configuration files (linting, formatting, build tools)\n- Development environment setup\n- Git repository initialization\n- CI/CD pipeline scaffolding\n\n**When to Use**:\n- Starting new projects from scratch\n- Adding new build tools or development dependencies\n- Setting up infrastructure before code implementation\n\n**Example**:\n```markdown\n### TASK-001 - Initialize Python project with uv\n**Dependencies**: None\n**Files**: pyproject.toml, uv.lock\n**Criteria**: `uv sync` runs successfully\n```\n\n### Phase 1: Foundation\n\n**Purpose**: Create core data structures and testing infrastructure\n\n**Typical Tasks**:\n- Data models and type definitions\n- Core interfaces and protocols\n- Database schemas and migrations\n- Test infrastructure and fixtures\n- Base classes and abstract components\n- Shared utilities\n\n**When to Use**:\n- Defining data contracts that other code depends on\n- Creating type systems for type-safe implementations\n- Establishing testing patterns before feature work\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py, tests/test_models.py\n**Criteria**: All model tests pass, types validate with mypy\n```\n\n### Phase 2: Core Implementation\n\n**Purpose**: Implement primary business logic and features\n\n**Typical Tasks**:\n- Service layer implementation\n- Business logic and algorithms\n- API endpoint implementations\n- Core feature functionality\n- Domain-specific operations\n- State management\n\n**When to Use**:\n- Building main application features\n- Implementing business requirements\n- Creating user-facing functionality\n\n**Example**:\n```markdown\n### TASK-007 - Implement task dependency resolver [P]\n**Dependencies**: TASK-002, TASK-003\n**Files**: src/services/resolver.py, tests/test_resolver.py\n**Criteria**: Resolves complex dependency graphs, handles cycles\n```\n\n### Phase 3: Integration\n\n**Purpose**: Connect components and integrate external systems\n\n**Typical Tasks**:\n- External API integrations\n- Middleware implementation\n- Error handling and recovery\n- Logging and monitoring\n- Database connection pooling\n- Message queue integrations\n- Authentication/authorization hooks\n\n**When to Use**:\n- Connecting to external services\n- Adding cross-cutting concerns\n- Implementing system-wide error handling\n\n**Example**:\n```markdown\n### TASK-012 - Add structured logging with context\n**Dependencies**: TASK-007, TASK-009\n**Files**: src/middleware/logging.py, src/utils/logger.py\n**Criteria**: All operations logged with correlation IDs\n```\n\n### Phase 4: Polish\n\n**Purpose**: Optimize, document, and finalize for production\n\n**Typical Tasks**:\n- Performance optimization and profiling\n- detailed documentation\n- End-to-end testing\n- Security hardening\n- Code cleanup and refactoring\n- Production readiness checks\n\n**When to Use**:\n- After core functionality is complete\n- Preparing for production deployment\n- Addressing technical debt before release\n\n**Example**:\n```markdown\n### TASK-015 - Add API documentation with examples\n**Dependencies**: TASK-007, TASK-010\n**Files**: docs/api.md, examples/quickstart.py\n**Criteria**: All endpoints documented, examples run successfully\n```\n\n## Phase Selection Guidelines\n\n### Moving Between Phases\n\n- **Complete phase foundations before advancing**: Don't jump to Phase 3 if Phase 1 models are incomplete\n- **Parallel work within phases**: Multiple Phase 2 tasks can run concurrently if dependencies allow\n- **Return to earlier phases sparingly**: Indicates incomplete planning or new requirements\n\n### Common Patterns\n\n**Small Features** (5-10 tasks):\n- Phase 0: Usually skipped (project exists)\n- Phase 1: 1-2 tasks (data models)\n- Phase 2: 3-5 tasks (core logic)\n- Phase 3: 1-2 tasks (integration)\n- Phase 4: 1-2 tasks (docs, tests)\n\n**Medium Features** (10-20 tasks):\n- Phase 0: 1-2 tasks (new dependencies)\n- Phase 1: 3-4 tasks (multiple models, test infrastructure)\n- Phase 2: 6-10 tasks (multiple services)\n- Phase 3: 2-4 tasks (several integrations)\n- Phase 4: 2-3 tasks (optimization, detailed docs)\n\n**Large Features** (20+ tasks):\n- Consider breaking into multiple features\n- Each phase may have 5+ tasks\n- Requires careful dependency management\n- May benefit from sub-phases\n\n## Anti-Patterns to Avoid\n\n- **Phase jumping**: Implementing Phase 2 features before Phase 1 models exist\n- **Phase mixing**: Putting setup tasks in Phase 2 or implementation tasks in Phase 1\n- **Skipping phases**: Every feature needs at least Phase 1 (models) and Phase 2 (logic)\n- **Over-granular phases**: Creating sub-phases or custom phase numbers\n\nFile v1.9.14:modules/tech-stack-patterns.md\n\n---\nname: tech-stack-patterns\ndescription: Technology-specific patterns for common stacks, tools, and ignore file configurations\ncategory: patterns\ntags: [patterns, tech-stack, configuration, ignore-files]\ndependencies: [task-planning]\ncomplexity: beginner\nestimated_tokens: 600\n---\n\n# Technology Stack Patterns\n\n## Overview\n\nCommon patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.\n\n## Universal Ignore Patterns\n\nPatterns that apply to all projects regardless of stack:\n\n```\n# OS artifacts\n.DS_Store\nThumbs.db\ndesktop.ini\n\n# IDE/Editor\n.vscode/\n.idea/\n*.swp\n*.swo\n*~\n.project\n.classpath\n.settings/\n\n# Logs\n*.log\nlogs/\n```\n\n## Language-Specific Patterns\n\n### Node.js / JavaScript / TypeScript\n\n```\n# Dependencies\nnode_modules/\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\n\n# Build outputs\ndist/\nbuild/\nout/\n.next/\n.nuxt/\n\n# Cache\n.npm\n.eslintcache\n.cache/\n.parcel-cache/\n\n# Environment\n.env\n.env.local\n.env.*.local\n```\n\n### Python\n\n```\n# Virtual environments\nvenv/\nenv/\n.venv/\nENV/\n.Python\n\n# Build outputs\n__pycache__/\n*.py[cod]\n*$py.class\n*.so\n.eggs/\n*.egg-info/\ndist/\nbuild/\n\n# Testing\n.pytest_cache/\n.coverage\nhtmlcov/\n.tox/\n```\n\n### Rust\n\n```\n# Build outputs\ntarget/\nCargo.lock  # (exclude for libraries, include for binaries)\n\n# Debug symbols\n*.pdb\n```\n\n### Go\n\n```\n# Build outputs\n*.exe\n*.exe~\n*.dll\n*.so\n*.dylib\n*.test\n\n# Binary\nbin/\nvendor/\n```\n\n### Java / Kotlin\n\n```\n# Build outputs\n*.class\n*.jar\n*.war\n*.ear\ntarget/\nbuild/\nout/\n\n# IDE\n.gradle/\n.mvn/\n```\n\n### C# / .NET\n\n```\n# Build outputs\nbin/\nobj/\n*.dll\n*.exe\n*.pdb\n\n# User-specific\n*.user\n*.suo\n*.userprefs\n```\n\n## Common Tool Configurations\n\n### Docker\n\n```\n# Docker\n.dockerignore\ndocker-compose.override.yml\n```\n\n### Git\n\n```\n# Git\n.git/\n.gitattributes\n```\n\n### Terraform\n\n```\n# Terraform\n*.tfstate\n*.tfstate.*\n.terraform/\n.terraform.lock.hcl\n```\n\n### Linting & Formatting\n\n```\n# ESLint\n.eslintcache\n\n# Prettier\n.prettierignore\n\n# Ruff (Python)\n.ruff_cache/\n```\n\n## Cloud Provider Artifacts\n\n```\n# AWS\n.aws/\n*.pem\n\n# GCP\n.gcloud/\n*-key.json\n\n# Azure\n.azure/\n```\n\n## Usage in Spec-Kit\n\nWhen generating .gitignore recommendations in planning phase:\n1. Start with universal patterns\n2. Add language-specific patterns based on tech stack\n3. Include tool-specific patterns from implementation plan\n4. Add cloud provider patterns if applicable\n\nFile v1.9.14:skill-card.md\n\n## Description: <br>\nGenerates phased, dependency-ordered implementation tasks from specifications after the specification is complete and before implementation begins. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineers use this skill after a specification is complete to turn specs and implementation plans into phased, dependency-ordered tasks with dependencies, file targets, parallel markers, and completion criteria. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate during broad planning or implementation discussions and produce task plans from incomplete context. <br>\nMitigation: Review when it is invoked and check generated tasks against the accepted specification before using them as project requirements. <br>\nRisk: Incorrect dependencies, file coordination, or parallel markers could lead to misleading implementation order or conflicting work. <br>\nMitigation: Review dependency declarations, file overlap, and completion criteria before executing the task plan. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-spec-kit-task-planning) <br>\n- [OpenClaw homepage from skill metadata](https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit) <br>\n- [Task phase structure module](artifact/modules/phase-structure.md) <br>\n- [Task dependency patterns module](artifact/modules/dependency-patterns.md) <br>\n- [Technology stack patterns module](artifact/modules/tech-stack-patterns.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown task plan entries with phased headings, dependency metadata, file paths, and verification criteria.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces task-planning guidance only; no tool calls, hidden execution, persistence, or credential use were identified in server security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.14 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.13: 6 files, 8911 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), skill-card.md (2315b), SKILL.md (3638b), _meta.json (145b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: task-planning\ndescription: |\n  Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation\nversion: 1.9.8\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in strict order when dependencies exist\n- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met\n- **File Coordination**: Tasks affecting same files MUST run sequentially\n\n**Nonconflicting Criteria for Parallel Execution**:\n- ✅ Files: No file overlap between tasks\n- ✅ State: No shared configuration or global state\n- ✅ Dependencies: All prerequisites satisfied\n- ✅ Code paths: No merge conflicts possible\n- ✅ Outputs: Tasks don't need each other's results\n\n**Mark tasks with [P] ONLY if they pass ALL criteria above.**\n\nFor fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.\n\n## Example Task Entry\n\n```markdown\n## Phase 2: Core Implementation\n\n### TASK-007 - Implement user authentication service [P]\n**Dependencies**: TASK-003, TASK-004\n**Files**: src/services/auth.ts, src/types/user.ts\n**Criteria**: All auth tests pass, tokens are valid JWT\n```\n**Verification:** Run `pytest -v` to verify tests pass.\n\n## Quality Checklist\n\n- [ ] All requirements mapped to tasks\n- [ ] Dependencies are explicit\n- [ ] Parallel opportunities identified\n- [ ] Tasks are right-sized (not too large/small)\n- [ ] Each task has clear completion criteria\n\n## Related Skills\n\n- `spec-writing`: Creating source specifications\n- `speckit-orchestrator`: Workflow coordination\n\nFile v1.9.13:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-spec-kit-task-planning\",\n  \"version\": \"1.9.13\",\n  \"publishedAt\": 1782577507145\n}\n\nFile v1.9.13:modules/dependency-patterns.md\n\n# Task Dependency Patterns\n\n## Overview\n\nDependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.\n\n## Dependency Types\n\n### Sequential Dependencies\n\n**Definition**: Task B cannot start until Task A completes\n\n**When to Use**:\n- Task B modifies output from Task A\n- Task B requires interfaces/types defined in Task A\n- Task B tests functionality implemented in Task A\n- Tasks affect the same file(s)\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py\n```\n\n**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.\n\n### Parallel Dependencies [P]\n\n**Definition**: Tasks can execute concurrently with no conflicts\n\n**When to Use**:\n- No shared dependencies beyond a common foundation\n- Operate on different files\n- Independent feature implementations\n- Separate test suites\n\n**Marker**: Suffix task with `[P]`\n\n**Example**:\n```markdown\n### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py\n```\n\n**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.\n\n### Fan-Out Pattern\n\n**Definition**: Multiple tasks depend on single foundation task\n\n**Pattern**:\n```\nTASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\n\n**Use Case**: After creating data models, implement multiple independent services\n\n**Example**:\n```markdown\n### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts\n```\n\n### Fan-In Pattern\n\n**Definition**: Single task depends on multiple prerequisites\n\n**Pattern**:\n```\nTASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘\n```\n\n**Use Case**: Integration task requiring multiple components\n\n**Example**:\n```markdown\n### TASK-002 - Implement auth service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py\n\n### TASK-003 - Implement storage service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py\n\n### TASK-004 - Implement notification service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/notifications.py\n\n### TASK-005 - Integrate services in workflow\n**Dependencies**: TASK-002, TASK-003, TASK-004\n**Files**: src/workflow/coordinator.py\n```\n\n## File Coordination Rules\n\n### Same-File Modification\n\n**Rule**: Tasks modifying the same file must execute sequentially\n\n**Example**:\n```markdown\n### TASK-006 - Add base Task class\n**Files**: src/models/task.py\n\n### TASK-007 - Add Task validation methods\n**Dependencies**: TASK-006\n**Files**: src/models/task.py\n```\n\n**Reasoning**: Prevents merge conflicts and validates clean incremental changes.\n\n### Same-Directory Independence\n\n**Rule**: Tasks creating different files in same directory can run in parallel\n\n**Example**:\n```markdown\n### TASK-008 - Create user model [P]\n**Files**: src/models/user.py\n\n### TASK-009 - Create task model [P]\n**Files**: src/models/task.py\n```\n\n**Reasoning**: No file conflicts, different models, independent implementations.\n\n### Test-Implementation Pairing\n\n**Rule**: Implementation and its tests are typically sequential\n\n**Example**:\n```markdown\n### TASK-010 - Implement resolver logic\n**Files**: src/services/resolver.py\n\n### TASK-011 - Add resolver integration tests\n**Dependencies**: TASK-010\n**Files**: tests/integration/test_resolver.py\n```\n\n**Reasoning**: Can't test what doesn't exist yet.\n\n**Exception**: TDD approach might reverse this (write test first).\n\n## Task ID Conventions\n\n### Numbering Format\n\n**Pattern**: `TASK-NNN` where NNN is zero-padded number\n\n**Examples**:\n- `TASK-001` - First task\n- `TASK-023` - Twenty-third task\n- `TASK-100` - Hundredth task\n\n**Rules**:\n- Always zero-pad to 3 digits minimum\n- Sequential numbering across phases\n- No gaps in sequence\n- Don't reuse IDs\n\n### Ordering Strategy\n\n**By Phase First**:\n```markdown\nTASK-001 through TASK-003: Phase 0\nTASK-004 through TASK-010: Phase 1\nTASK-011 through TASK-025: Phase 2\nTASK-026 through TASK-030: Phase 3\nTASK-031 through TASK-035: Phase 4\n```\n\n**Benefit**: Clear phase boundaries, easy to identify task phase\n\n## Dependency Declaration Format\n\n### Single Dependency\n```markdown\n**Dependencies**: TASK-001\n```\n\n### Multiple Dependencies\n```markdown\n**Dependencies**: TASK-001, TASK-003, TASK-007\n```\n\n### No Dependencies\n```markdown\n**Dependencies**: None\n```\n\n## Common Dependency Patterns\n\n### Linear Chain\n```\nTASK-001 -> TASK-002 -> TASK-003 -> TASK-004\n```\nUse when each task builds directly on previous task.\n\n### Independent Parallel\n```\nTASK-001\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\nUse when multiple features share only initial setup.\n\n### Diamond Pattern\n```\n        TASK-001\n       /          \\\nTASK-002 [P]    TASK-003 [P]\n       \\          /\n        TASK-004\n```\nUse when parallel work converges for integration.\n\n### Layered Dependencies\n```\nPhase 1: TASK-001, TASK-002, TASK-003\n           ↓         ↓         ↓\nPhase 2: TASK-004 depends on all Phase 1\n```\nUse when foundation must be complete before next phase.\n\n## Validation Rules\n\n- [ ] Every task has explicit dependency field\n- [ ] No circular dependencies\n- [ ] Parallel tasks [P] have no file conflicts\n- [ ] Sequential tasks on same file are ordered\n- [ ] All referenced task IDs exist\n- [ ] Tasks reference dependencies from earlier phases\n\nFile v1.9.13:modules/phase-structure.md\n\n# Task Phase Structure\n\n## Overview\n\nTasks 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.\n\n## Phase Definitions\n\n### Phase 0: Setup\n\n**Purpose**: Establish project foundation and development environment\n\n**Typical Tasks**:\n- Project initialization (package.json, pyproject.toml, etc.)\n- Dependency installation and lock files\n- Configuration files (linting, formatting, build tools)\n- Development environment setup\n- Git repository initialization\n- CI/CD pipeline scaffolding\n\n**When to Use**:\n- Starting new projects from scratch\n- Adding new build tools or development dependencies\n- Setting up infrastructure before code implementation\n\n**Example**:\n```markdown\n### TASK-001 - Initialize Python project with uv\n**Dependencies**: None\n**Files**: pyproject.toml, uv.lock\n**Criteria**: `uv sync` runs successfully\n```\n\n### Phase 1: Foundation\n\n**Purpose**: Create core data structures and testing infrastructure\n\n**Typical Tasks**:\n- Data models and type definitions\n- Core interfaces and protocols\n- Database schemas and migrations\n- Test infrastructure and fixtures\n- Base classes and abstract components\n- Shared utilities\n\n**When to Use**:\n- Defining data contracts that other code depends on\n- Creating type systems for type-safe implementations\n- Establishing testing patterns before feature work\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py, tests/test_models.py\n**Criteria**: All model tests pass, types validate with mypy\n```\n\n### Phase 2: Core Implementation\n\n**Purpose**: Implement primary business logic and features\n\n**Typical Tasks**:\n- Service layer implementation\n- Business logic and algorithms\n- API endpoint implementations\n- Core feature functionality\n- Domain-specific operations\n- State management\n\n**When to Use**:\n- Building main application features\n- Implementing business requirements\n- Creating user-facing functionality\n\n**Example**:\n```markdown\n### TASK-007 - Implement task dependency resolver [P]\n**Dependencies**: TASK-002, TASK-003\n**Files**: src/services/resolver.py, tests/test_resolver.py\n**Criteria**: Resolves complex dependency graphs, handles cycles\n```\n\n### Phase 3: Integration\n\n**Purpose**: Connect components and integrate external systems\n\n**Typical Tasks**:\n- External API integrations\n- Middleware implementation\n- Error handling and recovery\n- Logging and monitoring\n- Database connection pooling\n- Message queue integrations\n- Authentication/authorization hooks\n\n**When to Use**:\n- Connecting to external services\n- Adding cross-cutting concerns\n- Implementing system-wide error handling\n\n**Example**:\n```markdown\n### TASK-012 - Add structured logging with context\n**Dependencies**: TASK-007, TASK-009\n**Files**: src/middleware/logging.py, src/utils/logger.py\n**Criteria**: All operations logged with correlation IDs\n```\n\n### Phase 4: Polish\n\n**Purpose**: Optimize, document, and finalize for production\n\n**Typical Tasks**:\n- Performance optimization and profiling\n- detailed documentation\n- End-to-end testing\n- Security hardening\n- Code cleanup and refactoring\n- Production readiness checks\n\n**When to Use**:\n- After core functionality is complete\n- Preparing for production deployment\n- Addressing technical debt before release\n\n**Example**:\n```markdown\n### TASK-015 - Add API documentation with examples\n**Dependencies**: TASK-007, TASK-010\n**Files**: docs/api.md, examples/quickstart.py\n**Criteria**: All endpoints documented, examples run successfully\n```\n\n## Phase Selection Guidelines\n\n### Moving Between Phases\n\n- **Complete phase foundations before advancing**: Don't jump to Phase 3 if Phase 1 models are incomplete\n- **Parallel work within phases**: Multiple Phase 2 tasks can run concurrently if dependencies allow\n- **Return to earlier phases sparingly**: Indicates incomplete planning or new requirements\n\n### Common Patterns\n\n**Small Features** (5-10 tasks):\n- Phase 0: Usually skipped (project exists)\n- Phase 1: 1-2 tasks (data models)\n- Phase 2: 3-5 tasks (core logic)\n- Phase 3: 1-2 tasks (integration)\n- Phase 4: 1-2 tasks (docs, tests)\n\n**Medium Features** (10-20 tasks):\n- Phase 0: 1-2 tasks (new dependencies)\n- Phase 1: 3-4 tasks (multiple models, test infrastructure)\n- Phase 2: 6-10 tasks (multiple services)\n- Phase 3: 2-4 tasks (several integrations)\n- Phase 4: 2-3 tasks (optimization, detailed docs)\n\n**Large Features** (20+ tasks):\n- Consider breaking into multiple features\n- Each phase may have 5+ tasks\n- Requires careful dependency management\n- May benefit from sub-phases\n\n## Anti-Patterns to Avoid\n\n- **Phase jumping**: Implementing Phase 2 features before Phase 1 models exist\n- **Phase mixing**: Putting setup tasks in Phase 2 or implementation tasks in Phase 1\n- **Skipping phases**: Every feature needs at least Phase 1 (models) and Phase 2 (logic)\n- **Over-granular phases**: Creating sub-phases or custom phase numbers\n\nFile v1.9.13:modules/tech-stack-patterns.md\n\n---\nname: tech-stack-patterns\ndescription: Technology-specific patterns for common stacks, tools, and ignore file configurations\ncategory: patterns\ntags: [patterns, tech-stack, configuration, ignore-files]\ndependencies: [task-planning]\ncomplexity: beginner\nestimated_tokens: 600\n---\n\n# Technology Stack Patterns\n\n## Overview\n\nCommon patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.\n\n## Universal Ignore Patterns\n\nPatterns that apply to all projects regardless of stack:\n\n```\n# OS artifacts\n.DS_Store\nThumbs.db\ndesktop.ini\n\n# IDE/Editor\n.vscode/\n.idea/\n*.swp\n*.swo\n*~\n.project\n.classpath\n.settings/\n\n# Logs\n*.log\nlogs/\n```\n\n## Language-Specific Patterns\n\n### Node.js / JavaScript / TypeScript\n\n```\n# Dependencies\nnode_modules/\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\n\n# Build outputs\ndist/\nbuild/\nout/\n.next/\n.nuxt/\n\n# Cache\n.npm\n.eslintcache\n.cache/\n.parcel-cache/\n\n# Environment\n.env\n.env.local\n.env.*.local\n```\n\n### Python\n\n```\n# Virtual environments\nvenv/\nenv/\n.venv/\nENV/\n.Python\n\n# Build outputs\n__pycache__/\n*.py[cod]\n*$py.class\n*.so\n.eggs/\n*.egg-info/\ndist/\nbuild/\n\n# Testing\n.pytest_cache/\n.coverage\nhtmlcov/\n.tox/\n```\n\n### Rust\n\n```\n# Build outputs\ntarget/\nCargo.lock  # (exclude for libraries, include for binaries)\n\n# Debug symbols\n*.pdb\n```\n\n### Go\n\n```\n# Build outputs\n*.exe\n*.exe~\n*.dll\n*.so\n*.dylib\n*.test\n\n# Binary\nbin/\nvendor/\n```\n\n### Java / Kotlin\n\n```\n# Build outputs\n*.class\n*.jar\n*.war\n*.ear\ntarget/\nbuild/\nout/\n\n# IDE\n.gradle/\n.mvn/\n```\n\n### C# / .NET\n\n```\n# Build outputs\nbin/\nobj/\n*.dll\n*.exe\n*.pdb\n\n# User-specific\n*.user\n*.suo\n*.userprefs\n```\n\n## Common Tool Configurations\n\n### Docker\n\n```\n# Docker\n.dockerignore\ndocker-compose.override.yml\n```\n\n### Git\n\n```\n# Git\n.git/\n.gitattributes\n```\n\n### Terraform\n\n```\n# Terraform\n*.tfstate\n*.tfstate.*\n.terraform/\n.terraform.lock.hcl\n```\n\n### Linting & Formatting\n\n```\n# ESLint\n.eslintcache\n\n# Prettier\n.prettierignore\n\n# Ruff (Python)\n.ruff_cache/\n```\n\n## Cloud Provider Artifacts\n\n```\n# AWS\n.aws/\n*.pem\n\n# GCP\n.gcloud/\n*-key.json\n\n# Azure\n.azure/\n```\n\n## Usage in Spec-Kit\n\nWhen generating .gitignore recommendations in planning phase:\n1. Start with universal patterns\n2. Add language-specific patterns based on tech stack\n3. Include tool-specific patterns from implementation plan\n4. Add cloud provider patterns if applicable\n\nFile v1.9.13:skill-card.md\n\n## Description: <br>\nGenerates phased, dependency-ordered implementation tasks from completed specifications. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and implementation agents use this skill after a specification is complete to convert requirements into phased task lists with explicit dependencies, affected files, parallelization markers, and completion criteria. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generic triggers such as tasks, planning, implementation, and dependencies may activate the skill in ordinary planning conversations. <br>\nMitigation: Confirm the user is asking to turn a completed specification into an implementation task plan before relying on the output. <br>\nRisk: Generated task plans may include incorrect dependencies, unsafe parallelization, or incomplete verification criteria. <br>\nMitigation: Review file overlaps, task ordering, and completion criteria before executing the plan. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-spec-kit-task-planning) <br>\n- [Clawdis homepage](https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit) <br>\n- [Task phase structure](modules/phase-structure.md) <br>\n- [Task dependency patterns](modules/dependency-patterns.md) <br>\n- [Technology stack patterns](modules/tech-stack-patterns.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Guidance, Shell commands, Configuration] <br>\n**Output Format:** [Markdown task plan with phased task entries, dependency fields, affected file paths, and verification criteria] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include parallel markers and code or shell snippets when useful.] <br>\n\n## Skill Version(s): <br>\n1.9.13 (source: release metadata; artifact frontmatter lists 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.12: 6 files, 8843 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), skill-card.md (2068b), SKILL.md (3638b), _meta.json (145b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: task-planning\ndescription: |\n  Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation\nversion: 1.9.8\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in strict order when dependencies exist\n- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met\n- **File Coordination**: Tasks affecting same files MUST run sequentially\n\n**Nonconflicting Criteria for Parallel Execution**:\n- ✅ Files: No file overlap between tasks\n- ✅ State: No shared configuration or global state\n- ✅ Dependencies: All prerequisites satisfied\n- ✅ Code paths: No merge conflicts possible\n- ✅ Outputs: Tasks don't need each other's results\n\n**Mark tasks with [P] ONLY if they pass ALL criteria above.**\n\nFor fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.\n\n## Example Task Entry\n\n```markdown\n## Phase 2: Core Implementation\n\n### TASK-007 - Implement user authentication service [P]\n**Dependencies**: TASK-003, TASK-004\n**Files**: src/services/auth.ts, src/types/user.ts\n**Criteria**: All auth tests pass, tokens are valid JWT\n```\n**Verification:** Run `pytest -v` to verify tests pass.\n\n## Quality Checklist\n\n- [ ] All requirements mapped to tasks\n- [ ] Dependencies are explicit\n- [ ] Parallel opportunities identified\n- [ ] Tasks are right-sized (not too large/small)\n- [ ] Each task has clear completion criteria\n\n## Related Skills\n\n- `spec-writing`: Creating source specifications\n- `speckit-orchestrator`: Workflow coordination\n\nFile v1.9.12:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-spec-kit-task-planning\",\n  \"version\": \"1.9.12\",\n  \"publishedAt\": 1781839257742\n}\n\nFile v1.9.12:modules/dependency-patterns.md\n\n# Task Dependency Patterns\n\n## Overview\n\nDependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.\n\n## Dependency Types\n\n### Sequential Dependencies\n\n**Definition**: Task B cannot start until Task A completes\n\n**When to Use**:\n- Task B modifies output from Task A\n- Task B requires interfaces/types defined in Task A\n- Task B tests functionality implemented in Task A\n- Tasks affect the same file(s)\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py\n```\n\n**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.\n\n### Parallel Dependencies [P]\n\n**Definition**: Tasks can execute concurrently with no conflicts\n\n**When to Use**:\n- No shared dependencies beyond a common foundation\n- Operate on different files\n- Independent feature implementations\n- Separate test suites\n\n**Marker**: Suffix task with `[P]`\n\n**Example**:\n```markdown\n### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py\n```\n\n**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.\n\n### Fan-Out Pattern\n\n**Definition**: Multiple tasks depend on single foundation task\n\n**Pattern**:\n```\nTASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\n\n**Use Case**: After creating data models, implement multiple independent services\n\n**Example**:\n```markdown\n### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts\n```\n\n### Fan-In Pattern\n\n**Definition**: Single task depends on multiple prerequisites\n\n**Pattern**:\n```\nTASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘\n```\n\n**Use Case**: Integration task requiring multiple components\n\n**Example**:\n```markdown\n### TASK-002 - Implement auth service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py\n\n### TASK-003 - Implement storage service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py\n\n### TASK-004 - Implement notification service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/notifications.py\n\n### TASK-005 - Integrate services in workflow\n**Dependencies**: TASK-002, TASK-003, TASK-004\n**Files**: src/workflow/coordinator.py\n```\n\n## File Coordination Rules\n\n### Same-File Modification\n\n**Rule**: Tasks modifying the same file must execute sequentially\n\n**Example**:\n```markdown\n### TASK-006 - Add base Task class\n**Files**: src/models/task.py\n\n### TASK-007 - Add Task validation methods\n**Dependencies**: TASK-006\n**Files**: src/models/task.py\n```\n\n**Reasoning**: Prevents merge conflicts and validates clean incremental changes.\n\n### Same-Directory Independence\n\n**Rule**: Tasks creating different files in same directory can run in parallel\n\n**Example**:\n```markdown\n### TASK-008 - Create user model [P]\n**Files**: src/models/user.py\n\n### TASK-009 - Create task model [P]\n**Files**: src/models/task.py\n```\n\n**Reasoning**: No file conflicts, different models, independent implementations.\n\n### Test-Implementation Pairing\n\n**Rule**: Implementation and its tests are typically sequential\n\n**Example**:\n```markdown\n### TASK-010 - Implement resolver logic\n**Files**: src/services/resolver.py\n\n### TASK-011 - Add resolver integration tests\n**Dependencies**: TASK-010\n**Files**: tests/integration/test_resolver.py\n```\n\n**Reasoning**: Can't test what doesn't exist yet.\n\n**Exception**: TDD approach might reverse this (write test first).\n\n## Task ID Conventions\n\n### Numbering Format\n\n**Pattern**: `TASK-NNN` where NNN is zero-padded number\n\n**Examples**:\n- `TASK-001` - First task\n- `TASK-023` - Twenty-third task\n- `TASK-100` - Hundredth task\n\n**Rules**:\n- Always zero-pad to 3 digits minimum\n- Sequential numbering across phases\n- No gaps in sequence\n- Don't reuse IDs\n\n### Ordering Strategy\n\n**By Phase First**:\n```markdown\nTASK-001 through TASK-003: Phase 0\nTASK-004 through TASK-010: Phase 1\nTASK-011 through TASK-025: Phase 2\nTASK-026 through TASK-030: Phase 3\nTASK-031 through TASK-035: Phase 4\n```\n\n**Benefit**: Clear phase boundaries, easy to identify task phase\n\n## Dependency Declaration Format\n\n### Single Dependency\n```markdown\n**Dependencies**: TASK-001\n```\n\n### Multiple Dependencies\n```markdown\n**Dependencies**: TASK-001, TASK-003, TASK-007\n```\n\n### No Dependencies\n```markdown\n**Dependencies**: None\n```\n\n## Common Dependency Patterns\n\n### Linear Chain\n```\nTASK-001 -> TASK-002 -> TASK-003 -> TASK-004\n```\nUse when each task builds directly on previous task.\n\n### Independent Parallel\n```\nTASK-001\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\nUse when multiple features share only initial setup.\n\n### Diamond Pattern\n```\n        TASK-001\n       /          \\\nTASK-002 [P]    TASK-003 [P]\n       \\          /\n        TASK-004\n```\nUse when parallel work converges for integration.\n\n### Layered Dependencies\n```\nPhase 1: TASK-001, TASK-002, TASK-003\n           ↓         ↓         ↓\nPhase 2: TASK-004 depends on all Phase 1\n```\nUse when foundation must be complete before next phase.\n\n## Validation Rules\n\n- [ ] Every task has explicit dependency field\n- [ ] No circular dependencies\n- [ ] Parallel tasks [P] have no file conflicts\n- [ ] Sequential tasks on same file are ordered\n- [ ] All referenced task IDs exist\n- [ ] Tasks reference dependencies from earlier phases\n\nFile v1.9.12:modules/phase-structure.md\n\n# Task Phase Structure\n\n## Overview\n\nTasks 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.\n\n## Phase Definitions\n\n### Phase 0: Setup\n\n**Purpose**: Establish project foundation and development environment\n\n**Typical Tasks**:\n- Project initialization (package.json, pyproject.toml, etc.)\n- Dependency installation and lock files\n- Configuration files (linting, formatting, build tools)\n- Development environment setup\n- Git repository initialization\n- CI/CD pipeline scaffolding\n\n**When to Use**:\n- Starting new projects from scratch\n- Adding new build tools or development dependencies\n- Setting up infrastructure before code implementation\n\n**Example**:\n```markdown\n### TASK-001 - Initialize Python project with uv\n**Dependencies**: None\n**Files**: pyproject.toml, uv.lock\n**Criteria**: `uv sync` runs successfully\n```\n\n### Phase 1: Foundation\n\n**Purpose**: Create core data structures and testing infrastructure\n\n**Typical Tasks**:\n- Data models and type definitions\n- Core interfaces and protocols\n- Database schemas and migrations\n- Test infrastructure and fixtures\n- Base classes and abstract components\n- Shared utilities\n\n**When to Use**:\n- Defining data contracts that other code depends on\n- Creating type systems for type-safe implementations\n- Establishing testing patterns before feature work\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py, tests/test_models.py\n**Criteria**: All model tests pass, types validate with mypy\n```\n\n### Phase 2: Core Implementation\n\n**Purpose**: Implement primary business logic and features\n\n**Typical Tasks**:\n- Service layer implementation\n- Business logic and algorithms\n- API endpoint implementations\n- Core feature functionality\n- Domain-specific operations\n- State management\n\n**When to Use**:\n- Building main application features\n- Implementing business requirements\n- Creating user-facing functionality\n\n**Example**:\n```markdown\n### TASK-007 - Implement task dependency resolver [P]\n**Dependencies**: TASK-002, TASK-003\n**Files**: src/services/resolver.py, tests/test_resolver.py\n**Criteria**: Resolves complex dependency graphs, handles cycles\n```\n\n### Phase 3: Integration\n\n**Purpose**: Connect components and integrate external systems\n\n**Typical Tasks**:\n- External API integrations\n- Middleware implementation\n- Error handling and recovery\n- Logging and monitoring\n- Database connection pooling\n- Message queue integrations\n- Authentication/authorization hooks\n\n**When to Use**:\n- Connecting to external services\n- Adding cross-cutting concerns\n- Implementing system-wide error handling\n\n**Example**:\n```markdown\n### TASK-012 - Add structured logging with context\n**Dependencies**: TASK-007, TASK-009\n**Files**: src/middleware/logging.py, src/utils/logger.py\n**Criteria**: All operations logged with correlation IDs\n```\n\n### Phase 4: Polish\n\n**Purpose**: Optimize, document, and finalize for production\n\n**Typical Tasks**:\n- Performance optimization and profiling\n- detailed documentation\n- End-to-end testing\n- Security hardening\n- Code cleanup and refactoring\n- Production readiness checks\n\n**When to Use**:\n- After core functionality is complete\n- Preparing for production deployment\n- Addressing technical debt before release\n\n**Example**:\n```markdown\n### TASK-015 - Add API documentation with examples\n**Dependencies**: TASK-007, TASK-010\n**Files**: docs/api.md, examples/quickstart.py\n**Criteria**: All endpoints documented, examples run successfully\n```\n\n## Phase Selection Guidelines\n\n### Moving Between Phases\n\n- **Complete phase foundations before advancing**: Don't jump to Phase 3 if Phase 1 models are incomplete\n- **Parallel work within phases**: Multiple Phase 2 tasks can run concurrently if dependencies allow\n- **Return to earlier phases sparingly**: Indicates incomplete planning or new requirements\n\n### Common Patterns\n\n**Small Features** (5-10 tasks):\n- Phase 0: Usually skipped (project exists)\n- Phase 1: 1-2 tasks (data models)\n- Phase 2: 3-5 tasks (core logic)\n- Phase 3: 1-2 tasks (integration)\n- Phase 4: 1-2 tasks (docs, tests)\n\n**Medium Features** (10-20 tasks):\n- Phase 0: 1-2 tasks (new dependencies)\n- Phase 1: 3-4 tasks (multiple models, test infrastructure)\n- Phase 2: 6-10 tasks (multiple services)\n- Phase 3: 2-4 tasks (several integrations)\n- Phase 4: 2-3 tasks (optimization, detailed docs)\n\n**Large Features** (20+ tasks):\n- Consider breaking into multiple features\n- Each phase may have 5+ tasks\n- Requires careful dependency management\n- May benefit from sub-phases\n\n## Anti-Patterns to Avoid\n\n- **Phase jumping**: Implementing Phase 2 features before Phase 1 models exist\n- **Phase mixing**: Putting setup tasks in Phase 2 or implementation tasks in Phase 1\n- **Skipping phases**: Every feature needs at least Phase 1 (models) and Phase 2 (logic)\n- **Over-granular phases**: Creating sub-phases or custom phase numbers\n\nFile v1.9.12:modules/tech-stack-patterns.md\n\n---\nname: tech-stack-patterns\ndescription: Technology-specific patterns for common stacks, tools, and ignore file configurations\ncategory: patterns\ntags: [patterns, tech-stack, configuration, ignore-files]\ndependencies: [task-planning]\ncomplexity: beginner\nestimated_tokens: 600\n---\n\n# Technology Stack Patterns\n\n## Overview\n\nCommon patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.\n\n## Universal Ignore Patterns\n\nPatterns that apply to all projects regardless of stack:\n\n```\n# OS artifacts\n.DS_Store\nThumbs.db\ndesktop.ini\n\n# IDE/Editor\n.vscode/\n.idea/\n*.swp\n*.swo\n*~\n.project\n.classpath\n.settings/\n\n# Logs\n*.log\nlogs/\n```\n\n## Language-Specific Patterns\n\n### Node.js / JavaScript / TypeScript\n\n```\n# Dependencies\nnode_modules/\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\n\n# Build outputs\ndist/\nbuild/\nout/\n.next/\n.nuxt/\n\n# Cache\n.npm\n.eslintcache\n.cache/\n.parcel-cache/\n\n# Environment\n.env\n.env.local\n.env.*.local\n```\n\n### Python\n\n```\n# Virtual environments\nvenv/\nenv/\n.venv/\nENV/\n.Python\n\n# Build outputs\n__pycache__/\n*.py[cod]\n*$py.class\n*.so\n.eggs/\n*.egg-info/\ndist/\nbuild/\n\n# Testing\n.pytest_cache/\n.coverage\nhtmlcov/\n.tox/\n```\n\n### Rust\n\n```\n# Build outputs\ntarget/\nCargo.lock  # (exclude for libraries, include for binaries)\n\n# Debug symbols\n*.pdb\n```\n\n### Go\n\n```\n# Build outputs\n*.exe\n*.exe~\n*.dll\n*.so\n*.dylib\n*.test\n\n# Binary\nbin/\nvendor/\n```\n\n### Java / Kotlin\n\n```\n# Build outputs\n*.class\n*.jar\n*.war\n*.ear\ntarget/\nbuild/\nout/\n\n# IDE\n.gradle/\n.mvn/\n```\n\n### C# / .NET\n\n```\n# Build outputs\nbin/\nobj/\n*.dll\n*.exe\n*.pdb\n\n# User-specific\n*.user\n*.suo\n*.userprefs\n```\n\n## Common Tool Configurations\n\n### Docker\n\n```\n# Docker\n.dockerignore\ndocker-compose.override.yml\n```\n\n### Git\n\n```\n# Git\n.git/\n.gitattributes\n```\n\n### Terraform\n\n```\n# Terraform\n*.tfstate\n*.tfstate.*\n.terraform/\n.terraform.lock.hcl\n```\n\n### Linting & Formatting\n\n```\n# ESLint\n.eslintcache\n\n# Prettier\n.prettierignore\n\n# Ruff (Python)\n.ruff_cache/\n```\n\n## Cloud Provider Artifacts\n\n```\n# AWS\n.aws/\n*.pem\n\n# GCP\n.gcloud/\n*-key.json\n\n# Azure\n.azure/\n```\n\n## Usage in Spec-Kit\n\nWhen generating .gitignore recommendations in planning phase:\n1. Start with universal patterns\n2. Add language-specific patterns based on tech stack\n3. Include tool-specific patterns from implementation plan\n4. Add cloud provider patterns if applicable\n\nFile v1.9.12:skill-card.md\n\n## Description: <br>\nGenerates phased, dependency-ordered implementation tasks from specifications after the specification is complete and before implementation starts. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and agent operators use this skill to turn completed specifications and implementation plans into phased, dependency-ordered task lists before implementation begins. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad activation words may cause the skill to appear during generic planning or implementation conversations. <br>\nMitigation: Confirm the task is specifically about converting a completed specification into implementation tasks before relying on the output. <br>\nRisk: The referenced Night Market or Claude Code plugin may include agents, hooks, or commands beyond this Markdown-only skill. <br>\nMitigation: Review the referenced plugin separately before installing any additional components. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/athola/nm-spec-kit-task-planning) <br>\n- [Skill Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Guidance] <br>\n**Output Format:** [Markdown task lists with phased task entries, dependencies, file paths, and completion criteria.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Tasks use TASK-NNN identifiers, phase labels, dependency fields, and [P] markers for parallel work.] <br>\n\n## Skill Version(s): <br>\n1.9.12 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.2: 6 files, 9046 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), skill-card.md (2323b), SKILL.md (3881b), _meta.json (144b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: task-planning\ndescription: |\n  Generate phased, dependency-ordered tasks from specifications with parallelization opportunities and tech-stack patterns\nversion: 1.9.5\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in strict order when dependencies exist\n- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met\n- **File Coordination**: Tasks affecting same files MUST run sequentially\n\n**Nonconflicting Criteria for Parallel Execution**:\n- ✅ Files: No file overlap between tasks\n- ✅ State: No shared configuration or global state\n- ✅ Dependencies: All prerequisites satisfied\n- ✅ Code paths: No merge conflicts possible\n- ✅ Outputs: Tasks don't need each other's results\n\n**Mark tasks with [P] ONLY if they pass ALL criteria above.**\n\nFor fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.\n\n## Example Task Entry\n\n```markdown\n## Phase 2: Core Implementation\n\n### TASK-007 - Implement user authentication service [P]\n**Dependencies**: TASK-003, TASK-004\n**Files**: src/services/auth.ts, src/types/user.ts\n**Criteria**: All auth tests pass, tokens are valid JWT\n```\n**Verification:** Run `pytest -v` to verify tests pass.\n\n## Quality Checklist\n\n- [ ] All requirements mapped to tasks\n- [ ] Dependencies are explicit\n- [ ] Parallel opportunities identified\n- [ ] Tasks are right-sized (not too large/small)\n- [ ] Each task has clear completion criteria\n\n## Related Skills\n\n- `spec-writing`: Creating source specifications\n- `speckit-orchestrator`: Workflow coordination\n## Troubleshooting\n\n### Common Issues\n\n**Command not found**\nEnsure all dependencies are installed and in PATH\n\n**Permission errors**\nCheck file permissions and run with appropriate privileges\n\n**Unexpected behavior**\nEnable verbose logging with `--verbose` flag\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-spec-kit-task-planning\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1778293248979\n}\n\nFile v1.0.2:modules/dependency-patterns.md\n\n# Task Dependency Patterns\n\n## Overview\n\nDependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.\n\n## Dependency Types\n\n### Sequential Dependencies\n\n**Definition**: Task B cannot start until Task A completes\n\n**When to Use**:\n- Task B modifies output from Task A\n- Task B requires interfaces/types defined in Task A\n- Task B tests functionality implemented in Task A\n- Tasks affect the same file(s)\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py\n```\n\n**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.\n\n### Parallel Dependencies [P]\n\n**Definition**: Tasks can execute concurrently with no conflicts\n\n**When to Use**:\n- No shared dependencies beyond a common foundation\n- Operate on different files\n- Independent feature implementations\n- Separate test suites\n\n**Marker**: Suffix task with `[P]`\n\n**Example**:\n```markdown\n### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py\n```\n\n**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.\n\n### Fan-Out Pattern\n\n**Definition**: Multiple tasks depend on single foundation task\n\n**Pattern**:\n```\nTASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\n\n**Use Case**: After creating data models, implement multiple independent services\n\n**Example**:\n```markdown\n### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts\n```\n\n### Fan-In Pattern\n\n**Definition**: Single task depends on multiple prerequisites\n\n**Pattern**:\n```\nTASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘\n```\n\n**Use Case**: Integration task requiring multiple components\n\n**Example**:\n```markdown\n### TASK-002 - Implement auth service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py\n\n### TASK-003 - Implement storage service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py\n\n### TASK-004 - Implement notification service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/notifications.py\n\n### TASK-005 - Integrate services in workflow\n**Dependencies**: TASK-002, TASK-003, TASK-004\n**Files**: src/workflow/coordinator.py\n```\n\n## File Coordination Rules\n\n### Same-File Modification\n\n**Rule**: Tasks modifying the same file must execute sequentially\n\n**Example**:\n```markdown\n### TASK-006 - Add base Task class\n**Files**: src/models/task.py\n\n### TASK-007 - Add Task validation methods\n**Dependencies**: TASK-006\n**Files**: src/models/task.py\n```\n\n**Reasoning**: Prevents merge conflicts and validates clean incremental changes.\n\n### Same-Directory Independence\n\n**Rule**: Tasks creating different files in same directory can run in parallel\n\n**Example**:\n```markdown\n### TASK-008 - Create user model [P]\n**Files**: src/models/user.py\n\n### TASK-009 - Create task model [P]\n**Files**: src/models/task.py\n```\n\n**Reasoning**: No file conflicts, different models, independent implementations.\n\n### Test-Implementation Pairing\n\n**Rule**: Implementation and its tests are typically sequential\n\n**Example**:\n```markdown\n### TASK-010 - Implement resolver logic\n**Files**: src/services/resolver.py\n\n### TASK-011 - Add resolver integration tests\n**Dependencies**: TASK-010\n**Files**: tests/integration/test_resolver.py\n```\n\n**Reasoning**: Can't test what doesn't exist yet.\n\n**Exception**: TDD approach might reverse this (write test first).\n\n## Task ID Conventions\n\n### Numbering Format\n\n**Pattern**: `TASK-NNN` where NNN is zero-padded number\n\n**Examples**:\n- `TASK-001` - First task\n- `TASK-023` - Twenty-third task\n- `TASK-100` - Hundredth task\n\n**Rules**:\n- Always zero-pad to 3 digits minimum\n- Sequential numbering across phases\n- No gaps in sequence\n- Don't reuse IDs\n\n### Ordering Strategy\n\n**By Phase First**:\n```markdown\nTASK-001 through TASK-003: Phase 0\nTASK-004 through TASK-010: Phase 1\nTASK-011 through TASK-025: Phase 2\nTASK-026 through TASK-030: Phase 3\nTASK-031 through TASK-035: Phase 4\n```\n\n**Benefit**: Clear phase boundaries, easy to identify task phase\n\n## Dependency Declaration Format\n\n### Single Dependency\n```markdown\n**Dependencies**: TASK-001\n```\n\n### Multiple Dependencies\n```markdown\n**Dependencies**: TASK-001, TASK-003, TASK-007\n```\n\n### No Dependencies\n```markdown\n**Dependencies**: None\n```\n\n## Common Dependency Patterns\n\n### Linear Chain\n```\nTASK-001 -> TASK-002 -> TASK-003 -> TASK-004\n```\nUse when each task builds directly on previous task.\n\n### Independent Parallel\n```\nTASK-001\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\nUse when multiple features share only initial setup.\n\n### Diamond Pattern\n```\n        TASK-001\n       /          \\\nTASK-002 [P]    TASK-003 [P]\n       \\          /\n        TASK-004\n```\nUse when parallel work converges for integration.\n\n### Layered Dependencies\n```\nPhase 1: TASK-001, TASK-002, TASK-003\n           ↓         ↓         ↓\nPhase 2: TASK-004 depends on all Phase 1\n```\nUse when foundation must be complete before next phase.\n\n## Validation Rules\n\n- [ ] Every task has explicit dependency field\n- [ ] No circular dependencies\n- [ ] Parallel tasks [P] have no file conflicts\n- [ ] Sequential tasks on same file are ordered\n- [ ] All referenced task IDs exist\n- [ ] Tasks reference dependencies from earlier phases\n\nFile v1.0.2:modules/phase-structure.md\n\n# Task Phase Structure\n\n## Overview\n\nTasks 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.\n\n## Phase Definitions\n\n### Phase 0: Setup\n\n**Purpose**: Establish project foundation and development environment\n\n**Typical Tasks**:\n- Project initialization (package.json, pyproject.toml, etc.)\n- Dependency installation and lock files\n- Configuration files (linting, formatting, build tools)\n- Development environment setup\n- Git repository initialization\n- CI/CD pipeline scaffolding\n\n**When to Use**:\n- Starting new projects from scratch\n- Adding new build tools or development dependencies\n- Setting up infrastructure before code implementation\n\n**Example**:\n```markdown\n### TASK-001 - Initialize Python project with uv\n**Dependencies**: None\n**Files**: pyproject.toml, uv.lock\n**Criteria**: `uv sync` runs successfully\n```\n\n### Phase 1: Foundation\n\n**Purpose**: Create core data structures and testing infrastructure\n\n**Typical Tasks**:\n- Data models and type definitions\n- Core interfaces and protocols\n- Database schemas and migrations\n- Test infrastructure and fixtures\n- Base classes and abstract components\n- Shared utilities\n\n**When to Use**:\n- Defining data contracts that other code depends on\n- Creating type systems for type-safe implementations\n- Establishing testing patterns before feature work\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py, tests/test_models.py\n**Criteria**: All model tests pass, types validate with mypy\n```\n\n### Phase 2: Core Implementation\n\n**Purpose**: Implement primary business logic and features\n\n**Typical Tasks**:\n- Service layer implementation\n- Business logic and algorithms\n- API endpoint implementations\n- Core feature functionality\n- Domain-specific operations\n- State management\n\n**When to Use**:\n- Building main application features\n- Implementing business requirements\n- Creating user-facing functionality\n\n**Example**:\n```markdown\n### TASK-007 - Implement task dependency resolver [P]\n**Dependencies**: TASK-002, TASK-003\n**Files**: src/services/resolver.py, tests/test_resolver.py\n**Criteria**: Resolves complex dependency graphs, handles cycles\n```\n\n### Phase 3: Integration\n\n**Purpose**: Connect components and integrate external systems\n\n**Typical Tasks**:\n- External API integrations\n- Middleware implementation\n- Error handling and recovery\n- Logging and monitoring\n- Database connection pooling\n- Message queue integrations\n- Authentication/authorization hooks\n\n**When to Use**:\n- Connecting to external services\n- Adding cross-cutting concerns\n- Implementing system-wide error handling\n\n**Example**:\n```markdown\n### TASK-012 - Add structured logging with context\n**Dependencies**: TASK-007, TASK-009\n**Files**: src/middleware/logging.py, src/utils/logger.py\n**Criteria**: All operations logged with correlation IDs\n```\n\n### Phase 4: Polish\n\n**Purpose**: Optimize, document, and finalize for production\n\n**Typical Tasks**:\n- Performance optimization and profiling\n- detailed documentation\n- End-to-end testing\n- Security hardening\n- Code cleanup and refactoring\n- Production readiness checks\n\n**When to Use**:\n- After core functionality is complete\n- Preparing for production deployment\n- Addressing technical debt before release\n\n**Example**:\n```markdown\n### TASK-015 - Add API documentation with examples\n**Dependencies**: TASK-007, TASK-010\n**Files**: docs/api.md, examples/quickstart.py\n**Criteria**: All endpoints documented, examples run successfully\n```\n\n## Phase Selection Guidelines\n\n### Moving Between Phases\n\n- **Complete phase foundations before advancing**: Don't jump to Phase 3 if Phase 1 models are incomplete\n- **Parallel work within phases**: Multiple Phase 2 tasks can run concurrently if dependencies allow\n- **Return to earlier phases sparingly**: Indicates incomplete planning or new requirements\n\n### Common Patterns\n\n**Small Features** (5-10 tasks):\n- Phase 0: Usually skipped (project exists)\n- Phase 1: 1-2 tasks (data models)\n- Phase 2: 3-5 tasks (core logic)\n- Phase 3: 1-2 tasks (integration)\n- Phase 4: 1-2 tasks (docs, tests)\n\n**Medium Features** (10-20 tasks):\n- Phase 0: 1-2 tasks (new dependencies)\n- Phase 1: 3-4 tasks (multiple models, test infrastructure)\n- Phase 2: 6-10 tasks (multiple services)\n- Phase 3: 2-4 tasks (several integrations)\n- Phase 4: 2-3 tasks (optimization, detailed docs)\n\n**Large Features** (20+ tasks):\n- Consider breaking into multiple features\n- Each phase may have 5+ tasks\n- Requires careful dependency management\n- May benefit from sub-phases\n\n## Anti-Patterns to Avoid\n\n- **Phase jumping**: Implementing Phase 2 features before Phase 1 models exist\n- **Phase mixing**: Putting setup tasks in Phase 2 or implementation tasks in Phase 1\n- **Skipping phases**: Every feature needs at least Phase 1 (models) and Phase 2 (logic)\n- **Over-granular phases**: Creating sub-phases or custom phase numbers\n\nFile v1.0.2:modules/tech-stack-patterns.md\n\n---\nname: tech-stack-patterns\ndescription: Technology-specific patterns for common stacks, tools, and ignore file configurations\ncategory: patterns\ntags: [patterns, tech-stack, configuration, ignore-files]\ndependencies: [task-planning]\ncomplexity: beginner\nestimated_tokens: 600\n---\n\n# Technology Stack Patterns\n\n## Overview\n\nCommon patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.\n\n## Universal Ignore Patterns\n\nPatterns that apply to all projects regardless of stack:\n\n```\n# OS artifacts\n.DS_Store\nThumbs.db\ndesktop.ini\n\n# IDE/Editor\n.vscode/\n.idea/\n*.swp\n*.swo\n*~\n.project\n.classpath\n.settings/\n\n# Logs\n*.log\nlogs/\n```\n\n## Language-Specific Patterns\n\n### Node.js / JavaScript / TypeScript\n\n```\n# Dependencies\nnode_modules/\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\n\n# Build outputs\ndist/\nbuild/\nout/\n.next/\n.nuxt/\n\n# Cache\n.npm\n.eslintcache\n.cache/\n.parcel-cache/\n\n# Environment\n.env\n.env.local\n.env.*.local\n```\n\n### Python\n\n```\n# Virtual environments\nvenv/\nenv/\n.venv/\nENV/\n.Python\n\n# Build outputs\n__pycache__/\n*.py[cod]\n*$py.class\n*.so\n.eggs/\n*.egg-info/\ndist/\nbuild/\n\n# Testing\n.pytest_cache/\n.coverage\nhtmlcov/\n.tox/\n```\n\n### Rust\n\n```\n# Build outputs\ntarget/\nCargo.lock  # (exclude for libraries, include for binaries)\n\n# Debug symbols\n*.pdb\n```\n\n### Go\n\n```\n# Build outputs\n*.exe\n*.exe~\n*.dll\n*.so\n*.dylib\n*.test\n\n# Binary\nbin/\nvendor/\n```\n\n### Java / Kotlin\n\n```\n# Build outputs\n*.class\n*.jar\n*.war\n*.ear\ntarget/\nbuild/\nout/\n\n# IDE\n.gradle/\n.mvn/\n```\n\n### C# / .NET\n\n```\n# Build outputs\nbin/\nobj/\n*.dll\n*.exe\n*.pdb\n\n# User-specific\n*.user\n*.suo\n*.userprefs\n```\n\n## Common Tool Configurations\n\n### Docker\n\n```\n# Docker\n.dockerignore\ndocker-compose.override.yml\n```\n\n### Git\n\n```\n# Git\n.git/\n.gitattributes\n```\n\n### Terraform\n\n```\n# Terraform\n*.tfstate\n*.tfstate.*\n.terraform/\n.terraform.lock.hcl\n```\n\n### Linting & Formatting\n\n```\n# ESLint\n.eslintcache\n\n# Prettier\n.prettierignore\n\n# Ruff (Python)\n.ruff_cache/\n```\n\n## Cloud Provider Artifacts\n\n```\n# AWS\n.aws/\n*.pem\n\n# GCP\n.gcloud/\n*-key.json\n\n# Azure\n.azure/\n```\n\n## Usage in Spec-Kit\n\nWhen generating .gitignore recommendations in planning phase:\n1. Start with universal patterns\n2. Add language-specific patterns based on tech stack\n3. Include tool-specific patterns from implementation plan\n4. Add cloud provider patterns if applicable\n\nFile v1.0.2:skill-card.md\n\n## Description: <br>\nGenerate phased, dependency-ordered tasks from specifications with parallelization opportunities and tech-stack patterns. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineers use this skill to turn specifications and implementation plans into phased task lists with dependencies, file coordination, completion criteria, and safe parallelization markers. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generated plans may contain incorrect dependencies, file conflicts, or unsafe parallelization markers. <br>\nMitigation: Review task dependencies, shared file paths, and [P] markers before using the plan to coordinate implementation. <br>\nRisk: The linked Claude Code/Night Market plugin was not part of the scanned markdown-only artifact. <br>\nMitigation: Review and scan that plugin independently before installing or relying on its agents, hooks, or commands. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-spec-kit-task-planning) <br>\n- [Claude Night Market spec-kit plugin](https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit) <br>\n- [Task phase structure](artifact/modules/phase-structure.md) <br>\n- [Task dependency patterns](artifact/modules/dependency-patterns.md) <br>\n- [Technology stack patterns](artifact/modules/tech-stack-patterns.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Markdown, Guidance, Configuration] <br>\n**Output Format:** [Markdown task lists with dependency metadata and optional code or configuration snippets] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces phased tasks with IDs, dependencies, file paths, completion criteria, and [P] parallel markers.] <br>\n\n## Skill Version(s): <br>\n1.0.2 (source: server release metadata; artifact frontmatter reports 1.9.5) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.1: 5 files, 7879 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), SKILL.md (3881b), _meta.json (144b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: task-planning\ndescription: |\n  Generate phased, dependency-ordered tasks from specifications with parallelization opportunities and tech-stack patterns\nversion: 1.9.4\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in st\n\nArchive v1.0.0: 5 files, 7878 bytes\n\nFiles: modules/dependency-patterns.md (6127b), modules/phase-structure.md (5038b), modules/tech-stack-patterns.md (2392b), SKILL.md (3881b), _meta.json (144b)","readmeExcerpt":"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:","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"## Phase 2: Core Implementation\n\n### TASK-007 - Implement user authentication service [P]\n**Dependencies**: TASK-003, TASK-004\n**Files**: src/services/auth.ts, src/types/user.ts\n**Criteria**: All auth tests pass, tokens are valid JWT"},{"language":"markdown","snippet":"### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py"},{"language":"markdown","snippet":"### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py"},{"language":"text","snippet":"TASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]"},{"language":"markdown","snippet":"### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts"},{"language":"text","snippet":"TASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: task-planning\ndescription: |\n  Generates phased, dependency-ordered implementation tasks from specifications. Use after spec is complete and before starting implementation\nversion: 1.9.8\ntriggers:\n  - speckit\n  - tasks\n  - planning\n  - implementation\n  - dependencies\nmetadata: {\"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\"]}}}\nsource: claude-night-market\nsource_plugin: spec-kit\n---\n\n> **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.\n\n\n# Task Planning\n\n## Overview\n\nTransforms specifications and implementation plans into actionable, dependency-ordered tasks. Creates phased breakdowns that guide systematic implementation.\n\n## When To Use\n\n- Converting specifications to implementation tasks\n- Planning feature implementation order\n- Identifying parallel execution opportunities\n- Breaking down complex features into phases\n\n## When NOT To Use\n\n- Writing specifications - use spec-writing\n\n## Task Phases\n\nTasks follow a 5-phase structure from setup through polish:\n\n- **Phase 0: Setup** - Project initialization, dependencies, configuration\n- **Phase 1: Foundation** - Data models, interfaces, test infrastructure\n- **Phase 2: Core Implementation** - Business logic, APIs, services\n- **Phase 3: Integration** - External services, middleware, logging\n- **Phase 4: Polish** - Optimization, documentation, final testing\n\nFor detailed phase definitions, selection guidelines, and anti-patterns, see `modules/phase-structure.md`.\n\n## Task Format\n\nEach task includes:\n- **ID**: Unique identifier (TASK-001)\n- **Description**: Clear action statement\n- **Phase**: Which phase it belongs to\n- **Dependencies**: Tasks that must complete first\n- **Parallel Marker**: [P] if can run concurrently\n- **Files**: Affected file paths\n- **Criteria**: How to verify completion\n\n## Dependency Rules\n\nDependencies define execution order and identify parallelization opportunities:\n\n- **Sequential Tasks**: Execute in strict order when dependencies exist\n- **Parallel Tasks [P]**: Can run concurrently when ALL nonconflicting conditions are met\n- **File Coordination**: Tasks affecting same files MUST run sequentially\n\n**Nonconflicting Criteria for Parallel Execution**:\n- ✅ Files: No file overlap between tasks\n- ✅ State: No shared configuration or global state\n- ✅ Dependencies: All prerequisites satisfied\n- ✅ Code paths: No merge conflicts possible\n- ✅ Outputs: Tasks don't need each other's results\n\n**Mark tasks with [P] ONLY if they pass ALL criteria above.**\n\nFor fan-out/fan-in patterns, task ID conventions, and validation rules, see `modules/dependency-patterns.md`.\n\n## Example Task Entry\n\n```markdown\n## Phase 2: Cor"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-spec-kit-task-planning\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787750602185\n}"},{"path":"modules/dependency-patterns.md","content":"# Task Dependency Patterns\n\n## Overview\n\nDependencies define task execution order and identify parallelization opportunities. Proper dependency modeling prevents race conditions and validates components exist before they're used.\n\n## Dependency Types\n\n### Sequential Dependencies\n\n**Definition**: Task B cannot start until Task A completes\n\n**When to Use**:\n- Task B modifies output from Task A\n- Task B requires interfaces/types defined in Task A\n- Task B tests functionality implemented in Task A\n- Tasks affect the same file(s)\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py\n\n### TASK-003 - Implement task validation\n**Dependencies**: TASK-002\n**Files**: src/models/task.py, src/validators/task.py\n```\n\n**Reasoning**: Task validation requires the Task model to exist first. Both affect task.py, requiring sequential execution.\n\n### Parallel Dependencies [P]\n\n**Definition**: Tasks can execute concurrently with no conflicts\n\n**When to Use**:\n- No shared dependencies beyond a common foundation\n- Operate on different files\n- Independent feature implementations\n- Separate test suites\n\n**Marker**: Suffix task with `[P]`\n\n**Example**:\n```markdown\n### TASK-004 - Implement user authentication [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py, tests/test_auth.py\n\n### TASK-005 - Implement task storage [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py, tests/test_storage.py\n```\n\n**Reasoning**: Both depend on TASK-001 setup but operate on different files and can run concurrently.\n\n### Fan-Out Pattern\n\n**Definition**: Multiple tasks depend on single foundation task\n\n**Pattern**:\n```\nTASK-001 (Foundation)\n    ├─> TASK-002 [P]\n    ├─> TASK-003 [P]\n    └─> TASK-004 [P]\n```\n\n**Use Case**: After creating data models, implement multiple independent services\n\n**Example**:\n```markdown\n### TASK-001 - Define API schemas\n**Dependencies**: None\n**Files**: src/types/api.ts\n\n### TASK-002 - Implement user endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/users.ts\n\n### TASK-003 - Implement task endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/tasks.ts\n\n### TASK-004 - Implement project endpoints [P]\n**Dependencies**: TASK-001\n**Files**: src/routes/projects.ts\n```\n\n### Fan-In Pattern\n\n**Definition**: Single task depends on multiple prerequisites\n\n**Pattern**:\n```\nTASK-002 [P] ─┐\nTASK-003 [P] ─┼─> TASK-005\nTASK-004 [P] ─┘\n```\n\n**Use Case**: Integration task requiring multiple components\n\n**Example**:\n```markdown\n### TASK-002 - Implement auth service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/auth.py\n\n### TASK-003 - Implement storage service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/storage.py\n\n### TASK-004 - Implement notification service [P]\n**Dependencies**: TASK-001\n**Files**: src/services/notifications.py\n\n### TASK-005 - Integrate services in workflow\n**Dependencies**: TASK-002, TASK-003, TASK-004\n**Files**: src/workflow/coordinato"},{"path":"modules/phase-structure.md","content":"# Task Phase Structure\n\n## Overview\n\nTasks 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.\n\n## Phase Definitions\n\n### Phase 0: Setup\n\n**Purpose**: Establish project foundation and development environment\n\n**Typical Tasks**:\n- Project initialization (package.json, pyproject.toml, etc.)\n- Dependency installation and lock files\n- Configuration files (linting, formatting, build tools)\n- Development environment setup\n- Git repository initialization\n- CI/CD pipeline scaffolding\n\n**When to Use**:\n- Starting new projects from scratch\n- Adding new build tools or development dependencies\n- Setting up infrastructure before code implementation\n\n**Example**:\n```markdown\n### TASK-001 - Initialize Python project with uv\n**Dependencies**: None\n**Files**: pyproject.toml, uv.lock\n**Criteria**: `uv sync` runs successfully\n```\n\n### Phase 1: Foundation\n\n**Purpose**: Create core data structures and testing infrastructure\n\n**Typical Tasks**:\n- Data models and type definitions\n- Core interfaces and protocols\n- Database schemas and migrations\n- Test infrastructure and fixtures\n- Base classes and abstract components\n- Shared utilities\n\n**When to Use**:\n- Defining data contracts that other code depends on\n- Creating type systems for type-safe implementations\n- Establishing testing patterns before feature work\n\n**Example**:\n```markdown\n### TASK-002 - Define Task data model\n**Dependencies**: TASK-001\n**Files**: src/models/task.py, tests/test_models.py\n**Criteria**: All model tests pass, types validate with mypy\n```\n\n### Phase 2: Core Implementation\n\n**Purpose**: Implement primary business logic and features\n\n**Typical Tasks**:\n- Service layer implementation\n- Business logic and algorithms\n- API endpoint implementations\n- Core feature functionality\n- Domain-specific operations\n- State management\n\n**When to Use**:\n- Building main application features\n- Implementing business requirements\n- Creating user-facing functionality\n\n**Example**:\n```markdown\n### TASK-007 - Implement task dependency resolver [P]\n**Dependencies**: TASK-002, TASK-003\n**Files**: src/services/resolver.py, tests/test_resolver.py\n**Criteria**: Resolves complex dependency graphs, handles cycles\n```\n\n### Phase 3: Integration\n\n**Purpose**: Connect components and integrate external systems\n\n**Typical Tasks**:\n- External API integrations\n- Middleware implementation\n- Error handling and recovery\n- Logging and monitoring\n- Database connection pooling\n- Message queue integrations\n- Authentication/authorization hooks\n\n**When to Use**:\n- Connecting to external services\n- Adding cross-cutting concerns\n- Implementing system-wide error handling\n\n**Example**:\n```markdown\n### TASK-012 - Add structured logging with context\n**Dependencies**: TASK-007, TASK-009\n**Files**: src/middleware/logging.py, src/utils/logger.py\n**Criteria**: All operations logged with correlation IDs\n```\n\n###"},{"path":"modules/tech-stack-patterns.md","content":"---\nname: tech-stack-patterns\ndescription: Technology-specific patterns for common stacks, tools, and ignore file configurations\ncategory: patterns\ntags: [patterns, tech-stack, configuration, ignore-files]\ndependencies: [task-planning]\ncomplexity: beginner\nestimated_tokens: 600\n---\n\n# Technology Stack Patterns\n\n## Overview\n\nCommon patterns for ignore files, tool configurations, and technology-specific artifacts across different development stacks.\n\n## Universal Ignore Patterns\n\nPatterns that apply to all projects regardless of stack:\n\n```\n# OS artifacts\n.DS_Store\nThumbs.db\ndesktop.ini\n\n# IDE/Editor\n.vscode/\n.idea/\n*.swp\n*.swo\n*~\n.project\n.classpath\n.settings/\n\n# Logs\n*.log\nlogs/\n```\n\n## Language-Specific Patterns\n\n### Node.js / JavaScript / TypeScript\n\n```\n# Dependencies\nnode_modules/\nnpm-debug.log*\nyarn-debug.log*\nyarn-error.log*\npnpm-debug.log*\n\n# Build outputs\ndist/\nbuild/\nout/\n.next/\n.nuxt/\n\n# Cache\n.npm\n.eslintcache\n.cache/\n.parcel-cache/\n\n# Environment\n.env\n.env.local\n.env.*.local\n```\n\n### Python\n\n```\n# Virtual environments\nvenv/\nenv/\n.venv/\nENV/\n.Python\n\n# Build outputs\n__pycache__/\n*.py[cod]\n*$py.class\n*.so\n.eggs/\n*.egg-info/\ndist/\nbuild/\n\n# Testing\n.pytest_cache/\n.coverage\nhtmlcov/\n.tox/\n```\n\n### Rust\n\n```\n# Build outputs\ntarget/\nCargo.lock  # (exclude for libraries, include for binaries)\n\n# Debug symbols\n*.pdb\n```\n\n### Go\n\n```\n# Build outputs\n*.exe\n*.exe~\n*.dll\n*.so\n*.dylib\n*.test\n\n# Binary\nbin/\nvendor/\n```\n\n### Java / Kotlin\n\n```\n# Build outputs\n*.class\n*.jar\n*.war\n*.ear\ntarget/\nbuild/\nout/\n\n# IDE\n.gradle/\n.mvn/\n```\n\n### C# / .NET\n\n```\n# Build outputs\nbin/\nobj/\n*.dll\n*.exe\n*.pdb\n\n# User-specific\n*.user\n*.suo\n*.userprefs\n```\n\n## Common Tool Configurations\n\n### Docker\n\n```\n# Docker\n.dockerignore\ndocker-compose.override.yml\n```\n\n### Git\n\n```\n# Git\n.git/\n.gitattributes\n```\n\n### Terraform\n\n```\n# Terraform\n*.tfstate\n*.tfstate.*\n.terraform/\n.terraform.lock.hcl\n```\n\n### Linting & Formatting\n\n```\n# ESLint\n.eslintcache\n\n# Prettier\n.prettierignore\n\n# Ruff (Python)\n.ruff_cache/\n```\n\n## Cloud Provider Artifacts\n\n```\n# AWS\n.aws/\n*.pem\n\n# GCP\n.gcloud/\n*-key.json\n\n# Azure\n.azure/\n```\n\n## Usage in Spec-Kit\n\nWhen generating .gitignore recommendations in planning phase:\n1. Start with universal patterns\n2. Add language-specific patterns based on tech stack\n3. Include tool-specific patterns from implementation plan\n4. Add cloud provider patterns if applicable"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"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:","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1335,"uniquenessScore":47,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T05:25:04.852Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T05:25:04.852Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T10:44:39.942Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"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!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"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","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}