claudify-agent 1.0.6 → 1.0.7

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.
@@ -0,0 +1,20 @@
1
+ ---
2
+ description: Scan the project and draft BACKBONE.md (project map loaded every session)
3
+ argument-hint: [extra notes about the project]
4
+ ---
5
+
6
+ Draft or refresh `BACKBONE.md` at the project root. Notes from me: $ARGUMENTS
7
+
8
+ 1. Scan shallowly, do not read whole trees:
9
+ - manifests: package.json, go.mod, pyproject.toml, foundry.toml, Cargo.toml, docker/compose files;
10
+ - top-level dirs (and sub-repos if this is a multi-repo workspace);
11
+ - README, CLAUDE.md, `docs/` file names and first headings; `openspec/` or `spec/` if present;
12
+ - CI workflows for the real lint/test/build commands.
13
+ 2. Fill every section of the existing `BACKBONE.md` (or the template if missing):
14
+ - Docs index: one line per doc, with status. Mark a doc outdated only with evidence (superseded note, archive folder, version mismatch); otherwise ask.
15
+ - Capabilities: one line per `spec/specs/*.md` (or `openspec/specs/*/` if migrating from OpenSpec).
16
+ - Invariants: only rules found in docs or that I confirm. Never invent business rules.
17
+ 3. Keep it under ~80 lines. Link, never copy.
18
+ 4. List what you could not determine as questions, batched in one message.
19
+ 5. Set `Last synced: <HEAD short sha> (<date>)` so `/backbone-sync` can diff from here.
20
+ 6. Show the full diff and wait for my approval before writing.
@@ -0,0 +1,20 @@
1
+ ---
2
+ description: Re-sync BACKBONE.md with the current source after work done without specs
3
+ argument-hint: [area to focus on]
4
+ ---
5
+
6
+ Sync `BACKBONE.md` with the code as it is now. Focus: $ARGUMENTS
7
+
8
+ 1. Find what changed since the last sync:
9
+ - read the `Last synced:` commit in `BACKBONE.md`; run `git log --stat <commit>..HEAD` (and `git status` for uncommitted work);
10
+ - no commit recorded → fall back to the shallow scan of `/backbone-init`.
11
+ Read only the changed files that matter (manifests, new dirs, new docs, CI, public APIs); not every diff line.
12
+ 2. Compare against `BACKBONE.md` section by section and list gaps:
13
+ - Structure: new / moved / removed modules or repos;
14
+ - Docs index: new docs, docs that now contradict the code (candidate outdated);
15
+ - Commands: scripts or CI steps that changed;
16
+ - Capabilities: behaviour that exists in code but has no `spec/specs/*.md` entry;
17
+ - Open changes: entries whose `spec/changes/*.md` is gone or done.
18
+ 3. Also compare with `spec/specs/*.md` for the touched areas. Report code that contradicts an archived requirement, but do not edit specs: that is my call (fix the code or open a change).
19
+ 4. Ask me about anything you cannot decide from evidence, batched in one message. Never invent invariants.
20
+ 5. Show the `BACKBONE.md` diff, including `Last synced: <HEAD short sha> (<date>)`, and wait for my approval before writing.
@@ -9,7 +9,8 @@ If the argument is empty, infer the lesson from the correction I made earlier in
9
9
 
10
10
  1. State the lesson as one imperative line: what to do (or never do) and when. Add a one-line why if not obvious.
11
11
  2. Pick where it belongs, most specific first:
12
- - business invariant of this project → Invariants in `spec/config.md`;
12
+ - business invariant or project-wide fact (e.g. a doc is outdated) → Invariants or Docs index in `BACKBONE.md`;
13
+ - how specs should be written → `spec/config.md`;
13
14
  - a technology or practice covered by a skill → that `.claude/skills/<name>/SKILL.md`, under a `## Lessons` section;
14
15
  - general working style → `.claude/rules/lessons.md` (always loaded, keep it under 30 lines).
15
16
  3. Check the target for an existing rule that covers it; if so, sharpen that line instead of adding a duplicate.
@@ -5,7 +5,7 @@ argument-hint: <change-name> [task number]
5
5
 
6
6
  Implement spec change: $ARGUMENTS
7
7
 
8
- 1. Read `spec/changes/<change-name>.md` and the Invariants in `spec/config.md`. Nothing else up front; read code only as each task needs it.
8
+ 1. Read `spec/changes/<change-name>.md`; respect the Invariants in `BACKBONE.md`. Nothing else up front; read code only as each task needs it.
9
9
  2. Take the requested task, or the first unchecked `- [ ]` task. Work one task at a time.
10
10
  3. Implement it, then run its DoD. Fix until it passes (max 5 attempts, then stop and report).
11
11
  4. Tick it `- [x]` in the change file. If reality differs from the spec, update the spec (Requirements/Design) in the same step and tell me.
@@ -11,4 +11,5 @@ Archive spec change: $ARGUMENTS
11
11
  - ADDED → append. MODIFIED → replace the requirement of the same name in full. REMOVED → delete it.
12
12
  - If a MODIFIED/REMOVED name does not exist in the backbone, stop and ask instead of guessing.
13
13
  3. Move the change file to `spec/changes/archive/YYYY-MM-DD-<change-name>.md`.
14
- 4. Show me the diff of `spec/specs/` in a short summary.
14
+ 4. Update `BACKBONE.md`: remove the change from "Open changes"; add or update the one-line entry under "Capabilities" for each capability touched.
15
+ 5. Show me the diff of `spec/specs/` in a short summary.
@@ -5,7 +5,7 @@ argument-hint: <change-name> <what the feature should do>
5
5
 
6
6
  Create a spec change for: $ARGUMENTS
7
7
 
8
- 1. Read `spec/config.md` (stop and offer to create it from the template if missing). Read only the `spec/specs/*.md` capabilities this feature touches, and only the source-of-truth sections it needs.
8
+ 1. `BACKBONE.md` is already in context. Read `spec/config.md`, then only the `spec/specs/*.md` capabilities this feature touches and only the doc sections from the Docs index it needs.
9
9
  2. Ask me (one batched question) anything that changes scope. Do not guess scope.
10
10
  3. Write `spec/changes/<change-name>.md` with exactly these sections, following the rules in `spec/config.md`:
11
11
 
@@ -36,4 +36,5 @@ Status: draft | Depends on: <change or none>
36
36
 
37
37
  4. Keep the whole file under ~800 words, plus ~300 per extra capability. No restating config, docs or code; link them.
38
38
  If it still does not fit (e.g. more than 4 capabilities), propose splitting into smaller changes with `Depends on:` instead of one giant spec.
39
- 5. Do not write code. Finish by showing the task list and asking me to approve before `/spec-apply`.
39
+ 5. Add the change as one line under "Open changes" in `BACKBONE.md`.
40
+ 6. Do not write code. Finish by showing the task list and asking me to approve before `/spec-apply`.
package/CLAUDE.md CHANGED
@@ -4,6 +4,12 @@
4
4
 
5
5
  ---
6
6
 
7
+ ## 0. 🗺️ Project Backbone (always loaded)
8
+ @BACKBONE.md
9
+
10
+ If it still holds `<placeholders>`, suggest `/backbone-init`. Follow its Invariants on every task.
11
+ If you finish work without a spec that changes structure, docs, commands or capabilities, suggest `/backbone-sync`.
12
+
7
13
  ## 1. 🛑 Context & Token Preservation (Sub-20 Line Core)
8
14
  - Keep responses concise and targeted. Never dump entire files when diffs suffice.
9
15
  - Do NOT read whole directory trees. Inspect shallow structure first.
package/bin/cli.js CHANGED
@@ -41,13 +41,19 @@ if (command === 'init') {
41
41
  console.log(` ⚠️ Kept your existing .claude/settings.json — merge the "hooks" block from ${settingsSrc} manually.`);
42
42
  }
43
43
 
44
- // 3. Scaffold spec/ for the feature workflow (never overwrite an existing config)
45
- const specConfig = join(targetDir, 'spec', 'config.md');
46
- if (existsSync(specConfig)) {
47
- console.log(' ⚠️ Kept your existing spec/config.md');
48
- } else {
49
- await cp(join(packageRoot, 'templates', 'spec', 'config.md'), specConfig);
50
- console.log(' ✅ Created spec/config.md (fill in context & invariants, then use /spec-new)');
44
+ // 3. Scaffold BACKBONE.md and spec/ (never overwrite existing files)
45
+ const templates = [
46
+ ['BACKBONE.md', 'project map loaded every session; run /backbone-init to fill it'],
47
+ ['spec/config.md', 'rules for /spec-new'],
48
+ ];
49
+ for (const [file, purpose] of templates) {
50
+ const dest = join(targetDir, file);
51
+ if (existsSync(dest)) {
52
+ console.log(` ⚠️ Kept your existing ${file}`);
53
+ } else {
54
+ await cp(join(packageRoot, 'templates', file), dest);
55
+ console.log(` ✅ Created ${file} (${purpose})`);
56
+ }
51
57
  }
52
58
 
53
59
  console.log('\n🎉 Successfully initialized Claudify!');
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "claudify-agent",
3
- "version": "1.0.6",
3
+ "version": "1.0.7",
4
4
  "description": "Enterprise-grade workflow & context optimization framework for Claude Code, Claude Desktop, and AI coding agents.",
5
5
  "repository": {
6
6
  "type": "git",
@@ -0,0 +1,40 @@
1
+ # Project Backbone
2
+
3
+ > Loaded every session. A map, not documentation: link to details, never copy them. Keep under ~80 lines.
4
+ > Fill with `/backbone-init`; kept in sync by `/spec-new`, `/spec-archive` and `/learn`; after work done without specs, run `/backbone-sync`.
5
+
6
+ Last synced: <commit> (<date>)
7
+
8
+ ## Overview
9
+ - What: <one or two lines: what the system does and for whom>
10
+ - Stack: <languages, frameworks, infra>
11
+
12
+ ## Structure
13
+ | Path / repo | Role |
14
+ |---|---|
15
+ | <path> | <what lives there> |
16
+
17
+ ## Docs index
18
+ | Doc | About | Status |
19
+ |---|---|---|
20
+ | <path> | <topic> | current / outdated (do not use for X) |
21
+
22
+ ## Capabilities
23
+ <!-- One line per spec/specs/<capability>.md -->
24
+ - <capability>: <one line>
25
+
26
+ ## Open changes
27
+ <!-- One line per spec/changes/<name>.md not yet archived -->
28
+ - none
29
+
30
+ ## Commands
31
+ - Install: <cmd>
32
+ - Verify (DoD default): <lint && typecheck && test>
33
+
34
+ ## Invariants
35
+ <!-- Rules every change MUST respect. One line each. -->
36
+ - <e.g. money amounts are integers in base units, never floats>
37
+
38
+ ## Conventions
39
+ - Branch / commit: <e.g. feat/<topic> from develop, conventional commits>
40
+ - Language & style: <e.g. Vietnamese prose, English technical terms>
@@ -1,27 +1,16 @@
1
1
  # Spec Config
2
2
 
3
- > Read by `/spec-new` and `/spec-apply` only. Keep it short: every line here is paid for on each spec command.
3
+ > Rules for writing spec changes, read by `/spec-new` only. Project context, invariants and commands live in `BACKBONE.md`.
4
4
 
5
- ## Context
6
- - Project: <one or two lines: what the system does>
7
- - Stack: <languages, frameworks>
8
- - Sources of truth (read before writing a change): <design docs, ADRs>. If a change contradicts them, stop and say so.
5
+ ## Proposal
6
+ - Must have Why, Scope (in / out = Non-goals), Depends on, Risks.
7
+ - Reference docs by section instead of copying them.
9
8
 
10
- ## Invariants
11
- <!-- Rules every change MUST respect. One line each. -->
12
- - <e.g. money amounts are integers in base units, never floats>
9
+ ## Requirements
10
+ - `#### ADDED|MODIFIED|REMOVED Requirement: <name>` containing SHALL or MUST.
11
+ - Each has scenarios GIVEN / WHEN / THEN with concrete values: at least one happy path and one failure.
13
12
 
14
- ## Style
15
- - Language: <e.g. Vietnamese prose, English technical terms and spec keywords>
16
- - Concise: bullets, tables, short snippets. Reference docs by section instead of copying them.
17
-
18
- ## Rules
19
- ### Proposal
20
- - Must have Why, Scope (in / out = Non-goals), Depends on, Affected capabilities, Risks.
21
- ### Requirements
22
- - `### Requirement: <name>` containing SHALL or MUST.
23
- - Each has `#### Scenario:` GIVEN / WHEN / THEN with concrete values: at least one happy path and one failure.
24
- ### Tasks
13
+ ## Tasks
25
14
  - Each task fits in 2-4 hours, lists files/packages touched and its DoD.
26
15
  - Tests ship with the task that adds the logic, not at the end.
27
- - DoD default: <e.g. `npm run lint && npm run typecheck && npm test`>
16
+ - DoD default: the Verify command in `BACKBONE.md`.