Claude Cursor GitHub Copilot Skill

communication-style

This skill should be used when generating spec artifacts (research.md, requirements.md, design.md, tasks.md), formatting agent output, structuring phase results, or when any Ralph agent needs guidance on concise, scannable output formatting. Applies to all Ralph spec phase agents

LLM Mart · 0 points · 17 70 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download tzachbon-smart-ralph-plugins_ralph-specum_skills_communication-style-4890dd3.zip · 2 KB

tzachbon/smart-ralph 545 48 forks MIT Updated 8d ago

Part of tzachbon/smart-ralph — 44 skills

Install

skills CLI npx skills add https://github.com/tzachbon/smart-ralph/tree/main/plugins/ralph-specum/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

Be extremely concise. Sacrifice grammar for concision.

Rationale

Plans should not be novels
Terminal reads bottom-up
Scanning beats reading
Fewer 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

Action steps appear last because terminal output is read bottom-up -- the most important content occupies the most visible position.

## Next Steps

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

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

References

references/examples.md -- Bad vs good output examples for each spec phase (research, requirements, design, tasks)

Files (smart-ralph)

references

examples.md 1.9 KB

# Output Examples by Phase

## Research Phase

### 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.
```

### 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
```

## Requirements Phase

### Bad (verbose)
```
As a user, I would like to be able to log into the system so that I
can access my personal dashboard and view my data in a secure manner.
The system should validate my credentials against the database.
```

### Good (concise)
```
**US-1: User Login**
- Actor: Registered user
- Action: Authenticate via email/password
- Outcome: Access personal dashboard
- AC: Valid creds -> JWT token + redirect to /dashboard
- AC: Invalid creds -> 401 + error message
```

## Design Phase

### Bad (verbose)
```
The authentication module will be responsible for handling all aspects
of user authentication including login, logout, token refresh, and
session management. It will communicate with the database layer.
```

### Good (concise)
```
## Auth Module

| Component | Responsibility | Interface |
|-----------|---------------|-----------|
| LoginHandler | Validate credentials | POST /auth/login |
| TokenService | Issue/refresh JWT | generateToken(), refreshToken() |
| AuthMiddleware | Guard protected routes | verifyToken() |
```

## Tasks Phase

### Bad (verbose)
```
The first task will be to create the authentication module directory
structure and set up the necessary files. After that, we will need
to implement the login endpoint and write tests for it.
```

### Good (concise)
```
- [ ] 1.1 Create auth module at src/auth/
  - **Do**: mkdir src/auth, create index.ts, types.ts
  - **Verify**: `ls src/auth/`
  - **Commit**: `feat(auth): scaffold auth module`
```

SKILL.md 2.2 KB

---
name: communication-style
description: This skill should be used when generating spec artifacts (research.md, requirements.md, design.md, tasks.md), formatting agent output, structuring phase results, or when any Ralph agent needs guidance on concise, scannable output formatting. Applies to all Ralph spec phase agents.
version: 0.2.0
user-invocable: false
---

# Communication Style

Be extremely concise. Sacrifice grammar for concision.

## Rationale

- Plans should not be novels
- Terminal reads bottom-up
- Scanning beats reading
- Fewer 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

Action steps appear last because terminal output is read bottom-up -- the most important content occupies the most visible position.

```markdown
## Next Steps

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

### 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 |

## References

- **`references/examples.md`** -- Bad vs good output examples for each spec phase (research, requirements, design, tasks)