README update
OpenCode v1: Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native skill tool. Slash commands are direct user entry points only.
Describe current behavior, never a desired future presented as current state.
Discover the documentation contract
- Locate the relevant README and consumer-owned documentation instructions.
Do not assume one root file or a fixed docs layout.
- Discover the required language, audience, section conventions, ownership
details and generated/manual boundaries.
- Read the existing README and preserve accurate, intentional content.
- If target, language, audience or publication scope remains ambiguous, ask.
Build an evidence map
Inspect only sources that exist and are relevant:
- build and dependency definitions for stack and supported commands
- application code and schemas for interfaces and behavior
- deployment configuration for environments, auth, resources and integrations
- automation for actual CI/CD workflows
- migrations or data definitions for owned data
- observability configuration for verified dashboards, probes and alerts
- maintained documentation for domain purpose, operations and ownership
Find sources by role and content, not by a hardcoded path or stack. Record
support for consequential claims. Ask for product purpose, contact information
or private links that cannot be derived safely.
Choose only useful sections
| Section |
Include when |
| Purpose |
Always; state what the software does and for whom |
| Status or support |
The repository documents lifecycle or ownership |
| Development |
Verified setup, run and test instructions exist |
| Interfaces |
The repository exposes APIs, events, jobs or libraries |
| Data and dependencies |
They materially explain behavior or operation |
| Deployment and configuration |
Readers need it and evidence exists |
| Observability |
Verified dashboards, signals or runbooks exist |
| Architecture visual |
Three or more relationships are clearer visually |
| Further reading |
A maintained document is directly relevant |
Do not add badges, contact channels, dashboards, environment links or
technology lists unless they are verified and useful.
Update workflow
- Compare current text with the evidence map.
- Mark statements as keep, update, remove or unresolved.
- Preserve manual operational knowledge until it is disproven or the user
approves removal.
- Write the smallest coherent update.
- Validate commands and links where feasible, and review the diff for
unsupported claims.
For a new README, start with purpose and the shortest verified path to use or
develop it. Add sections only when evidence and reader need justify them.
Content rules
- Use the consumer's documented language and terminology.
- Prefer stable commands or pointers over copied output that will quickly age.
- Describe interfaces from code or generated contracts, not memory.
- Use service, topic, database, environment and auth names only after discovery.
- Use Mermaid only when it materially clarifies verified relationships.
- Do not duplicate an entire schema, runbook or ADR catalogue.
- Make uncertainty explicit instead of filling gaps with plausible defaults.
Approval boundary
The requested local README edit is allowed. Before publishing, committing,
opening a PR, commenting, or editing other docs, show the diff and get approval.
Grenser
Alltid
- Cross-check consequential statements against current repository evidence.
- Preserve accurate manual content.
- Validate local links and commands proportionally to risk.
Spør først
- Remove substantial manual sections.
- Choose between conflicting product descriptions or language rules.
- Add an unverified private link, owner or contact channel.
- Perform any external write.
Aldri
- Invent endpoints, data stores, auth, environments, owners or dashboards.
- Assume a framework, package, manifest or documentation path.
- Replace a repository-specific README with a generic template.
1---2name: readme-update-23description: Create or update a README from verified implementation and operational evidence. Use when repository purpose, setup, usage or ownership documentation is missing or stale; use `klarsprak` for a wording-only edit and `to-spec` for intended future behavior.4---5# README update67> **OpenCode v1:** Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native `skill` tool. Slash commands are direct user entry points only.89Describe current behavior, never a desired future presented as current state.1011## Discover the documentation contract12131. Locate the relevant README and consumer-owned documentation instructions.14 Do not assume one root file or a fixed docs layout.152. Discover the required language, audience, section conventions, ownership16 details and generated/manual boundaries.173. Read the existing README and preserve accurate, intentional content.184. If target, language, audience or publication scope remains ambiguous, ask.1920## Build an evidence map2122Inspect only sources that exist and are relevant:2324- build and dependency definitions for stack and supported commands25- application code and schemas for interfaces and behavior26- deployment configuration for environments, auth, resources and integrations27- automation for actual CI/CD workflows28- migrations or data definitions for owned data29- observability configuration for verified dashboards, probes and alerts30- maintained documentation for domain purpose, operations and ownership3132Find sources by role and content, not by a hardcoded path or stack. Record33support for consequential claims. Ask for product purpose, contact information34or private links that cannot be derived safely.3536## Choose only useful sections3738| Section | Include when |39|---|---|40| Purpose | Always; state what the software does and for whom |41| Status or support | The repository documents lifecycle or ownership |42| Development | Verified setup, run and test instructions exist |43| Interfaces | The repository exposes APIs, events, jobs or libraries |44| Data and dependencies | They materially explain behavior or operation |45| Deployment and configuration | Readers need it and evidence exists |46| Observability | Verified dashboards, signals or runbooks exist |47| Architecture visual | Three or more relationships are clearer visually |48| Further reading | A maintained document is directly relevant |4950Do not add badges, contact channels, dashboards, environment links or51technology lists unless they are verified and useful.5253## Update workflow54551. Compare current text with the evidence map.562. Mark statements as keep, update, remove or unresolved.573. Preserve manual operational knowledge until it is disproven or the user58 approves removal.594. Write the smallest coherent update.605. Validate commands and links where feasible, and review the diff for61 unsupported claims.6263For a new README, start with purpose and the shortest verified path to use or64develop it. Add sections only when evidence and reader need justify them.6566## Content rules6768- Use the consumer's documented language and terminology.69- Prefer stable commands or pointers over copied output that will quickly age.70- Describe interfaces from code or generated contracts, not memory.71- Use service, topic, database, environment and auth names only after discovery.72- Use Mermaid only when it materially clarifies verified relationships.73- Do not duplicate an entire schema, runbook or ADR catalogue.74- Make uncertainty explicit instead of filling gaps with plausible defaults.7576## Approval boundary7778The requested local README edit is allowed. Before publishing, committing,79opening a PR, commenting, or editing other docs, show the diff and get approval.8081## Grenser8283### Alltid8485- Cross-check consequential statements against current repository evidence.86- Preserve accurate manual content.87- Validate local links and commands proportionally to risk.8889### Spør først9091- Remove substantial manual sections.92- Choose between conflicting product descriptions or language rules.93- Add an unverified private link, owner or contact channel.94- Perform any external write.9596### Aldri9798- Invent endpoints, data stores, auth, environments, owners or dashboards.99- Assume a framework, package, manifest or documentation path.100- Replace a repository-specific README with a generic template.
navikt