Invoke local-rules skill.
Check if the project has a doc generator or scaffold tool before writing from scratch.
Update existing docs when branch changes add, rename, or remove public API surface. Keep examples, descriptions, and API tables in sync with the current implementation.
Link to related docs instead of duplicating. Treat docs as interconnected wiki articles.
Reuse existing mocks, fixtures, and API helpers. Create new ones in their canonical location, not inline in the docs.
Be brief. Only document what cannot be inferred from the API — intent, constraints, gotchas. Let examples speak for themselves.
Show the simplest useful example first. Add separate sections only for meaningfully different edge cases.
Every code example must be self-contained, runnable, and have a titled heading.
Prefer interactive examples over static props tables when the framework supports it.
Document only public API. Skip internals.
Mock or stub external dependencies so examples work without a running backend.

Más de este repositorio

mismo repositorio

review-pr

p2kmgcl/chachi-shell

Reviews a GitHub PR and creates a pending review with editorially gated inline/body findings. Use when the user asks to review a PR or create a draft GitHub review.

2026-07-016

local-rules

p2kmgcl/chachi-shell

Load machine-local rule overrides for a given skill from the shared ~/.agents skills directory.

2026-06-026

commit

p2kmgcl/chachi-shell

Create one or more atomic commits from current changes, grouping by logical unit

2026-06-026

create-ticket

p2kmgcl/chachi-shell

Create a JIRA ticket interactively — gathers requirements through conversation, proposes the ticket, and creates it after approval

2026-06-026

grill-with-docs

p2kmgcl/chachi-shell

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

2026-06-026

handoff

p2kmgcl/chachi-shell

Compact the current conversation into a handoff document for another agent to pick up.

2026-06-026

name	write-docs
description	Documentation standards to follow when creating or updating component docs in any project

Scope: changes in the current branch — committed, staged, or unstaged.

Invoke local-rules skill.
Check if the project has a doc generator or scaffold tool before writing from scratch.
Update existing docs when branch changes add, rename, or remove public API surface. Keep examples, descriptions, and API tables in sync with the current implementation.
Link to related docs instead of duplicating. Treat docs as interconnected wiki articles.
Reuse existing mocks, fixtures, and API helpers. Create new ones in their canonical location, not inline in the docs.
Be brief. Only document what cannot be inferred from the API — intent, constraints, gotchas. Let examples speak for themselves.
Show the simplest useful example first. Add separate sections only for meaningfully different edge cases.
Every code example must be self-contained, runnable, and have a titled heading.
Prefer interactive examples over static props tables when the framework supports it.
Document only public API. Skip internals.
Mock or stub external dependencies so examples work without a running backend.