shunk031-structured-writing

Solid

Structure and revise detailed instructions, plans, reports, documentation, evidence documents such as TRAINING.md, repository protocol documents, pull-request bodies, and bullet lists so their hierarchy and relationships are clear. Use when drafting or reorganizing multi-part prose and repository completion or status reports, even when the resulting report should be concise, especially when deciding between headings, topic bullets, supporting nested bullets, and independent flat items. Do not use for ordinary conversational short answers, code-only output, or machine-readable data unless the user also requests prose organization.

Data & Documents 153 stars 6 forks Updated today MIT

Install

View on GitHub

Quality Score: 86/100

Stars 20%
73
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Structured Writing Make the document's logical relationships visible without imposing a template on every sentence. ## Structure - Keep reports and responses concise. Expand only when asked. - Lead a detailed section with its main conclusion or topic. - Use headings to separate distinct concerns, not to decorate short text. For short repository completion or status reports, lead with the outcome and essential validation in the smallest readable paragraph or compact list; omit template headings or sections when that is enough, while retaining headings for genuinely distinct concerns in detailed reports. - Use `Label: Details` when it improves scanning. Treat it as an option, not a mandatory template. - Write procedures as steps to perform when work begins and in the order that prevents problems, rather than as checks to make only after a problem occurs. For example, when introducing a hook, write “When starting work in a new clone or worktree, install the hook before editing or committing,” rather than “Check it if it does not run.” - When one bullet states a topic and later bullets only support it, make the parent the topic sentence, nest supporting sentences, and use the last child as a conclusion when useful. ```text - topic sentence - support sentence - support sentence - conclusion sentence ``` - Treat consecutive sentences beginning with a pronoun such as “it” as supporting details when they refer to the preceding topic; keep a sentence with a di...

Details

Author
shunk031
Repository
shunk031/dotfiles
Created
10 years ago
Last Updated
today
Language
Shell
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Data & Documents Solid

structured-writing

Structure and revise detailed instructions, plans, reports, documentation, and bullet lists so their hierarchy and relationships are clear. Use when drafting or reorganizing multi-part prose, especially when deciding between headings, topic bullets, supporting nested bullets, and independent flat items. Do not use for short answers, code-only output, or machine-readable data unless the user also requests prose organization.

153 Updated today
shunk031
Data & Documents Listed

writing-documents

Write structured software-delivery and consultancy documents as Markdown in the repo by default. Use for canonical decision, contract, procedure, learning, system, incident, suite, plan, assurance, and brief types, including design and architecture docs, requirements, delivery plans, reviews, status, release, support, and service documentation. Produce designed HTML or PDF only when asked. Do not use for casual edits, metric-led reports (analytical-document-design), slides (presentation-design), standalone charts or diagrams, legal boilerplate, back-office commercial records, or unprompted restyling.

2 Updated 6 days ago
Avinava
Data & Documents Listed

adhd-structure

THIS IS THE MOST IMPORTANT SKILL!!! Plain-language format for one chunk of content, with escalating detail: 1-line summary, then a 5-line version, then a 3-part deep dive added only on request. ALWAYS use proactively — by default, not only when asked. ALWAYS use for every markdown file and ticket (Linear issues, PR descriptions, plan/review docs).

0 Updated yesterday
YoniChechik