Run any Skill in Manus with one click

to-spec

Stars17

Forks2

UpdatedJuly 9, 2026 at 19:01

Turn the current conversation into a draft local spec in specs/ using this repository's spec template and Nightmanager conventions. Synthesis, not an interview.

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

asabya

asabya/nightmanager

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	to-spec
description	Turn the current conversation into a draft local spec in specs/ using this repository's spec template and Nightmanager conventions. Synthesis, not an interview.

To Spec

Take the current conversation, idea, and codebase understanding and synthesise a draft spec under specs/ using the structure from specs/TEMPLATE.md. This document is a broad specification (you may know it as a PRD), not a strict product-requirements form.

Do not run an interview here — that is grill-me's job. Synthesise what you already know. Only ask a question when a required section cannot be written without a decision the conversation never settled.

Process

Inspect the repo to ground the spec in current behaviour and likely implementation areas. Use the project's existing vocabulary and respect anything the surrounding specs establish.
Sketch the test seams. Decide where the feature will be observed and tested — prefer existing seams to new ones, and the highest seam possible. The fewer seams, the better; the ideal is one. Record them in the spec's Testing Plan / Suggested Approach. If a new seam is needed, briefly check it matches the user's expectations.
Write specs/draft-<slug>.md (unless the user names a file) filling every section of specs/TEMPLATE.md with concrete, testable content:
- Keep Status: draft and the draft- prefix — promotion to active is to-ready's job, not this skill's.
- Fill Acceptance Criteria and Testing Plan with real, runnable checks. The Testing Plan is Nightmanager's single validation source for this spec, so make its commands exact.
- Do not paste file paths or code snippets that will go stale; describe decisions in prose. Exception: a small snippet that encodes a decision more precisely than prose (a schema, type shape, state machine) may be inlined.

Rules

Local-file-first: the draft spec is the only primary output. Do not create TODOs.md entries or GitHub issues here — that is to-tickets.
Leave no template placeholders (<title>, <human>, <yyyy-mm-dd>, empty bullets); to-ready will refuse to promote a spec that still has them.
If the user explicitly asks for a TODO candidate too, add it as [draft] only, never [ready].

More from this repository

same repository

code-review

asabya/nightmanager

Two-axis review of a diff — Standards (does it follow the repo's conventions and avoid code smells?) and Spec (does it implement what the ticket/spec asked?). Runs the axes as parallel sub-agents. Use to review a branch, PR, or work-in-progress.

2026-07-0917

grill-me

asabya/nightmanager

Relentlessly interrogate a plan or design one question at a time until the goal, risks, and trade-offs are clear.

2026-07-0917

implement

asabya/nightmanager

Implement one ready ticket or spec interactively in the foreground — the attended alternative to the AFK /nightmanager night shift. TDD where seams allow, then code review, then commit.

2026-07-0917

research

asabya/nightmanager

Investigate a question against high-trust primary sources and capture the findings as a Markdown note in the repo. Dispatches Nightmanager's librarian tool so you keep working while it reads.

2026-07-0917

tdd

asabya/nightmanager

Test-driven development reference — what a good test is, where tests go, the anti-patterns, and the rules of the red → green loop. Reference material for /implement and the night shift, not a workflow of its own.

2026-07-0917

to-tickets

asabya/nightmanager

Break a spec, plan, or conversation into vertically-sliced Nightmanager tickets — local TODOs.md entries, each declaring what it delivers and what blocks it.

2026-07-0917

To Spec

Process

Inspect the repo to ground the spec in current behaviour and likely implementation areas. Use the project's existing vocabulary and respect anything the surrounding specs establish.

Sketch the test seams. Decide where the feature will be observed and tested — prefer existing seams to new ones, and the highest seam possible. The fewer seams, the better; the ideal is one. Record them in the spec's Testing Plan / Suggested Approach. If a new seam is needed, briefly check it matches the user's expectations.

Write specs/draft-<slug>.md (unless the user names a file) filling every section of specs/TEMPLATE.md with concrete, testable content:

Keep Status: draft and the draft- prefix — promotion to active is to-ready's job, not this skill's.
Fill Acceptance Criteria and Testing Plan with real, runnable checks. The Testing Plan is Nightmanager's single validation source for this spec, so make its commands exact.
Do not paste file paths or code snippets that will go stale; describe decisions in prose. Exception: a small snippet that encodes a decision more precisely than prose (a schema, type shape, state machine) may be inlined.

Rules

Local-file-first: the draft spec is the only primary output. Do not create TODOs.md entries or GitHub issues here — that is to-tickets.

Leave no template placeholders (<title>, <human>, <yyyy-mm-dd>, empty bullets); to-ready will refuse to promote a spec that still has them.

If the user explicitly asks for a TODO candidate too, add it as [draft] only, never [ready].