to-goal

Name: to-goal
Author: tt-a1i

16stars3forks

How to install to-goal?

tt-a1i/matt-skills-with-to-goal/to-goal

$npx -y skills add tt-a1i/matt-skills-with-to-goal --skill to-goal

Installs into the current project.

Summary

Turn an approved spec, agent-ready ticket, tracker frontier, or partially implemented ticket into a verifiable execution goal without re-interviewing the user. Use after to-tickets or triage, before starting a fresh implementation session; use --all only for an explicitly request

Files · 1

View on GitHub

SKILL.md

1	# To Goal
2
3	Compile existing planning and repository evidence into an execution goal. Do not implement, mutate the tracker, create a branch, or modify files.
4
5	## Source of truth
6
7	Read and follow `../goal-crafter/SKILL.md` in compiled-handoff mode before drafting. It owns the rules for verifiable goals and target-harness formatting; its standalone interview phase does not run here. This skill owns context gathering, frontier selection, readiness checks, and execution handoff. Do not duplicate or weaken `goal-crafter`'s completion-standard rules, and do not re-interview decisions already made by `to-spec`, `to-tickets`, or `triage`.
8
9	## Accepted inputs
10
11	Resolve one of:
12
13	- no argument: inspect the configured tracker and select the current unblocked, agent-ready frontier ticket;
14	- a ticket number or URL: read that ticket in full;
15	- a parent spec issue: read the spec, sub-issues, and blocking graph, then select its current frontier;
16	- a local spec or ticket path: read the complete file and any directly referenced local planning document (local tracker: `.scratch/<feature>/spec.md` and one file per ticket under `.scratch/<feature>/issues/<NN>-<slug>.md`);
17	- `--all <parent>`: generate one dependency-ordered cross-ticket goal.
18
19	Always read ticket comments. For a tracker parent, use native sub-issue and dependency relationships when available; otherwise use explicit blocker text. Do not infer that a ticket is ready merely from its label.
20
21	If no argument yields several frontier tickets, list them and ask the user to choose one. Do not silently combine them. If a requested ticket is blocked, report its blockers and do not generate an implementation goal.
22
23	For a spec with no tickets, generate a goal directly only when the entire work fits one fresh context window. If it is multi-session work, route it through `to-tickets` instead of bypassing the context boundary.
24
25	## Gather current evidence
26
27	Before drafting:
28
29	1. Read the complete source spec and selected ticket, including acceptance criteria and comments.
30	2. Inspect the repository instructions and relevant design vocabulary.
31	3. Inspect the current branch, HEAD, worktree status, recent commits, and diff. Record the pre-implementation HEAD as the code-review fixed point.
32	4. Compare current behavior and tests with every acceptance criterion.
33	5. Classify criteria as evidenced complete, demonstrably incomplete, or unverified. A commit message is not evidence.
34	6. Discover validation commands from the repository's own scripts, CI, documentation, and existing tests.
35	7. Preserve user-established permissions and workspace boundaries from the source context.
36
37	Keep this work read-only. Do not create status artifacts merely to build the goal.
38
39	## Select scope
40
41	Default to exactly one frontier ticket. The generated goal must fit one fresh context window and must not attract work from downstream blocked tickets.
42
43	For `--all`:
44
45	- preserve the complete dependency order;
46	- distinguish the current frontier from future work;
47	- carry forward partially completed work without treating it as done;
48	- warn that the goal requires a persistent harness capable of context renewal;
49	- never present `--all` as the normal Matt workflow.
50
51	## Recommend execution capacity
52
53	Classify the implementation session by required capability, not by a hard-coded model name. The recommendation must remain portable across Claude Code, Codex, Pi, and other coding agents.
54
55	Choose exactly one capability tier:
56
57	- Lightweight: bounded search, inventory, formatting, mechanical edits, or a small change following an established pattern with low failure cost.
58	- Standard: normal feature work, focused bug fixes, tests, or moderate multi-file changes with clear repository patterns. This is the default.
59	- Advanced: difficult root-cause analysis, cross-module design, security or authorization changes, schema/data migrations, concurrency, long-context synthesis, or work where a plausible mistake has high cost.
60
61	Choose exactly one reasoning intensity:
62
63	- Low: deterministic work with little ambiguity and cheap verification.
64	- Medium: some design judgment, multiple affected files, or non-trivial tests. This is the default.
65	- High: ambiguous behavior, interacting invariants, risky migrations, concurrency, security boundaries, or expensive failure modes.
66
67	Recommend the lowest tier and intensity that can reliably complete the ticket. Include one short evidence-based reason. Do not recommend a stronger tier merely because the ticket is large; prefer splitting work when it cannot fit one fresh context window.
68
69	Only name a concrete model when the target

People who liked this also viewed

6 picks

Type

to-goal

16stars3forks

View on GitHub

How to install to-goal?

tt-a1i/matt-skills-with-to-goal/to-goal

$npx -y skills add tt-a1i/matt-skills-with-to-goal --skill to-goal

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# To Goal
2
3	Compile existing planning and repository evidence into an execution goal. Do not implement, mutate the tracker, create a branch, or modify files.
4
5	## Source of truth
6
7	Read and follow `../goal-crafter/SKILL.md` in compiled-handoff mode before drafting. It owns the rules for verifiable goals and target-harness formatting; its standalone interview phase does not run here. This skill owns context gathering, frontier selection, readiness checks, and execution handoff. Do not duplicate or weaken `goal-crafter`'s completion-standard rules, and do not re-interview decisions already made by `to-spec`, `to-tickets`, or `triage`.
8
9	## Accepted inputs
10
11	Resolve one of:
12
13	- no argument: inspect the configured tracker and select the current unblocked, agent-ready frontier ticket;
14	- a ticket number or URL: read that ticket in full;
15	- a parent spec issue: read the spec, sub-issues, and blocking graph, then select its current frontier;
16	- a local spec or ticket path: read the complete file and any directly referenced local planning document (local tracker: `.scratch/<feature>/spec.md` and one file per ticket under `.scratch/<feature>/issues/<NN>-<slug>.md`);
17	- `--all <parent>`: generate one dependency-ordered cross-ticket goal.
18
19	Always read ticket comments. For a tracker parent, use native sub-issue and dependency relationships when available; otherwise use explicit blocker text. Do not infer that a ticket is ready merely from its label.
20
21	If no argument yields several frontier tickets, list them and ask the user to choose one. Do not silently combine them. If a requested ticket is blocked, report its blockers and do not generate an implementation goal.
22
23	For a spec with no tickets, generate a goal directly only when the entire work fits one fresh context window. If it is multi-session work, route it through `to-tickets` instead of bypassing the context boundary.
24
25	## Gather current evidence
26
27	Before drafting:
28
29	1. Read the complete source spec and selected ticket, including acceptance criteria and comments.
30	2. Inspect the repository instructions and relevant design vocabulary.
31	3. Inspect the current branch, HEAD, worktree status, recent commits, and diff. Record the pre-implementation HEAD as the code-review fixed point.
32	4. Compare current behavior and tests with every acceptance criterion.
33	5. Classify criteria as evidenced complete, demonstrably incomplete, or unverified. A commit message is not evidence.
34	6. Discover validation commands from the repository's own scripts, CI, documentation, and existing tests.
35	7. Preserve user-established permissions and workspace boundaries from the source context.
36
37	Keep this work read-only. Do not create status artifacts merely to build the goal.
38
39	## Select scope
40
41	Default to exactly one frontier ticket. The generated goal must fit one fresh context window and must not attract work from downstream blocked tickets.
42
43	For `--all`:
44
45	- preserve the complete dependency order;
46	- distinguish the current frontier from future work;
47	- carry forward partially completed work without treating it as done;
48	- warn that the goal requires a persistent harness capable of context renewal;
49	- never present `--all` as the normal Matt workflow.
50
51	## Recommend execution capacity
52
53	Classify the implementation session by required capability, not by a hard-coded model name. The recommendation must remain portable across Claude Code, Codex, Pi, and other coding agents.
54
55	Choose exactly one capability tier:
56
57	- Lightweight: bounded search, inventory, formatting, mechanical edits, or a small change following an established pattern with low failure cost.
58	- Standard: normal feature work, focused bug fixes, tests, or moderate multi-file changes with clear repository patterns. This is the default.
59	- Advanced: difficult root-cause analysis, cross-module design, security or authorization changes, schema/data migrations, concurrency, long-context synthesis, or work where a plausible mistake has high cost.
60
61	Choose exactly one reasoning intensity:
62
63	- Low: deterministic work with little ambiguity and cheap verification.
64	- Medium: some design judgment, multiple affected files, or non-trivial tests. This is the default.
65	- High: ambiguous behavior, interacting invariants, risky migrations, concurrency, security boundaries, or expensive failure modes.
66
67	Recommend the lowest tier and intensity that can reliably complete the ticket. Include one short evidence-based reason. Do not recommend a stronger tier merely because the ticket is large; prefer splitting work when it cannot fit one fresh context window.
68
69	Only name a concrete model when the target

People who liked this also viewed

6 picks

Type