td-ai-tools 1.2.2 → 1.2.4

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.
@@ -1,131 +0,0 @@
1
- ---
2
- name: car-ticket-generator
3
- version: 1.0.0
4
- description: Generate a ticket for the codex-auto-runner queue
5
- alwaysApply: false
6
- ---
7
-
8
- # CAR Ticket Skill
9
-
10
- Generate a ticket for the Codex-Auto-Runner ticket queue
11
-
12
- ---
13
-
14
- ## 1) Ticket files
15
-
16
- - Filename: `TICKET-###*.md`
17
- Examples: `TICKET-001.md`, `TICKET-120-api-parity.md`
18
- - Tickets **must be in ascending numeric order**.
19
- - Numbers **do not need to be consecutive**.
20
- Leave gaps if follow-up tickets are likely.
21
- - Location: `.codex-autorunner/tickets`
22
-
23
- ---
24
-
25
- ## 2) Required frontmatter (minimum)
26
-
27
- ```yaml
28
- ---
29
- agent: 'codex'
30
- done: false
31
- ---
32
- ```
33
-
34
- Required (linted):
35
-
36
- - `agent`: registered CAR agent id for this repo (for example `codex`, `opencode`) or the special value `user`
37
- - `done`: boolean
38
-
39
- Do not use assistant product names as `agent` values (for example `chatgpt` or `claude`) unless those exact ids are configured in CAR for this repo.
40
-
41
- Common optional fields:
42
-
43
- - `title`: short, outcome-focused summary
44
- - `goal`: one-sentence statement of intent
45
- - `model`: pin a specific model when necessary
46
-
47
- ---
48
-
49
- ## 3) Recommended ticket body structure
50
-
51
- Keep tickets concise and independently verifiable.
52
-
53
- Preferred sections:
54
-
55
- - `## Tasks` - concrete implementation steps
56
- - `## Acceptance criteria` (or `## Exit criteria`) - observable outcomes
57
- - `## Tests` - commands or explicit verification steps
58
- - `## Notes` - only if necessary
59
-
60
- Write criteria so another agent can prove completion without guesswork.
61
-
62
- ---
63
-
64
- ## 4) Sequencing rules (critical)
65
-
66
- CAR's `ticket_flow`:
67
-
68
- - Executes tickets in ascending order
69
- - Picks the first ticket where `done != true`
70
-
71
- Implications:
72
-
73
- - Put prerequisites in lower-numbered tickets.
74
- - Never make a lower-numbered ticket depend on a higher-numbered one.
75
- - If reverse dependencies appear, reorder or split tickets.
76
- - Each ticket must be independently completable when its turn arrives.
77
-
78
- ---
79
-
80
- ## 5) Assignment defaults
81
-
82
- - Implementation work -> repo agents (`codex`, `opencode`, etc.).
83
- - Final human review/signoff -> user-assigned ticket near the end.
84
- - In PMA mode, prefer delegation, not direct code edits.
85
-
86
- ---
87
-
88
- ## 6) Quality bar for good tickets
89
-
90
- A good ticket:
91
-
92
- - Has a single, well-scoped outcome
93
- - References specific files/modules when useful
94
- - Includes explicit verification (tests, checks, or observable behavior)
95
- - Avoids vague language (`"improve"`, `"clean up"`, `"fix issues"`) without criteria
96
-
97
- ---
98
-
99
- ## 7) Copy-paste ticket template
100
-
101
- ```md
102
- ---
103
- title: '<Outcome-focused title>'
104
- agent: 'codex'
105
- done: false
106
- goal: '<What will be true when this ticket is complete>.'
107
- ---
108
-
109
- ## Tasks
110
-
111
- - <Concrete implementation step>
112
- - <Concrete implementation step>
113
-
114
- ## Acceptance criteria
115
-
116
- - <Observable behavior or artifact>
117
- - <Observable behavior or artifact>
118
-
119
- ## Tests
120
-
121
- - <Commands to run or explicit checks>
122
- ```
123
-
124
- ---
125
-
126
- ## 8) Anti-patterns to reject
127
-
128
- - Missing or invalid frontmatter
129
- - Cross-ticket dependency deadlocks
130
- - Tickets that rely on unstated or hidden context
131
- - `done: true` without evidence against acceptance criteria
@@ -1,4 +0,0 @@
1
- interface:
2
- display_name: 'Car Ticket Generator'
3
- short_description: 'Generate a car ticket for the user'
4
- default_prompt: 'Generate a car ticket for the user'
@@ -1,2 +0,0 @@
1
- EVERHOUR_API_KEY=replace-with-everhour-api-key
2
- EVERHOUR_PROJECT_ID=ev:1234567890
@@ -1,75 +0,0 @@
1
- ---
2
- name: everhour-basecamp-estimates
3
- version: 1.0.0
4
- description: Bulk update Everhour task estimates from a Basecamp todo or todolist URL, then append bracketed hours to the Basecamp todo titles.
5
- alwaysApply: false
6
- ---
7
-
8
- Use this skill when the user wants to update Everhour task estimates in bulk from a Basecamp todo or todolist URL.
9
-
10
- ## Files
11
-
12
- - Local config: `.agents/skills/everhour-basecamp-estimates/.env`
13
- - Example config: `.agents/skills/everhour-basecamp-estimates/.env.example`
14
- - Workflow script: `.agents/skills/everhour-basecamp-estimates/scripts/update_estimates.py`
15
-
16
- ## Required inputs
17
-
18
- - A Basecamp todo or todolist URL
19
- - Either one estimate in hours to apply to every active task, or a JSON array of per-task estimates in hours
20
-
21
- ## Workflow
22
-
23
- 1. Confirm `.agents/skills/everhour-basecamp-estimates/.env` exists and contains:
24
- - `EVERHOUR_API_KEY`
25
- - `EVERHOUR_PROJECT_ID`
26
- 2. Run the bundled script from the repo root:
27
-
28
- ```bash
29
- python3 .agents/skills/everhour-basecamp-estimates/scripts/update_estimates.py \
30
- "https://3.basecamp.com/..." \
31
- 2.5
32
- ```
33
-
34
- 3. For todolists that need different estimates per todo, pass a JSON array. The array length must match the number of active todos after completed items are skipped:
35
-
36
- ```bash
37
- python3 .agents/skills/everhour-basecamp-estimates/scripts/update_estimates.py \
38
- "https://3.basecamp.com/..." \
39
- "[1,2.5,4]"
40
- ```
41
-
42
- 4. Use `--dry-run` first if the user wants to review matches before mutating anything:
43
-
44
- ```bash
45
- python3 .agents/skills/everhour-basecamp-estimates/scripts/update_estimates.py \
46
- "https://3.basecamp.com/..." \
47
- "[1,2.5,4]" \
48
- --dry-run
49
- ```
50
-
51
- ## Behavior
52
-
53
- - The script parses the Basecamp URL with the Basecamp CLI.
54
- - For a todo URL, it loads one todo title.
55
- - For a todolist URL, it loads every todo title in that list.
56
- - Completed Basecamp todos are skipped.
57
- - A scalar estimate is applied to each active todo.
58
- - A JSON estimate array is applied in active-todo order and must match the active todo count exactly.
59
- - It matches Basecamp titles against Everhour task names inside the configured project.
60
- - If multiple Everhour tasks have the same normalized title, it selects the task whose Everhour task id or URL maps to the Basecamp todo id.
61
- - Matching is exact after normalization:
62
- - trim whitespace
63
- - collapse repeated spaces
64
- - case-insensitive compare
65
- - strip a trailing estimate suffix like `[2.5h]` before matching
66
- - It updates Everhour estimates first, converting hours to seconds and sending an overall estimate.
67
- - Only after all Everhour updates succeed does it rename the Basecamp todos to append the bracketed hours suffix.
68
-
69
- ## Guardrails
70
-
71
- - If any Basecamp title has no Everhour match, stop and report it.
72
- - If any Basecamp title matches more than one Everhour task and the Basecamp todo id cannot resolve one task, stop and report the ambiguity.
73
- - If an estimate array length does not match the active todo count, stop before any updates.
74
- - If the provided todo URL is already completed, stop without updating anything.
75
- - Do not update Basecamp titles before Everhour updates complete.
@@ -1,4 +0,0 @@
1
- interface:
2
- display_name: 'Everhour Estimates'
3
- short_description: 'Bulk sync Everhour estimates from Basecamp todos.'
4
- default_prompt: 'Use $everhour-basecamp-estimates to update Everhour task estimates from a Basecamp todo or todolist URL.'