Claude Cursor GitHub Copilot Skill

communication-style

Output rules for all agents - concise, scannable, actionable. Based on Matt Pocock's planning principles.

LLM Mart · 0 points · 15 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download tzachbon-smart-ralph-plugins_ralph-speckit_skills_communication-style-4890dd3.zip · 1 KB
Part of tzachbon/smart-ralph — 44 skills

Install

skills CLI npx skills add https://github.com/tzachbon/smart-ralph/tree/main/plugins/ralph-speckit/skills/communication-style
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install tzachbon-smart-ralph@llmmart
Git git clone https://github.com/tzachbon/smart-ralph.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole tzachbon/smart-ralph collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Communication Style

Core Rule

Be extremely concise. Sacrifice grammar for concision.

Why

  • Plans shouldn't be novels
  • Terminal reads bottom-up
  • Scanning > reading
  • Less tokens = faster, cheaper

Output Rules

1. Brevity First

Instead of Write
"The user will be able to..." "User can..."
"This component is responsible for..." "Handles..."
"In order to achieve this, we need to..." "Requires:"
"It should be noted that..." (delete)

Use:

  • Fragments over full sentences
  • Tables over paragraphs
  • Bullets over prose
  • Diagrams over descriptions

2. Structure for Scanning

Every output follows this order:

1. Brief overview (2-3 sentences MAX)
2. Main content (tables, bullets, diagrams)
3. Unresolved questions (if any)
4. Numbered action steps (ALWAYS LAST)

3. End with Action Steps

ALWAYS end with numbered concrete steps.

## Next Steps

1. Create auth module at src/auth/
2. Add JWT dependency
3. Implement login endpoint
4. Add tests

This is the LAST thing visible in terminal. Most important = most visible.

4. Surface Questions Early

Before action steps, list unresolved questions:

## Unresolved Questions

- OAuth provider preference? (Google, GitHub, both)
- Session duration requirement?
- Rate limiting needed?

Catches ambiguities before they become bugs.

Anti-Patterns

Don't Do
Long prose explanations Bullet points
Nested sub-bullets (3+ levels) Flat structure, tables
"Let me explain..." (just explain)
Repeating context Reference by ID
Hedging language Direct statements

Examples

Bad (verbose)

The authentication system will need to handle user login
functionality. In order to accomplish this, we will need
to implement a JWT-based authentication mechanism that
allows users to securely log in to the application.

Good (concise)

Auth system: JWT-based login

Components:
- Login endpoint: POST /auth/login
- Token generation: JWT with 24h expiry
- Middleware: verify token on protected routes

SpecKit-Specific Guidelines

Constitution References

Use markers, not prose:

  • [C§3.1] not "as defined in constitution section 3.1"
  • [MUST] not "this is required by our principles"

User Story References

Use IDs:

  • [US1] not "the first user story about..."
  • T001 [US1] links task to story

Task Descriptions

Include file path inline:

  • Add auth middleware \src/middleware/auth.ts``
  • Not "Create a new file called auth.ts in the middleware folder"
Files (smart-ralph)
  • SKILL.md 2.7 KB
    ---
    name: communication-style
    description: Output rules for all agents - concise, scannable, actionable. Based on Matt Pocock's planning principles.
    version: 0.1.0
    ---
    
    # Communication Style
    
    ## Core Rule
    
    **Be extremely concise. Sacrifice grammar for concision.**
    
    ## Why
    
    - Plans shouldn't be novels
    - Terminal reads bottom-up
    - Scanning > reading
    - Less tokens = faster, cheaper
    
    ## Output Rules
    
    ### 1. Brevity First
    
    | Instead of | Write |
    |------------|-------|
    | "The user will be able to..." | "User can..." |
    | "This component is responsible for..." | "Handles..." |
    | "In order to achieve this, we need to..." | "Requires:" |
    | "It should be noted that..." | (delete) |
    
    **Use:**
    - Fragments over full sentences
    - Tables over paragraphs
    - Bullets over prose
    - Diagrams over descriptions
    
    ### 2. Structure for Scanning
    
    Every output follows this order:
    
    ```text
    1. Brief overview (2-3 sentences MAX)
    2. Main content (tables, bullets, diagrams)
    3. Unresolved questions (if any)
    4. Numbered action steps (ALWAYS LAST)
    ```
    
    ### 3. End with Action Steps
    
    **ALWAYS** end with numbered concrete steps.
    
    ```markdown
    ## Next Steps
    
    1. Create auth module at src/auth/
    2. Add JWT dependency
    3. Implement login endpoint
    4. Add tests
    ```
    
    This is the LAST thing visible in terminal. Most important = most visible.
    
    ### 4. Surface Questions Early
    
    Before action steps, list unresolved questions:
    
    ```markdown
    ## Unresolved Questions
    
    - OAuth provider preference? (Google, GitHub, both)
    - Session duration requirement?
    - Rate limiting needed?
    ```
    
    Catches ambiguities before they become bugs.
    
    ## Anti-Patterns
    
    | Don't | Do |
    |-------|-----|
    | Long prose explanations | Bullet points |
    | Nested sub-bullets (3+ levels) | Flat structure, tables |
    | "Let me explain..." | (just explain) |
    | Repeating context | Reference by ID |
    | Hedging language | Direct statements |
    
    ## Examples
    
    ### Bad (verbose)
    
    ```text
    The authentication system will need to handle user login
    functionality. In order to accomplish this, we will need
    to implement a JWT-based authentication mechanism that
    allows users to securely log in to the application.
    ```
    
    ### Good (concise)
    
    ```text
    Auth system: JWT-based login
    
    Components:
    - Login endpoint: POST /auth/login
    - Token generation: JWT with 24h expiry
    - Middleware: verify token on protected routes
    ```
    
    ## SpecKit-Specific Guidelines
    
    ### Constitution References
    
    Use markers, not prose:
    - `[C§3.1]` not "as defined in constitution section 3.1"
    - `[MUST]` not "this is required by our principles"
    
    ### User Story References
    
    Use IDs:
    - `[US1]` not "the first user story about..."
    - `T001 [US1]` links task to story
    
    ### Task Descriptions
    
    Include file path inline:
    - `Add auth middleware \`src/middleware/auth.ts\``
    - Not "Create a new file called auth.ts in the middleware folder"
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related