Code to content

Skill bakerstreetco/skills/code-to-content

Reusable agent skills for real repository work: review, implementation, release, documentation, and project hygiene.

Install

npx -y skills add bakerstreetco/skills --skill code-to-content

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turn recent repository work into private team updates, internal documentation, handoff notes, implementation summaries, launch notes, or decision records. Use when asked to review current session work, recent commits, pull requests, branch names, issues, changed files, or the last week of development and draft internal content based on real repo evidence.

SKILL.md

3.2 KB, as published. Nobody here has run it

Code to Content

Use this skill to translate real engineering activity into private, plain-English team content. Inspect the repository before writing and ground every claim in local git history, PR data, issue links, branch names, commit messages, changed files, or conversation context.

Evidence Gathering

Default to the current user's last week of work unless a different date range is provided.

Start with local repository evidence:

git status --short
git config user.name
git log --author="$(git config user.name)" --since="1 week ago" --pretty=format:"%h|%ai|%s|%an" --no-merges
git log --author="$(git config user.name)" --since="1 week ago" --stat --no-merges
git branch --show-current

If a GitHub remote and gh authentication are available, also gather PR evidence:

gh pr list --author @me --state all --limit 20 --json number,title,state,createdAt,mergedAt,url,additions,deletions

If gh is unavailable or unauthenticated, continue with git evidence and mention the limitation briefly. Do not fabricate PRs, metrics, links, deployments, or issue references.

Internal Content Types

Choose the content type that matches the request and evidence:

Team update: what changed, why it matters, current status, risks, and next steps.
Handoff note: context, touched files, key decisions, verification, and remaining work.
Implementation summary: what shipped, important design choices, testing coverage, and known tradeoffs.
Internal launch note: user-facing impact, rollout status, verification instructions, and support caveats.
Decision record: problem, options considered, chosen direction, rationale, and follow-up triggers.
AI implementation note: practical lessons, integration friction, evaluation gaps, workflow constraints, tooling tradeoffs, and what surprised the team.

Group related work into themes. Explain outcomes, impact, tricky problems solved, and what remains in progress. Do not just list commits.

Style

Write in a conversational, confident tone.
Explain technical work in terms a non-technical manager can understand.
Avoid corporate jargon, status-report padding, and vague AI hype.
Include links to PRs, commits, deployments, dashboards, or test instructions when available, and explain what each link is for.
Include specific testing instructions when the recipient can verify the work themselves.
Keep the content private-team appropriate and focused on internal coordination, documentation, decisions, and verification.

Use fenced code blocks for commands:

command to verify

Output

Return a send-ready internal update, handoff note, implementation summary, launch note, or decision record depending on the request. Include a short "what's next" section only when the evidence shows clear follow-up work.