spectask-mcp 0.1.1__tar.gz

spectask_mcp-0.1.1/.cursor/mcp.json

@@ -0,0 +1,3 @@
+{
+  "mcpServers": {}
+}

spectask_mcp-0.1.1/.cursor/skills/spawn-ext-bootstrap/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: spawn-ext-bootstrap
+description: Bootstrap a new Spawn extension repo with extsrc skeleton and stable id.
+---
+
+
+Goal: start a new Spawn extension (methodology pack) from zero or from an existing repo that lacks `extsrc/`.
+
+1. Confirm or choose extension id (`name`): kebab-case, stable across releases; decide initial `version` string.
+2. From the extension repo root run `spawn extension init . --name <id>` so `extsrc/` and `config.yaml` exist.
+3. Set `schema: 1`, `name`, `version` in `config.yaml`; remove empty stub keys you will not use yet if the tool allows, or leave minimal valid maps.
+4. Plan top-level namespaces under `extsrc/files/` (e.g. `my-org/spec/`, `my-org/guides/`) so paths do not collide with other extensions in combined targets.
+5. Next steps: use sibling skills to declare **`files`** / **`folders`**, add templates under **`extsrc/files/`**; MCP lives under **`extsrc/mcp/*.json`** (see **spawn-ext-mcp**); then **`spawn extension check . --strict`**.
+6. **Later:** whenever packaging meaningfully evolves after bootstrap, **prompt** a **`version`** bump using **`spawn-ext-increment-version`** before publishing (initial `0.1.0` or `1.0.0` is typical until first stable story).
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spawn-ext-guide/ai/core.md` - Machine baseline — terms, extsrc tree rules, static vs artifact, name and uniqueness, install outputs.
+- `spawn-ext-guide/ai/cli.md` - Machine CLI reference — spawn init/extension/build commands, extensions.yaml bundle shape, authoring checklist.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spawn-ext-guide/ai/config-yaml.md` - Machine schema for config.yaml — keys, files/folders/skills modes, reads, ignores, setup, annotated example.
+- `spawn-ext-guide/ai/skill-sources.md` - Machine rules for extsrc/skills/*.md — frontmatter, name/description resolution, rendered skill shape, example.
+- `spawn-ext-guide/ai/mcp-json.md` - Machine schema for extsrc/mcp/windows.json, linux.json, macos.json — servers, OS selection, aligned name sets, transport, env, capabilities, JSON examples.
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.

spectask_mcp-0.1.1/.cursor/skills/spawn-ext-config/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: spawn-ext-config
+description: Declare config.yaml files/folders/ignores/setup and mirror every path under extsrc/files.
+---
+
+
+Goal: wire every template path under `extsrc/files/` into `config.yaml` with correct `mode`, `globalRead`/`localRead`, and optional `folders`/`setup`/`agent-ignore`/`git-ignore`/`hints`.
+
+1. List every file under `extsrc/files/`; each MUST have a matching key under `files:` (POSIX path relative to target root). Fix gaps before strict check.
+2. For each path choose `mode`: `static` for shared methodology the pack may overwrite on update; `artifact` for repo-owned outputs (tasks, local notes) that must never be overwritten after creation.
+3. Set `globalRead`/`localRead` so humans and agents discover the right docs (`required`/`auto`/`no`). Any non-`no` read flag needs a non-empty `description` under strict validation.
+4. Use `folders:` for directories whose ownership/update policy matters even when templates are sparse.
+5. Reference setup scripts only with basenames that exist under `extsrc/setup/`; hooks must be idempotent and safe for artifact data.
+6. For optional plain-text **`hints`** (`global` / `local` string lists merged into navigation and rendered skills — not a substitute for read surfaces), follow **`spawn-ext-hints`**.
+7. Run `spawn extension check . --strict` and fix reported issues.
+8. **Version:** If these edits materially change what consumers get (paths, read surfaces, ignores, setup, hints), **prompt** the author to bump **`version`** using **`spawn-ext-increment-version`** before tagging or publishing. Trivial typo-only fixes to existing templates may skip a bump — ask if unsure.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spawn-ext-guide/ai/core.md` - Machine baseline — terms, extsrc tree rules, static vs artifact, name and uniqueness, install outputs.
+- `spawn-ext-guide/ai/config-yaml.md` - Machine schema for config.yaml — keys, files/folders/skills modes, reads, ignores, setup, annotated example.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spawn-ext-guide/ai/skill-sources.md` - Machine rules for extsrc/skills/*.md — frontmatter, name/description resolution, rendered skill shape, example.
+- `spawn-ext-guide/ai/mcp-json.md` - Machine schema for extsrc/mcp/windows.json, linux.json, macos.json — servers, OS selection, aligned name sets, transport, env, capabilities, JSON examples.
+- `spawn-ext-guide/ai/cli.md` - Machine CLI reference — spawn init/extension/build commands, extensions.yaml bundle shape, authoring checklist.
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.

spectask_mcp-0.1.1/.cursor/skills/spawn-ext-hints/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: spawn-ext-hints
+description: Add optional hints.global / hints.local in config.yaml — plain-text agent reminders merged like global reads vs pack-local skills.
+---
+
+
+Goal: add short methodology reminders Spawn injects beside reads and skills — without replacing `globalRead` / `localRead` / skill `required-read`.
+
+1. Add optional top-level **`hints`** with **`global`** and/or **`local`**, each a **YAML list of strings**. Content is **plain text only** (no pointers into other files).
+2. **`global`**: included in **`spawn/navigation.yaml`** on this pack’s **`read-required` → `- ext:`** as **`hints`**, echoed into **every rendered skill** (each pack’s `hints.global`, in installed-extension order — same breadth idea as merged global mandatory reads), and merged into **`AGENTS.md`** / entry rollup together with maintainer hints.
+3. **`local`**: appended only when rendering skills **owned by this pack**, after globals for that lineage; **not** written under the navigation ext **`hints`** block; **not** folded into **`AGENTS.md`**.
+4. Expect **strip + dedupe by exact string** (first occurrence wins). Long lines may emit **`SpawnWarning`**; **`spawn/navigation.yaml`** may **truncate past 512 Unicode codepoints** per string; rendered skill **Hints** blocks may truncate total payload; **`AGENTS.md`** keeps full text but may warn on same thresholds — keep entries terse.
+5. Use hints for durable one-liners (conventions, “always run X before Y”). Prefer real specs as **`files:`** entries with **`globalRead`** / **`localRead`** or skill **`required-read`** when the agent must load a document body.
+6. **Version:** If hint text or which strings are global vs local changes observable behavior for consumers, **prompt** the author to bump **`version`** via **`spawn-ext-increment-version`** before release.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spawn-ext-guide/ai/core.md` - Machine baseline — terms, extsrc tree rules, static vs artifact, name and uniqueness, install outputs.
+- `spawn-ext-guide/ai/config-yaml.md` - Machine schema for config.yaml — keys, files/folders/skills modes, reads, ignores, setup, annotated example.
+- `spawn-ext-guide/user-guide.md` - Human-readable standalone guide — narrative for all authoring topics.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spawn-ext-guide/ai/skill-sources.md` - Machine rules for extsrc/skills/*.md — frontmatter, name/description resolution, rendered skill shape, example.
+- `spawn-ext-guide/ai/mcp-json.md` - Machine schema for extsrc/mcp/windows.json, linux.json, macos.json — servers, OS selection, aligned name sets, transport, env, capabilities, JSON examples.
+- `spawn-ext-guide/ai/cli.md` - Machine CLI reference — spawn init/extension/build commands, extensions.yaml bundle shape, authoring checklist.
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.

spectask_mcp-0.1.1/.cursor/skills/spawn-ext-increment-version/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: spawn-ext-increment-version
+description: Bump extension version in extsrc/config.yaml for releases (semver-oriented guidance).
+---
+
+
+Goal: update **`version`** at the top level of **`extsrc/config.yaml`** before publishing or tagging so consumers and `spawn extension update` flows see a monotonic, intentional change.
+
+1. Open **`extsrc/config.yaml`** and locate **`version`** (required string; compared **as a string** on extension update — ordering follows Spawn/tooling string rules, so prefer **semantic versioning** `MAJOR.MINOR.PATCH` for predictable ordering).
+2. Choose bump level:
+   - **PATCH** (`1.0.0` → `1.0.1`): fixes, docs-only template tweaks that do not change behavior contracts.
+   - **MINOR** (`1.0.1` → `1.1.0`): backward-compatible additions (new optional files, new skills, stricter defaults that remain compatible).
+   - **MAJOR** (`1.1.0` → `2.0.0`): breaking changes (removed paths, renamed skills, changed `name`, incompatible template or read semantics).
+3. Edit **`version`** to the new value only — keep **`schema`**, **`name`**, and **`version`** consistent with prior releases (**`name`** MUST stay stable across releases unless you intentionally ship a new extension id).
+4. If the repo keeps a **changelog**, add an entry for this version in that file (optional; not part of Spawn manifest).
+5. Run **`spawn extension check . --strict`** from the extension source root.
+
+Do **not** bump **`schema`** unless you migrate to a new Spawn **`config.yaml`** format version documented by Spawn.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spawn-ext-guide/ai/core.md` - Machine baseline — terms, extsrc tree rules, static vs artifact, name and uniqueness, install outputs.
+- `spawn-ext-guide/ai/config-yaml.md` - Machine schema for config.yaml — keys, files/folders/skills modes, reads, ignores, setup, annotated example.
+- `spawn-ext-guide/ai/cli.md` - Machine CLI reference — spawn init/extension/build commands, extensions.yaml bundle shape, authoring checklist.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spawn-ext-guide/ai/skill-sources.md` - Machine rules for extsrc/skills/*.md — frontmatter, name/description resolution, rendered skill shape, example.
+- `spawn-ext-guide/ai/mcp-json.md` - Machine schema for extsrc/mcp/windows.json, linux.json, macos.json — servers, OS selection, aligned name sets, transport, env, capabilities, JSON examples.
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.

spectask_mcp-0.1.1/.cursor/skills/spawn-ext-mcp/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: spawn-ext-mcp
+description: Add or edit extsrc/mcp/*.json — three platform files, Spawn servers shape, matching server names, safe env placeholders.
+---
+
+
+Goal: declare MCP servers bundled with the extension so Spawn merges them per host OS into IDE configs.
+
+### Layout
+
+- Use **`extsrc/mcp/windows.json`**, **`extsrc/mcp/linux.json`**, **`extsrc/mcp/macos.json`** only (`spawn extension init` scaffolds all three as `{"servers": []}`).
+- **Do not** add **`extsrc/mcp.json`** — obsolete; **`spawn extension check`** flags it.
+
+### Editing workflow (add or change servers)
+
+1. **Plan globally unique **`servers[].name`** values** across every extension that might install beside this one in the same target (prefer prefixed ids, e.g. `myorg-docs-mcp`).
+2. **Keep the server `name` set identical** in all three JSON files (same names; order may differ per file).
+3. For each OS file, edit the **`servers`** array with the Spawn shape: top-level **`servers`** — not IDE **`mcpServers`**.
+4. **`transport`**: default mental model **`stdio`** with **`command`** / **`args`** / **`cwd`**; **`sse`** / **`streamable-http`** use **`url`** where the adapter supports that **`type`**.
+5. **`env`**: never commit secrets; structured objects with **`secret`** / **`required`**, or non-object placeholders — generated IDE config uses placeholders for user values.
+6. **`capabilities`**: set when defaults (tools on, resources/prompts off) are wrong for the server.
+7. When transport truly differs by OS (e.g. **`python`** vs **`python3`**, or Windows-specific exe), duplicate the server **`name`** in each file but adjust only **`transport`** (and **`env`** if needed) per platform.
+8. **Homogeneous setups:** duplicate the **same** JSON payload into **`windows.json`**, **`linux.json`**, and **`macos.json`** if all three match — still three files required.
+9. Run **`spawn extension check .`** (`--strict` in CI): parsing, stray obsolete **`extsrc/mcp.json`**, and **matching `name`** sets across **`extsrc/mcp/*.json`**.
+
+### Release discipline
+
+Changing **`servers`**, transports, **`env`** contract, or **`capabilities`** is consumer-visible MCP behavior — **prompt** the author to bump **`version`** via **`spawn-ext-increment-version`** before publishing.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spawn-ext-guide/ai/core.md` - Machine baseline — terms, extsrc tree rules, static vs artifact, name and uniqueness, install outputs.
+- `spawn-ext-guide/ai/mcp-json.md` - Machine schema for extsrc/mcp/windows.json, linux.json, macos.json — servers, OS selection, aligned name sets, transport, env, capabilities, JSON examples.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spawn-ext-guide/ai/config-yaml.md` - Machine schema for config.yaml — keys, files/folders/skills modes, reads, ignores, setup, annotated example.
+- `spawn-ext-guide/ai/skill-sources.md` - Machine rules for extsrc/skills/*.md — frontmatter, name/description resolution, rendered skill shape, example.
+- `spawn-ext-guide/ai/cli.md` - Machine CLI reference — spawn init/extension/build commands, extensions.yaml bundle shape, authoring checklist.
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.

spectask_mcp-0.1.1/.cursor/skills/spawn-ext-skill-sources/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: spawn-ext-skill-sources
+description: Author extsrc/skills and register them in config with required-read merges.
+---
+
+
+Goal: add or change agent skills shipped with the extension.
+
+1. Add `extsrc/skills/<skill-key>.md` (UTF-8 Markdown). Filename must match the key under `skills:` when declared.
+2. Prefer short procedural bodies; long reference belongs under `extsrc/files/` and is linked via `localRead`/`globalRead` or per-skill `required-read`.
+3. Optional YAML frontmatter with `name` and/or `description`; otherwise set them under `skills:` in `config.yaml` (config overrides frontmatter where both apply per resolution rules).
+4. Under `skills:` list `required-read` target paths only when they are mandatory for that skill beyond merged global/local rules; avoid pointless duplication.
+5. After normalization, skill display names must remain unique across all extensions installed in one target — use a stable prefix.
+6. Run `spawn extension check . --strict` after adding or renaming skill files.
+7. **Version:** Adding, removing, or materially changing skills or their **`required-read`** affects consumers — **prompt** the author to bump **`version`** via **`spawn-ext-increment-version`** before release (unless the change is typo-only text with no behavior impact).
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spawn-ext-guide/ai/core.md` - Machine baseline — terms, extsrc tree rules, static vs artifact, name and uniqueness, install outputs.
+- `spawn-ext-guide/ai/config-yaml.md` - Machine schema for config.yaml — keys, files/folders/skills modes, reads, ignores, setup, annotated example.
+- `spawn-ext-guide/ai/skill-sources.md` - Machine rules for extsrc/skills/*.md — frontmatter, name/description resolution, rendered skill shape, example.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spawn-ext-guide/ai/mcp-json.md` - Machine schema for extsrc/mcp/windows.json, linux.json, macos.json — servers, OS selection, aligned name sets, transport, env, capabilities, JSON examples.
+- `spawn-ext-guide/ai/cli.md` - Machine CLI reference — spawn init/extension/build commands, extensions.yaml bundle shape, authoring checklist.
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.

spectask_mcp-0.1.1/.cursor/skills/spawn-ext-verify/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: spawn-ext-verify
+description: Strict check extension layout and smoke-test install in a disposable target.
+---
+
+
+Goal: ship only packs that pass strict validation and install cleanly.
+
+1. From extension source root: **`spawn extension check . --strict`** — resolve missing skills, undeclared files under `extsrc/files/`, descriptions for non-no read flags, invalid or mismatched **`extsrc/mcp/*.json`** (including stray obsolete **`extsrc/mcp.json`**), missing setup scripts.
+2. In a throwaway clone or empty repo: **`spawn init`**, then **`spawn extension add <path-or-url-to-your-extension-source>`** (match consumer workflow).
+3. Confirm materialized paths under **`files:`** exist as expected; confirm **`artifact`** paths are not overwritten on a repeat add/update where applicable.
+4. If **`healthcheck`** is configured: **`spawn extension healthcheck <name>`** from the target.
+5. Document distribution: plain repo URL/path, zip, or entry in an **`extensions.yaml`** bundle for **`spawn build install`**.
+6. **Version:** If this session changed **`config.yaml`**, skills, **`extsrc/files/`** layout, or **`extsrc/mcp/*.json`** in a user-visible way, **prompt** the author to bump **`version`** with **`spawn-ext-increment-version`** before tagging or releasing — unless they confirm it was docs-only typos with no behavioral impact.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spawn-ext-guide/ai/core.md` - Machine baseline — terms, extsrc tree rules, static vs artifact, name and uniqueness, install outputs.
+- `spawn-ext-guide/ai/cli.md` - Machine CLI reference — spawn init/extension/build commands, extensions.yaml bundle shape, authoring checklist.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spawn-ext-guide/ai/config-yaml.md` - Machine schema for config.yaml — keys, files/folders/skills modes, reads, ignores, setup, annotated example.
+- `spawn-ext-guide/ai/skill-sources.md` - Machine rules for extsrc/skills/*.md — frontmatter, name/description resolution, rendered skill shape, example.
+- `spawn-ext-guide/ai/mcp-json.md` - Machine schema for extsrc/mcp/windows.json, linux.json, macos.json — servers, OS selection, aligned name sets, transport, env, capabilities, JSON examples.
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.

spectask_mcp-0.1.1/.cursor/skills/spawn-methodology-shape/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: spawn-methodology-shape
+description: Design methodology namespaces, static vs artifact layout, and read surfaces before packing.
+---
+
+
+Goal: before editing YAML heavily, decide what the methodology teaches and where files live under `extsrc/files/`.
+
+1. Define audiences (human vs agent) and primary workflows; map each to concrete paths under a single namespace prefix.
+2. Classify each deliverable as `static` (canonical methodology the pack maintains) vs `artifact` (per-repo living documents).
+3. Choose what belongs in global navigation (`globalRead`) vs only when using this pack’s skills (`localRead`).
+4. Split long specs into `extsrc/files/` and keep `extsrc/skills/*.md` as thin procedures that point to those reads.
+5. Align names with uniqueness rules (prefixed skill ids, MCP server ids, path prefixes) if this pack coexists with others.
+6. Implement the tree under `extsrc/files/`, then run `spawn-ext-config` and `spawn-ext-verify` workflows.
+7. **Version:** If namespaces, static vs artifact split, or read surfaces change shipped methodology, **prompt** the author to bump **`version`** via **`spawn-ext-increment-version`** before consumers upgrade.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spawn-ext-guide/ai/core.md` - Machine baseline — terms, extsrc tree rules, static vs artifact, name and uniqueness, install outputs.
+- `spawn-ext-guide/ai/config-yaml.md` - Machine schema for config.yaml — keys, files/folders/skills modes, reads, ignores, setup, annotated example.
+- `spawn-ext-guide/user-guide.md` - Human-readable standalone guide — narrative for all authoring topics.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spawn-ext-guide/ai/skill-sources.md` - Machine rules for extsrc/skills/*.md — frontmatter, name/description resolution, rendered skill shape, example.
+- `spawn-ext-guide/ai/mcp-json.md` - Machine schema for extsrc/mcp/windows.json, linux.json, macos.json — servers, OS selection, aligned name sets, transport, env, capabilities, JSON examples.
+- `spawn-ext-guide/ai/cli.md` - Machine CLI reference — spawn init/extension/build commands, extensions.yaml bundle shape, authoring checklist.
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.

spectask_mcp-0.1.1/.cursor/skills/spectask-code-review-passed/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: spectask-code-review-passed
+description: After user confirms code review — Steps 6–7 in one run (spec/main.md).
+---
+
+
+Operate within the **spectask** process defined in attached **spec/main.md**.
+
+On the active `spec/tasks/{X}-{name}/overview.md`, finish **Step 6** (mark **code review passed** and the Step 6 prompt), then complete **Step 7** through **Design documents updated** in the same run. If **`overview.md`** ties a **`spec/seeds/`** file to this task, run **Step 7** item **6** (seed `_DONE_` rename) per **`spec/main.md`**. Ask which task if unclear.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.

spectask_mcp-0.1.1/.cursor/skills/spectask-create/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: spectask-create
+description: Use when drafting a new spectask (specification only, per spec/main.md).
+---
+
+
+Operate within the **spectask** process defined in attached **spec/main.md**.
+Complete **Steps 1–2** only — then stop and wait for the user’s **Step 3** (spec review).
+
+Under this skill, writing implementation code without an approved specification is not allowed — stay within Steps 1–2 (overview.md and subtasks) until spec review passes.
+
+If work began from **`spec/seeds/`**, tie the seed to the new task in **Step 1** (**`linked task:`** + **Source seed** in **`overview.md`**) and close it in **Step 7** item **6**, per **`spec/main.md`**.
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.

spectask_mcp-0.1.1/.cursor/skills/spectask-design/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: spectask-design
+description: Use when registering architecture files in spec/design.yaml or drafting spec/design/*.md.
+---
+
+
+Operate within the **spectask** process defined in attached **spec/main.md**.
+
+## `spec/design.yaml`
+
+- **Schema:** top-level `schema: 1` and list **`documents`**. Each item has **`path`** and **`description`** (plain language: what the document covers, when to read it).
+- **Paths:** repo-relative POSIX, typically `spec/design/{name}.md`. Reuse existing names when editing; avoid duplicates in `documents`.
+- **Edits:** append or update entries when adding or renaming architecture markdown. Keep descriptions short and unique in intent (not copy-paste of the file title only).
+
+## New or updated `spec/design/*.md`
+
+1. **Purpose** — one paragraph: why this document exists.
+2. **Scope** — in/out; link to HLA if this is a slice of the whole system.
+3. **Content** — components, boundaries, data or control flow, integrations, constraints; diagrams as fenced blocks or links if the user prefers.
+4. **Related** — other `spec/design` docs by path when relevant.
+
+If the user only wants a registry row, still ensure the target **`.md` exists** or create a minimal stub so `path` is not orphaned.
+
+## Spawn / agent reads
+
+New paths are discoverable from **`spec/design.yaml`** once that file is read. For mandatory or default context at session start, paths still need **`globalRead` / `localRead`** (and non-empty **`description`**) in a Spawn extension **`config.yaml`** for the repo. If the user maintains this methodology pack, add a matching `files:` entry under **`extsrc/config.yaml`** and reinstall/update the extension; otherwise note the requirement for a companion extension or local config.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.

spectask_mcp-0.1.1/.cursor/skills/spectask-execute/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: spectask-execute
+description: Steps 4–5 in spec/main.md; then wait for user Step 6.
+---
+
+
+Operate within the **spectask** process defined in attached **spec/main.md**.
+
+Complete **Steps 4–5**. Then wait for the user for **Step 6**.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.

spectask_mcp-0.1.1/.cursor/skills/spectask-seed-create/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: spectask-seed-create
+description: Capture a rough idea as spec/seeds/{X}-{slug}.md (not a full task); then offer to start spectask-create.
+---
+
+
+Operate within the **spectask** process defined in attached **spec/main.md**.
+
+Follow the short **Seed** paragraph and **[Seed file template (header)](#seed-file-template-header)** in **spec/main.md**.
+
+Pick a kebab-case **slug** and the next **`X`** under **`spec/seeds/`** (default: max numeric prefix among **`*.md`** there + **1**). Create **`spec/seeds/{X}-{slug}.md`**: **`linked task: none`** unless it already binds to an **`overview.md`** path — blank line — then informal notes (**not** a full spectask).
+
+Suggest **spectask-create** when the user promotes; **Step 1** and **Step 7** item **6** covering seed wiring live there.
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.

spectask_mcp-0.1.1/.cursor/skills/spectask-spec-review-passed/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: spectask-spec-review-passed
+description: Step 3 — spec approved (spec/main.md).
+---
+
+
+Operate within the **spectask** process defined in attached **spec/main.md**.
+
+On the active `spec/tasks/{X}-{name}/overview.md`, finish Step 3: **Spec review passed** and the Step 3 prompt. Ask which task if unclear.
+
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+Mandatory reads:
+- `spec/main.md` - Spec-Tasks methodology — folder structure, seven-step process, overview template.
+- `spec/design.yaml` - Index of architecture documents under spec/design/ — path and description per entry.
+- `spawn/navigation.yaml` - Merged Spawn navigation (read-required, read-contextual).
+
+Contextual reads:
+- `spec/design/hla.md` - Project high-level architecture; updated in Step 7.

spectask_mcp-0.1.1/.cursorignore

@@ -0,0 +1,9 @@
+# spawn:core:start
+spawn/.core/**
+spawn/.metadata/**
+spawn/.extend/**
+# spawn:core:end
+# spawn:ext:start
+spec/seeds/_DONE_*.md
+spec/tasks/**/_DONE_*/_DONE_*.md
+# spawn:ext:end

spectask_mcp-0.1.1/.gitattributes

@@ -0,0 +1,2 @@
+# Auto detect text files and perform LF normalization
+* text=auto

spectask_mcp-0.1.1/.gitignore

@@ -0,0 +1,3 @@
+# spawn:start
+spawn/.metadata/temp/**
+# spawn:end

spectask_mcp-0.1.1/AGENTS.md

@@ -0,0 +1,12 @@
+<!-- spawn:start -->
+Before working, read `spawn/navigation.yaml`.
+Read every file listed under `read-required`.
+Inspect `read-contextual` descriptions and read only files relevant to the current task.
+
+Hints:
+- No emojis or exotic Unicode in code, logs, documentation, or messages; plain ASCII where practical.
+- User-facing replies, documentation, and task descriptions: concise wording; minimal markdown (avoid decorative bold/italic); explain with lists and structure; short, clear sentences.
+- Specifications, code comments, and project documentation must be written in English.
+- If the user only asked a question, answer first; do not edit files unless changes are clearly needed.
+
+<!-- spawn:end -->

spectask_mcp-0.1.1/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 anton
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

spectask_mcp-0.1.1/PKG-INFO

@@ -0,0 +1,9 @@
+Metadata-Version: 2.4
+Name: spectask-mcp
+Version: 0.1.1
+Summary: Stdio MCP and CLI for Spectask-Jira workflows
+License-File: LICENSE
+Requires-Python: >=3.11
+Requires-Dist: httpx[socks]>=0.27.0
+Requires-Dist: mcp>=1.2.0
+Requires-Dist: pyyaml>=6.0.1