원클릭으로 Manus에서 모든 스킬 실행

canary-lab-author

스타3

포크0

업데이트2026년 7월 10일 01:09

Use when creating or extending a Canary Lab feature by hand — "create a feature for X", "add test cases to <feature>", "capture the env files", "switch the feature's branch" — through the author MCP tools (create_feature, capture_feature_env_files, write_envset, start/update/apply_external_draft, get_feature_repo_status, checkout_feature_repo_branch). For docs/PRD/coverage use canary-lab-coverage; for full onboarding of a bare repo use canary-lab (flight).

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

ferterahadi

ferterahadi/canary-lab

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Canary Lab — Feature Authoring

This client writes the specs; Canary Lab is the control plane and artifact store. These tools arrive via the Canary Lab MCP server. If this client is already connected (the plugin connects with full), skip this step. To configure a connection manually: npx canary-lab mcp --profile author (the composite lifecycle/full profiles carry the same tools).

Workspace Bootstrap

Read ~/.canary-lab/workspaces.json (Windows: %USERPROFILE%\.canary-lab\workspaces.json); one workspace → use it, several → ask which, none → ask the user to run npx canary-lab setup.
Check /mcp/health on the UI's port: read port from the workspace's canary-lab.config.json (fallback 7421), then curl -s http://127.0.0.1:<port>/mcp/health — success is a JSON response. Confirm projectRoot matches the selected workspace.
If the health check fails, start npx canary-lab ui from the workspace in a visible long-running terminal; if this client cannot run long-lived commands, ask the user to run npx canary-lab ui from the workspace and confirm when it's up.
Do not reflexively call list_features or list_runs after health. For random or new feature creation, call create_feature directly with a unique feature name; use list_features only to discover or choose an existing feature.

Create or Extend a Feature

For random or new feature creation, call create_feature directly with a unique feature name. It creates the skeleton files and returns test-file rules, envset schema, and next-step tool hints. Do not call list_features just to avoid collisions; if the chosen name already exists, retry create_feature with a different unique name.
If the user asks to preserve existing .env, .env.dev, application.properties, or similar repo config files, inspect the source repo enough to identify the files, then call capture_feature_env_files. Do not paste secret values into chat; Canary Lab returns redacted previews only. write_envset fills in or corrects individual envset values (it is confirm-gated).
Author or edit specs under <workspace>/features/<feature>/e2e/ — the Canary Lab WORKSPACE, not the product repo under test.

Specs must import:

import { test, expect } from 'canary-lab/feature-support/log-marker-fixture'

Call start_external_draft with a stable session_id and a useful conversation_name (do not pass client_kind — the bridge auto-detects it). This only creates a visible Canary Lab task so the user sees that this external client is authoring tests; it does not start an internal wizard agent. Carry the draftId it returns into every subsequent update_external_draft_stage / apply_external_draft call for this draft.
After start_external_draft returns, tell the user you are authoring tests and they can wait in this external client. Continue writing specs locally, then call update_external_draft_stage(draftId, stage) as work progresses: scaffolding, authoring-tests, validating, ready, applied, or error.
Call apply_external_draft with draftId, confirm: true, and files: [{path, content}, …] for the externally authored files (omit files if you already wrote them directly under <workspace>/features/<feature>/e2e/ — it then validates what's on disk), so Canary Lab validates and records the applied draft. Do not ask Canary Lab to spawn another Claude/Codex agent for MCP-created authoring. On a validation error, fix the named file and re-call apply_external_draft.
get_feature_repo_status / checkout_feature_repo_branch inspect and switch the feature's bound repo branches when the user asks to test a different branch.

Guardrails

Keep the same session_id for the whole conversation.
Canary Lab never writes the test body for external authoring — this client does.
After authoring, the natural next steps live in sibling skills: map coverage (canary-lab-coverage), run + heal (canary-lab-run), export the evaluation (canary-lab-export).

이 저장소의 다른 Skills

같은 저장소

canary-lab-coverage

ferterahadi/canary-lab

Use when working the Canary Lab semantic coverage ledger — "what's actually tested?", "map coverage for <feature>", "refresh the PRD summary", "close the coverage gaps", "add this plan/spec to the feature docs" — through the coverage MCP tools (write/list/delete_feature_doc, start/submit_external_summary, start/submit_external_coverage, get_feature_coverage, clear_prd_summary). For writing new tests use canary-lab-author.

2026-07-103

canary-lab-export

ferterahadi/canary-lab

Use when exporting a Canary Lab run as an evaluation — "export the evaluation", "produce the report for run 7cvh", "give me the evaluation archive", "review what the run proved" — through the export MCP tools (start/submit_external_evaluation_export, get/list/download_evaluation_export). The run must be terminal (passed, failed, or aborted).

2026-07-103

canary-lab-portify

ferterahadi/canary-lab

Use when making a Canary Lab feature concurrency-ready — "portify <feature>", "make the ports injectable", "why can't these run concurrently", "undo the portification" — through the portify MCP tools (start/submit_external_portify, get_portify, save_portify, cancel_portify, remove_portification, list_portify_status).

2026-07-103

canary-lab-run

ferterahadi/canary-lab

Use when running or healing an EXISTING Canary Lab feature locally — "run <feature>", "fix the failing run", "rerun 7cvh", "drive the heal loop" — through the repair MCP tools (start_run, wait_for_heal_task, signal_run, get_heal_context, pause_run, cancel_heal, abort_run). Fix failing runs by editing app/service code, not tests. For end-to-end onboarding of a new repo use canary-lab (flight); for deployed-environment checks use canary-lab-verify.

2026-07-103

canary-lab

ferterahadi/canary-lab

Use when the user wants Canary Lab to take a product repo end to end — "test this app", "onboard this repo", "run a flight", "evaluate what I just built" — through the flight pipeline (start_flight / get_flight / respond_flight_checkpoint over MCP). One conducted background pipeline goes from bare repo(s) to a green, covered, healed run ending in an evaluation export. For a single capability use the focused skills instead — canary-lab-run (run + heal), canary-lab-verify (deployed-env verification), canary-lab-author (create feature + specs), canary-lab-coverage (PRD summary + coverage ledger), canary-lab-portify (concurrency-readiness), canary-lab-export (evaluation export).

2026-07-103

canary-lab-verify

ferterahadi/canary-lab

Use when verifying a Canary Lab feature against a DEPLOYED environment (staging/production URL) — "verify checkout on staging", "run the saved verify config", "check the deployed app" — through the verify MCP tools (list/get/create/update_verification_config, execute_verification, get_verification_result). No local boot, no heal loop. For local run + heal use canary-lab-run; for end-to-end onboarding use canary-lab (flight).

2026-07-103

name	canary-lab-author
description	Use when creating or extending a Canary Lab feature by hand — "create a feature for X", "add test cases to <feature>", "capture the env files", "switch the feature's branch" — through the author MCP tools (create_feature, capture_feature_env_files, write_envset, start/update/apply_external_draft, get_feature_repo_status, checkout_feature_repo_branch). For docs/PRD/coverage use canary-lab-coverage; for full onboarding of a bare repo use canary-lab (flight).
type	skill

Canary Lab — Feature Authoring

Workspace Bootstrap

Read ~/.canary-lab/workspaces.json (Windows: %USERPROFILE%\.canary-lab\workspaces.json); one workspace → use it, several → ask which, none → ask the user to run npx canary-lab setup.
Check /mcp/health on the UI's port: read port from the workspace's canary-lab.config.json (fallback 7421), then curl -s http://127.0.0.1:<port>/mcp/health — success is a JSON response. Confirm projectRoot matches the selected workspace.
If the health check fails, start npx canary-lab ui from the workspace in a visible long-running terminal; if this client cannot run long-lived commands, ask the user to run npx canary-lab ui from the workspace and confirm when it's up.
Do not reflexively call list_features or list_runs after health. For random or new feature creation, call create_feature directly with a unique feature name; use list_features only to discover or choose an existing feature.

Create or Extend a Feature

For random or new feature creation, call create_feature directly with a unique feature name. It creates the skeleton files and returns test-file rules, envset schema, and next-step tool hints. Do not call list_features just to avoid collisions; if the chosen name already exists, retry create_feature with a different unique name.
If the user asks to preserve existing .env, .env.dev, application.properties, or similar repo config files, inspect the source repo enough to identify the files, then call capture_feature_env_files. Do not paste secret values into chat; Canary Lab returns redacted previews only. write_envset fills in or corrects individual envset values (it is confirm-gated).
Author or edit specs under <workspace>/features/<feature>/e2e/ — the Canary Lab WORKSPACE, not the product repo under test.

Specs must import:

import { test, expect } from 'canary-lab/feature-support/log-marker-fixture'

Call start_external_draft with a stable session_id and a useful conversation_name (do not pass client_kind — the bridge auto-detects it). This only creates a visible Canary Lab task so the user sees that this external client is authoring tests; it does not start an internal wizard agent. Carry the draftId it returns into every subsequent update_external_draft_stage / apply_external_draft call for this draft.
After start_external_draft returns, tell the user you are authoring tests and they can wait in this external client. Continue writing specs locally, then call update_external_draft_stage(draftId, stage) as work progresses: scaffolding, authoring-tests, validating, ready, applied, or error.
Call apply_external_draft with draftId, confirm: true, and files: [{path, content}, …] for the externally authored files (omit files if you already wrote them directly under <workspace>/features/<feature>/e2e/ — it then validates what's on disk), so Canary Lab validates and records the applied draft. Do not ask Canary Lab to spawn another Claude/Codex agent for MCP-created authoring. On a validation error, fix the named file and re-call apply_external_draft.
get_feature_repo_status / checkout_feature_repo_branch inspect and switch the feature's bound repo branches when the user asks to test a different branch.

Guardrails

Keep the same session_id for the whole conversation.
Canary Lab never writes the test body for external authoring — this client does.
After authoring, the natural next steps live in sibling skills: map coverage (canary-lab-coverage), run + heal (canary-lab-run), export the evaluation (canary-lab-export).