readme

어떤 스킬인가요?

Use when creating, updating, or generating README and documentation files for projects and libraries

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

---
disable-model-invocation: true
---

Invoke the readme skill and follow it exactly as presented to you

'use strict';
/**
 * Post-execute hook for readme
 * Auto-generated by enterprise-bundle-scaffolder
 *
 * Records metrics after skill execution.
 */

function postExecute(_context) {
  // Record execution metrics
  return { ok: true, skill: 'readme' };
}

module.exports = { postExecute };

'use strict';
/**
 * Pre-execute hook for readme
 * Auto-generated by enterprise-bundle-scaffolder
 *
 * Validates inputs before skill execution.
 */

function preExecute(context) {
  // Validate skill invocation context
  if (!context || typeof context !== 'object') {
    return { allow: true, message: 'readme: no context to validate' };
  }
  return { allow: true };
}

module.exports = { preExecute };

# Angular Novo Elements .cursorrules prompt file

Author: Dan Donathan

## What you can build

Code Refactoring Tool: Develop an intelligent code refactoring tool that adheres to the principles outlined in the .cursorrules file. This tool can automatically detect code smells, suggest improvements for code simplification, and ensure best practices like DRY, KISS, and the Boy-Scout Rule are applied.Unit Test Generator: Create a tool that automatically generates unit tests for Angular components, ensuring all new code is thoroughly tested before merging. The tool should analyze existing code and create tests that cover a wide range of edge cases.Real-Time Code Review System: Build a platform that provides real-time feedback during code writing, highlighting areas where the principles like YAGNI, Curly’s Law, and the Principle of Least Astonishment can be applied to improve code quality.Angular Component Analyzer: Develop a service that analyzes standalone Angular components and provides insights into their integration with Novo Elements. It should check for best practices, compatibility issues, and optimization opportunities.Code Maintenance Dashboard: Construct a dashboard for tracking the maintainability of a codebase. It should use metrics to evaluate cleanliness, adherence to rules like DRY and Curly’s Law, and offer suggestions for improvement, making code maintenance easier.Project Structure Optimizer: Design a tool that suggests optimal file and directory structures for Angular projects using Novo Elements, ensuring the project remains clear, organized, and free from clutter.Automated Documentation Generator: Develop a generator that creates comprehensive and easy-to-understand documentation for Angular projects, focusing on clarifying code functionality and expected behavior to follow the Principle of Least Astonishment.Debugging Assistant: Create an AI-powered debugging assistant that helps identify and resolve issues by generating detailed logs and providing potential fixes, based on the debugging and testing rules from .cursorrules.Code Quality Checker: Implement a service that checks code against the provided style and formatting guidelines in real-time, ensuring consistent naming conventions and the use of up-to-date libraries.Premature Optimization Detector: Develop a tool that analyzes code for unnecessary optimizations and advises developers on when to focus on critical efficiencies, in line with the concept that premature optimization is the root of all evil.

## Benefits

## Synopsis

This prompt is useful for Angular developers working with standalone components and Novo Elements, providing guidelines to ensure efficient, maintainable code that adheres to modern best practices.

## Overview of .cursorrules prompt

The .cursorrules file outlines a set of coding standards and principles to guide developers in creating optimal, production-ready code. It emphasizes preserving existing code structures, verifying changes, and delivering concise solutions. Key coding principles such as DRY (Don't Repeat Yourself), KISS (Keep It Simple Stupid), and YAGNI (You Aren't Gonna Need It) are highlighted to maintain code quality and avoid unnecessary complexity. It also includes specific rules for debugging, testing, and maintaining project structure, while integrating Angular with standalone components and Novo Elements. The file aims for thorough testing, clear documentation, and minimal diffs in code changes to meet specified project requirements efficiently.

# Research Requirements

- Use Exa first for current best practices.
- Use WebFetch/arXiv fallback when Exa is insufficient.
- Capture constraints and map them to hooks/rules/schemas/workflows.

# readme Rules

## Purpose

Use when creating, updating, or generating README and documentation files for projects and libraries

## Best Practices

- Follow established patterns
- Validate inputs at boundaries

## Integration Points

See SKILL.md for complete documentation.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "readmeInput",
  "description": "Input schema for Use when creating, updating, or generating README and documentation files for projects and libraries",
  "type": "object",
  "additionalProperties": true,
  "properties": {
    "target": {
      "type": "string",
      "description": "Target file or path for the skill to operate on"
    },
    "options": {
      "type": "object",
      "description": "Additional options for skill execution",
      "additionalProperties": true
    }
  }
}

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "readmeOutput",
  "type": "object",
  "additionalProperties": true,
  "properties": {
    "ok": {
      "type": "boolean"
    },
    "summary": {
      "type": "string"
    }
  }
}

#!/usr/bin/env node
/**
 * readme - Rule-based Skill
 * Converted from: README.md
 */

const fs = require('fs');
const path = require('path');

// Parse arguments
const args = process.argv.slice(2);
const options = {};
for (let i = 0; i < args.length; i++) {
  if (args[i].startsWith('--')) {
    const key = args[i].slice(2);
    const value = args[i + 1] && !args[i + 1].startsWith('--') ? args[++i] : true;
    options[key] = value;
  }
}

if (options.help) {
  console.log(`
readme - Code Guidelines Skill

Usage:
  node main.cjs --check <file>    Check a file against guidelines
  node main.cjs --list            List all guidelines
  node main.cjs --help            Show this help

Description:
  Angular Novo Elements .cursorrules prompt file
`);
  process.exit(0);
}

if (options.list) {
  console.log('Guidelines for readme:');
  console.log('See SKILL.md for full guidelines');
  process.exit(0);
}

console.log('readme skill loaded. Use with Claude for code review.');

---
name: readme
description: Use when creating, updating, or generating README and documentation files for projects and libraries
version: 1.1.0
tools:
  - Read
  - Write
  - Edit
  - Grep
  - Glob
verified: true
lastVerifiedAt: 2026-02-22T00:00:00.000Z
source: builtin
trust_score: 100
provenance_sha: 10b7131c57ec2bc5
---

# Readme Skill

<identity>
Readme specialist focused on creating clear, comprehensive README files and project documentation. Helps developers write effective project introductions, setup guides, and usage documentation.
</identity>

<capabilities>
- Generate comprehensive README files from project context
- Create clear installation and setup instructions
- Write usage examples and API documentation
- Document project structure and architecture
- Generate table of contents and navigation
- Create contributing guidelines and troubleshooting sections
- Optimize readability with formatting and visual structure
</capabilities>

## When to Use

Use this skill when:

- Creating a new README or documentation file
- Updating existing README with new features
- Documenting project setup, installation, or configuration
- Writing usage examples and API references
- Generating contributing guidelines or quick-start guides
- Improving documentation clarity and structure

## Core Workflow

### Step 1: Gather Project Information

Analyze the project to understand:

1. **Project Purpose**: What problem does it solve?
2. **Target Audience**: Who are the users (developers, users, contributors)?
3. **Key Features**: What makes this project special?
4. **Technical Stack**: Languages, frameworks, dependencies
5. **Project Structure**: How is code organized?

### Step 2: Create README Structure

Use this standard structure:

```markdown
# Project Name

Brief description (1-2 sentences)

## Features

- Feature 1
- Feature 2
- Feature 3

## Installation

[Setup instructions]

## Quick Start

[Basic usage example]

## Documentation

[Link to detailed docs]

## API Reference

[Key endpoints/functions]

## Examples

[Working examples]

## Configuration

[Setup options]

## Troubleshooting

[Common issues and solutions]

## Contributing

[How to contribute]

## License

[License information]
```

### Step 3: Write Clear Content

- **Be specific**: Use concrete examples, not vague descriptions
- **Show, don't tell**: Include code examples and screenshots
- **Progressive disclosure**: Start simple, add complexity gradually
- **Organize logically**: Group related information
- **Use formatting**: Headers, lists, code blocks for readability

### Step 4: Add Examples

Include practical, working examples:

- Installation examples
- Basic usage snippets
- Complex feature demonstrations
- Common use cases
- Copy-paste ready code

### Step 5: Verify Quality

Check before completing:

- [ ] Clear project purpose in first paragraph
- [ ] Installation instructions are complete
- [ ] Examples are runnable
- [ ] Table of contents matches sections
- [ ] All links work
- [ ] Formatting is consistent
- [ ] No typos or grammar errors

## README Components Reference

### Project Title and Description

```markdown
# Project Name

One-liner explaining what this project does.

Long paragraph (2-3 sentences) describing problem solved and approach.
```

### Features Section

```markdown
## Features

- ✅ Feature with emoji for visual interest
- ✅ Key capability with brief description
- ✅ Unique advantage over alternatives
```

### Installation

```markdown
## Installation

### Requirements

- Node.js 18+
- pnpm 8+

### Steps

\`\`\`bash
pnpm install project-name
\`\`\`
```

### Quick Start

Keep this minimal (5-10 lines of code max):

```markdown
## Quick Start

\`\`\`javascript
import { feature } from 'project-name';

const result = feature({ option: 'value' });
console.log(result);
\`\`\`
```

### Examples

Make examples realistic and copy-paste ready:

```markdown
## Examples

### Basic Usage

\`\`\`typescript
// Simple example with real output
const instance = new MyClass();
instance.doSomething(); // Output: expected result
\`\`\`

### Advanced Configuration

\`\`\`typescript
// Complex example showing options
const instance = new MyClass({
option1: true,
option2: 'value'
});
\`\`\`
```

## Best Practices

1. **Lead with value**: First paragraph should answer "why should I use this?"
2. **Show working examples**: Code examples should be runnable
3. **Keep installation simple**: Complex setup gets a dedicated guide
4. **Document dependencies**: List what's required upfront
5. **Include screenshots**: Visual examples for UI projects
6. **Write for skimmers**: Use headers so people can scan content
7. **Link to detailed docs**: README is overview, link to full documentation
8. **Keep it current**: Update README when adding features
9. **Be honest about limitations**: What's not covered or not supported
10. **Include contributing guidelines**: How to report issues or submit PRs

## Anti-Patterns

| Pattern              | Problem               | Fix                               |
| -------------------- | --------------------- | --------------------------------- |
| Wall of text         | Impossible to scan    | Use headers and lists             |
| Missing setup        | Readers can't install | Include step-by-step instructions |
| No examples          | Unclear how to use    | Add working code examples         |
| Outdated info        | Misleads users        | Update with releases              |
| Too detailed         | Overwhelming          | Link to full docs instead         |
| No table of contents | Hard to navigate      | Add section links at top          |
| Broken links         | Poor user experience  | Test all external links           |
| Marketing fluff      | Lacks substance       | Focus on what it does, not hype   |

## Iron Laws

1. **ALWAYS** lead with the value proposition — the first paragraph must answer "what problem does this solve?" before any installation or setup instructions.
2. **NEVER** write a Quick Start section longer than 10 lines — if setup requires more, link to a detailed guide rather than overwhelming the first-time reader.
3. **ALWAYS** include working, copy-paste-ready code examples — non-runnable pseudocode examples are worse than no examples because they waste the reader's time.
4. **NEVER** let a README become stale after a feature release — outdated installation commands and broken examples destroy user trust immediately.
5. **ALWAYS** test all external links and code examples before considering the README complete — dead links and broken examples are the most common README failure mode.

## Anti-Patterns

| Anti-Pattern                                             | Why It Fails                                                             | Correct Approach                                                                 |
| -------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| Starting with a long feature list before the description | Readers don't know what the project is, so features are meaningless      | Lead with a 1-2 sentence value proposition before listing features               |
| Using pseudocode or placeholder examples                 | Forces readers to infer the real API; causes frustration and abandonment | Show actual runnable code with real imports, function names, and expected output |
| Putting a 20-step installation guide in Quick Start      | Overwhelming setup drives users away; contradicts "quick" start          | Quick Start must be 1-3 commands; link detailed setup to a separate guide        |
| Writing marketing copy instead of technical facts        | Vague statements like "blazing fast" give no actionable information      | Use specific claims with data: "reduces build time by 40% (measured on 10k LOC)" |
| Not updating README when features change                 | Outdated commands fail silently; users blame the project, not the docs   | Treat README as code: update it in the same PR as every feature change           |

## Integration Points

**Related Skills**:

- `doc-generator` - Automated documentation from code
- `writing-skills` - Writing quality guidelines
- `technical-writer` - Professional documentation agent

**Related Agents**:

- `technical-writer` - Uses this skill for documentation
- `developer` - Writes README for new projects

## Memory Protocol (MANDATORY)

**Before starting:**
Read `.claude/context/memory/learnings.md`

**After completing:**

- New pattern → `.claude/context/memory/learnings.md`
- Issue found → `.claude/context/memory/issues.md`
- Decision made → `.claude/context/memory/decisions.md`

> ASSUME INTERRUPTION: If it's not in memory, it didn't happen.

# readme Implementation Template

## Goal

- Define target outcome and acceptance criteria.

## TDD

1. Red
2. Green
3. Refactor

## Verification

- lint
- format
- targeted tests