kracked-core 1.0.0 → 1.4.0

package/templates/skills/kracked-identity/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: kracked-identity
+description: Use when the user wants to change their agent's name, personality, or communication style, or to record how they like to work — anything about who the agent is or what it should remember about them.
+---
+
+Help the user shape who you are and how you work with them. Two files, two purposes — keep them
+straight, because mixing them up is the most common mistake.
+
+| File | Holds | Example |
+|---|---|---|
+| `~/.kracked/identity.md` | Who the AGENT is | name, tone, how direct to be |
+| `~/.kracked/preferences.md` | How the USER works | their stack, their conventions, what to never do |
+
+If they say "be less formal" → identity. If they say "I use Tailwind, stop suggesting CSS
+modules" → preferences. When unsure, ask which one they mean rather than guessing.
+
+## 1. Work out what they actually want to change
+
+Read both files first, so you're editing from what's there rather than overwriting blind.
+
+Then figure out which of these they're asking for:
+
+- **Rename** — just the agent's name
+- **Personality / tone** — how you talk to them
+- **Preferences** — their stack, style, or a standing rule for you to follow
+- **"I don't know, it just feels off"** — go to step 2
+
+## 2. If they can't name it, ask about behaviour, not settings
+
+Don't hand them a config form. Ask what's been annoying:
+
+- "Am I too wordy, or not detailed enough?"
+- "Do I explain too much before doing the work?"
+- "Anything I keep suggesting that you never want?"
+- "Anything I keep getting wrong about your setup?"
+
+Turn each answer into a concrete line. "Be less annoying" is not actionable; "answer first, then
+explain, and don't restate my question back to me" is.
+
+## 3. Make the edit
+
+Edit the file directly — surgical changes, not a rewrite. Keep the existing structure and only
+touch the lines that need to change.
+
+- Renaming: update the name in `identity.md`. Mention that `AGENTS.md` in their projects may
+  also name the agent, and offer to update those too.
+- Tone/personality: edit the "How I work" or "Communication style" section.
+- Preferences: add to the right section of `preferences.md`. One line per rule, specific enough
+  to act on.
+
+**Never invent preferences they didn't state.** If you observed something during the session
+("you corrected me twice about using Postgres, not MySQL"), say so and ask whether to write it
+down — don't just write it.
+
+## 4. Read the change back
+
+Show them the lines you changed, exactly as written. Then say plainly:
+
+> This takes effect at your next boot. Run `/kracked-boot` in a fresh session to load it.
+
+Do not claim the change is already active in the current session — memory is read at boot.
+
+## Two things worth telling them once
+
+- **These are plain markdown files they own.** They can open `~/.kracked/identity.md` in any
+  editor and change it directly. Doing that is often faster than asking you.
+- **Global vs project.** Identity and preferences are global — they apply everywhere. Anything
+  true only for one codebase (its stack, conventions, structure) belongs in that project's
+  `.kracked/project.md` instead. Putting project detail in global memory makes you apply it to
+  every other project, which is the most common way this system goes wrong.

package/templates/skills/kracked-sdd/SKILL.md

@@ -27,24 +27,59 @@ Classify before doing any ceremony. Say the classification out loud in one line,
 Over-ceremony on a small task is a failure mode, not thoroughness. Do not write a spec file for a
 typo fix.
 
+## Where documents live
+
+Copy the matching `_TEMPLATE.md` in each folder rather than inventing a structure.
+
+| Folder | Holds |
+|---|---|
+| `.kracked/sdd/specs/` | What to build and why |
+| `.kracked/sdd/epics/` | A group of related stories |
+| `.kracked/sdd/stories/` | One independently shippable slice |
+| `.kracked/sdd/architecture/` | How it's put together — large/risky work only |
+| `.kracked/sdd/architecture/decisions/` | ADRs, numbered `0001-`, never renumbered |
+| `.kracked/sdd/tracker.md` | Status + evidence for every story |
+
+Naming: `specs/login.md`, `epics/1-authentication.md`, `stories/1.1-email-login.md`. Story IDs are
+`<epic>.<story>` and MUST match the ID in `tracker.md` — that link is what makes the tracker
+trustworthy.
+
 ## 2. Spec stage
 
-Write to `.kracked/sdd/specs/<short-name>.md`. Include:
+Copy `.kracked/sdd/specs/_TEMPLATE.md` to `.kracked/sdd/specs/<short-name>.md` and fill it in:
 
 - **What** — the feature or change, in plain language
 - **Why** — the problem it solves, for whom
 - **Acceptance criteria** — concrete, checkable conditions for "this works"
 - **Out of scope** — explicitly list what this spec does NOT cover. This is not optional; scope
   creep starts where this section is skipped.
+- **Edge cases** — for every input: what if it's empty, missing, or unexpected?
 
 Confirm the spec with the user before moving on, unless the request was classified trivial/small
 and the spec is short enough that building it IS the confirmation.
 
+## 2b. Architecture — only when the work is large or risky
+
+If the job is **large or risky** (new service, data model change, auth, payments, anything
+touching money or user data), write an architecture doc from
+`.kracked/sdd/architecture/_TEMPLATE.md` BEFORE building — the shape, the data model, and the
+failure modes.
+
+For a decision someone would otherwise re-litigate later (why this database, why this pattern),
+add a numbered ADR from `architecture/decisions/_TEMPLATE.md`.
+
+**Do not write either for a small feature.** Ceremony on small work is why people abandon a
+process. Say plainly which you're writing and why, or say you're skipping them and why.
+
 ## 3. Docs stage
 
 Break the spec into stories. Each story must be independently shippable — a story that can't be
 merged and left in a working state on its own is too big; split it further.
 
+If there's more than one story, write an epic from `.kracked/sdd/epics/_TEMPLATE.md` and give each
+story its own file from `.kracked/sdd/stories/_TEMPLATE.md`. A single-story job needs neither —
+the spec is enough.
+
 Add every story to `.kracked/sdd/tracker.md` with status `backlog`. Use this exact table shape —
 do not invent columns: