Creating Briefs

Creating Briefs

Purpose

This skill teaches the craft of writing effective briefs — transforming unstructured, often vague requests into clear, bounded, actionable specifications that downstream agents can execute against.

A good brief establishes common understanding between requester and executor by:

• Capturing exactly what was intended (not what was literally said)
• Extracting concrete requirements from applicable standards
• Defining clear boundaries and measurable success criteria
• Creating a verifiable specification where the requester can read it and say "yes, this is what I meant"

This skill covers all brief types (artefact briefs, research briefs) using a consistent requirements-extraction methodology.

Core Principles

Outcomes, not solutions — A brief defines WHAT we want to achieve, not HOW to execute it. State the desired outcome and let the executor determine the approach. Prescribe solutions only when there's a specific constraint that requires it.

Context is never assumed — Don't assume the executor knows the project history, has read previous work, or understands the bigger picture. State context explicitly. Better to over-communicate than leave critical gaps. The executor might be a different agent, a future version of yourself, or a human who wasn't present for earlier conversations.

Fit for purpose AND fit for audience — The brief must enable work that serves its intended purpose and is appropriate for its audience. An artefact for the orchestrator needs different structure than one for a human developer. Always specify who will use the deliverable.

When to Use This Skill

Use this skill when:

• You receive an unstructured request that needs clarification before work begins
• The task must meet specific quality standards (Skills, style guides, frameworks)
• The request is non-trivial (3+ distinct steps or multiple quality dimensions)
• You need to create shared quality expectations between requester and executor
• The task has unclear boundaries or success criteria

Skip this skill when:

• The task is trivial (single file edit, simple clarification)
• No quality standards exist or apply
• The work is purely exploratory with undefined outcomes
• The request is already well-specified with clear requirements

Inputs Required

1. Unstructured request - What the requester wants created, researched, or modified (may be vague, incomplete, or ambiguous)
2. Applicable standards - Which Skills, style guides, or frameworks govern quality for this type of work (e.g., writing-skills for skill creation, conducting-research for research tasks)
3. Basic context (if provided) - Existing files, constraints, dependencies, or background information
4. Clarifications (if needed) - Answers to questions that eliminate ambiguity in the request

Outputs Produced

A brief file (typically brief.md) containing:

• Why this work matters (the purpose and bigger picture)
• Clear task objective (one sentence capturing intended outcome)
• Target audience (who will use the deliverable)
• Requirements extracted from applicable standards (5-12 checkboxes grouped by source)
• Constraints and boundaries (scope limits, format requirements, dependencies)
• Success criteria (measurable outcomes that define completion)
• References to relevant materials (skills, previous work, examples)
• Optional context (research findings, background decisions)

Typical length: 50-150 lines depending on task complexity.

Workflow

Step 1: Clarify the Request

Before writing anything, ensure you understand what's being asked AND why it matters.

Extract from the request:

• Core intent - What outcome does the requester actually want? (Look beyond literal words to underlying need)
• Purpose - Why does this work matter? Where does it fit in the bigger picture? What problem does it solve?
• Scope boundaries - What's included vs excluded? Where does this task end?
• Success vision - How will the requester know it's done correctly?
• Audience - Who will use the output? (orchestrator, specific agent, user, other humans)
• Ambiguities - What assumptions are you making that might be wrong?

The WHY question is critical — Without understanding purpose, the executor might do technically correct work that serves the wrong goal. Example: "research feedback methodologies" could mean feedback for users, for code reviews, or for critic skills. The purpose clarifies which domain matters.

Don't assume the executor has context you possess — They might not have read previous work, attended earlier discussions, or know the project's history. If background matters, you must state it explicitly in the brief.

If critical information is missing, ask targeted questions:

• "You mentioned X — does that include Y and Z, or just X specifically?"
• "When you say 'comprehensive', do you mean covering all edge cases, or just the common scenarios?"
• "Should this handle A, or can we exclude that for now?"
• "Who's the primary audience — will this be used by agents, users, or both?"
• "Where does this fit in the bigger picture? Why are we doing this now?"

Output: Mental model (or notes) capturing what's actually being requested, why it matters, and who it's for.

Step 2: Identify Applicable Standards

Determine which quality standards govern this type of work.

For artefact briefs:

• If creating/updating a Skill → writing-skills applies
• If creating documentation → relevant style guide or documentation standards
• If creating code → code quality standards, architectural guidelines
• If creating workflow → workflow standards, process frameworks

For research briefs:

• conducting-research skill (requirements extraction methodology)
• verifying-claims skill (if fact-checking needed)
• Domain-specific research standards (if applicable)

Multiple standards may apply — e.g., a research brief about skill quality might reference both conducting-research and writing-skills.

Output: List of 1-3 applicable standards with file paths or references.

Step 3: Write the Brief Header

Start with metadata that frames the task, explains why it matters, and identifies the audience.

Template:

# Brief: [Task Name]

**Created:** YYYY-MM-DD
**Objective:** [One sentence describing the intended outcome]
**Audience:** [Who will use the deliverable]
**Applicable Standards:** [List of standards/skills that define quality]

## Why

[2-4 sentences explaining:
- Why this work matters
- Where it fits in the bigger picture
- What problem it solves or what goal it serves]

Why section guidance:

• Be concise (2-4 sentences) but establish the big picture
• Explain purpose, not mechanics (GOOD: "We're building a critic skill that needs structured feedback principles" / PROBLEMATIC: "This will help us create better documentation")
• Connect to broader goals (GOOD: "This supports the Producer-Critic-Learner workflow by enabling quality assessment" / PROBLEMATIC: "We need this for the project")
• Provide context the executor might not have (GOOD: "Previous research showed 3 patterns; we're implementing the multi-file approach" / PROBLEMATIC: "Continue the previous work")

Objective crafting tips:

• State the outcome, not the activity (GOOD: "Enable agents to write well-structured briefs" / PROBLEMATIC: "Create a briefing skill")
• Be specific enough to verify (GOOD: "Produce API docs QA can test without questions" / PROBLEMATIC: "Document the API")
• Use verifiable language (enable, produce, achieve) not aspirational language (improve, enhance, support)

Audience specification:

• Be specific (GOOD: "producer-agent" / PROBLEMATIC: "agents")
• Consider how audience affects requirements (documentation for users needs different clarity than documentation for orchestrators)
• State audience explicitly even if it seems obvious — what's obvious to you may not be to the executor

Output: Brief header that captures intent, purpose, and audience clearly.

Step 4: Extract Requirements from Standards (Core Step)

This is the most critical step — it creates shared quality expectations and prevents compliance gaps.

For each applicable standard:

1. Read the standard's quality checklist (or Evaluation Scenarios section if no explicit checklist exists)
2. Select 5-12 relevant requirements that directly apply to this specific task
3. Ignore irrelevant criteria — if the standard has 20 requirements but only 8 apply to this task, extract only those 8
4. Rephrase for clarity if needed, but preserve the substance of the requirement
5. Structure as checkboxes grouped by source:

Template:

## Requirements Extracted from Standards

**From [standard-name-1]:**
- [ ] Requirement 1 (specific, verifiable)
- [ ] Requirement 2 (specific, verifiable)
- [ ] Requirement 3 (specific, verifiable)

**From [standard-name-2]:**
- [ ] Requirement 4 (specific, verifiable)
- [ ] Requirement 5 (specific, verifiable)

Why this matters:

• Executor references requirements during creation → higher first-draft compliance (research shows 87-90% when standards explicit vs ~60% when implied)
• Reviewer uses same requirements as rubric → consistent evaluation
• Both parties share quality expectations → faster convergence, fewer iteration cycles
• Requirements become objective checklist, not subjective judgement

Common mistakes:

• Extracting ALL requirements from standard when only subset applies (creates noise)
• Writing vague requirements ("must be good quality" vs "must include 3+ realistic examples")
• Mixing requirements with context or background (keep requirements actionable)
• Forgetting to group by source (makes validation harder)

Output: 5-12 checkbox requirements extracted from standards, grouped by source.

Step 5: Define Constraints and Boundaries

Add specific limits that clarify scope.

Constraints typically include:

• Format - File type, structure, template (e.g., "Single Markdown file", "JSON schema", "Multi-file package")
• Length - Target size or limits (e.g., "200-250 lines", "Under 5 pages", "3-5 examples minimum")
• Dependencies - What must exist or be referenced (e.g., "Must reference existing authentication module")
• Exclusions - What's explicitly out of scope (e.g., "Does not cover error handling")
• Technical constraints - Tools, languages, platforms (e.g., "Python 3.10+", "Must work offline")

Template:

## Constraints

- Format: [Specific format requirement]
- Length: [Target or range]
- Dependencies: [What must exist or be used]
- Out of scope: [What's explicitly excluded]

Keep this minimal — typically 3-6 constraints. If you have more, the scope may be unclear or too broad.

Focus on WHAT is required, not HOW to achieve it — Unless there's a specific constraint (e.g., "must use existing authentication library"), let the executor determine the approach.

Output: Clear scope boundaries that prevent misunderstandings.

Step 6: Define Measurable Success Criteria

State how to verify the brief is satisfied.

Good success criteria are:

• Measurable - Can be checked objectively (GOOD: "QA can test all endpoints without questions" / PROBLEMATIC: "Documentation is comprehensive")
• Outcome-focused - State what's achieved, not how (GOOD: "Developer can integrate in under 30 minutes" / PROBLEMATIC: "Guide includes step-by-step instructions")
• Verifiable by requester - The person who asked can check it (GOOD: "All requirements from standards met" / PROBLEMATIC: "Code follows best practices")

Remember the outcomes principle — Success criteria should describe the achieved state, not the implementation method. Let the executor determine the path.

Template:

## Success Criteria

The deliverable is complete when:
1. [Specific, measurable outcome]
2. [Another measurable outcome]
3. All requirements from standards are met (always include this as final criterion)

Typically 2-4 criteria — one covering the core outcome, one covering compliance, optionally 1-2 covering specific concerns.

Output: 2-4 verifiable success statements.

Step 7: Include References and Add Context

Provide references to materials the executor needs, then add any additional context.

References are mandatory when provided — If the orchestrator gave you relevant skills, previous research, existing artefacts, or examples, you MUST include them. They're not optional nice-to-haves; they're inputs the executor needs.

Template:

## References

**Skills:** [Path to skill files that inform this work]
**Previous work:** [Path to research files, earlier versions, related artefacts]
**Examples:** [Path to reference implementations or templates]
**Background materials:** [Any other relevant resources]

## Context

**Research findings:** [Link to research file if relevant]
**Background decisions:** [Choices already made that constrain the approach]
**Known risks:** [Issues or challenges the executor should anticipate]

Context guidance:

• Include background information the executor needs but might not have
• Don't assume they've read previous work — summarise key points or link to files
• State decisions already made that affect the approach
• Highlight risks or challenges to anticipate
• Apply "Just Barely Good Enough" principle — include what's needed, omit speculation

What NOT to include:

• Speculation ("the user might want...")
• Obvious information ("code should be readable")
• Disguised requirements (put those in requirements section)
• "Nice to know" information — only "need to know"

Output: References section with mandatory materials; Context section with 2-5 bullet points of directly relevant background, or omit Context entirely if none exists.

Step 8: Establish Common Understanding (Validation)

Before considering the brief complete, validate it creates shared understanding.

Self-review questions:

• If the requester reads this brief, will they recognise it as capturing their intent?
• If the executor reads this brief, can they start work without clarification questions?
• Does the WHY section explain purpose clearly enough that the executor understands the bigger picture?
• Is the audience specified so the executor knows who they're creating for?
• Are success criteria measurable by someone other than the executor?
• Are requirements specific enough to be checkboxes (not interpretive guidelines)?
• Are constraints realistic and necessary (not aspirational or nice-to-haves)?
• Are references included for all materials the orchestrator provided?
• Is context sufficient that the executor doesn't need to assume background knowledge?

If validation reveals gaps:

• Ambiguous requirements → Clarify with requester or make reasonable assumptions (document them)
• Unmeasurable success criteria → Rephrase to be objective and verifiable
• Unclear scope → Add explicit boundary constraints
• Missing purpose → Add or strengthen WHY section
• Missing context → Add background the executor needs
• Solution prescribed unnecessarily → Rephrase to focus on outcome

Common understanding principle: A technically perfect brief that doesn't match what was requested is a failure. The brief succeeds when both requester and executor recognise it as correct.

Output: Validated brief ready for handoff to executor.

Template

Use this structure for most briefs (adapt as needed):

# Brief: [Task Name]

**Created:** YYYY-MM-DD
**Objective:** [One sentence outcome that's verifiable]
**Audience:** [Who will use the deliverable]
**Applicable Standards:** [Standards/skills that define quality]

## Why

[2-4 sentences explaining why this work matters, where it fits in the bigger picture, and what problem it solves or goal it serves]

## Requirements Extracted from Standards

**From

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [isvlasov](https://github.com/isvlasov)
- **Source:** [isvlasov/rageatc-oss](https://github.com/isvlasov/rageatc-oss)
- **License:** MIT

Install and usage instructions live in the source repository linked above.