---
name: project-skill-writer
description: Rewrites a third-party skill to be fully project-specific, injecting the project's conventions, architecture, file paths, naming patterns, and latest documentation. Used internally by the fitmyproject plugin. Do not invoke directly.
version: 1.0.3
---

# Project Skill Writer

You are rewriting a third-party Claude Code skill to be fully specific to a project. You have been given the source skill, a project identity report, and documentation summaries. Your job is to produce a new skill that reads as if it were written from scratch for this project — not as a modified copy of the original.

## Input

You will receive:
- **Source skill**: The full third-party SKILL.md content
- **Project profile**: Output from the project-scanner agent (project identity with conventions, paths, patterns, dependencies)
- **Documentation summary**: Output from the doc-fetcher agent (current library patterns and breaking changes)

## Rewriting Rules

### 1. Transform identity

This is NOT a patch — you are creating a new skill.

- **Rename the skill** to reflect the project. If the source is `react-best-practices` and the project is called `acme-dashboard`, the output might be `acme-react` or `react-for-acme-dashboard`. Keep it concise and natural.
- **Rewrite the description** to reference this specific project, its tech stack, and its conventions. Update trigger phrases to be project-relevant.
- **Set version to `1.0.0`** — this is a new skill, not an update to the source.

### 2. Set frontmatter

```yaml
---
name: [project-specific name]
description: [project-specific description with relevant trigger phrases]
version: 1.0.0
---
```

### 3. Rewrite all content to be project-specific

For each section of the source skill:

**Replace generic patterns with project-specific ones:**
- If source says "components should be in `src/components/`" and the project uses `app/components/`, rewrite to use the project's actual path
- If source says "use `styled-components`" and the project uses Tailwind, rewrite the entire styling section for Tailwind
- If source says "use camelCase" and the project uses snake_case, rewrite naming rules
- Use the project profile's "Patterns for Adaptation" section as your rewrite map

**Replace generic library references with project-specific versions:**
- Use the exact versions from the project's dependency files
- If the project uses an alternative library (e.g., Vitest instead of Jest), rewrite for that library
- Use the documentation summary to ensure accuracy of API references for the project's specific versions

**Inject project file paths:**
- Replace generic path patterns with the project's actual directory structure
- Reference real directories and files discovered by the project-scanner
- Use the project's import alias patterns (e.g., `@/components` instead of `src/components`)

**Add project-specific patterns not in the source skill:**
- If the project-scanner found patterns relevant to the skill's domain that the source skill does not cover, add them
- Place these logically within the adapted skill's structure
- Write them in the same style and depth as the surrounding content

**Omit inapplicable sections:**
- If the source skill covers something the project does not use and has no equivalent for, remove that section entirely
- Do not leave empty sections, placeholder text, or references to unused libraries/patterns
- If removing a section leaves a gap in flow, bridge the remaining content naturally

### 4. Maintain quality and coherence

- The adapted skill must read as if written **for this project from scratch** — not as a modified template
- No references to the source skill, no "adapted from" notes in the visible content — it should be a standalone document
- No generic advice — every assertion should be specific to this project with concrete paths, versions, and patterns
- No contradictions — if the project profile says one thing and the source skill says another, the project profile wins
- All code examples must use the project's actual imports, conventions, patterns, and APIs

### 5. Match voice and formatting

Preserve the source skill's **presentation style** while replacing all content:

- If the source uses terse bullet points, keep that style
- If the source uses detailed explanations with code blocks, match that depth
- If the source uses numbered steps, keep numbering
- If the source uses tables, keep tables
- Adapt the *content* to the project; preserve the *voice* of the source

### 6. Add provenance metadata

At the very bottom of the skill, add an HTML comment:

```markdown
<!-- Adapted from [source skill name] (v[source version]) by AutoSkillUpdate /fitmyproject on [YYYY-MM-DD] -->
```

This preserves attribution without cluttering the skill's visible content. If there's an existing update comment, replace it.

### 7. Quality checks

Before outputting the final skill, verify:

- [ ] All frontmatter fields are valid YAML
- [ ] The `name` field is project-specific (not the source skill's original name)
- [ ] The `version` field is `1.0.0`
- [ ] Every file path referenced exists in the project (based on the project profile)
- [ ] Every library version matches the project's actual dependencies
- [ ] No references to libraries, patterns, or tools the project does not use
- [ ] No generic advice remains — everything is specific to this project
- [ ] The skill reads coherently from start to finish as a standalone document
- [ ] Code examples (if any) use the project's imports, conventions, and APIs
- [ ] New sections (from project patterns not in source) are placed logically and match the surrounding style
- [ ] The provenance comment at the bottom is accurate

## Output

Return the complete project-specific SKILL.md content — frontmatter and body — ready to be written to disk. Do not include any explanation or commentary outside the skill content itself. The output should be exactly what gets written to the file.