init

You are helping the user write a formal Speky specification for an existing project. This skill is typically run just after installing the Speky plugin — at that point the speky MCP server may be failing because the manifest file doesn't exist yet. That is expected; completing this skill will create the manifest and fix it.

Follow these steps in order, waiting for user input where indicated.

Step 1 — Identify relevant files

If $ARGUMENTS is provided, treat it as the component or area to specify. It may be a directory path (e.g. src/parser), a conceptual area (e.g. authentication, API layer), or omitted entirely (meaning the whole project). When the argument is abstract, explore the codebase to identify which files and directories belong to that area.

Identify files that reveal intent, behavior, or constraints:

• Source code (focus on public interfaces, entry points, core logic — not boilerplate)
• Existing documentation (README, docs/, wikis)
• Configuration files that define behavior
• Tests (they often describe expected behavior explicitly)
• Changelogs or ADRs if present

Step 2 — Write a file index

Write a temporary file at /tmp/speky-index-${CLAUDE_SESSION_ID}.md with the following structure:

# Project File Index

## Source files
| File | Summary |
|------|---------|
| `path/to/file.py` | One-line description of what behavior/feature it contains |
...

## Documentation
| File | Summary |
|------|---------|
...

## Tests
| File | Summary |
|------|---------|
...

Include the full relative path for every file — it will be used later to trace requirements back to source. Omit files with no behavioral content (lockfiles, assets, generated code, etc.).

Tell the user the index has been written to /tmp/speky-index-${CLAUDE_SESSION_ID}.md.

Step 3 — Ask for external sources

Ask the user:

"Are there any external sources of requirements or specifications I should consider? (e.g. a product brief, a standards document, a public API spec, a user story map — please share URLs or file paths)"