@zeldrisho/pi-anthropics-skills 0.1.1 → 0.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +9 -1
- package/LICENSE +0 -3
- package/README.md +9 -3
- package/package.json +3 -3
- package/skills/documentation/SKILL.md +43 -16
- package/skills/tech-debt/SKILL.md +18 -24
- package/skills/testing-strategy/SKILL.md +19 -17
- package/skills/documentation/evals/evals.json +0 -23
- package/skills/tech-debt/evals/evals.json +0 -23
- package/skills/testing-strategy/evals/evals.json +0 -23
package/CHANGELOG.md
CHANGED
|
@@ -7,6 +7,13 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
7
7
|
|
|
8
8
|
## [Unreleased]
|
|
9
9
|
|
|
10
|
+
## [0.1.2] - 2026-09-28
|
|
11
|
+
|
|
12
|
+
### Changed
|
|
13
|
+
|
|
14
|
+
- Restored pinned upstream skill content, removed bundled auxiliary files, and corrected package license metadata.
|
|
15
|
+
- Clarified documentation API guidance and required evidence for technical-debt findings; removed unrelated text appended to the license.
|
|
16
|
+
|
|
10
17
|
## [0.1.1] - 2026-09-23
|
|
11
18
|
|
|
12
19
|
### Changed
|
|
@@ -20,6 +27,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
20
27
|
|
|
21
28
|
- `documentation`, `testing-strategy`, and `tech-debt` Pi skills from Anthropic's knowledge-work plugins
|
|
22
29
|
|
|
23
|
-
[Unreleased]: https://github.com/zeldrisho/pi-packages/compare/pi-anthropics-skills-v0.1.
|
|
30
|
+
[Unreleased]: https://github.com/zeldrisho/pi-packages/compare/pi-anthropics-skills-v0.1.2...HEAD
|
|
31
|
+
[0.1.2]: https://github.com/zeldrisho/pi-packages/compare/pi-anthropics-skills-v0.1.1...pi-anthropics-skills-v0.1.2
|
|
24
32
|
[0.1.1]: https://github.com/zeldrisho/pi-packages/compare/pi-anthropics-skills-v0.1.0...pi-anthropics-skills-v0.1.1
|
|
25
33
|
[0.1.0]: https://github.com/zeldrisho/pi-packages/releases/tag/pi-anthropics-skills-v0.1.0
|
package/LICENSE
CHANGED
|
@@ -1,6 +1,3 @@
|
|
|
1
|
-
Anthropic engineering skill adaptations are licensed under Apache-2.0. Package-authored evaluation cases are offered under MIT. Source: https://github.com/anthropics/knowledge-work-plugins/tree/93d82a54e9516d172c1d0a010c1c09d56bf9d11b/engineering/skills
|
|
2
|
-
|
|
3
|
-
|
|
4
1
|
Apache License
|
|
5
2
|
Version 2.0, January 2004
|
|
6
3
|
http://www.apache.org/licenses/
|
package/README.md
CHANGED
|
@@ -1,6 +1,12 @@
|
|
|
1
1
|
# @zeldrisho/pi-anthropics-skills
|
|
2
2
|
|
|
3
|
-
Pi
|
|
3
|
+
Pi package of selected [Anthropic engineering skills](https://github.com/anthropics/knowledge-work-plugins). This package is not endorsed by Anthropic.
|
|
4
|
+
|
|
5
|
+
| Skill | Purpose |
|
|
6
|
+
| ------------------ | -------------------------------------------- |
|
|
7
|
+
| `documentation` | Write and maintain engineering documentation |
|
|
8
|
+
| `testing-strategy` | Plan risk-based testing |
|
|
9
|
+
| `tech-debt` | Audit and prioritize technical debt |
|
|
4
10
|
|
|
5
11
|
## Install
|
|
6
12
|
|
|
@@ -10,8 +16,8 @@ pi install npm:@zeldrisho/pi-anthropics-skills
|
|
|
10
16
|
pi install -l npm:@zeldrisho/pi-anthropics-skills
|
|
11
17
|
```
|
|
12
18
|
|
|
13
|
-
Select individual skills with [Pi package filtering](../../docs/package-filtering.md).
|
|
19
|
+
Select individual skills with [Pi package filtering](../../docs/package-filtering.md).
|
|
14
20
|
|
|
15
21
|
## License
|
|
16
22
|
|
|
17
|
-
|
|
23
|
+
The upstream skills are Apache-2.0. See [`LICENSE`](LICENSE) for terms and attribution.
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@zeldrisho/pi-anthropics-skills",
|
|
3
|
-
"version": "0.1.
|
|
4
|
-
"description": "
|
|
3
|
+
"version": "0.1.2",
|
|
4
|
+
"description": "Anthropic engineering skills packaged for Pi",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"documentation",
|
|
7
7
|
"pi",
|
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
"bugs": {
|
|
15
15
|
"url": "https://github.com/zeldrisho/pi-packages/issues"
|
|
16
16
|
},
|
|
17
|
-
"license": "
|
|
17
|
+
"license": "Apache-2.0",
|
|
18
18
|
"author": "Zeldris",
|
|
19
19
|
"repository": {
|
|
20
20
|
"type": "git",
|
|
@@ -1,27 +1,54 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: documentation
|
|
3
|
-
description:
|
|
3
|
+
description: Write and maintain technical documentation. Trigger with "write docs for", "document this", "create a README", "write a runbook", "onboarding guide", or when the user needs help with any form of technical writing — API docs, architecture docs, or operational runbooks.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Technical Documentation
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Write clear, maintainable technical documentation for different audiences and purposes.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Document Types
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
2. Inspect the implementation and authoritative sources (configuration, API schemas, existing docs, tests, CI). Reuse verified commands and names; mark unresolved behavior as a question rather than guessing.
|
|
14
|
-
3. Lead with the information needed to act. Order steps by dependency and include prerequisites, expected results, and failure or rollback guidance when relevant.
|
|
15
|
-
4. Include a minimal working example for interfaces or procedures. Verify syntax, paths, options, outputs, and links against available sources; do not invent API behavior.
|
|
16
|
-
5. Link to the source of truth instead of duplicating policy or reference material. Keep duplicated facts minimal and clearly scoped.
|
|
17
|
-
6. Review for the intended reader: can they find the next action, understand terminology, and distinguish required from optional steps? Remove stale, redundant, or generic text.
|
|
12
|
+
### README
|
|
18
13
|
|
|
19
|
-
|
|
14
|
+
- What this is and why it exists
|
|
15
|
+
- Quick start (< 5 minutes to first success)
|
|
16
|
+
- Configuration and usage
|
|
17
|
+
- Contributing guide
|
|
20
18
|
|
|
21
|
-
|
|
22
|
-
- **API reference:** authentication, request/response shapes, errors, pagination/limits where applicable, and runnable examples.
|
|
23
|
-
- **Runbook:** trigger/conditions, access prerequisites, ordered procedure, verification, rollback, and escalation when known.
|
|
24
|
-
- **Architecture:** context, goals, components/data flow, key decisions, trade-offs, and boundaries.
|
|
25
|
-
- **Onboarding:** environment setup, system relationships, common tasks, and verified help channels.
|
|
19
|
+
### API Documentation
|
|
26
20
|
|
|
27
|
-
|
|
21
|
+
- Endpoint reference with request/response examples
|
|
22
|
+
- Authentication and error codes
|
|
23
|
+
- Rate limits and pagination, when supported by the API
|
|
24
|
+
- SDK examples, when available and verified
|
|
25
|
+
|
|
26
|
+
### Runbook
|
|
27
|
+
|
|
28
|
+
- When to use this runbook
|
|
29
|
+
- Prerequisites and access needed
|
|
30
|
+
- Step-by-step procedure
|
|
31
|
+
- Rollback steps
|
|
32
|
+
- Escalation path
|
|
33
|
+
|
|
34
|
+
### Architecture Doc
|
|
35
|
+
|
|
36
|
+
- Context and goals
|
|
37
|
+
- High-level design with diagrams
|
|
38
|
+
- Key decisions and trade-offs
|
|
39
|
+
- Data flow and integration points
|
|
40
|
+
|
|
41
|
+
### Onboarding Guide
|
|
42
|
+
|
|
43
|
+
- Environment setup
|
|
44
|
+
- Key systems and how they connect
|
|
45
|
+
- Common tasks with walkthroughs
|
|
46
|
+
- Who to ask for what
|
|
47
|
+
|
|
48
|
+
## Principles
|
|
49
|
+
|
|
50
|
+
1. **Write for the reader** — Who is reading this and what do they need?
|
|
51
|
+
2. **Start with the most useful information** — Don't bury the lede
|
|
52
|
+
3. **Show, don't tell** — Code examples, commands, screenshots
|
|
53
|
+
4. **Keep it current** — Outdated docs are worse than no docs
|
|
54
|
+
5. **Link, don't duplicate** — Reference other docs instead of copying
|
|
@@ -1,39 +1,33 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: tech-debt
|
|
3
|
-
description:
|
|
3
|
+
description: Identify, categorize, and prioritize technical debt. Trigger with "tech debt", "technical debt audit", "what should we refactor", "code health", or when the user asks about code quality, refactoring priorities, or maintenance backlog.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Tech Debt Management
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Systematically identify, categorize, and prioritize technical debt.
|
|
9
9
|
|
|
10
|
-
##
|
|
11
|
-
|
|
12
|
-
1. Clarify the audit scope, goals, constraints, and time horizon. Inspect relevant code, tests, dependency/configuration files, operational docs, and recent history or incidents when available.
|
|
13
|
-
2. Record each candidate with a specific location or artifact, observed condition, current/potential consequence, and evidence. Separate confirmed problems from hypotheses and identify missing evidence.
|
|
14
|
-
3. Categorize candidates: code, architecture, test, dependency, documentation, or infrastructure. Describe overlap once and link related items rather than double-counting.
|
|
15
|
-
4. Estimate impact, risk, and effort using the anchors below. Explain unusual scores and note dependencies or uncertainty; do not imply numeric precision.
|
|
16
|
-
5. Prioritize changes that reduce material risk or recurring friction. Suggest a bounded first step, success/exit criteria, and a suitable phase that can fit alongside feature work.
|
|
10
|
+
## Categories
|
|
17
11
|
|
|
18
|
-
|
|
12
|
+
| Type | Examples | Risk |
|
|
13
|
+
| ----------------------- | ---------------------------------------------------- | ------------------------ |
|
|
14
|
+
| **Code debt** | Duplicated logic, poor abstractions, magic numbers | Bugs, slow development |
|
|
15
|
+
| **Architecture debt** | Monolith that should be split, wrong data store | Scaling limits |
|
|
16
|
+
| **Test debt** | Low coverage, flaky tests, missing integration tests | Regressions ship |
|
|
17
|
+
| **Dependency debt** | Outdated libraries, unmaintained dependencies | Security vulns |
|
|
18
|
+
| **Documentation debt** | Missing runbooks, outdated READMEs, tribal knowledge | Onboarding pain |
|
|
19
|
+
| **Infrastructure debt** | Manual deploys, no monitoring, no IaC | Incidents, slow recovery |
|
|
19
20
|
|
|
20
|
-
|
|
21
|
-
- **Risk:** 1 = unlikely/low consequence; 3 = plausible regression, outage, or maintenance failure; 5 = credible severe or broad harm.
|
|
22
|
-
- **Effort:** 1 = small, isolated change; 3 = several files or coordinated tests; 5 = broad redesign/migration or substantial unknowns.
|
|
21
|
+
## Prioritization Framework
|
|
23
22
|
|
|
24
|
-
|
|
23
|
+
Score each item on:
|
|
25
24
|
|
|
26
|
-
|
|
25
|
+
- **Impact**: How much does it slow the team down? (1-5)
|
|
26
|
+
- **Risk**: What happens if we don't fix it? (1-5)
|
|
27
|
+
- **Effort**: How hard is the fix? (1-5, inverted — lower effort = higher priority)
|
|
27
28
|
|
|
28
|
-
|
|
29
|
-
| -------------- | ------------------------------------------------- | --------------------------------- |
|
|
30
|
-
| Code | Duplication, brittle coupling, unclear invariants | Defects, slow changes |
|
|
31
|
-
| Architecture | Misplaced boundaries, unsafe data flows | Scaling or change constraints |
|
|
32
|
-
| Test | Missing critical-path checks, flaky suites | Regressions, slow feedback |
|
|
33
|
-
| Dependency | Unsupported or risky dependency versions | Security, compatibility |
|
|
34
|
-
| Documentation | Stale procedures or undocumented constraints | Onboarding and operational errors |
|
|
35
|
-
| Infrastructure | Manual recovery/deployments, missing safeguards | Incidents and recovery time |
|
|
29
|
+
Priority = (Impact + Risk) x (6 - Effort)
|
|
36
30
|
|
|
37
31
|
## Output
|
|
38
32
|
|
|
39
|
-
|
|
33
|
+
Produce a prioritized list with evidence and source locations, observed consequences, estimated effort, business justification for each item, and a phased remediation plan that can be done alongside feature work.
|
|
@@ -1,31 +1,33 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: testing-strategy
|
|
3
|
-
description:
|
|
3
|
+
description: Design test strategies and test plans. Trigger with "how should we test", "test strategy for", "write tests for", "test plan", "what tests do we need", or when the user needs help with testing approaches, coverage, or test architecture.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Testing Strategy
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
Design effective testing strategies balancing coverage, speed, and maintenance.
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Testing Pyramid
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
6. Recommend coverage targets only when tied to a risk or meaningful behavior; do not prescribe a universal percentage.
|
|
12
|
+
```
|
|
13
|
+
/ E2E \ Few, slow, high confidence
|
|
14
|
+
/ Integration \ Some, medium speed
|
|
15
|
+
/ Unit Tests \ Many, fast, focused
|
|
16
|
+
```
|
|
18
17
|
|
|
19
|
-
##
|
|
18
|
+
## Strategy by Component Type
|
|
20
19
|
|
|
21
|
-
-
|
|
22
|
-
- Data
|
|
23
|
-
-
|
|
24
|
-
- Infrastructure
|
|
25
|
-
- Scripts and migrations: include tests when they transform important data, change permissions, or can cause costly/irreversible effects. Do not exclude work just because it is a one-off.
|
|
20
|
+
- **API endpoints**: Unit tests for business logic, integration tests for HTTP layer, contract tests for consumers
|
|
21
|
+
- **Data pipelines**: Input validation, transformation correctness, idempotency tests
|
|
22
|
+
- **Frontend**: Component tests, interaction tests, visual regression, accessibility
|
|
23
|
+
- **Infrastructure**: Smoke tests, chaos engineering, load tests
|
|
26
24
|
|
|
27
|
-
|
|
25
|
+
## What to Cover
|
|
26
|
+
|
|
27
|
+
Focus on: business-critical paths, error handling, edge cases, security boundaries, data integrity.
|
|
28
|
+
|
|
29
|
+
Skip: trivial getters/setters, framework code, one-off scripts.
|
|
28
30
|
|
|
29
31
|
## Output
|
|
30
32
|
|
|
31
|
-
|
|
33
|
+
Produce a test plan with: what to test, test type for each area, coverage targets, and example test cases. Identify gaps in existing coverage.
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"skill_name": "documentation",
|
|
3
|
-
"evals": [
|
|
4
|
-
{
|
|
5
|
-
"id": 1,
|
|
6
|
-
"prompt": "Update this README's quick start based on the package scripts and config. Check commands actually exist.",
|
|
7
|
-
"expected_output": "A concise README section using verified commands/config, with source paths and no invented behavior.",
|
|
8
|
-
"assertions": [
|
|
9
|
-
"Commands are verified against project files",
|
|
10
|
-
"Unverified behavior is not stated as fact"
|
|
11
|
-
]
|
|
12
|
-
},
|
|
13
|
-
{
|
|
14
|
-
"id": 2,
|
|
15
|
-
"prompt": "Write an incident runbook for the service, but its rollback procedure is unclear in the docs.",
|
|
16
|
-
"expected_output": "A procedure grounded in known steps, with unknown rollback details clearly called out rather than fabricated.",
|
|
17
|
-
"assertions": [
|
|
18
|
-
"Unknown rollback details are explicit",
|
|
19
|
-
"Procedure includes verification or escalation when known"
|
|
20
|
-
]
|
|
21
|
-
}
|
|
22
|
-
]
|
|
23
|
-
}
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"skill_name": "tech-debt",
|
|
3
|
-
"evals": [
|
|
4
|
-
{
|
|
5
|
-
"id": 1,
|
|
6
|
-
"prompt": "Audit this package for technical debt. Give evidence and a practical first phase; don't just list style preferences.",
|
|
7
|
-
"expected_output": "Prioritized candidates tied to artifacts, consequences, confidence, and actionable completion criteria.",
|
|
8
|
-
"assertions": [
|
|
9
|
-
"Each finding has evidence/location and consequence",
|
|
10
|
-
"Scoring uncertainty and completion criteria are stated"
|
|
11
|
-
]
|
|
12
|
-
},
|
|
13
|
-
{
|
|
14
|
-
"id": 2,
|
|
15
|
-
"prompt": "A dependency looks old. Should we replace it? We have no incident history handy.",
|
|
16
|
-
"expected_output": "The agent verifies support/security status before claiming risk, records uncertainty, and suggests a bounded next step.",
|
|
17
|
-
"assertions": [
|
|
18
|
-
"Does not claim vulnerability or unsupported status without evidence",
|
|
19
|
-
"States what needs verification"
|
|
20
|
-
]
|
|
21
|
-
}
|
|
22
|
-
]
|
|
23
|
-
}
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"skill_name": "testing-strategy",
|
|
3
|
-
"evals": [
|
|
4
|
-
{
|
|
5
|
-
"id": 1,
|
|
6
|
-
"prompt": "Plan tests for an endpoint that updates a user's billing address. Inspect existing tests first and cover authorization and validation.",
|
|
7
|
-
"expected_output": "A prioritized, repository-grounded plan accounting for existing coverage and unauthorized access.",
|
|
8
|
-
"assertions": [
|
|
9
|
-
"Existing tests are inspected before gaps are claimed",
|
|
10
|
-
"Unauthorized access and invalid input are covered"
|
|
11
|
-
]
|
|
12
|
-
},
|
|
13
|
-
{
|
|
14
|
-
"id": 2,
|
|
15
|
-
"prompt": "This one-off migration rewrites customer identifiers and can be rerun after failure. What tests should we add?",
|
|
16
|
-
"expected_output": "Risk-based tests for correctness, idempotency, partial failure/recovery and data integrity.",
|
|
17
|
-
"assertions": [
|
|
18
|
-
"Does not exclude tests because migration is one-off",
|
|
19
|
-
"Covers rerun/idempotency and data integrity"
|
|
20
|
-
]
|
|
21
|
-
}
|
|
22
|
-
]
|
|
23
|
-
}
|