Problem Statement / Background
Many skills require project-specific inputs (e.g., target staging URL, database branch, test coverage threshold). Hardcoding these in static markdown forces teams to create duplicated variations of the same skill.
Inspiration from State-of-the-Art Tools
cookiecutter, copier, and jinja2 allow declarative parameter schemas with default values, validation regexes, and interactive prompts.
Proposed Solution & Architecture
- Support
parameters block in frontmatter:
parameters:
min_coverage: { type: int, default: 80, help: "Minimum test coverage %" }
framework: { type: string, choices: [pytest, jest, vitest] }
- When running or compiling with
cinch sync --interactive, prompt the developer for values or load from .cinch.env.
- Render variables using safe stdlib string templates or Jinja2 syntax.
Acceptance Criteria & Test Plan
Problem Statement / Background
Many skills require project-specific inputs (e.g., target staging URL, database branch, test coverage threshold). Hardcoding these in static markdown forces teams to create duplicated variations of the same skill.
Inspiration from State-of-the-Art Tools
cookiecutter,copier, andjinja2allow declarative parameter schemas with default values, validation regexes, and interactive prompts.Proposed Solution & Architecture
parametersblock in frontmatter:cinch sync --interactive, prompt the developer for values or load from.cinch.env.Acceptance Criteria & Test Plan
--param min_coverage=90) and environment variables.