BC Unify
Harmony analysis across any set of inputs (systems, rules, skills, goals, documents, plans), defaulting to all of LifeOS and its subcomponents when none are named. Extracts each input's core principles and ultimate aim, maps where they reinforce, pull in productive tension, duplicate, or work against each other, runs FirstPrinciples, Superior and SystemsThinking (plus other thinking skills as fit) to find the real conflicts, and recommends ranked changes that bring the whole into unity. Read-only; recommends, never edits. USE WHEN unify, harmonize, harmony check, are these in harmony, are these working against each other, do these conflict, where do these contradict, coherence check, unify LifeOS, is LifeOS coherent, are my systems fighting each other, alignment across components, bring these into unity. NOT FOR attacking one plan (RedTeam), feedback loops of one system (SystemsThinking), trimming prompt rules (BitterLessonEngineering), climbing one target (HillClimb), editing personal goals (use Telos).
Promises to analyze harmony across any set of inputs—systems, rules, skills, goals, documents, plans. Extracts core principles from each, maps reinforcement points, productive tensions, duplicates, and conflicts, then recommends ranked changes for unity.
Contains 5 files and 1 script totaling 902 tokens. Quality score 79, process score 57. No critical findings, no lint errors. Never ran on models, no sandbox test. Works read-only—analyzes only, recommends changes without executing them. Supports 10 platforms including Claude and Cursor.
Use it to surface contradictions between documents or check whether goals and rules pull in opposite directions. Without model runs, deploying it on production logic is a gamble—no proof it actually catches real conflicts.
Harmony analysis across any set of inputs (systems, rules, skills, goals, documents, plans), defaulting to all of LifeOS and its subcomponents when none are…
As a process C 57/100 · Has gaps — weak spots: result and completion, inputs and preconditions, failures and branches
How to improve
- Your own cases (evals/evals.json, 4–6 real requests with expected answers): the full check would then run those instead of a model-drafted suite.
- A spec.yaml with trigger phrases and assertions — a behaviour contract for CI; `skilltest init` writes a template.
Guard findings · 0
✓ No critical or high findings
Files scanned: 5. Evidence is masked. Grey chips explain why severity was lowered.
Against the Agent Skills spec
- warning
name-formatname should be kebab-case (lowercase letters, digits, hyphens) - note
frontmatter-keyunknown frontmatter key "evals"
Process rating: all ten parameters 57/100
- 0Result and completion. Does not say what the result is
- 0Inputs and preconditions. Does not say what the process needs to start
- 0Failures and branches. Linear process with no failure handling
- 0Progress reporting. Says nothing while it works
- 50When it triggers. No condition that starts the skill
- 100Tools and files. No external tools needed
- 100Steps. 7 steps
- 100Consistency. Name and required fields are in place
- 100Execution cost. Instruction body is 902 tokens
- 100Running it twice. No mutating operations
Everything here is measured from the skill text rather than judged by a model, so the numbers are checkable. A parameter weighs more when it is a more common reason for the process to stall.
Quality signals
- +5Description has no quoted example phrases that should trigger the skill
- +3Description length 1019: 120–800 characters recommended
- +3Output format is not stated: the model decides each time
- +1No license
- +2Single-language instructions
- +4Description says when NOT to use the skill
- +4Structure: 6 headings
- +3Step-by-step instructions: 7 items
- +4Has examples (3 code blocks)
Quality base 70; lint remarks subtract, signals add up to 100. Result: 79.