@zalom/plastic 1.0.0-alpha.2 → 1.0.0-alpha.21
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/PLASTIC.md +128 -473
- package/README.md +90 -58
- package/agents/future-intent-researcher.md +1 -1
- package/agents/intent-curator.md +1 -1
- package/bin/plastic.js +57 -0
- package/bin/test +28 -0
- package/deprecations.yml +7 -6
- package/hooks/auto-arm +5 -0
- package/hooks/bash-gate +3 -0
- package/hooks/check-update +12 -8
- package/hooks/code-gate +10 -0
- package/hooks/hooks.json +25 -4
- package/hooks/statusline +50 -10
- package/package.json +2 -2
- package/scripts/dashboard.rb +480 -0
- package/scripts/doctor.rb +973 -0
- package/scripts/hook-auto-arm +52 -0
- package/scripts/hook-bash-gate +53 -0
- package/scripts/hook-code-gate +39 -0
- package/scripts/hook-continue +15 -114
- package/scripts/hook-gate-check +19 -4
- package/scripts/hook-session-start +76 -31
- package/scripts/install.rb +91 -480
- package/scripts/lib/bridge.rb +255 -0
- package/scripts/lib/installer_core.rb +760 -0
- package/scripts/migrate-to-global +1 -1
- package/scripts/select-update-target +93 -0
- package/scripts/uninstall.rb +53 -0
- package/scripts/update.rb +142 -0
- package/scripts/versions.rb +141 -0
- package/skills/_active-intent-gate.md +26 -0
- package/skills/auto/SKILL.md +62 -9
- package/skills/auto/evals/evals.json +92 -0
- package/skills/auto/references/agent-architecture.md +60 -0
- package/skills/brainstorming/SKILL.md +143 -0
- package/skills/brainstorming-grill-me/SKILL.md +5 -5
- package/skills/continuing/SKILL.md +102 -77
- package/skills/continuing/evals/evals.json +136 -0
- package/skills/continuing/references/context-management.md +32 -0
- package/skills/creating-intent/SKILL.md +16 -1
- package/skills/creating-intent/references/lifecycle.md +74 -0
- package/skills/creating-intent/references/wikilinks.md +8 -0
- package/skills/creating-project/SKILL.md +8 -4
- package/skills/creating-project/references/hubs-projects.md +55 -0
- package/skills/dashboard/SKILL.md +92 -0
- package/skills/doctor/SKILL.md +116 -0
- package/skills/doctor/references/gates-stuck-detection.md +38 -0
- package/skills/doctor/report.md +96 -0
- package/skills/evaluating-skills/SKILL.md +140 -0
- package/skills/evaluating-skills/assets/eval-template.json +12 -0
- package/skills/evaluating-skills/evals/evals.json +75 -0
- package/skills/evaluating-skills/references/convention-checks.md +76 -0
- package/skills/evaluating-skills/references/eval-methodology.md +154 -0
- package/skills/executing-plan/SKILL.md +3 -3
- package/skills/install/SKILL.md +56 -8
- package/skills/intent-curator/SKILL.md +3 -3
- package/skills/linking-intents/SKILL.md +5 -1
- package/skills/linking-intents/references/zettelkasten.md +33 -0
- package/skills/managing-index/SKILL.md +5 -1
- package/skills/releasing/SKILL.md +119 -18
- package/skills/releasing/references/deprecations.md +44 -0
- package/skills/research/SKILL.md +114 -0
- package/skills/savepoint/SKILL.md +46 -37
- package/skills/savepoint/references/context-management.md +32 -0
- package/skills/uninstall/SKILL.md +39 -28
- package/skills/update/SKILL.md +41 -36
- package/skills/versions/SKILL.md +65 -0
- package/skills/writing-instructions/SKILL.md +159 -0
- package/skills/writing-instructions/references/agentskills-spec.md +135 -0
- package/skills/writing-plans/SKILL.md +183 -0
- package/templates/agents.md +16 -0
- package/templates/outcome.md +13 -0
- package/templates/project.yml +5 -0
- package/templates/savepoint.md +14 -13
- package/templates/spec.md +25 -0
- package/bin/install.js +0 -29
|
@@ -0,0 +1,75 @@
|
|
|
1
|
+
{
|
|
2
|
+
"skill_name": "evaluating-skills",
|
|
3
|
+
"evals": [
|
|
4
|
+
{
|
|
5
|
+
"id": 1,
|
|
6
|
+
"prompt": "I want to evaluate whether my creating-intent skill follows Plastic conventions",
|
|
7
|
+
"expected_output": "The skill should activate and guide the user through convention compliance evaluation: choose eval scope, design test cases using convention-checks reference, run paired evals, write assertions after observing.",
|
|
8
|
+
"files": [],
|
|
9
|
+
"assertions": []
|
|
10
|
+
},
|
|
11
|
+
{
|
|
12
|
+
"id": 2,
|
|
13
|
+
"prompt": "Run evals on the brainstorming skill to see if the description triggers correctly",
|
|
14
|
+
"expected_output": "The skill should activate and guide through description triggering evaluation: design ~20 queries with should-trigger and near-miss negatives, 60/40 train/validation split, compute trigger rates.",
|
|
15
|
+
"files": [],
|
|
16
|
+
"assertions": []
|
|
17
|
+
},
|
|
18
|
+
{
|
|
19
|
+
"id": 3,
|
|
20
|
+
"prompt": "Create evals for a new skill I just wrote for database migrations",
|
|
21
|
+
"expected_output": "The skill should activate, help create evals/evals.json in the migration skill directory using the template, guide through choosing eval scope (likely output quality), and design initial test cases.",
|
|
22
|
+
"files": [],
|
|
23
|
+
"assertions": []
|
|
24
|
+
},
|
|
25
|
+
{
|
|
26
|
+
"id": 4,
|
|
27
|
+
"prompt": "Check if my SKILL.md is under the token budget and follows progressive disclosure",
|
|
28
|
+
"expected_output": "The skill should activate and guide through convention compliance evaluation focused on progressive disclosure checks: body under 500 lines/5000 tokens, references have conditional triggers, description under 1024 chars.",
|
|
29
|
+
"files": [],
|
|
30
|
+
"assertions": []
|
|
31
|
+
},
|
|
32
|
+
{
|
|
33
|
+
"id": 5,
|
|
34
|
+
"prompt": "My skill's description isn't triggering on the right prompts, how do I fix it?",
|
|
35
|
+
"expected_output": "The skill should activate and guide through description triggering evaluation: create should-trigger and should-not-trigger queries, run paired evals, measure trigger rate, iterate on description wording.",
|
|
36
|
+
"files": [],
|
|
37
|
+
"assertions": []
|
|
38
|
+
},
|
|
39
|
+
{
|
|
40
|
+
"id": 6,
|
|
41
|
+
"prompt": "Write unit tests for my Ruby model that validates email addresses",
|
|
42
|
+
"expected_output": "The skill should NOT trigger. This is a code testing task, not a skill evaluation task. Near-miss negative — shares 'test' keyword but needs a different skill.",
|
|
43
|
+
"files": [],
|
|
44
|
+
"assertions": []
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"id": 7,
|
|
48
|
+
"prompt": "Fix the bug in my login controller where sessions aren't persisting",
|
|
49
|
+
"expected_output": "The skill should NOT trigger. This is a debugging task with no relation to skill evaluation.",
|
|
50
|
+
"files": [],
|
|
51
|
+
"assertions": []
|
|
52
|
+
},
|
|
53
|
+
{
|
|
54
|
+
"id": 8,
|
|
55
|
+
"prompt": "Review this pull request for code quality issues",
|
|
56
|
+
"expected_output": "The skill should NOT trigger. Code review is different from skill evaluation. Near-miss negative — shares 'review/evaluate' concept.",
|
|
57
|
+
"files": [],
|
|
58
|
+
"assertions": []
|
|
59
|
+
},
|
|
60
|
+
{
|
|
61
|
+
"id": 9,
|
|
62
|
+
"prompt": "I updated my skill and want to make sure it still works correctly",
|
|
63
|
+
"expected_output": "The skill should activate and guide through regression evaluation: run existing evals against the updated skill, compare pass rates with previous version, check for backsliding.",
|
|
64
|
+
"files": [],
|
|
65
|
+
"assertions": []
|
|
66
|
+
},
|
|
67
|
+
{
|
|
68
|
+
"id": 10,
|
|
69
|
+
"prompt": "How do I know if a skill is still needed or if the model has learned the behavior?",
|
|
70
|
+
"expected_output": "The skill should activate and guide through skill retirement detection: monitor with/without delta over time, if delta approaches zero the model has internalized the skill.",
|
|
71
|
+
"files": [],
|
|
72
|
+
"assertions": []
|
|
73
|
+
}
|
|
74
|
+
]
|
|
75
|
+
}
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# Plastic Convention Checks
|
|
2
|
+
|
|
3
|
+
Assertion library for convention compliance evals on Plastic skills.
|
|
4
|
+
Load when running convention compliance evals on a Plastic skill.
|
|
5
|
+
|
|
6
|
+
## Directory Structure
|
|
7
|
+
|
|
8
|
+
| Check | Pass criteria |
|
|
9
|
+
|-------|--------------|
|
|
10
|
+
| SKILL.md exists | File present at skill root |
|
|
11
|
+
| Name matches directory | `name` in frontmatter equals directory name |
|
|
12
|
+
| Standard directories only | Only scripts/, references/, assets/, evals/ at root level (all optional) |
|
|
13
|
+
| References one level deep | No nested directories inside references/ |
|
|
14
|
+
| No orphan files | Every file in the skill dir is referenced from SKILL.md or another skill file |
|
|
15
|
+
| evals/ has evals.json | If evals/ exists, it contains evals.json |
|
|
16
|
+
|
|
17
|
+
## Frontmatter
|
|
18
|
+
|
|
19
|
+
| Check | Pass criteria |
|
|
20
|
+
|-------|--------------|
|
|
21
|
+
| `name` present | Non-empty, 1-64 chars |
|
|
22
|
+
| `name` format | Lowercase alphanumeric + hyphens, no leading/trailing/consecutive hyphens |
|
|
23
|
+
| `name` matches dir | Exact match with skill directory name |
|
|
24
|
+
| `description` present | Non-empty, 1-1024 chars |
|
|
25
|
+
| `description` phrasing | Starts with imperative verb or "Use when" pattern |
|
|
26
|
+
| `description` triggers | Mentions at least one trigger context ("Use when...") |
|
|
27
|
+
| `description` edge cases | Includes at least one indirect trigger (user doesn't name the domain) |
|
|
28
|
+
| No unknown required fields | Only uses fields from agentskills.io spec: name, description, license, compatibility, metadata, allowed-tools |
|
|
29
|
+
|
|
30
|
+
## Progressive Disclosure
|
|
31
|
+
|
|
32
|
+
| Check | Pass criteria |
|
|
33
|
+
|-------|--------------|
|
|
34
|
+
| Body line count | SKILL.md body (excluding frontmatter) under 500 lines |
|
|
35
|
+
| Body token count | SKILL.md body under 5000 tokens (estimate: lines * 10) |
|
|
36
|
+
| Deep detail in references | Content exceeding activation budget lives in references/ |
|
|
37
|
+
| Conditional reference triggers | Every reference file mentioned in SKILL.md has a "when" condition |
|
|
38
|
+
| No generic references | No "see references/ for more" — each reference has specific load trigger |
|
|
39
|
+
| Description token budget | Description stays under ~100 tokens for discovery stage |
|
|
40
|
+
|
|
41
|
+
## Content Quality
|
|
42
|
+
|
|
43
|
+
| Check | Pass criteria |
|
|
44
|
+
|-------|--------------|
|
|
45
|
+
| Gotchas are concrete | Each gotcha is a specific correction, not general advice |
|
|
46
|
+
| Gotchas positioned early | Gotchas section appears before or near the top of procedures |
|
|
47
|
+
| Defaults, not menus | Skill picks one approach; alternatives mentioned briefly if at all |
|
|
48
|
+
| Procedures over declarations | Instructions teach HOW to approach, not WHAT to produce |
|
|
49
|
+
| Reasoning over rigid directives | Uses "Do X because Y" pattern, not "ALWAYS/NEVER" without rationale |
|
|
50
|
+
| No redundant knowledge | Every instruction passes "would the agent get this wrong without it?" |
|
|
51
|
+
| No explaining basics | Does not explain HTTP, JSON, what a migration is, etc. |
|
|
52
|
+
|
|
53
|
+
## Eval Quality (when evals/ exists)
|
|
54
|
+
|
|
55
|
+
| Check | Pass criteria |
|
|
56
|
+
|-------|--------------|
|
|
57
|
+
| Standard format | evals.json follows agentskills.io eval structure |
|
|
58
|
+
| Prompts are realistic | Each prompt reads like a real user message |
|
|
59
|
+
| Varied phrasing | Prompts use different wording, detail levels, formality |
|
|
60
|
+
| Near-miss negatives | At least 2 should-not-trigger cases that share keywords |
|
|
61
|
+
| Expected output descriptive | expected_output describes success, not exact text |
|
|
62
|
+
| Assertions (if populated) | Each assertion is specific, verifiable, and countable |
|
|
63
|
+
|
|
64
|
+
## Intent Structure (when evaluating intent compliance)
|
|
65
|
+
|
|
66
|
+
| Check | Pass criteria |
|
|
67
|
+
|-------|--------------|
|
|
68
|
+
| Intent file exists | `{ID}--{slug}.md` present in intent directory |
|
|
69
|
+
| Frontmatter complete | id, intent, sources, chain, created, author, tags present |
|
|
70
|
+
| ID format correct | Follows Luhmann alternating: digits and letters alternate |
|
|
71
|
+
| Directory name matches | `{ID}--{slug}` format, 3-5 word slug |
|
|
72
|
+
| Lifecycle artifacts | Present artifacts match the intent's lifecycle stage |
|
|
73
|
+
| spec.md gate | plan.md only exists if spec.md exists |
|
|
74
|
+
| plan.md gate | checklist.md only exists if plan.md exists |
|
|
75
|
+
| outcome.md gate | outcome.md only exists if all checklist items checked |
|
|
76
|
+
| Insights append-only | `## Insights` section only grows, never shrinks |
|
|
@@ -0,0 +1,154 @@
|
|
|
1
|
+
# Evaluation Methodology
|
|
2
|
+
|
|
3
|
+
Load when choosing a grader type, interpreting pass rate results, or deciding
|
|
4
|
+
whether to graduate or retire evals.
|
|
5
|
+
|
|
6
|
+
Sources: agentskills.io, Anthropic eval engineering, Tessl eval framework,
|
|
7
|
+
Philipp Schmid skill testing guide.
|
|
8
|
+
|
|
9
|
+
## Three-Tier Grader Taxonomy
|
|
10
|
+
|
|
11
|
+
Layer graders like a Swiss cheese model — no single tier catches everything.
|
|
12
|
+
Use the simplest grader that covers the assertion. Combine tiers for coverage.
|
|
13
|
+
|
|
14
|
+
### Code-Based Graders
|
|
15
|
+
|
|
16
|
+
Best for structural and mechanical checks:
|
|
17
|
+
- File existence and correct path
|
|
18
|
+
- JSON/YAML validity
|
|
19
|
+
- Line count, character count, token budget
|
|
20
|
+
- Regex pattern matching (frontmatter fields, required sections)
|
|
21
|
+
- Exit codes from bundled scripts
|
|
22
|
+
|
|
23
|
+
Use as the default tier. Fast, deterministic, reproducible.
|
|
24
|
+
|
|
25
|
+
### LLM-as-Judge Graders
|
|
26
|
+
|
|
27
|
+
Best for subjective quality and semantic checks:
|
|
28
|
+
- "Does this description convey when to use the skill?"
|
|
29
|
+
- "Are the gotchas concrete corrections, not general advice?"
|
|
30
|
+
- "Does the output address the user's actual intent?"
|
|
31
|
+
|
|
32
|
+
Calibration protocol:
|
|
33
|
+
1. Write a natural-language rubric (not binary pass/fail)
|
|
34
|
+
2. Run the judge on 10-15 cases where you already know the correct grade
|
|
35
|
+
3. Compare judge grades to your grades — adjust rubric until >80% agreement
|
|
36
|
+
4. Spot-check with human grading periodically (every 5th eval run)
|
|
37
|
+
|
|
38
|
+
Rubric template:
|
|
39
|
+
- PASS: [specific criteria with examples]
|
|
40
|
+
- PARTIAL: [what partial credit looks like]
|
|
41
|
+
- FAIL: [specific failure modes]
|
|
42
|
+
|
|
43
|
+
### Human Graders
|
|
44
|
+
|
|
45
|
+
Best for edge cases and final calibration:
|
|
46
|
+
- Novel failure modes the other tiers miss
|
|
47
|
+
- Calibration set for LLM judges
|
|
48
|
+
- Final sign-off on graduating evals to regression
|
|
49
|
+
|
|
50
|
+
Use sparingly — human grading doesn't scale. Reserve for calibration
|
|
51
|
+
and cases where code + LLM judges disagree.
|
|
52
|
+
|
|
53
|
+
## pass@k vs pass^k
|
|
54
|
+
|
|
55
|
+
Two metrics that diverge dramatically. Always track both.
|
|
56
|
+
|
|
57
|
+
### pass@k — Capability
|
|
58
|
+
|
|
59
|
+
"Did it succeed at least once in k trials?"
|
|
60
|
+
|
|
61
|
+
Formula: pass@k = 1 - (1 - p)^k where p = single-trial pass rate
|
|
62
|
+
|
|
63
|
+
Measures: Can the skill/agent do this at all?
|
|
64
|
+
|
|
65
|
+
Example at p=0.7, k=10: pass@k = 97.2%
|
|
66
|
+
|
|
67
|
+
Use when: evaluating whether a skill enables a new capability,
|
|
68
|
+
initial development, deciding whether to invest more iteration.
|
|
69
|
+
|
|
70
|
+
### pass^k — Reliability
|
|
71
|
+
|
|
72
|
+
"Did it succeed every time in k trials?"
|
|
73
|
+
|
|
74
|
+
Formula: pass^k = p^k
|
|
75
|
+
|
|
76
|
+
Measures: Will it always do this correctly?
|
|
77
|
+
|
|
78
|
+
Example at p=0.7, k=10: pass^k = 2.8%
|
|
79
|
+
|
|
80
|
+
Use when: evaluating production readiness, regression testing,
|
|
81
|
+
deciding whether a skill is reliable enough to ship.
|
|
82
|
+
|
|
83
|
+
### Interpreting the Gap
|
|
84
|
+
|
|
85
|
+
| pass@k | pass^k | Interpretation |
|
|
86
|
+
|--------|--------|----------------|
|
|
87
|
+
| High | High | Reliable — ready for production |
|
|
88
|
+
| High | Low | Capable but flaky — needs iteration on consistency |
|
|
89
|
+
| Low | Low | Not yet capable — needs fundamental skill improvement |
|
|
90
|
+
| Low | High | Impossible (pass^k <= pass@k always) |
|
|
91
|
+
|
|
92
|
+
Run k=3 minimum for meaningful results. k=5 for production decisions.
|
|
93
|
+
|
|
94
|
+
## Capability-to-Regression Graduation
|
|
95
|
+
|
|
96
|
+
Track pass rates across iterations. When a capability eval consistently
|
|
97
|
+
hits ~100% (pass@k=1.0 for 3+ consecutive runs):
|
|
98
|
+
|
|
99
|
+
1. Graduate the eval from "capability" to "regression"
|
|
100
|
+
2. Regression evals run on every skill change — they protect against backsliding
|
|
101
|
+
3. If a regression eval starts failing, the recent change broke something
|
|
102
|
+
4. Investigate the failing regression before iterating further
|
|
103
|
+
|
|
104
|
+
Graduation is one-way. Once an eval is regression, it stays regression
|
|
105
|
+
unless the underlying requirement changes.
|
|
106
|
+
|
|
107
|
+
## Skill Retirement Detection
|
|
108
|
+
|
|
109
|
+
Monitor the with/without skill delta over time:
|
|
110
|
+
|
|
111
|
+
1. Run paired evals (with-skill vs without-skill) periodically
|
|
112
|
+
2. Compute the delta in pass rates
|
|
113
|
+
3. If delta shrinks to near-zero across 3+ consecutive runs:
|
|
114
|
+
- The model has likely internalized the skill's knowledge
|
|
115
|
+
- The skill may be ready for retirement
|
|
116
|
+
4. Before retiring: run one final full eval suite to confirm
|
|
117
|
+
5. Archive the skill (don't delete — may need to restore if model changes)
|
|
118
|
+
|
|
119
|
+
Common cause of false retirement signals: model update changed capabilities.
|
|
120
|
+
Re-test after model updates.
|
|
121
|
+
|
|
122
|
+
## Tessl Three-Layer Eval Taxonomy
|
|
123
|
+
|
|
124
|
+
Three layers of increasing realism. Each catches failures the others miss.
|
|
125
|
+
|
|
126
|
+
### Layer 1: Skill Review (Structural Lint)
|
|
127
|
+
|
|
128
|
+
Does the skill itself follow best practices?
|
|
129
|
+
- SKILL.md structure (frontmatter, sections, length)
|
|
130
|
+
- Description quality (imperative, user-intent, trigger keywords)
|
|
131
|
+
- Reference organization (conditional triggers, one level deep)
|
|
132
|
+
- Convention compliance (for Plastic skills, see convention-checks.md)
|
|
133
|
+
|
|
134
|
+
Fast, cheap, runs without executing the skill.
|
|
135
|
+
|
|
136
|
+
### Layer 2: Task Evals (Synthetic)
|
|
137
|
+
|
|
138
|
+
Does the skill improve agent output on synthetic tasks?
|
|
139
|
+
- Paired with/without comparison
|
|
140
|
+
- Controlled prompts with known-good expected outputs
|
|
141
|
+
- Measures the delta the skill adds
|
|
142
|
+
|
|
143
|
+
This is the core eval loop (Steps 2-5 in the SKILL.md procedure).
|
|
144
|
+
|
|
145
|
+
### Layer 3: Repo Evals (Real Codebase)
|
|
146
|
+
|
|
147
|
+
Does the skill work correctly in a real project context?
|
|
148
|
+
- Install the skill in a real repository
|
|
149
|
+
- Run real tasks (not synthetic prompts)
|
|
150
|
+
- Measure whether the agent uses the skill correctly in situ
|
|
151
|
+
|
|
152
|
+
Most expensive, most realistic. Catches skills that pass synthetic tests
|
|
153
|
+
but fail under real project complexity. Use for high-stakes skills
|
|
154
|
+
or before shipping to users.
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: plastic
|
|
2
|
+
name: plastic-executing-plan
|
|
3
3
|
description: Use when you have a written implementation plan to execute. Default mode is subagent-driven (dispatches fresh subagent per task with two-stage review). Fallback mode is inline execution for environments without subagent support. If superpowers:subagent-driven-development or superpowers:executing-plans are available, delegates to them.
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -70,7 +70,7 @@ After all tasks complete, dispatch a final reviewer for the entire implementatio
|
|
|
70
70
|
### Step 4: Update Intent and Complete
|
|
71
71
|
Capture observations in `## Insights`. When ALL checklist items are checked:
|
|
72
72
|
|
|
73
|
-
1. Write `outcome.md` with detailed results in the intent directory
|
|
73
|
+
1. Write `outcome.md` with detailed results in the intent directory, using the `${CLAUDE_PLUGIN_ROOT}/templates/outcome.md` form
|
|
74
74
|
2. Write `## Outcome` summary in the intent file (1-2 sentences)
|
|
75
75
|
3. Move intent from `## Active` to `## Completed` in INDEX.md (with today's date)
|
|
76
76
|
4. Update cluster entries to show `_(completed)_`
|
|
@@ -95,7 +95,7 @@ For each task:
|
|
|
95
95
|
### Step 3: Update Intent and Complete
|
|
96
96
|
Capture observations in `## Insights`. When ALL checklist items are checked:
|
|
97
97
|
|
|
98
|
-
1. Write `outcome.md` with detailed results in the intent directory
|
|
98
|
+
1. Write `outcome.md` with detailed results in the intent directory, using the `${CLAUDE_PLUGIN_ROOT}/templates/outcome.md` form
|
|
99
99
|
2. Write `## Outcome` summary in the intent file (1-2 sentences)
|
|
100
100
|
3. Move intent from `## Active` to `## Completed` in INDEX.md (with today's date)
|
|
101
101
|
4. Update cluster entries to show `_(completed)_`
|
package/skills/install/SKILL.md
CHANGED
|
@@ -1,22 +1,64 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: plastic
|
|
3
|
-
description: Use when initializing Plastic globally (~/.plastic/) or locally in a project. Global install is recommended — creates the global intent store as a git-backed repository. Local install creates .plastic/ in the current project for testing.
|
|
2
|
+
name: plastic-install
|
|
3
|
+
description: Use when initializing Plastic globally (~/.plastic/) or locally in a project, or to re-install/repair a broken installation. Accepts channel flags (--alpha, --beta, --latest) to select release channel. Default is --latest (stable). Global install is recommended — creates the global intent store as a git-backed repository. Local install creates .plastic/ in the current project for testing.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Install Plastic
|
|
7
7
|
|
|
8
|
+
> **Recommended path:** for a first install, run `npx @zalom/plastic@latest install --claude`
|
|
9
|
+
> in your shell (or `bunx @zalom/plastic@latest --claude` if you use Bun). This skill
|
|
10
|
+
> exists to **re-install or repair** an existing setup from inside the agent, and to
|
|
11
|
+
> drive interactive global configuration. Whenever this skill performs an install or
|
|
12
|
+
> re-install, it **runs `/plastic-doctor` afterward** and reports the result.
|
|
13
|
+
|
|
14
|
+
## Re-install / repair
|
|
15
|
+
|
|
16
|
+
If Plastic is already installed but something is broken (skills missing, hooks not
|
|
17
|
+
firing, leftover legacy plugin), re-run the installer — it is idempotent, prunes
|
|
18
|
+
files that no longer ship, and removes any legacy plugin/marketplace layout:
|
|
19
|
+
|
|
20
|
+
```bash
|
|
21
|
+
npx @zalom/plastic@latest install --reinstall --claude # or @beta / @alpha to match your channel
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
Then **run `/plastic-doctor`** and report what it found.
|
|
25
|
+
|
|
26
|
+
## Channel Flags
|
|
27
|
+
|
|
28
|
+
| Flag | Behavior |
|
|
29
|
+
|------|----------|
|
|
30
|
+
| `--latest` | Install from stable channel (default) |
|
|
31
|
+
| `--beta` | Install from beta channel |
|
|
32
|
+
| `--alpha` | Install from alpha channel |
|
|
33
|
+
|
|
34
|
+
When invoked from within Claude Code (re-install or channel switch), the skill
|
|
35
|
+
runs the appropriate npx command:
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
# Stable (default)
|
|
39
|
+
npx @zalom/plastic install --claude
|
|
40
|
+
|
|
41
|
+
# Beta
|
|
42
|
+
npx @zalom/plastic@beta install --claude
|
|
43
|
+
|
|
44
|
+
# Alpha
|
|
45
|
+
npx @zalom/plastic@alpha install --claude
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
The installed version and channel are recorded in `~/.plastic/VERSION`.
|
|
49
|
+
|
|
8
50
|
## Modes
|
|
9
51
|
|
|
10
52
|
### Global Install (default, recommended)
|
|
11
53
|
|
|
12
|
-
Run `/plastic
|
|
54
|
+
Run `/plastic-install` with no arguments.
|
|
13
55
|
|
|
14
56
|
#### Procedure
|
|
15
57
|
|
|
16
58
|
**Step 1: Check for existing installation**
|
|
17
59
|
|
|
18
60
|
Check if `~/.plastic/INDEX.md` exists.
|
|
19
|
-
- If yes: announce "Plastic is already installed at ~/.plastic/. Run `/plastic
|
|
61
|
+
- If yes: announce "Plastic is already installed at ~/.plastic/. Run `/plastic-update` to sync core files."
|
|
20
62
|
- If no: proceed with fresh install.
|
|
21
63
|
|
|
22
64
|
**Step 2: Create ~/.plastic/ as a git repo**
|
|
@@ -106,13 +148,19 @@ Update `config.yml` with any additional roots.
|
|
|
106
148
|
|
|
107
149
|
Auto-commit the config change.
|
|
108
150
|
|
|
109
|
-
**Step 4:
|
|
151
|
+
**Step 4: Verify with doctor**
|
|
152
|
+
|
|
153
|
+
Run `/plastic-doctor` and report the result. Resolve any fixable findings before
|
|
154
|
+
announcing success.
|
|
155
|
+
|
|
156
|
+
**Step 5: Announce**
|
|
110
157
|
|
|
111
|
-
> "Plastic installed globally at ~/.plastic/.
|
|
158
|
+
> "Plastic installed globally at ~/.plastic/. Health check: [doctor summary].
|
|
159
|
+
> Create your first intent with `/plastic-creating-intent`."
|
|
112
160
|
|
|
113
161
|
### Local Install (testing/legacy)
|
|
114
162
|
|
|
115
|
-
Run `/plastic
|
|
163
|
+
Run `/plastic-install --local`.
|
|
116
164
|
|
|
117
165
|
#### Procedure
|
|
118
166
|
|
|
@@ -131,4 +179,4 @@ Run `/plastic:install --local`.
|
|
|
131
179
|
|
|
132
180
|
**Step 4:** Commit in project: `git add .plastic/ && git commit -m "chore: initialize Plastic local store"`
|
|
133
181
|
|
|
134
|
-
**Step 5:** Announce: "Plastic initialized locally. This is a testing/legacy mode. Consider `/plastic
|
|
182
|
+
**Step 5:** Announce: "Plastic initialized locally. This is a testing/legacy mode. Consider `/plastic-install` for global mode."
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: plastic
|
|
2
|
+
name: plastic-intent-curator
|
|
3
3
|
description: |
|
|
4
4
|
Use when completing or reviewing intents, reorganizing the index,
|
|
5
5
|
or when the intent store needs maintenance. Examples:
|
|
@@ -15,7 +15,7 @@ description: |
|
|
|
15
15
|
|
|
16
16
|
# Intent Curator
|
|
17
17
|
|
|
18
|
-
Dispatches to the `plastic
|
|
18
|
+
Dispatches to the `plastic-intent-curator` agent for intent store maintenance.
|
|
19
19
|
|
|
20
20
|
## When to Use
|
|
21
21
|
- Completing or reviewing intents
|
|
@@ -25,7 +25,7 @@ Dispatches to the `plastic:intent-curator` agent for intent store maintenance.
|
|
|
25
25
|
|
|
26
26
|
## Workflow
|
|
27
27
|
|
|
28
|
-
Invoke the `plastic
|
|
28
|
+
Invoke the `plastic-intent-curator` agent via the Agent tool with `subagent_type: "plastic-intent-curator"`. Pass the user's request as the prompt, including:
|
|
29
29
|
|
|
30
30
|
1. **What to do** — complete intent, reorganize, triage stale, etc.
|
|
31
31
|
2. **Which store** — global (`~/.plastic/`) or project (`.plastic/store/`)
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: plastic
|
|
2
|
+
name: plastic-linking-intents
|
|
3
3
|
description: Use when creating connections between intents, the user says "link" or "connect", or when discovering that two intents are related. Manages sources, chain, and cross-reference links.
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -70,3 +70,7 @@ Add a wikilink in the `## Links` section of **both** intents (bidirectional).
|
|
|
70
70
|
|
|
71
71
|
### 4. Update INDEX.md Clusters
|
|
72
72
|
If both intents share a topic, ensure they're in the same cluster.
|
|
73
|
+
|
|
74
|
+
## References
|
|
75
|
+
|
|
76
|
+
- Read `references/zettelkasten.md` for the three Zettelkasten structures (Folgezettel, directed graph, tags), ID encoding rules, and dual-mode (Obsidian + programmatic) design
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Zettelkasten Structure
|
|
2
|
+
|
|
3
|
+
Plastic implements three Zettelkasten structures:
|
|
4
|
+
|
|
5
|
+
| Structure | Implementation | Purpose |
|
|
6
|
+
|---|---|---|
|
|
7
|
+
| Folgezettel (linked list) | `sources` + `chain` in frontmatter | Sequential provenance |
|
|
8
|
+
| Directed graph (web of notes) | `## Links` with wikilinks | Obsidian navigation |
|
|
9
|
+
| Tag-based taxonomy | `tags` in frontmatter | Topic grouping |
|
|
10
|
+
|
|
11
|
+
INDEX.md is a structure note (hub), not a table of contents.
|
|
12
|
+
|
|
13
|
+
## Folgezettel IDs
|
|
14
|
+
|
|
15
|
+
IDs encode lineage using Luhmann's alternating convention:
|
|
16
|
+
- Root intents: sequential numbers (`1`, `2`, `3`...)
|
|
17
|
+
- Branches alternate letters and numbers: `1` → `1a` → `1a1` → `1a1a` → ...
|
|
18
|
+
- Multiple branches from the same parent increment: `1a`, `1b`, `1c`
|
|
19
|
+
- IDs are assigned at creation time and never change
|
|
20
|
+
|
|
21
|
+
## Knowledge Graph
|
|
22
|
+
|
|
23
|
+
`sources` + `chain` form the double-linked knowledge graph:
|
|
24
|
+
- `sources` = what fed into this intent (parents, inspirations, prerequisites)
|
|
25
|
+
- `chain` = what this intent produced (children, follow-ups, spin-offs)
|
|
26
|
+
|
|
27
|
+
## Dual-Mode
|
|
28
|
+
|
|
29
|
+
This store works in two modes without modification:
|
|
30
|
+
- **Obsidian** (human, offline) — browse, link, write markdown
|
|
31
|
+
- **Programmatic** (any agent) — read/write via filesystem operations
|
|
32
|
+
|
|
33
|
+
No special tooling required for either mode.
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: plastic
|
|
2
|
+
name: plastic-managing-index
|
|
3
3
|
description: Use after creating, completing, or abandoning intents, when the user says "index" or "organize", or when INDEX.md needs maintenance. Curates the INDEX.md structure note.
|
|
4
4
|
---
|
|
5
5
|
|
|
@@ -64,3 +64,7 @@ When 3+ intents share tags but aren't in a cluster, suggest a new cluster headin
|
|
|
64
64
|
Intents with no links (empty `sources`, empty `chain`, no `## Links` entries, not in any cluster) should be flagged for curation.
|
|
65
65
|
|
|
66
66
|
REQUIRED BACKGROUND: linking-intents (for understanding connection types and Zettelkasten theory)
|
|
67
|
+
|
|
68
|
+
## References
|
|
69
|
+
|
|
70
|
+
- Read `references/zettelkasten-linking.md` for the three structural layers (Folgezettel, directed graph, tags) and how they map to INDEX.md organization
|