ct-writing-plans-prescriptive

Writes prescriptive implementation plans for Control Tower slices that pass plan-contract validation.

1|Updated Sep 8, 2026
One-click install
npx skills add https://github.com/mercadona/control-tower --skill ct-writing-plans-prescriptive-mercadona
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ct-writing-plans-prescriptive
Source: https://github.com/mercadona/control-tower/tree/main/plugin/skills/ct-writing-plans-prescriptive
Command: npx skills add https://github.com/mercadona/control-tower --skill ct-writing-plans-prescriptive-mercadona

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a task-scoped subagent is dispatched for a Control Tower slice, it arrives with zero context and cannot ask questions. This Skill turns the GitHub issue into a prescriptive plan that closes every decision (names, signatures, typed errors, constants, test names, exact commands) while leaving function bodies to test-driven development, so the plan passes the machine-checked plan-contract validation. ## Core Features & Use Cases - Fixed 9-section plan structure: Enforces a strict template with closed decisions, reference patterns, inventory, interfaces, test strategy, tasks, global verification, and assumptions. - Labelled code block taxonomy with budgets: Current state (12 lines), Contract (25 lines), Call site (10 lines), and Final text (12 lines) blocks, capped at 30 lines per task and 3500 characters per task. - Machine-checked literality and language rules: Every quoted current state must exist verbatim in the repo, verification commands must be exit-code predicates, and prose must follow Simplified Technical English rules validated by --check-plan. - Use Case: You are dispatched for issue #42 of a TypeScript monorepo slice. You read the issue and conventions, copy the plan template, write one task at a time running dispatch-check --check-plan after each, then commit the plan as the branch's first commit and post it as an issue comment. ## Quick Start Use the writing-plans-prescriptive skill to turn the dispatched Control Tower issue into a validated prescriptive slice plan before touching any production code.

Frequently Asked Questions about ct-writing-plans-prescriptive

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a Control Tower slice plan that passes plan-contract validation?

Copy the plan template, fill sections 1-6 from the issue, then write one task at a time running dispatch-check --check-plan after each. Every task needs labelled blocks within budget, a TDD test name, and predicate verification commands, and the plan must be committed as the branch's first commit.

What code block labels does the plan validator enforce?

The validator enforces four labels: Current state (12 lines, verbatim from the repo), Contract (25 lines, declarations only), Call site (10 lines), and Final text (12 lines, text artifacts only). Blocks total 30 lines per task, and each task fits within 3500 characters.

Why does --check-plan reject my verification command?

The gate scores verification blocks by exit code alone, so every command must be a predicate whose exit code is the claim. A bare grep -c exits 0 on any match, so wrap counts in test, for example test "$(... | grep -c 'x')" -eq 0.

Can a plan cite files that the slice itself rewrites?

Yes. The --check-plan gate reads the working tree while --release reads the base of the branch, so a Current state citation of a file your tasks later rewrite keeps validating after the work lands. Never relabel a citation as prose to dodge the gate.

What happens when the plan needs a word the STE gate rejects?

The plan prose follows Simplified Technical English with six sub-rules covering sentence length, passive voice, gerunds, and a 47-word non-approved list. If the gate refuses a word the plan genuinely needs, record it in the Assumptions section and stop, since a wrong refusal is a finding for a human.