Run any Skill in Manus with one click

specforge-convert-spec

Stars3

Forks0

UpdatedJune 18, 2026 at 16:12

Convert an existing design/spec file into a SpecForge spec in the store. Use when the user asks to "convert <file> to a spec", "import this design doc", or "turn this markdown/HTML into a SpecForge spec". Handles two cases: an existing SpecForge-style .html is ingested as-is; a .md or freeform design doc is re-authored into a full house-style HTML spec. Attaches the result to this session and lints before finishing.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

NitinJ

NitinJ/specforge

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	specforge:convert-spec
user-invocable	false
description	Convert an existing design/spec file into a SpecForge spec in the store. Use when the user asks to "convert <file> to a spec", "import this design doc", or "turn this markdown/HTML into a SpecForge spec". Handles two cases: an existing SpecForge-style .html is ingested as-is; a .md or freeform design doc is re-authored into a full house-style HTML spec. Attaches the result to this session and lints before finishing.
allowed-tools	Read, Write, Edit, Bash, Glob, Grep

convert-spec

Bring an existing file into the SpecForge store. ${CLAUDE_PLUGIN_ROOT} is the installed plugin directory.

1. Inspect the source

The user names a file ($ARGUMENTS). Read it and decide:
- Already a SpecForge-style HTML spec (has the section ids / theme contract / structured plan) → ingest as-is (step 2A).
- A .md, or a freeform .html/design doc → re-author into a house-style spec (step 2B).
Infer the spec type from the source — research (a findings report), design (a design doc, no plan), design-impl (design + a plan), or impl (a build plan). Default to design-impl when unsure. Pass it as --type below.

2A. Ingest an existing HTML spec

node "${CLAUDE_PLUGIN_ROOT}/lib/specforge-cli.mjs" import "<file>" --title "<title>" --type <type>

Prints { id, htmlPath, url, status, type } — the file is copied into the store, attached to this session, daemon ensured. Lint htmlPath (step 3). If lint fails because it isn't house-style, fall back to 2B (author into the same htmlPath).

2B. Re-author a design doc into a house-style spec

Read the house rules: ${CLAUDE_PLUGIN_ROOT}/templates/house-rules.md.
Scaffold a fresh store spec from the template:
```
node "${CLAUDE_PLUGIN_ROOT}/lib/specforge-cli.mjs" create --title "<title>" --type <type>
```
It prints { id, htmlPath, url, type }. Author into htmlPath.
Map the source onto the type's sections exactly as the create-spec skill describes (design / research / design-impl / impl) — adapt sections to the content; keep stable unique ids, the theme, and the floating TOC in sync. For impl types build impl-plan as Stages → Tasks (data-sf-stage/data-sf-task/ data-sf-status, one stage = one PR, each task a verify: note) mirrored into task-tracker, and leave the Runtime stubs. Preserve the author's intent; don't invent scope.
Keep every <section id="…">, the theme CSS, and the floating <nav class="toc"> (update TOC links to match the sections you keep).

3. Lint (must pass)

node "${CLAUDE_PLUGIN_ROOT}/lib/lint-spec.mjs" <htmlPath>

Fix and re-run until PASS. Do not finish on a failing lint.

4. Hand off + arm the review watcher

Print the spec url. The spec is attached to this session; browser review comments are delivered back here automatically. Mention the original file is left untouched (its path is recorded as the spec's origin).
Arm the review watcher (once per session) so comments are picked up while you're idle. If it isn't already running this session, start it in the background: node "${CLAUDE_PLUGIN_ROOT}/lib/specforge-cli.mjs" wait-batch. On its { ready, pending } return, run review-spec for each pending spec then relaunch it; on timeout, just relaunch. One watcher covers every spec here.

More from this repository

same repository

specforge-tune-templates

NitinJ/specforge

Optimize the SpecForge spec templates from the review-comment history. Use when the user asks to "tune the templates", "improve the spec templates", "bake review learnings into the templates", or after a batch of specs has accumulated feedback. Mines every human comment across the store, clusters the recurring cross-spec themes + redundant sections, proposes template changes as a spec, and — only on the user's go-ahead — edits the four template specs in place. Never touches or rewrites existing specs; templates only.

2026-07-093

specforge-create-spec

NitinJ/specforge

Author a new house-style spec into the SpecForge store. Use when the user asks to "write a spec", "create a design doc", "draft a spec for <x>", "research <x>", or "plan to implement <x>". Picks the spec type (design | research | design-impl | impl), scaffolds the right shell, and authors the type's sections — light/dark HTML, stable section ids, a floating TOC; impl types also get a Stages/Tasks plan, a live task tracker, and impl-time stubs. Lints the universal basics before done.

2026-07-043

specforge-export

NitinJ/specforge

Export a spec from the store to Google Docs. Auto-invoked when the owning session's Stop/UserPromptSubmit hook surfaces a queued export (the human clicked "Export to Google Docs" in the review UI); can also be run manually. Reads the spec HTML, creates a Google Doc via the connected Google Drive MCP, and reports the Doc link back so the dropdown shows it.

2026-06-253

specforge-review-spec

NitinJ/specforge

Process a submitted batch of human comments on a spec in the store: reply to each thread inline and amend the spec accordingly. Usually auto-invoked when the owning session's Stop/UserPromptSubmit hook surfaces a pending batch; can also be run manually. Replies are append-only; only the human resolves threads.

2026-06-213

specforge-list-specs

NitinJ/specforge

List SpecForge specs — either every spec in the store (mode "all") or just the specs attached to this session (mode "mine"). Use when the user asks to "list specs", "show all specs", "what specs do I have open", or wants to open/detach a spec. Starts or reuses the daemon, prints a table, and offers to open/detach.

2026-06-183

name	specforge:convert-spec
user-invocable	false
description	Convert an existing design/spec file into a SpecForge spec in the store. Use when the user asks to "convert <file> to a spec", "import this design doc", or "turn this markdown/HTML into a SpecForge spec". Handles two cases: an existing SpecForge-style .html is ingested as-is; a .md or freeform design doc is re-authored into a full house-style HTML spec. Attaches the result to this session and lints before finishing.
allowed-tools	Read, Write, Edit, Bash, Glob, Grep

convert-spec

Bring an existing file into the SpecForge store. ${CLAUDE_PLUGIN_ROOT} is the installed plugin directory.

1. Inspect the source

The user names a file ($ARGUMENTS). Read it and decide:
- Already a SpecForge-style HTML spec (has the section ids / theme contract / structured plan) → ingest as-is (step 2A).
- A .md, or a freeform .html/design doc → re-author into a house-style spec (step 2B).
Infer the spec type from the source — research (a findings report), design (a design doc, no plan), design-impl (design + a plan), or impl (a build plan). Default to design-impl when unsure. Pass it as --type below.

2A. Ingest an existing HTML spec

node "${CLAUDE_PLUGIN_ROOT}/lib/specforge-cli.mjs" import "<file>" --title "<title>" --type <type>

2B. Re-author a design doc into a house-style spec

Read the house rules: ${CLAUDE_PLUGIN_ROOT}/templates/house-rules.md.
Scaffold a fresh store spec from the template:
```
node "${CLAUDE_PLUGIN_ROOT}/lib/specforge-cli.mjs" create --title "<title>" --type <type>
```
It prints { id, htmlPath, url, type }. Author into htmlPath.
Map the source onto the type's sections exactly as the create-spec skill describes (design / research / design-impl / impl) — adapt sections to the content; keep stable unique ids, the theme, and the floating TOC in sync. For impl types build impl-plan as Stages → Tasks (data-sf-stage/data-sf-task/ data-sf-status, one stage = one PR, each task a verify: note) mirrored into task-tracker, and leave the Runtime stubs. Preserve the author's intent; don't invent scope.
Keep every <section id="…">, the theme CSS, and the floating <nav class="toc"> (update TOC links to match the sections you keep).

3. Lint (must pass)

node "${CLAUDE_PLUGIN_ROOT}/lib/lint-spec.mjs" <htmlPath>

Fix and re-run until PASS. Do not finish on a failing lint.

4. Hand off + arm the review watcher

Print the spec url. The spec is attached to this session; browser review comments are delivered back here automatically. Mention the original file is left untouched (its path is recorded as the spec's origin).
Arm the review watcher (once per session) so comments are picked up while you're idle. If it isn't already running this session, start it in the background: node "${CLAUDE_PLUGIN_ROOT}/lib/specforge-cli.mjs" wait-batch. On its { ready, pending } return, run review-spec for each pending spec then relaunch it; on timeout, just relaunch. One watcher covers every spec here.