feat: add some useful skills
This commit is contained in:
13
skills/planka-project/README.md
Normal file
13
skills/planka-project/README.md
Normal file
@@ -0,0 +1,13 @@
|
||||
Project planning and management using Planka
|
||||
|
||||
Requires your agent to have access to Planka, either using a CLI, MCP server, or you can probably just tell it what the URL and API key is and let it explore the Swagger docs itself. They are referenced in the skill.
|
||||
|
||||
- [Swagger Docs](https://plankanban.github.io/planka/swagger-ui/)
|
||||
|
||||
It gives the agent an understanding of what Planka is, how it works, and it's expected to use it to plan and manage a project.
|
||||
|
||||
This skill is a mash up of the following other skills found on https://skillsmp.com:
|
||||
|
||||
- [Shubhamsaboo project-planner](https://github.com/Shubhamsaboo/awesome-llm-apps/tree/main/awesome_agent_skills/project-planner)
|
||||
- [ssube planka](https://github.com/ssube/conclave/tree/main/pi/skills/planka)
|
||||
|
||||
107
skills/planka-project/SKILL.md
Normal file
107
skills/planka-project/SKILL.md
Normal file
@@ -0,0 +1,107 @@
|
||||
---
|
||||
name: planka-project
|
||||
description: |
|
||||
Breaks down complex projects into actionable tasks, dependencies, and milestones.
|
||||
Use when: planning projects, creating task breakdowns, defining milestones, estimating timelines, managing dependencies, or when user mentions project planning, roadmap, work breakdown, or task estimation.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: awesome-llm-apps
|
||||
version: "1.0.0"
|
||||
---
|
||||
|
||||
# Project Planner
|
||||
|
||||
You are an expert project planner who breaks down complex projects into achievable, well-structured tasks.
|
||||
|
||||
## When to Apply
|
||||
|
||||
Use this skill when:
|
||||
- Defining project scope and deliverables
|
||||
- Creating work breakdown structures (WBS)
|
||||
- Identifying task dependencies
|
||||
- Estimating effort
|
||||
- Planning milestones and phases
|
||||
- Allocating resources
|
||||
- Risk assessment and mitigation
|
||||
|
||||
## Planning Process
|
||||
|
||||
### 1. **Define Success**
|
||||
- What is the end goal?
|
||||
- What are the success criteria?
|
||||
- What defines "done"?
|
||||
- What are the constraints (time, budget, resources)?
|
||||
|
||||
### 2. **Identify Deliverables**
|
||||
- What are the major outputs?
|
||||
- What milestones mark progress?
|
||||
- What dependencies exist?
|
||||
- What can be parallelized?
|
||||
|
||||
### 3. **Break Down Tasks**
|
||||
- Each task: 2-8 hours of work
|
||||
- Clear "done" criteria
|
||||
- Assignable to single owner
|
||||
- Testable/verifiable completion
|
||||
|
||||
### 4. **Map Dependencies**
|
||||
- What must be done first?
|
||||
- What can happen in parallel?
|
||||
- What are the critical path items?
|
||||
- Where are the bottlenecks?
|
||||
|
||||
### 6. **Assign and Track**
|
||||
- Who owns each task?
|
||||
- What skills are required?
|
||||
- How will progress be tracked?
|
||||
- When are check-ins scheduled?
|
||||
|
||||
## Task Sizing Guidelines
|
||||
|
||||
**Too Large** (>2 days):
|
||||
- Break into subtasks
|
||||
- Hard to estimate accurately
|
||||
- Difficult to track progress
|
||||
- Blocks other work too long
|
||||
|
||||
**Well-Sized** (2-8 hours):
|
||||
- Clear deliverable
|
||||
- One person can complete
|
||||
- Progress visible daily
|
||||
- Easy to estimate
|
||||
|
||||
**Too Small** (<1 hour):
|
||||
- May be over-planning
|
||||
- Too much overhead
|
||||
- Combine related micro-tasks
|
||||
|
||||
## Output Format
|
||||
|
||||
Output will be a list Manage tasks and projects using the **Planka** kanban board. The output is a set of **Planka cards** on a board.
|
||||
|
||||
**Planka** is a modern Kanban project management tool for teams who like to visualize and successfully organize their tasks. It can be interacted with using an API and a web interface, so it works well for humans and agents alike. Content is organized as a heiarchy or **Projects**, which contain multiple **Boards**. Each **Board** represents a milestone and contains a number of **Lists** that are used to track the lifecycle of the milestone. **Lists** contain **Cards** which are tasks to be completed.
|
||||
|
||||
You likely already have a tool or a skill that describes how to interact with Planka, but you can consult the Swagger docs here if needed: https://plankanban.github.io/planka/swagger-ui/swagger.json
|
||||
|
||||
### Planka Resources
|
||||
|
||||
Start by asking which **Project** you should be working on, and whether or not you need to create it. Projects can contain a description, use that as a product requirements document (PRD). Include core features, target audience, and business logic. If applicable, also record the tech stack, folder structure, and data flow details.
|
||||
|
||||
Once the project is set up, create a **Board** for each milestone, with 1-3 word description.
|
||||
|
||||
### Typical Board Lists
|
||||
|
||||
1. `Backlog` — Future tasks
|
||||
2. `Next Up` — Ready to work on
|
||||
3. `In Progress` — Currently being worked on
|
||||
4. `Blocked` — Waiting on external dependency
|
||||
5. `Done` — Completed
|
||||
|
||||
### Planka Cards
|
||||
|
||||
When creating cards, use the template in {baseDir}/references/card-template.md to structure the card description. Fill in each section (Goal, Context, Requirements, Considerations, Acceptance Criteria) based on the task at hand.
|
||||
|
||||
Add the human label for tasks created by or intended for a *human*, and the agent label for tasks the *agent* should work on autonomously.
|
||||
|
||||
As work progresses, progress will be tracked by updating the description. Discoveries related to the task will be added as comments. Progress of the cards will be tracked by moving them to another list, progressing towards **Done**.
|
||||
|
||||
32
skills/planka-project/references/card-template.md
Normal file
32
skills/planka-project/references/card-template.md
Normal file
@@ -0,0 +1,32 @@
|
||||
## Goal
|
||||
|
||||
[One-sentence description of what this work enables or unblocks.]
|
||||
|
||||
## Context
|
||||
|
||||
[Brief explanation of the current state: what exists, what's missing, and why this work is needed. Include links to relevant repos, services, or docs.]
|
||||
|
||||
## Requirements
|
||||
|
||||
1. **[Requirement area]**: [Description of what must happen]
|
||||
2. **Approach options**:
|
||||
- [Option A]: [Brief description, tradeoffs]
|
||||
- [Option B]: [Brief description, tradeoffs]
|
||||
- [Option C]: [Brief description, tradeoffs]
|
||||
3. **Scope**: [What to target first, and what to extend to later]
|
||||
4. **Safety**: [Guardrails, constraints, or deployment protections]
|
||||
|
||||
## Considerations
|
||||
|
||||
- [Infrastructure or permissions prerequisites]
|
||||
- [Long-term vs short-term tradeoff notes]
|
||||
- [Simplest starting point]
|
||||
- [Generalizability / reusability concerns]
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] [Primary end-to-end workflow works]
|
||||
- [ ] [Secondary/manual trigger path works]
|
||||
- [ ] [Failure recovery mechanism exists]
|
||||
- [ ] [Pattern is documented and reusable]
|
||||
|
||||
Reference in New Issue
Block a user