sync: skills and tool contract overhaul from private repo

This commit is contained in:
“BeeRad”
2026-03-07 11:45:26 +11:00
parent 46ac8d9bde
commit 2cdd685c04
32 changed files with 2548 additions and 681 deletions
+29
View File
@@ -0,0 +1,29 @@
---
name: Audit
description: "Run a structured audit of graph quality, skill quality, and operational consistency."
when_to_use: "User asks for review, QA, cleanup, or governance checks."
when_not_to_use: "Simple one-off write/read requests."
success_criteria: "Findings are prioritized, concrete, and tied to actionable fixes."
---
# Audit
## Scope
1. Node quality: duplicates, vague descriptions, missing dates, weak titles.
2. Edge quality: missing links, weak explanations, wrong directionality.
3. Dimension quality: drift, overlap, low-signal categories.
4. Skill quality: trigger clarity, overlap, dead/unused skills.
## Output Format
1. Critical issues
2. High-impact improvements
3. Cleanup actions
4. Optional refinements
## Rules
- Prefer specific evidence over generic commentary.
- Propose the smallest high-leverage fixes first.
- Separate defects from optional polish.
+33
View File
@@ -0,0 +1,33 @@
---
name: Calibration
description: "Run periodic check-ins to recalibrate goals, projects, preferences, and graph structure."
when_to_use: "User asks for a check-in, reset, review, or strategic recalibration."
when_not_to_use: "Single isolated question with no strategic update needed."
success_criteria: "Graph reflects current reality: updated hubs, changed priorities, and explicit deltas."
---
# Calibration
## Objective
Re-anchor the graph to the user's current state.
## Check-in Sequence
1. Review major hub nodes and active project nodes.
2. Ask what changed: goals, priorities, constraints, beliefs, preferences.
3. Identify stale nodes and missing nodes.
4. Propose precise updates: update existing vs create new.
5. Apply changes with explicit rationale.
## Write Guidance
- Prefer updating existing nodes when continuity matters.
- Create new nodes for genuine shifts in direction/identity/approach.
- Add edges that explain evolution (old -> new).
## Output
- What changed
- What was updated vs newly created
- What should be reviewed next check-in
+26
View File
@@ -0,0 +1,26 @@
---
name: Connect
description: "Create and refine meaningful relationships between nodes, including integration-style synthesis links."
when_to_use: "User asks to connect ideas, merge insights, or strengthen graph relationships."
when_not_to_use: "Task is purely node creation with no relationship work required."
success_criteria: "High-signal edges improve retrieval quality and graph coherence."
---
# Connect
## Goal
Turn isolated nodes into a useful reasoning graph.
## Process
1. Identify candidate nodes to connect.
2. Check existing relationships first.
3. Add/upgrade edges with explicit directional explanation.
4. When integrating multiple nodes, create synthesis links that preserve provenance.
## Quality Bar
- Edge explanation must answer: "why does this relationship exist?"
- Direction should be intentional and interpretable.
- Avoid obvious/tautological edges.
+42
View File
@@ -0,0 +1,42 @@
---
name: Create Skill
description: "Design or refine a skill using a tight trigger, explicit contract, and measurable outcomes."
when_to_use: "User asks to create, rewrite, or improve a skill."
when_not_to_use: "Task is normal graph operation and no new skill is needed."
success_criteria: "Skill has clear trigger boundaries, execution steps, guardrails, and evaluation hooks."
---
# Create Skill
## Objective
Create skills that are precise, callable, and testable.
## Skill Design Standard
1. Define trigger boundary clearly: when to use and when not to use.
2. Define required outputs and quality bar.
3. Specify concrete execution sequence.
4. Add hard guardrails (what to reject/avoid).
5. Keep it short; remove fluff and duplicate policy text.
## Required Structure
- `name`
- `description`
- `when_to_use`
- `when_not_to_use`
- `success_criteria`
- Step-by-step procedure
- Do-not list
## Validation Checklist
- Can another agent execute this without guessing?
- Does it avoid overlap with existing skills?
- Are failure modes explicit?
- Is there an obvious way to evaluate success?
## Consolidation Rule
If two skills have the same trigger + same tool path + same output contract, merge them.
+37
View File
@@ -0,0 +1,37 @@
---
name: DB Operations
description: "Use this for all graph read/write operations with strict data quality standards."
when_to_use: "Any request to read, create, update, connect, classify, or traverse graph data."
when_not_to_use: "Pure conversation with no graph interaction needed."
success_criteria: "Writes are explicit and correct; descriptions are concrete; edges and dimensions are high-signal."
---
# DB Operations
## Core Rules
1. Search before create to avoid duplicates.
2. Every create/update must include an explicit description of WHAT the thing is and WHY it matters.
3. Use event dates when known (when it happened, not when saved).
4. Apply dimensions deliberately; prefer existing dimensions over creating noisy new ones.
5. Create edges when relationships are meaningful; edge explanations should read as a sentence.
## Write Quality Contract
- `title`: clear and specific.
- `description`: concrete object-level description, not vague summaries.
- `notes/content`: extra context, analysis, supporting detail.
- `link`: external source URL only.
## Execution Pattern
1. Read context (search + relevant nodes + relevant edges).
2. Decide: create vs update vs connect.
3. Execute minimum required writes.
4. Verify result reflects user intent exactly.
## Do Not
- Create duplicate nodes when an update is correct.
- Write vague descriptions ("discusses", "explores", "is about").
- Create weak or directionless edges.
+34
View File
@@ -0,0 +1,34 @@
---
name: Onboarding
description: "Onboard a new user by mapping goals, projects, worldview, and preferences into a strong initial graph."
when_to_use: "New user setup or major reset of account context."
when_not_to_use: "User asks for a narrow tactical operation only."
success_criteria: "User has an initial hub-node structure and clear next steps for graph growth."
---
# Onboarding
## Goal
Understand the user deeply enough to bootstrap a useful externalized context graph.
## Interview Flow
1. Clarify outcomes: goals for this system and success horizon.
2. Map active projects: responsibilities, timelines, decision pressure.
3. Capture worldview: beliefs, principles, working assumptions, decision criteria.
4. Capture identity/context anchors: roles, domains, recurring themes.
5. Capture interaction preferences: style, rigor, speed vs depth, tone.
## Graph Bootstrap
1. Propose 3-6 hub nodes with clear rationale.
2. Propose starter dimensions that reflect real domains.
3. Create initial edges between hubs and active projects.
4. Confirm with user before writing.
## Output
- Initial hub map
- Suggested first write actions
- Suggested weekly maintenance rhythm
+30
View File
@@ -0,0 +1,30 @@
---
name: Persona
description: "Build and maintain a user-defined agent persona and interaction style profile."
when_to_use: "User asks to set or refine how the agent should behave."
when_not_to_use: "No behavior/persona request is present."
success_criteria: "Persona is explicit, editable, and consistently applied across interactions."
---
# Persona
## Objective
Make agent behavior fully malleable to the user.
## Capture Model
1. Communication style (directness, brevity, tone).
2. Thinking style (exploratory vs decisive, framework-heavy vs practical).
3. Decision style (challenge level, risk posture, evidence threshold).
4. Collaboration style (pushback expectations, cadence, format preferences).
## Persistence Pattern
- Store persona as explicit nodes (and updates over time), not hidden assumptions.
- Keep versioned changes visible to the user.
## Do Not
- Freeze persona permanently.
- Apply unstated style assumptions when user instructions conflict.
+28
View File
@@ -0,0 +1,28 @@
---
name: Traverse
description: "Gather deeper context by traversing connected nodes before answering."
when_to_use: "Question benefits from broader context than a single direct lookup."
when_not_to_use: "Simple factual answer can be resolved from one direct node."
success_criteria: "Answer is grounded in relevant connected context without over-traversal noise."
---
# Traverse
## Strategy
1. Start with seed nodes from the user query.
2. Expand neighbors breadth-first with depth limits.
3. Prioritize high-signal nodes (strong relevance + strong edge semantics).
4. Pull key evidence from top nodes.
5. Answer directly and explain why chosen nodes mattered.
## Defaults
- Depth: 2
- Seed count: 3-5
- Exploration budget: ~40 nodes
## Do Not
- Traverse without limits.
- Include distant low-signal nodes just to add volume.