feat: review Gustavo and Marcos submitted skills
This commit is contained in:
@@ -0,0 +1,72 @@
|
||||
# How-To — Template
|
||||
|
||||
Use for step-by-step runbooks. Each step is one concrete action with the
|
||||
expected result.
|
||||
|
||||
## Sections
|
||||
|
||||
- Title — verb-first ("Configure TLS on the staging cluster", not "TLS
|
||||
Configuration")
|
||||
- Prerequisites (what must already be true before starting)
|
||||
- Steps (numbered, one action per step, with the expected output)
|
||||
- Verification (the single check that proves the change worked)
|
||||
- Troubleshooting (top 3 things that go wrong, with their fixes)
|
||||
- Related (links to sister how-tos and the owning team page)
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Don't write steps that require a human to interpret them. "Configure the
|
||||
cluster" is not a step.
|
||||
- Don't bury the verification at the end of the page. Put it where the reader
|
||||
will see it after step 1.
|
||||
- Don't use screenshots where commands work. Screenshots go out of date;
|
||||
commands don't.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<h1>{Verb-first title}</h1>
|
||||
<p>{One sentence: what this how-to does and when to use it.}</p>
|
||||
|
||||
<h2>Prerequisites</h2>
|
||||
<ul>
|
||||
<li>{what must already be true}</li>
|
||||
</ul>
|
||||
|
||||
<h2>Steps</h2>
|
||||
<ol>
|
||||
<li>
|
||||
<p>{action}</p>
|
||||
<p><em>Expected output:</em></p>
|
||||
<ac:structured-macro ac:name="code">
|
||||
<ac:parameter ac:name="language">bash</ac:parameter>
|
||||
<ac:plain-text-body><![CDATA[{expected output}]]></ac:plain-text-body>
|
||||
</ac:structured-macro>
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<h2>Verification</h2>
|
||||
<p>{Single check that proves the change worked. If it fails, the rest of the
|
||||
how-to doesn't apply.}</p>
|
||||
|
||||
<h2>Troubleshooting</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Symptom</th>
|
||||
<th>Cause</th>
|
||||
<th>Fix</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{symptom}</td>
|
||||
<td>{cause}</td>
|
||||
<td>{fix}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
```
|
||||
|
||||
## Cross-references
|
||||
|
||||
- Storage macros: `confluence-page/references/macros.md`
|
||||
- Diagrams: `diagram-plantuml/SKILL.md`
|
||||
@@ -0,0 +1,79 @@
|
||||
# Hub Page — Template
|
||||
|
||||
Use for top-level overview / landing pages under a space home.
|
||||
|
||||
## Sections
|
||||
|
||||
- Overview (one paragraph, last sentence ties to the next section)
|
||||
- Latest release (table or list, with link to the release page)
|
||||
- Useful Links (table: Name, Link)
|
||||
- Documentation (table: Document, Link)
|
||||
- Teams & Contacts (bullet list with links to team pages)
|
||||
- Related (links to sister pages)
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Don't duplicate release notes here — link to the release page.
|
||||
- Don't paste the full architecture diagram — link to it.
|
||||
- Don't list every related page — only the ones a reader of this hub will need.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<h1>{Page Title}</h1>
|
||||
<p>{One-paragraph overview. Last sentence points to "Useful Links" below.}</p>
|
||||
|
||||
<h2>Latest release</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Release</th>
|
||||
<th>Scope</th>
|
||||
<th>Delivery</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><ac:link><ri:page ri:content-title="NDO Release 2026.2"/></ac:link></td>
|
||||
<td><ac:link><ri:page ri:content-title="2026.2 Release Scope"/></ac:link></td>
|
||||
<td>23 June 2026</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Useful Links</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Link</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>JIRA project</td>
|
||||
<td><a href="https://psup.netcracker.com/projects/UNM">UNM</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Documentation</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Document</th>
|
||||
<th>Link</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Admin Guide</td>
|
||||
<td><a href="https://doc.netcracker.com/display/NetworkDomainOrchestrator/...">Admin Guide</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Teams & Contacts</h2>
|
||||
<ul>
|
||||
<li><ac:link><ri:page ri:content-title="NDO Teams"/></ac:link></li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
## Cross-references
|
||||
|
||||
- Storage macros: `confluence-page/references/macros.md`
|
||||
- NDO Hub mirror (real example): `~/Netcracker/Projects/NDO/knowledge/confluence/AVP/network-domain-orchestrator-ndo.md`
|
||||
@@ -0,0 +1,117 @@
|
||||
# Postmortem — Template
|
||||
|
||||
Use for incident write-ups. The structure follows the standard blameless
|
||||
format: what happened, what was supposed to happen, why it didn't, what we
|
||||
change.
|
||||
|
||||
## Sections
|
||||
|
||||
- Summary (two or three sentences: who was affected, for how long, by what)
|
||||
- Impact (the numbers: users, requests, dollars, internal teams)
|
||||
- Timeline (UTC timestamps, one row per significant event)
|
||||
- Root cause (the chain of decisions and conditions that produced the
|
||||
incident; not a single "the bug")
|
||||
- Detection (how we found out, and how long after it started)
|
||||
- Response (what we did, what worked, what didn't)
|
||||
- Recovery (what we did to get back to a steady state)
|
||||
- Lessons (the things we want to remember)
|
||||
- Action items (table with owner, due date, status)
|
||||
- Related (links to the incident ticket, runbook, and follow-up docs)
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Don't assign blame. The postmortem is about the system, not the person.
|
||||
- Don't hide the timeline. The reader's first question is "how long"; the
|
||||
timeline is the answer.
|
||||
- Don't list action items without owners. An action item without an owner
|
||||
is a wish.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<h1>{Incident title — short, dated}</h1>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Date</th>
|
||||
<td>{YYYY-MM-DD}</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Severity</th>
|
||||
<td>{SEV-1 / SEV-2 / SEV-3}</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Duration</th>
|
||||
<td>{start} → {end} (UTC)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Incident commander</th>
|
||||
<td>{name}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Summary</h2>
|
||||
<p>{two or three sentences}</p>
|
||||
|
||||
<h2>Impact</h2>
|
||||
<ul>
|
||||
<li>{users affected}</li>
|
||||
<li>{requests failed / throttled}</li>
|
||||
<li>{internal teams paged}</li>
|
||||
</ul>
|
||||
|
||||
<h2>Timeline (UTC)</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Time</th>
|
||||
<th>Event</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{HH:MM}</td>
|
||||
<td>{event}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Root cause</h2>
|
||||
<p>{chain of decisions and conditions}</p>
|
||||
|
||||
<h2>Detection</h2>
|
||||
<p>{how we found out, and how long after the incident started}</p>
|
||||
|
||||
<h2>Response</h2>
|
||||
<p>{what we did}</p>
|
||||
|
||||
<h2>Recovery</h2>
|
||||
<p>{how we got back to steady state}</p>
|
||||
|
||||
<h2>Lessons</h2>
|
||||
<ul>
|
||||
<li>{lesson}</li>
|
||||
</ul>
|
||||
|
||||
<h2>Action items</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Action</th>
|
||||
<th>Owner</th>
|
||||
<th>Due</th>
|
||||
<th>Status</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{action}</td>
|
||||
<td>{owner}</td>
|
||||
<td>{YYYY-MM-DD}</td>
|
||||
<td>{OPEN / DONE}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
```
|
||||
|
||||
## Cross-references
|
||||
|
||||
- Storage macros: `confluence-page/references/macros.md`
|
||||
- BASS / AVP page hierarchy — see the owning team's incident process doc
|
||||
@@ -0,0 +1,105 @@
|
||||
# RFC — Template
|
||||
|
||||
Use for proposals that need a written decision record. Status field goes at
|
||||
the top so the page reader sees it before the rest.
|
||||
|
||||
## Sections
|
||||
|
||||
- Status (DRAFT / REVIEW / ACCEPTED / REJECTED / SUPERSEDED)
|
||||
- Author + reviewers (the people whose names should be on the proposal)
|
||||
- Context (the problem and why now)
|
||||
- Proposal (the change, in concrete terms)
|
||||
- Alternatives considered (one paragraph each, with the reason rejected)
|
||||
- Risks and mitigations (table)
|
||||
- Rollout plan (phases, owners, rollback)
|
||||
- Open questions (the things still being decided)
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
- Don't write an RFC without alternatives. A proposal that has no rejected
|
||||
alternatives either didn't think hard enough or didn't consider the reader.
|
||||
- Don't hide the status. The reader's first question is "is this decided?";
|
||||
answer it in the first line.
|
||||
- Don't open questions at the end of the proposal. Put them after the rollout
|
||||
plan, where they don't read as part of the decision.
|
||||
|
||||
## Storage template
|
||||
|
||||
```xml
|
||||
<h1>{Title — verb-first}</h1>
|
||||
|
||||
<ac:structured-macro ac:name="status">
|
||||
<ac:parameter ac:name="colour">Yellow</ac:parameter>
|
||||
<ac:parameter ac:name="title">DRAFT</ac:parameter>
|
||||
</ac:structured-macro>
|
||||
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Author</th>
|
||||
<td>{name}</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Reviewers</th>
|
||||
<td>{names}</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Status</th>
|
||||
<td>DRAFT</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Context</h2>
|
||||
<p>{problem + why now}</p>
|
||||
|
||||
<h2>Proposal</h2>
|
||||
<p>{the change in concrete terms}</p>
|
||||
|
||||
<h2>Alternatives considered</h2>
|
||||
<h3>{Alternative 1}</h3>
|
||||
<p>{why rejected}</p>
|
||||
<h3>{Alternative 2}</h3>
|
||||
<p>{why rejected}</p>
|
||||
|
||||
<h2>Risks and mitigations</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Risk</th>
|
||||
<th>Mitigation</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{risk}</td>
|
||||
<td>{mitigation}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Rollout plan</h2>
|
||||
<table>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Phase</th>
|
||||
<th>Owner</th>
|
||||
<th>Rollback</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>{phase}</td>
|
||||
<td>{owner}</td>
|
||||
<td>{how to roll back}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
<h2>Open questions</h2>
|
||||
<ul>
|
||||
<li>{question}</li>
|
||||
</ul>
|
||||
```
|
||||
|
||||
## Cross-references
|
||||
|
||||
- Storage macros: `confluence-page/references/macros.md`
|
||||
- Status colors: `Yellow` (DRAFT), `Blue` (REVIEW), `Green` (ACCEPTED),
|
||||
`Red` (REJECTED), `Grey` (SUPERSEDED)
|
||||
Reference in New Issue
Block a user