Run any Skill in Manus with one click

testing-spec-kit-canon-extension

Stars5

Forks1

UpdatedApril 16, 2026 at 21:18

Validate the local Spec Kit Canon extension and canon-core preset against the real sibling workspace layout (`spec-kit`, `spec-kit-canon`, `spec-kit-canon-test`). Use when starting or resuming the dedicated extension test workflow, optionally clearing `spec-kit-canon-test` before step 1, overriding the scaffolded Spec Kit script variant (`sh` vs `ps`) when needed, verifying constitution config rendering from the shared fixture, seeding the trivial canon, running the standard `/speckit.specify` to `/speckit.implement` workflow, exercising `/speckit.canon.drift` (with manual resolve and analyze gates) and `/speckit.canon.vibecode-drift` (with analyze gate before canonize), verifying that canon updates capture new API and web UI behavior, and generating a final Markdown test report with per-step results, test-run metrics, and developer-history copies in `spec-kit-canon/tests/history/`.

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

maximiliamus

maximiliamus/spec-kit-canon

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

File Explorer

15 files

SKILL.md

readonly

name

testing-spec-kit-canon-extension

description

Testing Spec Kit Canon Extension

This folder is the canonical shared skill source.

Use the shared material from:

./core
./scripts
./assets

Shared Rules

Treat core/workflow.md as the canonical workflow.
Treat core/test-flow.md as the canonical prompt and verification reference.
Begin command-driven runs with scripts/prepare_workflow.py so resume versus restart behavior stays consistent across agents.
Use scripts/manage_progress.py to create and update the resumable workflow progress file.
Use scripts/generate_test_report.py to render the final Markdown report from the saved workflow state.
Treat --script sh as the default fresh-run variant unless a command explicitly requests --script ps.
Resume the current workflow by default when the progress file still has pending work.
If the progress file shows the workflow is fully completed, restart from scratch automatically before continuing.
Support a command-level --restart flag that forces a fresh run even when resumable progress exists.
Keep the shared workflow and validation guidance in this skill package.
Treat spec-kit-canon-test as a real git repository. The validation run must leave it in a valid branch/commit state, not just a passing working tree.
Before staging sandbox changes, verify the installed extension copy at .specify/extensions/canon does not contain a nested .git directory. If it does, remove the installed copy's .git metadata before committing the sandbox and note the packaging regression in the source repo.
Before switching branches during the workflow, make sure the progress file at .specify/tmp/testing-spec-kit-canon-extension-progress.json is committed or stashed if git would otherwise block checkout.

More from this repository

same repository

committing-bulk-modifications

maximiliamus/spec-kit-canon

Claude skill entrypoint for grouping staged files into meaningful conventional commits. Use when Claude needs to inspect the staging area, cluster staged files by logical concern, propose a commit plan with messages and file lists, and apply that plan one group at a time without staging anything that was not already staged.

2026-04-165

committing-bulk-modifications

maximiliamus/spec-kit-canon

Group already-staged files from a bulk operation into meaningful commits and propose the message and file list for each commit. Use when a large batch of staged changes spans multiple logical concerns and must be split into well-scoped conventional commits before pushing. Only staged files are considered — unstaged changes are ignored.

2026-04-165

bumping-spec-kit-canon-version

maximiliamus/spec-kit-canon

Claude skill entrypoint for the shared Spec Kit Canon version bump workflow. Use when Claude needs to default to the next minor version in `extension/extension.yml` and `preset/preset.yml`, update the pinned release commands in `docs/INSTALL.md` and `docs/UPGRADE.md`, keep documented base Spec Kit versions aligned with `preset/spec-kit-release.json`, update `CHANGELOG.md` automatically from Conventional Commit subjects, bump only patch or major when that scope is explicitly requested, or apply an exact version only when the user explicitly provides one.

2026-04-165

syncing-spec-kit-canon-core-preset

maximiliamus/spec-kit-canon

Claude skill entrypoint for syncing `preset/` with the latest released upstream `spec-kit` core commands. Use when Claude needs to verify the real latest release tag against `../spec-kit` `origin`, export the upstream release snapshot, rebase the regular upstream-tracking commands by preserving or intentionally retiring named `spec-kit-canon` overlay blocks, and manually merge the `speckit.constitution` and constitution template files.

2026-04-165

bumping-spec-kit-canon-version

maximiliamus/spec-kit-canon

Bump the shared release version in both publishable Spec Kit Canon manifests, update the version-pinned release commands in `docs/INSTALL.md` and `docs/UPGRADE.md`, keep any documented base Spec Kit version in sync with `preset/spec-kit-release.json`, and automatically update the repo changelog. Use when preparing the next release, aligning `extension/extension.yml` and `preset/preset.yml`, defaulting to the next minor version when the prompt just asks to bump the extension version, bumping only patch or major when that scope is explicitly requested, or applying an exact `X.Y.Z` or `vX.Y.Z` version only when the user explicitly asks for a specific version.

2026-04-165

syncing-spec-kit-canon-core-preset

maximiliamus/spec-kit-canon

Sync `preset/` with the latest released upstream `spec-kit` core command sources. Use when rebasing `preset/commands/*.md` or `preset/templates/constitution-template.md` onto the newest upstream release tag, verifying the real latest release against `../spec-kit` `origin`, fetching a missing release tag locally, exporting upstream source snapshots, preserving or intentionally retiring canon-owned HTML comment overlay blocks in the regular upstream-tracking commands, handling the larger `speckit.constitution` merge, and keeping the visible upstream-baseline notes in the README files aligned with the recorded sync metadata.

2026-04-165

name

testing-spec-kit-canon-extension

description

Testing Spec Kit Canon Extension

This folder is the canonical shared skill source.

Use the shared material from:

./core
./scripts
./assets

Shared Rules

Treat core/workflow.md as the canonical workflow.
Treat core/test-flow.md as the canonical prompt and verification reference.
Begin command-driven runs with scripts/prepare_workflow.py so resume versus restart behavior stays consistent across agents.
Use scripts/manage_progress.py to create and update the resumable workflow progress file.
Use scripts/generate_test_report.py to render the final Markdown report from the saved workflow state.
Treat --script sh as the default fresh-run variant unless a command explicitly requests --script ps.
Resume the current workflow by default when the progress file still has pending work.
If the progress file shows the workflow is fully completed, restart from scratch automatically before continuing.
Support a command-level --restart flag that forces a fresh run even when resumable progress exists.
Keep the shared workflow and validation guidance in this skill package.
Treat spec-kit-canon-test as a real git repository. The validation run must leave it in a valid branch/commit state, not just a passing working tree.
Before staging sandbox changes, verify the installed extension copy at .specify/extensions/canon does not contain a nested .git directory. If it does, remove the installed copy's .git metadata before committing the sandbox and note the packaging regression in the source repo.
Before switching branches during the workflow, make sure the progress file at .specify/tmp/testing-spec-kit-canon-extension-progress.json is committed or stashed if git would otherwise block checkout.