Blog Automation Permission

A skill that enables autonomous blog content management operations without manual approval requirements. This skill configures Claude to work independently within the blog repository, following established content standards and architectural patterns.

Purpose

This skill grants Claude full permission to perform blog-related tasks in the current branch without requiring user approval for each action. It's designed for the blog project at Borifan02/blog, a Next.js-based blog with strict content standards and feature-based architecture.

Instructions

When this skill is activated, you are granted full autonomy to:

1. **Create, edit, and manage blog content** following the tagging guidelines and content standards

2. **Refactor code** according to the feature-based architecture patterns

3. **Debug and fix issues** using the established debugging protocols

4. **Modify components, hooks, and utilities** within the project structure

5. **Test changes** across all affected pages and components

Content Standards to Follow

#### Tagging Rules

#### Tag Selection Process

1. Primary language (if language-specific content >50%)

2. Main concept (required - what readers will learn)

3. Secondary concept OR primary tool (if significant >20% content)

4. Industry context (purpose/audience)

Architecture Patterns to Follow

#### Component Organization

#### Import Patterns

Debugging Protocol

When fixing component issues:

1. **Discovery**: Find ALL instances of the component/pattern

2. **Analysis**: Debug data structure with console.log or temporary debug pages

3. **Fix**: Apply consistently to ALL instances simultaneously

4. **Validation**: Test ALL affected pages

5. **Documentation**: Record reasoning for changes

#### PostItem Component Rules

Production Error Protocol

For production-only crashes:

1. **Environment Analysis**: Identify if error is production-specific

2. **Systematic Investigation**: Review component architecture, data flow, CSP issues

3. **Root Cause Categories**: Check for hydration mismatches, CSP violations, data validation failures

4. **Fix Implementation**: Add error boundaries, graceful fallbacks, data validation, type guards

#### MDX Safety Rules

Constraints

Examples

Example 1: Adding a new blog post

When asked to create a new blog post, you should:

1. Create the MDX file in the appropriate directory

2. Select appropriate tags (max 4) from `/lib/content/tags.json`

3. Follow the tag selection priority order

4. Validate against the content standards

5. Test the post appears correctly on homepage, blog page, and relevant tag pages

Example 2: Fixing a navigation bug

When fixing navigation issues:

1. Use `grep -r "ComponentName" .` to find ALL instances

2. Analyze the data structure (use `post.slugAsParams` not `post.slug`)

3. Apply fix to ALL instances (homepage, blog page, tag pages)

4. Test all affected URLs

5. Document the fix reasoning

Example 3: Refactoring a component

When refactoring:

1. Place in appropriate feature directory (`components/features/[domain]/`)

2. Create barrel export (`index.ts`)

3. Update all imports to use feature-based paths

4. Test across all pages that use the component

5. Ensure backward compatibility where needed

Notes