Show the current state of the project's tasks, hiding archived ones, by writing a project-local status script for however the project stores its tasks. Use when the user asks which tasks are open or in progress, or how far the work has got.
68
85%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Every project keeps its tasks somewhere, and the storage differs from project
to project: one Markdown file per task with a status key in the frontmatter,
headings in a single roadmap file, a YAML or JSON list, an issue tracker
reached through its CLI. flowai proposes one layout (the tasks role from
AGENTS.md, by default a date-nested <tasks dir>/<YYYY>/<MM>/<slug>.md tree
with status: to do | in progress | done | superseded) and many projects use
their own. Reading every task by hand on every request is slow and
inconsistent, so this skill writes a script for the project's storage once,
keeps that script in the project, and runs it from then on.
This skill ships no script. The storage is known only inside the project, so the script is written there, for that storage, against the output contract below. The contract keeps the report the same in every project; the completeness check replaces the tests a shared template would have had.
The project script is scripts/tasks-overview.py. It MUST:
subprocess is allowed
when the tasks live in a tracker reachable through a CLI);in progress first, to do
second, then the remaining statuses in alphabetical order, each group under
a <status>: header line, using the project's own status names (map the
project's equivalents of "in progress" and "to do" to the first two places);file#heading, issue
number), the progress [done/total] when the task has checklist steps, the
title, and the date when the storage has one;N open, M archived (hidden; use --all);--all, and then drop the
(hidden; use --all) part of the footer;no tasks under <location> and exit 0 when there are none;<step_by_step>
Reuse gate. Check for scripts/tasks-overview.py in the project root.
--all.Derive the storage from AGENTS.md. Read AGENTS.md (or CLAUDE.md
when that is the file the project has). Find the rules about tasks: the
tasks role in the documentation hierarchy, a "Tasks" section, or any
sentence naming where tasks live. Apply Rule 2. Establish:
done, superseded, closed, archived, dropped, …);- [ ] / - [x] items under a
given heading, sub-tasks), or none;tasks role names, every *.md under it, frontmatter status, archived done and
superseded, steps under ## Definition of Done, title from the first
# heading, frontmatter date) — but only after confirming that
directory exists. If the location cannot be established, apply Rule 6.
Look at one or two real tasks to confirm the shape before writing code.Show the derivation and write the script. Show one line per answer from
step 2 with its quoted source (Rule 5), for example:
status — the enclosing "## " section: "A task's status is the ## section it sits under".
Then write scripts/tasks-overview.py (create scripts/ if needed) to the
Output Contract (Rule 4).
Run it.
python3 scripts/tasks-overview.pyAdd --all when the user wants archived tasks too. Exit 2 → apply Rule 8.
Completeness check (new script only). Count the tasks without the
script — find <dir> -name '*.md' | wc -l minus the ignored files, grep -c
over the task headings, the tracker CLI's own count — and compare that
number with the script's total (open plus archived from the footer). Say in
chat what you counted, how, and whether the numbers agree.
Report. Paste the script's output VERBATIM in a fenced code block in
your reply — the user sees your message, not the tool result, and a
retelling of the list is not the list. Comments or a short reading of it may
follow the block, never replace it. When the script was just created, add
one sentence saying that scripts/tasks-overview.py now lives in their
project and is theirs to edit — the next request will run it directly.
</step_by_step>
korchasa/flowai-plugins
240d92b
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.