From avila-tek-skill-pack
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
npx claudepluginhub avila-tek/avila-tek-skill-packThis skill uses the workspace's default tool permissions.
Identify the active stack from the session-start hook output. State it explicitly: "Active stack: {name}".
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Identify the active stack from the session-start hook output. State it explicitly: "Active stack: {name}". If not injected, use the detection signals in CLAUDE.md → Stack System. Apply this stack's STACK.md Key Patterns and Verification Checklist before completing any output.
When breaking work into tasks, name the stack-specific artifacts each task must produce (e.g., repository, service, migration for NestJS; query hook, widget, infrastructure adapter for Next.js). This makes each task verifiable against the stack's Verification Checklist.
Decompose work into small, verifiable tasks with explicit acceptance criteria. Good task breakdown is the difference between an agent that completes work reliably and one that produces a tangled mess. Every task should be small enough to implement, test, and verify in a single focused session.
When NOT to use: Single-file changes with obvious scope, or when the spec already contains well-defined tasks.
Before writing any code, operate in read-only mode:
Do NOT write code during planning. The output is a plan document, not implementation.
Map what depends on what:
Database schema
│
├── API models/types
│ │
│ ├── API endpoints
│ │ │
│ │ └── Frontend API client
│ │ │
│ │ └── UI components
│ │
│ └── Validation logic
│
└── Seed data / migrations
Implementation order follows the dependency graph bottom-up: build foundations first.
Instead of building all the database, then all the API, then all the UI — build one complete feature path at a time:
Bad (horizontal slicing):
Task 1: Build entire database schema
Task 2: Build all API endpoints
Task 3: Build all UI components
Task 4: Connect everything
Good (vertical slicing):
Task 1: User can create an account (schema + API + UI for registration)
Task 2: User can log in (auth schema + API + UI for login)
Task 3: User can create a task (task schema + API + UI for creation)
Task 4: User can view task list (query + API + UI for list view)
Each vertical slice delivers working, testable functionality.
Each task follows this structure:
## Task [N]: [Short descriptive title]
**Description:** One paragraph explaining what this task accomplishes.
**Acceptance criteria:**
- [ ] [Specific, testable condition]
- [ ] [Specific, testable condition]
**Verification:**
- [ ] Tests pass: `npm test -- --grep "feature-name"`
- [ ] Build succeeds: `npm run build`
- [ ] Manual check: [description of what to verify]
**Dependencies:** [Task numbers this depends on, or "None"]
**Files likely touched:**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`
**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]
Arrange tasks so that:
Add explicit checkpoints:
## Checkpoint: After Tasks 1-3
- [ ] All tests pass
- [ ] Application builds without errors
- [ ] Core user flow works end-to-end
- [ ] Review with human before proceeding
| Size | Files | Scope | Example |
|---|---|---|---|
| XS | 1 | Single function or config change | Add a validation rule |
| S | 1-2 | One component or endpoint | Add a new API endpoint |
| M | 3-5 | One feature slice | User registration flow |
| L | 5-8 | Multi-component feature | Search with filtering and pagination |
| XL | 8+ | Too large — break it down further | — |
If a task is L or larger, it should be broken into smaller tasks. An agent performs best on S and M tasks.
When to break a task down further:
# Implementation Plan: [Feature/Project Name]
## Overview
[One paragraph summary of what we're building]
## Architecture Decisions
- [Key decision 1 and rationale]
- [Key decision 2 and rationale]
## Task List
### Phase 1: Foundation
- [ ] Task 1: ...
- [ ] Task 2: ...
### Checkpoint: Foundation
- [ ] Tests pass, builds clean
### Phase 2: Core Features
- [ ] Task 3: ...
- [ ] Task 4: ...
### Checkpoint: Core Features
- [ ] End-to-end flow works
### Phase 3: Polish
- [ ] Task 5: ...
- [ ] Task 6: ...
### Checkpoint: Complete
- [ ] All acceptance criteria met
- [ ] Ready for review
## Risks and Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [High/Med/Low] | [Strategy] |
## Open Questions
- [Question needing human input]
When multiple agents or sessions are available:
Before starting implementation, confirm:
When working on an Avila Tek story, write plan artifacts to the story's own folder:
docs/epics/E-XXX_slug/stories/E-XXX_S-YYY_slug/
├── E-XXX_S-YYY_slug.md ← story file (created by planning-5-story-generator)
├── spec.md ← written by /spec (Story-Driven Mode)
├── plan.md ← written here (this skill)
└── todo.md ← task checklist written here (this skill)
plan.md — full implementation plan using the template abovetodo.md — flat task checklist for daily tracking, derived from plan.mdWhen this skill completes, suggest to the user:
"Plan ready. When you're ready, run
/buildto start implementing (dev-incremental-implementation)."
Do not invoke /build automatically.