schub 0.1.25 → 0.1.26

package/drizzle/0010_restructure_templates.sql

@@ -0,0 +1,11 @@
+DROP TABLE IF EXISTS `templates`;--> statement-breakpoint
+CREATE TABLE `templates` (
+	`id` text PRIMARY KEY NOT NULL,
+	`project_id` text REFERENCES `projects`(`id`) ON DELETE set null,
+	`name` text NOT NULL,
+	`template_type` text NOT NULL,
+	`file_id` text NOT NULL REFERENCES `files`(`id`),
+	`is_default` integer NOT NULL DEFAULT 0,
+	`created_at` text NOT NULL,
+	`updated_at` text NOT NULL
+);

package/drizzle/meta/_journal.json

@@ -71,6 +71,13 @@
       "when": 1771891200000,
       "tag": "0009_refactor_workspace_artifacts",
       "breakpoints": true
+    },
+    {
+      "idx": 10,
+      "version": "6",
+      "when": 1771977600000,
+      "tag": "0010_restructure_templates",
+      "breakpoints": true
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "schub",
-  "version": "0.1.25",
+  "version": "0.1.26",
   "type": "module",
   "imports": {
     "#services": "./src/services.ts"

package/skills/create-proposal/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: create-proposal
-description: "Create or update proposals and review requirements with the user. Use this when asked to write a proposal, introduce changes that add features, large refactors, introduce breaking API or schema changes, modify architecture or design patterns, update security patterns, or after creating a plan, to save a plan as proposal. Do not create proposals for bug fixes that restore intended behavior, typos or formatting/comment-only changes, non-breaking dependency updates, configuration-only changes, or tests that validate existing behavior."
+description: "Create or update proposals. Use this when asked to write a proposal, introduce changes that add features, large refactors, introduce breaking API or schema changes, modify architecture or design patterns, update security patterns, or after creating a plan, to save a plan as proposal. Do not create proposals for bug fixes that restore intended behavior, typos or formatting/comment-only changes, non-breaking dependency updates, configuration-only changes, or tests that validate existing behavior."
 ---
 
 ## User Input
@@ -12,28 +12,25 @@ $ARGUMENTS
 ## Workflow
 
 1. Derive a concise, verb-led `title` from the request (kebab-case: `add-`, `update-`, `remove-`, `refactor-`, `fix-`).
-2. Run `npx schub proposals write --title "<title>" --input "<user prompt verbatim>"` to scaffold the proposal template.
-   - Treat the scaffolded file as temporary while drafting the proposal.
-   - Supported flags: `--title`, `--input`, `--overwrite`.
-3. Capture the generated proposal-id from the command output or the created path under `.schub/proposals/<proposal-id>/`.
-4. Update the generated proposal with concrete, testable statements.
-5. Identify the touch points throughout the project and track them in the proposal.
-6. Track missing information with [MISSING INFORMATION] tags in the proposal.
-7. (OPTIONAL) If the change affects a public surface, e.g. an api / sdk / cli. Run `npx schub templates create --name "cookbook" --proposal-id "<proposal-id>"` to scaffold `cookbook.md`.
-8. (OPTIONAL) If implementing the change requires knowledge of an api / db schema etc. encode this in a `contracts.md` or `schemas.md` files.
-9. (OPTIONAL) For complex tickets requiring deep understanding of the system, track relevant additional information in `research.md`.
-10. (OPTIONAL) For decisions with lasting architectural impact or important tradeoffs, run `npx schub templates create --name "adr" --proposal-id "<proposal-id>" --title "<title>"`.
-11. Run `npx schub proposals save --proposal-id "<proposal-id>"` to persist the final proposal and related files under `.schub/proposals/<proposal-id>/` (proposal, cookbook, schemas, contracts, research, adr).
+2. Run `npx schub tickets write --title "<title>" --input "<user prompt verbatim>" --status "backlog" --template "proposal-template"` to create a proposal.
+3. Update the proposal with concrete, testable statements.
+4. Identify touch points throughout the project and track them in the proposal sections.
+5. Track missing information with [MISSING INFORMATION] tags in the ticket.
+6. (OPTIONAL) If the change affects a public surface (API, SDK, CLI), run `npx schub templates create --ticket-id "<ticket-id>" --name "cookbook"` to scaffold `cookbook.md`.
+7. (OPTIONAL) If implementing the change requires knowledge of an API, DB schema, etc., encode this in a `contracts.md` or `schemas.md` file in the ticket folder.
+8. (OPTIONAL) For complex tickets requiring deep understanding of the system, track relevant additional information in a `research.md` file in the ticket folder.
+9. (OPTIONAL) For decisions with lasting architectural impact or important tradeoffs, run `npx schub templates create --ticket-id "<ticket-id>" --name "adr" --title "<title>"` to scaffold `adr.md`.
+10. Run `npx schub tickets save --id "<ticket-id>"` to persist the proposal.
 
 ## Output Locations
 
-- Proposal: `.schub/proposals/<proposal-id>/proposal.md`
-- (OPTIONAL) Cookbook: `.schub/proposals/<proposal-id>/cookbook.md`
-- (OPTIONAL) Schemas: `.schub/proposals/<proposal-id>/schemas.md`
-- (OPTIONAL) Contracts: `.schub/proposals/<proposal-id>/contracts.md`
-- (OPTIONAL) Research: `.schub/proposals/<proposal-id>/research.md`
-- (OPTIONAL) ADR: `.schub/proposals/<proposal-id>/adr.md`
+- Proposal: `.schub/tickets/<ticket-id>_<slug>/ticket.md`
+- (OPTIONAL) Cookbook: `.schub/tickets/<ticket-id>_<slug>/cookbook.md`
+- (OPTIONAL) Schemas: `.schub/tickets/<ticket-id>_<slug>/schemas.md`
+- (OPTIONAL) Contracts: `.schub/tickets/<ticket-id>_<slug>/contracts.md`
+- (OPTIONAL) Research: `.schub/tickets/<ticket-id>_<slug>/research.md`
+- (OPTIONAL) ADR: `.schub/tickets/<ticket-id>_<slug>/adr.md`
 
 ## Notes
 
-- **Do not start the implementation** only edit the `.schub/proposals` folder.
+- **Do not start the implementation**. Stop after the proposal content is saved.

package/skills/create-sub-tickets/SKILL.md

@@ -18,28 +18,17 @@ $ARGUMENTS
 4. Read the parent ticket and derive sub-tickets. Each sub-ticket should be:
    - Small enough to implement in one sitting.
    - Independently testable.
-   - Explicit about file paths and affected components.
-   - Include `References` linking to parent/proposal/spec files when available.
    - Include `Implementation Notes` covering assumptions, key decisions, and where to look in code.
    - Include `Acceptance` criteria with explicit tests (file paths, cases covered) and exact commands to run.
    - Include corresponding documentation updates.
 5. Create each sub-ticket via the CLI (one command per sub-ticket):
    - Run `npx schub tickets write --title "<ticket title>" --status "<status>"`.
-   - If the parent ticket has `proposal_id`, include it: `--proposal-id "<proposal-id>"`.
 6. After each `tickets write`, open the generated child ticket and set frontmatter `parent_id` to the parent ticket id:
    - `parent_id: "<parent-ticket-id>"`.
-7. Fill each child ticket template with concrete details:
-   - Priority (P1/P2/P3)
-   - Parallelizable (yes/no)
-   - Goal, scope, steps, acceptance, and evidence
-   - References to existing docs/specs (if any), otherwise record gaps as assumptions
-   - Implementation Notes with key files/modules and decisions
-   - Acceptance with explicit tests, file paths, and exact commands
-   - Documentation updates, or an explicit “no docs” note
-   - If blocked, run `npx schub tickets update --id "<ticket-id>" --status blocked --blocked-reason <reason>`
+7. Fill each child ticket template with concrete details.
 8. Verify every child ticket has `parent_id` set to the parent ticket id before saving.
 9. When defining acceptance, list the exact test file paths, cases covered, and commands to run. Tests must live in the same ticket as the feature/bugfix work. Do not create standalone “add tests” tickets. Tests belong with the functional change they validate.
-10. Resolve blockers by checking all existing tickets that are not done. If another ticket is a blocker, add it to `depends_on` in frontmatter.
+10. Resolve blockers by checking all existing tickets that are not done `npx schub tickets list open`. If another ticket is a blocker, add it to `depends_on` in frontmatter. If blocked, run `npx schub tickets update --id "<ticket-id>" --status blocked --blocked-reason <reason>`
 11. Run `npx schub tickets save --id "<ticket-id>"` for each child ticket to persist updates.
 12. Stop after the sub-ticket files are created. Do not implement code or modify plan artifacts.
 
@@ -47,7 +36,6 @@ $ARGUMENTS
 
 - Parent Ticket: `.schub/tickets/<parent-ticket-id>_<slug>/ticket.md`
 - Sub-tickets: `.schub/tickets/<ticket-id>_<slug>/ticket.md`
-- Validation Artifacts: `.schub/tickets/<ticket-id>_<slug>/artifacts/`
 
 ## Ticket Notes
 

package/skills/create-ticket/SKILL.md

@@ -16,7 +16,6 @@ $ARGUMENTS
    - Otherwise set status to `wip`.
 2. Derive a concise, verb-led ticket title from the user request and immediately run the schub CLI to create the ticket.
    - Run `npx schub tickets write --title "<ticket title>" --input "<user prompt verbatim>" --status "<status>"`.
-   - If the ticket maps to a proposal, include `--proposal-id "<shorthand>"`.
 3. Fill the ticket template with concrete details:
    - Priority (P1/P2/P3)
    - Parallelizable (yes/no)

package/skills/refine-ticket/SKILL.md

@@ -12,12 +12,12 @@ $ARGUMENTS
 ## Workflow
 
 1. Identify the target ticket shorthand from the user request (`TK####`).
-   - If the request includes a template name (e.g. `refine ticket: TK0001 with template create-ticket/ticket-template.md`), extract the template name.
-2. Run `npx schub tickets refine --id "<ticket-shorthand>"` (or `npx schub tickets refine --id "<ticket-shorthand>" --template "<template-name>"` when a template is specified).
+   - If the request includes a template name (e.g. `refine ticket: TK0001 with template proposal-template`), extract the template slug.
+2. Run `npx schub tickets refine --id "<ticket-shorthand>"` (or `npx schub tickets refine --id "<ticket-shorthand>" --template "<slug>"` when a template is specified).
    - This command pulls the ticket from DB if it is not local.
    - It creates `ticket.original.md` in the ticket folder as a backup.
    - It prepends the ticket template into `ticket.md`.
-   - When `--template` is provided, the specified template is used instead of the default `create-ticket/ticket-template.md`.
+   - The `--template` value is a lowercase slug matching the template name in the DB (e.g. `proposal-template`, `ticket-template`).
    - It wraps the original ticket content in:
      - `<MOVE_TO_TEMPLATE>`
      - `</MOVE_TO_TEMPLATE>`

package/skills/review-ticket/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: review-ticket
+description: "Run a review session for a ticket by creating a list of open questions, updating the ticket, adding a Q&A section, and deleting REVIEW_ME.md on completion. Use when asked to review tickets."
+---
+
+## User Input (ticket-id shorthand `TK####`)
+
+```text
+$ARGUMENTS
+```
+
+## Workflow
+
+1. Pull the ticket locally if not already present:
+   - Run `npx schub tickets pull --id "<ticket-id>"`.
+2. Confirm `.schub/tickets/<ticket-id>_<slug>/ticket.md` exists. If it is missing, ask the user to run the create-ticket skill first. If it is still a draft, ask the user to review it first.
+3. Review the ticket by checking the [MISSING INFORMATION] tags and the potential issues listed.
+4. If there are issues, or missing information, run `npx schub templates create --name "review" --ticket-id "<ticket-id>"` to scaffold `REVIEW_ME.md` in the ticket folder.
+5. Triage each item:
+   - **High-stakes** (scope, risks, dependencies, security, performance): create a bullet point item in the review checklist.
+   - **Minute details** (naming, copy, formatting, low-impact defaults): make a decision update the ticket and mark as an assumption.
+6. Once the review checklist is completed, gather unchecked items (`- [ ]`) in order.
+7. Start the review loop (process unchecked items in order), ask each item as a question. If unclear, ask a quick follow-up and do not advance.
+   - Update the review checklist accordingly inline with the answers.
+8. When no unchecked items remain, update the ticket with the new information.
+9. When no unchecked items remain, run `npx schub review complete --ticket-id "<ticket-id>"` to create `Q&A.md` in the ticket folder.
+   - Ask the LLM to migrate the TODO block into the Q&A sections and remove the TODO block.
+10. Mark the ticket Status as "Accepted".
+
+## Output Locations
+
+- Ticket: `.schub/tickets/<ticket-id>_<slug>/ticket.md`
+- (OPTIONAL) Review In Progress: `.schub/tickets/<ticket-id>_<slug>/REVIEW_ME.md`
+- (OPTIONAL) Review Completed: `.schub/tickets/<ticket-id>_<slug>/Q&A.md`
+
+## Notes
+
+- Avoid expanding scope beyond missing information in the ticket.
+- Focus review on high-stakes issues; place details into assumptions instead of asking.
+- **Do not start the implementation** only edit the ticket folder.

package/skills/update-documentation/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: update-documentation
+description: "Use when asked to update, add, or modify project documentation. Pull the latest project documentation, apply updates, and save changes back."
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Workflow
+
+1. Run `npx schub@latest docs pull` to pull the latest persisted documentation snapshot to `.schub/docs`:
+   - If the pull fails because docs have not been initialized, run `npx schub@latest docs init` first, then retry.
+2. Read `.schub/docs/docs.json` to understand the current sidebar structure and available pages.
+3. Apply the requested documentation changes:
+   - **Adding a new page**: create the markdown file under `.schub/docs/`, then add a sidebar entry in `docs.json` with `{ "text": "<title>", "link": "<relative-path>" }`.
+   - **Updating an existing page**: edit the markdown file in place.
+   - **Removing a page**: delete the markdown file and remove its sidebar entry from `docs.json`.
+   - **Reorganizing**: update `docs.json` sidebar order or grouping. Groups use `{ "text": "<group>", "items": [...] }`.
+4. Save the updated documentation:
+   - Run `npx schub@latest docs save`.
+   - Verify the command reports the expected number of updated/removed files.
+5. Summarize the changes made: list added, updated, and removed pages.
+
+## Output Locations
+
+- Documentation files: `.schub/docs/`
+- Sidebar config: `.schub/docs/docs.json`

package/templates/{create-proposal/adr-template.md → adr-template.md}

@@ -1,10 +1,10 @@
 ---
 status: "[Proposed | Accepted | Deprecated | Superseded]"
-date: "[YYYY-MM-DD]"
-related: "[PR link, spec link, plan link, issue link]"
+date: "{{DATE}}"
+related: "{{TICKET_ID}}"
 ---
 
-# ADR: [TITLE]
+# ADR: {{TITLE}}
 
 [What problem are we solving? What constraints, requirements, or incidents led here?]
 

package/templates/{create-proposal/cookbook-template.md → cookbook-template.md}

@@ -1,5 +1,5 @@
 ---
-proposal_id: "{{PROPOSAL_ID}}"
+ticket_id: "{{TICKET_ID}}"
 created: "{{DATE}}"
 ---
 

package/templates/{create-proposal/proposal-template.md → proposal-template.md}

@@ -1,14 +1,22 @@
 ---
-proposal_id: "{{PROPOSAL_ID}}"
+ticket_id: "{{TICKET_ID}}"
 created: "{{DATE}}"
 status: Draft
 input: "{{INPUT}}"
+parent_id: "{{PARENT_ID}}"
+priority: "[P1|P2|P3]"
+complexity: "[low|medium|high]"
+depends_on: []
+parallelizable: "[no|yes]"
+blocked_reason: ""
 ---
 
-# {{TITLE}}
+# {{TICKET_TITLE}}
 
 [1–3 sentences describing the change and the user-visible outcome.]
 
+[This proposal is maintained inside a ticket artifact and should stay implementation-ready.]
+
 ## Why
 
 [Problem/opportunity + motivation. What’s broken/missing today? Why now?]

package/templates/{review-proposal/q&a-template.md → q&a-template.md}

@@ -1,9 +1,9 @@
 ---
-proposal_id: "{{PROPOSAL_ID}}"
+ticket_id: "{{TICKET_ID}}"
 created: "{{DATE}}"
 ---
 
-# Q&A {{CHANGE_TITLE}}
+# Q&A {{TICKET_TITLE}}
 
 ### ❓ <Question 1>
 

package/templates/{review-proposal/review-me-template.md → review-me-template.md}

@@ -1,9 +1,9 @@
 ---
-proposal_id: "{{PROPOSAL_ID}}"
+ticket_id: "{{TICKET_ID}}"
 created: "{{DATE}}"
 ---
 
-# REVIEW_ME: {{CHANGE_TITLE}}
+# REVIEW_ME: {{TICKET_TITLE}}
 
 **Purpose**: Open questions to review requirements with the user.
 

package/templates/{create-ticket/ticket-template.md → ticket-template.md}

@@ -3,8 +3,7 @@ ticket_id: "{{TICKET_ID}}"
 created: "{{DATE}}"
 status: "{{STATUS}}"
 input: "{{INPUT}}"
-proposal_id: "{{PROPOSAL_ID}}"
-parent_id: ""
+parent_id: "{{PARENT_ID}}"
 priority: "[P1|P2|P3]"
 complexity: "[low|medium|high]"
 depends_on: []