Focus Code Skill Marketplace

Skill Introduction

Overview

Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.

Core value

Turns reusable Documentation know-how into an installable skill, helping users complete github, community work faster.

Target users

Developers, testers, and maintainers who handle Documentation tasks in Focus Code.
Teams that already trust workflows or content from mattpocock.
Users who want standardized prompts, steps, or conventions instead of repeating setup work.

Best practices

Read the skill content first to confirm required inputs, expected outputs, and dependencies.
Try it on a small task before relying on it for critical work.
Add project-specific constraints such as coding style, target platform, test expectations, and delivery format.
For external sources, verify the source link, version, and recent maintenance activity.

Best use cases

Tasks related to github, community that need a reusable execution flow.
Converting a community repo, team convention, or personal workflow into day-to-day assistance.
Starting from a proven skill instead of writing prompts or procedures from scratch.

Limits and boundaries

Results depend on the quality of the original skill content and may need human correction.
It does not replace code review, tests, security review, or professional judgment.
External tools, APIs, account permissions, and local dependencies still need separate setup.

Differentiation

Structured around Documentation, making it easier to discover and reuse than loose prompt snippets.
Marked as GitHub, which helps users judge trust and maintenance expectations.
Keeps the original source link available for repository, documentation, or discussion follow-up.
Tagged with github, community, so it can be filtered by concrete task intent.

Install and use

Install

Copy Install Command

focus install writing-beats-b37f5e

View source

Detail Preview

SKILL.md

Primary filemarkdown3 KB

name: writing-beats description: Shape an article as a journey of beats, choose-your-own-adventure style. The user picks a starting beat from the raw material, you write only that beat, then offer options for where to pivot next, beat by beat, until the article reaches a natural end. Use when the user has raw material and wants to assemble it as a narrative rather than an argument.

<what-to-do>

The user has passed (or will pass) a markdown file of raw material.

If the user did not say where to save the article, ask once and remember the path.

Then run a beat-by-beat journey:

Write 2–3 candidate starting beats, drawn from the raw material. Each is a different entry point into the article. Show the user the beats before writing it to the article file. The user picks one. Preview what beats that might lead to once written - as if the user is seeing a little way down the path.
Once the user picks a starting beat, write only that beat to the article file. A beat may be one sentence or several paragraphs — whatever that beat naturally is. Stop there.
Re-read the article file from disk. Then offer 2–3 candidate next beats — different directions the journey could pivot to from where the article now stands.
Loop steps 2–4 until the article reaches a natural end.

</what-to-do> <supporting-info>

What is a beat

A beat is one move in the journey. It does one thing — sets a scene, lands a point, asks a question, drops an aside, twists the angle. Then it stops, leaving the reader at a place where the next beat can pivot.

A beat is sized by what it needs:

A single sentence if that's all the move is ("And then nothing happened for three weeks.").
A short paragraph if the move needs setup.
Multiple paragraphs if the beat is a self-contained vignette, argument, or example.

If a "beat" needs five paragraphs and three subheadings, it's not a beat — it's two beats glued together. Split it.

Writing one beat

Once a beat is picked, write that beat only to the article file. Do not write the next beat.

Pull material from the raw pile to populate the beat. You can paraphrase, split, recombine, or quote. The pile is a quarry.

Ending the journey

The article ends when the journey is complete — not when the pile is empty. Most piles will have leftover fragments that don't make it in. That is fine; that is the point of having more raw material than you need.

Writing rhythm

Append one beat at a time. Never write ahead.
Re-read the article file from disk before every write. Preserve user edits absolutely.
If the user edits a previous beat substantially, let it change what comes next.
If the user says "rewrite that beat" or "go back and try a different beat 3", do it — edit in place, leave the rest alone.

</supporting-info>

writing beats