nextstage-brasil/skills

ns-docs-writer

(NS) Write and edit human-facing project documentation — README, docs/ guides, runbooks, and contributor-facing markdown.

First seen Aug 17, 2026

Installation

$ npx skills add nextstage-brasil/skills --skill ns-docs-writer

Summary

  • (NS) Write and edit human-facing project documentation — README, docs/ guides, runbooks, and contributor-facing markdown.
  • Use whenever the user asks for documentation, README updates, how-to guides, or docs/ content — even if they say "explain how to use" instead of "write docs".
  • Stack-agnostic; follow project layout from AGENTS.md.
  • Do NOT use for code comments, API docblocks in source, requirements.md, or SDD version artifacts (use PM skills).

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from nextstage-brasil/skills · top by installs.

npx skills add nextstage-brasil/skills

Browse all from nextstage-brasil/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

License LICENSE
Default branch main
Open issues 0
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

Version1.4
LicenseApache-2.0
More metadata
author
nextstage-brasil
version
1.4

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,894 B
  • docs SUMMARY.md 474 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 53 installs

SKILL.md

Docs Writer

Author clear, maintainable project documentation under docs/ and README files.

Session boot

See ../../ns-harness/references/session-boot.md.

Scope

In scope Out of scope
README.md at product or repo root Inline // or /** code comments
docs/**/*.md guides docs/versions//sdd/requirements.md, docs/versions//requirements.md (legacy SDD)
Runbooks, install guides, architecture overviews for humans Living specs in docs/specs/ (use ns-living-spec)
Changelog entries when requested Marketing copy outside repo

When to use

  • New feature needs user or developer documentation
  • README is stale after structural changes
  • Onboarding guide for contributors
  • Consolidating scattered notes into docs/

Workflow

  1. Discover — list existing docs/, README, and AGENTS.md links; avoid duplicating harness/brownfield artifacts (link instead).
  2. Audience — confirm developer vs operator vs end-user (default: developer).
  3. Outline — short TOC before drafting long guides.
  4. Draft — follow references/style-guide.md.
  5. Link — prefer relative links; point to canonical rules in .nextstage-harness/rules/ when relevant.

Layout (stack-agnostic)

Do not assume monorepo packages/ layout. Infer from:

  • AGENTS.md layout table
  • architecture-rules.md
  • Existing docs/ structure

Create subfolders only when they match project convention.

Integration

When called from ns-spec-driven, document delivered behavior — do not invent requirements.

Agent why (reference architecture, agent vs code, trade-offs, topology, HITL, change signal) lives in docs/specs/agent-architecture.md. Link it. Do not copy the interview or rewrite the decision record in README. docs/specs/agent.md is behavior (ns-living-spec), not this ADR.

Forbidden

  • Copying full bodies of brownfield-map.md or system-reverse-spec.md into new docs (link them)
  • English violations when project mandates English docs
  • Auto-generating docs for code that does not exist yet
  • Same version with both docs/versions//sdd/requirements.md and legacy docs/versions//requirements.md — link canonical sdd/ path only; never create or maintain dual trees