Menu
Create or update the task list artifact from gathered requirements
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Generates a feature spec for an existing codebase via an interview workflow. Use when the user wants to write, draft, or scope a feature spec — phrases like "write a feature spec", "spec out this feature", "draft a spec for X", "I want to add X to this codebase", "let's plan a new feature", or "scope out this feature". Do NOT use for bug fixes, pure refactors with no behavior change, or greenfield projects with no existing code.
Produces a long-form essay draft grounded in a user-supplied directory of research documents via an interview workflow. Use whenever the user wants to "draft an essay from my research", "write an essay from these notes", "turn this research directory into an essay", "I've been collecting notes on X, help me draft an essay", or "draft a long-form piece using these sources". Do NOT use for: one-shot summarization of a single document, short notes or tweets under ~600 words, pure research-findings synthesis with no drafting, or essay drafting when there is no research corpus to ground in.
Creates a new Claude Code skill that follows the Anchored Interview pattern — ground in a CORPUS, run an interview anchored by that grounding, then produce a single ARTIFACT. Use whenever the user wants to scaffold, generate, or design an interview-style skill — phrases like "make me an anchored interview skill", "create a skill that interviews me about X and produces Y", "scaffold a skill that reads my <corpus> and writes a <artifact>", "I want a skill for spec/draft/plan/findings creation via interview", or any request to build a skill that has the ground-then-ask-then-act shape. Do NOT use for: running an anchored interview on a specific task (this skill *creates* such skills, it doesn't perform them — for that, use or create the appropriate task-specific skill); editing an existing SKILL.md; one-shot transformations with no judgment calls; or skills where there is no corpus to ground in.
Parse PDF files to markdown using GLM-OCR via Ollama locally. Converts each page to an image, runs OCR, and outputs clean markdown. Use when the user wants to extract text from a PDF.
Use the Obsidian CLI to manage knowledge in an Obsidian vault — daily notes, search, tasks, tags, link graph analysis, properties, templates, and file operations. This skill should be used when the user asks to interact with their Obsidian vault, manage daily notes, search notes, manage tasks, explore tags or backlinks, set properties, use templates, or perform vault maintenance.
Generate QR codes from URLs, text, or other data and save them as SVG, PNG, EPS, or PDF files. This skill should be used when the user asks to create, generate, or make a QR code for any content such as website URLs, text strings, WiFi credentials, contact info, or other data. Triggers include mentions of 'QR code', 'QR', 'barcode for a link', or requests to make a scannable code. Supports customization of colors, size, error correction level, and output format.
| name | task-list-creator |
| description | Create or update the task list artifact from gathered requirements |
You are creating the Task List artifact (todo.md) for an artifact-driven development workflow.
You have access to the interrogation context from the conversation—requirements, scope, constraints, and success criteria gathered from the user.
Create .artifacts/bld-<project-slug>/todo.md (create the directory if it doesn't exist).
Organize tasks into three phases with hierarchical nesting:
Research, design decisions, and technical approach tasks that happen before coding.
The actual build work. Group related tasks under parent items with subtasks:
Testing, validation, and documentation tasks.
Phase-first thinking — What research/design must happen before building? What verification happens after?
Hierarchical grouping — Group related implementation work under parent tasks. Subtasks should be completable independently but contribute to the parent goal.
Atomic subtasks — Each subtask is a single, verifiable unit. Parent tasks complete when all subtasks complete.
Include the unsexy work — Error handling, edge cases, fallbacks deserve explicit tasks.
Verification is a phase — Not an afterthought. Testing, edge case validation, and documentation are first-class tasks.
If working within an existing codebase:
---
status: in-progress
created: <timestamp> (ex: 2025-12-09 08:47:19 -0800)
updated: <timestamp> (ex: 2025-12-09 08:49:30 -0800)
project: <project-slug>
description: "<one-line summary>"
---
# <Project Name>
## Planning Phase
- [x] Research X and their capabilities
- [x] Design system architecture and data flow
- [ ] Create implementation plan document
- [ ] Get user approval on technical approach
## Implementation Phase
- [ ] Set up project structure and dependencies
- [ ] Implement backend service
- [ ] Subtask one
- [ ] Subtask two
- [ ] Subtask three
- [ ] Build frontend interface
- [ ] Subtask one
- [ ] Subtask two
- [ ] Add error handling and fallbacks
## Verification Phase
- [ ] Test with multiple scenarios
- [ ] Verify core functionality
- [ ] Test edge cases and error scenarios
- [ ] Create walkthrough documentation
As work progresses, update checkboxes:
- [ ] → pending- [~] → in-progress (optional, for visibility)- [x] → completeIMPORTANT: Every time you modify todo.md, update the updated: field in the frontmatter with the current timestamp.
Present the artifact to the user for review before proceeding.
When presenting, always:
📄 .artifacts/bld-<project-slug>/todo.md[x] Completed task
[ ] Pending task
[ ] Nested subtask
[x] Completed subtask
This format makes progress immediately visible to the user.