feature-marker
Use this skill when the user asks to implement, plan, test, or hand off a
feature with Feature Marker.
The normal invocation is a plain LLM prompt:
Use feature-marker to implement <feature-slug>.
Run through the feature by default. Do not use an interactive menu, old CLI
workflow commands, checkpoint JSON, or a JavaScript workflow engine. The package
installer only installs this skill.
Run-Through Procedure
- Identify the feature slug from the prompt. If the slug is missing, derive a
short kebab-case slug from the feature request.
- Read repo state: current branch, base branch, git status, project files, and
any existing
tasks/{slug}/prd.md, tasks/{slug}/techspec.md, and
tasks/{slug}/tasks.md.
- Stop before implementation only when:
- the feature request is too ambiguous to produce useful artifacts;
- the checkout has unrelated uncommitted work and the user has not approved
a worktree or cleanup path;
- required verification or project setup is blocked.
- Use branch-first isolation. If the current branch is
main, master,
develop, or trunk, create feature-marker/{slug} unless the user gave a
branch name. Use a git worktree only when the checkout is dirty or the user
asks for one.
- Create or reuse artifacts in
tasks/{slug}/ using the bundled templates:
templates/prd-template.md -> tasks/{slug}/prd.mdtemplates/techspec-template.md -> tasks/{slug}/techspec.mdtemplates/tasks-template.md -> tasks/{slug}/tasks.md
Replace {slug} and {feature_title}, fill every relevant section, and do
not leave unresolved template placeholders in committed artifacts.
- Run an implementation grill pass before coding. Challenge the artifacts for
missing acceptance criteria, weak task order, risky files, data/migration
impact, missing tests, unclear edge cases, and handoff gaps.
- Resolve grill findings in
tasks/{slug}/ before implementation. Ask the
user only when a finding changes scope or requires a product decision.
Otherwise continue without a generic artifact approval gate.
- Implement only the tasks in
tasks/{slug}/tasks.md. Keep changes scoped to
the feature and preserve unrelated local edits.
- Run project-appropriate verification. If a command fails, fix the issue when
it is in scope; otherwise report the exact blocker and stop.
- Commit the feature locally when implementation and verification are complete,
unless the user prohibited commits. Do not push or open a PR automatically.
- Print the branch handoff with exact commands:
git push -u origin <branch>
gh pr create --base <base-branch> --head <branch>
Artifact State
The canonical state is user-facing markdown:
tasks/{slug}/
prd.md
techspec.md
tasks.md
Optional verification notes may also live under tasks/{slug}/ when they help
future continuation, but checkpoint JSON is not the source of truth.
Prompt Intents
There are no CLI workflow modes. Treat these as prompt intents:
full: run the complete PRD -> TechSpec -> Tasks -> implementation grill ->
implementation -> tests -> branch handoff flow.tasks-only: use existing artifacts and implement the task list.test-only: run verification on the current feature branch and report
results.prd-only: create or revise only tasks/{slug}/prd.md.
spec-driven and ralph-loop are out of scope for this skill-first v1 unless
they are rebuilt as explicit skill instructions.
1---2name: feature-marker-23description: Skill-first run-through feature workflow for Claude, Codex, and Gemini. Use when the user asks to implement a feature through PRD, TechSpec, Tasks, verification, local commit, and branch handoff. The npm package installs skill files only; the LLM skill performs the workflow.4---5
6# feature-marker
7
8Use this skill when the user asks to implement, plan, test, or hand off a
9feature with Feature Marker.
10
11The normal invocation is a plain LLM prompt:
12
13```text
14Use feature-marker to implement <feature-slug>.
15```
16
17Run through the feature by default. Do not use an interactive menu, old CLI
18workflow commands, checkpoint JSON, or a JavaScript workflow engine. The package
19installer only installs this skill.
20
21## Run-Through Procedure
22
231. Identify the feature slug from the prompt. If the slug is missing, derive a
24 short kebab-case slug from the feature request.
252. Read repo state: current branch, base branch, git status, project files, and
26 any existing `tasks/{slug}/prd.md`, `tasks/{slug}/techspec.md`, and
27 `tasks/{slug}/tasks.md`.
283. Stop before implementation only when:
29 - the feature request is too ambiguous to produce useful artifacts;
30 - the checkout has unrelated uncommitted work and the user has not approved
31 a worktree or cleanup path;
32 - required verification or project setup is blocked.
334. Use branch-first isolation. If the current branch is `main`, `master`,
34 `develop`, or `trunk`, create `feature-marker/{slug}` unless the user gave a
35 branch name. Use a git worktree only when the checkout is dirty or the user
36 asks for one.
375. Create or reuse artifacts in `tasks/{slug}/` using the bundled templates:
38 - `templates/prd-template.md` -> `tasks/{slug}/prd.md`
39 - `templates/techspec-template.md` -> `tasks/{slug}/techspec.md`
40 - `templates/tasks-template.md` -> `tasks/{slug}/tasks.md`
41 Replace `{slug}` and `{feature_title}`, fill every relevant section, and do
42 not leave unresolved template placeholders in committed artifacts.
436. Run an implementation grill pass before coding. Challenge the artifacts for
44 missing acceptance criteria, weak task order, risky files, data/migration
45 impact, missing tests, unclear edge cases, and handoff gaps.
467. Resolve grill findings in `tasks/{slug}/` before implementation. Ask the
47 user only when a finding changes scope or requires a product decision.
48 Otherwise continue without a generic artifact approval gate.
498. Implement only the tasks in `tasks/{slug}/tasks.md`. Keep changes scoped to
50 the feature and preserve unrelated local edits.
519. Run project-appropriate verification. If a command fails, fix the issue when
52 it is in scope; otherwise report the exact blocker and stop.
5310. Commit the feature locally when implementation and verification are complete,
54 unless the user prohibited commits. Do not push or open a PR automatically.
5511. Print the branch handoff with exact commands:
56
57```bash
58git push -u origin <branch>
59gh pr create --base <base-branch> --head <branch>
60```
61
62## Artifact State
63
64The canonical state is user-facing markdown:
65
66```text
67tasks/{slug}/
68 prd.md
69 techspec.md
70 tasks.md
71```
72
73Optional verification notes may also live under `tasks/{slug}/` when they help
74future continuation, but checkpoint JSON is not the source of truth.
75
76## Prompt Intents
77
78There are no CLI workflow modes. Treat these as prompt intents:
79
80- `full`: run the complete PRD -> TechSpec -> Tasks -> implementation grill ->
81 implementation -> tests -> branch handoff flow.
82- `tasks-only`: use existing artifacts and implement the task list.
83- `test-only`: run verification on the current feature branch and report
84 results.
85- `prd-only`: create or revise only `tasks/{slug}/prd.md`.
86
87`spec-driven` and `ralph-loop` are out of scope for this skill-first v1 unless
88they are rebuilt as explicit skill instructions.
majiayu000