implementation-plan-creator
Create the implementation plan artifact from an approved task list
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Create the implementation plan artifact from an approved task list
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 | implementation-plan-creator |
| description | Create the implementation plan artifact from an approved task list |
You are creating the Implementation Plan artifact (implementation-plan.md) for an artifact-driven development workflow.
.artifacts/bld-<project-slug>/todo.md for the approved task listCreate .artifacts/bld-<project-slug>/implementation-plan.md.
One paragraph describing what's being built and its core purpose.
Surface decisions requiring user input prominently at the top. Use blockquote callouts:
IMPORTANT Technology Stack: The plan uses X with Y. If you prefer Z, please let me know.
IMPORTANT [Decision Topic]: The proposed approach uses [approach]. Alternative approaches include:
- Alternative 1
- Alternative 2
- Alternative 3
Please confirm the preferred approach.
This section ensures approval gates are visible, not buried.
Organize by logical layer or area (Backend Service Layer, Frontend Components, Configuration, etc.).
For each file:
[NEW] path/to/file.ext
Brief description of this file's purpose:
[MODIFY] path/to/existing.ext
Changes to make:
How the implementation will be verified. Keep it practical—what tests or checks prove it works.
---
status: pending
created: <timestamp>
updated: <timestamp>
---
# <Project Name>
<One paragraph project summary>
## User Review Required
> **IMPORTANT**
> **[Decision 1]**: ...
> **IMPORTANT**
> **[Decision 2]**: ...
## Proposed Changes
### <Layer/Area Name>
**[NEW]** `filename.ext`
Description:
- Point one
- Point two
**[MODIFY]** `filename.ext`
Changes:
- Change one
- Change two
### Testing Strategy
...
Present the artifact to the user. This is an approval gate.
When presenting, always:
📄 .artifacts/bld-<project-slug>/implementation-plan.mdThe "User Review Required" section makes explicit what needs confirmation. Do not proceed until:
Once approved, update status: in-progress.
IMPORTANT: Every time you modify implementation-plan.md, update the updated: field in the frontmatter with the current timestamp.