state-the-target

Rewrite non-goals and exclusions into positive scope statements in specs and prompts.

Updated Nov 18, 2025
One-click install
npx skills add https://github.com/cajias/claude-skills --skill state-the-target
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: state-the-target
Source: https://github.com/cajias/claude-skills/tree/main/plugins/dev-process/skills/state-the-target
Command: npx skills add https://github.com/cajias/claude-skills --skill state-the-target

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you write specs, PRDs, design docs, READMEs, and agent prompts in a way that clearly states what should happen, instead of confusing readers with what should not happen.

Core Features & Use Cases

  • Positive scope framing: Rewrites exclusions and anti-goals into clear scope statements and future directions.
  • Prompt and doc improvement: Helps avoid misleading "is not" language in system prompts, requirements, and design notes.
  • Useful for team writing: Supports product, engineering, and AI workflow documents that need precise, actionable guidance.

Quick Start

Ask the Skill to rewrite your draft so it states the desired target positively and removes anti-goal wording.

Frequently Asked Questions about state-the-target

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

FAQPage Schema
How do I rewrite specs and PRDs to state desired outcomes positively?

To rewrite specs and PRDs positively, convert non-goals, out-of-scope sections, and exclusionary framing into clear scope statements and future directions. This preserves the original intent while providing actionable guidance for AI readers.

Why does using "is not" and anti-goal language confuse AI agent prompts?

Using "is not" and anti-goal language confuses AI agent prompts because identity negations and exclusionary framing fail to provide actionable guidance. AI readers need explicit positive guarantees and scope statements to execute instructions accurately.

What's the best way to convert non-goals and out-of-scope sections in design docs?

The best way to convert non-goals and out-of-scope sections in design docs is to reframe them as future directions or positive scope boundaries. This preserves the original boundaries while ensuring the document states desired outcomes clearly.

Can I use positive scope framing for team engineering and product docs?

Yes, you can use positive scope framing for team engineering and product docs. It supports precise, actionable guidance in requirements, design notes, and PRDs, ensuring both human collaborators and AI agents understand the target outcomes.

When should I fix exclusionary framing in README scope sections?

You should fix exclusionary framing in README scope sections when documents contain non-goals, identity negations, or exclusionary language. Rewriting these boundaries into positive guarantees prevents misinterpretation by both human readers and AI agents.

Does rewriting prompt boundaries into scope statements lose original intent?

No, rewriting prompt boundaries into scope statements does not lose original intent. The process explicitly preserves the original boundaries by converting exclusions into positive guarantees and future directions without dropping the original constraints.