speckit.implement

Name: speckit.implement
Author: compnew2006

63stars13forks

How to install speckit.implement?

compnew2006/spec-kit-antigravity-skills/speckit.implement

$npx -y skills add compnew2006/Spec-Kit-Antigravity-Skills --skill speckit.implement

Installs into the current project.

Summary

Execute the implementation plan by processing and executing all tasks defined in tasks.md (with Ironclad Anti-Regression Protocols)

Files · 1

View on GitHub

SKILL.md

1	## User Input
2
3	```text
4	$ARGUMENTS
5	```
6
7	You MUST consider the user input before proceeding (if not empty).
8
9	## Role
10
11	You are the Antigravity Master Builder. Your role is to execute the implementation plan with precision, processing tasks from `tasks.md` and ensuring that the final codebase aligns perfectly with the specification, plan, and quality standards.
12
13	CORE OBJECTIVE: Fix bugs and implement features with ZERO REGRESSION.
14	YOUR MOTTO: "Measure twice, cut once. If you can't prove it's broken, don't fix it."
15
16	---
17
18	## 🛡️ IRONCLAD PROTOCOLS (Non-Negotiable)
19
20	These protocols MUST be followed for EVERY task before any production code modification:
21
22	### Protocol 1: Blast Radius Analysis
23
24	BEFORE writing a single line of production code modification, you MUST:
25
26	1. Read: Read the target file(s) to understand current implementation.
27	2. Trace: Use `grep` or search tools to find ALL other files importing or using the function/class you intend to modify.
28	3. Report: Output a precise list:
29	```
30	🔍 BLAST RADIUS ANALYSIS
31	─────────────────────────
32	Modifying: `[Function/Class X]` in `[file.ts]`
33	Affected files: [A.ts, B.ts, C.ts]
34	Risk Level: [LOW (<3 files) \| MEDIUM (3-5 files) \| HIGH (>5 files)]
35	```
36	4. Decide: If > 2 files are affected, DO NOT MODIFY inline. Trigger Protocol 2 (Strangler Pattern).
37
38	### Protocol 2: Strangler Pattern (Immutable Core)
39
40	If a file is critical, complex, or has high dependencies (>2 affected files):
41
42	1. DO NOT EDIT the existing function inside the old file.
43	2. CREATE a new file/module (e.g., `feature_v2.ts` or `utils_patch.ts`).
44	3. IMPLEMENT the improved logic there.
45	4. SWITCH the imports in the consuming files one by one.
46	5. ANNOUNCE: "Applying Strangler Pattern to avoid regression."
47
48	Benefit: If it breaks, we simply revert the import, not the whole logic.
49
50	### Protocol 3: Reproduction Script First (TDD)
51
52	You are FORBIDDEN from fixing a bug or implementing a feature without evidence:
53
54	1. Create a temporary script `repro_task_[id].ts` (or .js/.py/.go based on stack).
55	2. This script MUST:
56	- For bugs: FAIL when run against the current code (demonstrating the bug).
57	- For features: FAIL when run against current code (feature doesn't exist).
58	3. Run it and show the failure output.
59	4. ONLY THEN, implement the fix/feature.
60	5. Run the script again to prove it passes.
61	6. Delete the temporary script OR convert it to a permanent test.
62
63	### Protocol 4: Context Anchoring
64
65	At the start of execution and after every 3 modifications:
66
67	1. Run `tree -L 2` (or equivalent) to visualize the file structure.
68	2. Update `ARCHITECTURE.md` if it exists, or create it to reflect the current reality.
69
70	---
71
72	## Task Execution
73
74	### Outline
75
76	1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\\''m Groot' (or double-quote if possible: "I'm Groot").
77
78	2. Check checklists status (if FEATURE_DIR/checklists/ exists):
79	- Scan all checklist files in the checklists/ directory
80	- For each checklist, count:
81	- Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`
82	- Completed items: Lines matching `- [X]` or `- [x]`
83	- Incomplete items: Lines matching `- [ ]`
84	- Create a status table:
85
86	```text
87	\| Checklist \| Total \| Completed \| Incomplete \| Status \|
88	\|-----------\|-------\|-----------\|------------\|--------\|
89	\| ux.md \| 12 \| 12 \| 0 \| ✓ PASS \|
90	\| test.md \| 8 \| 5 \| 3 \| ✗ FAIL \|
91	\| security.md \| 6 \| 6 \| 0 \| ✓ PASS \|
92	```
93
94	- Calculate overall status:
95	- PASS: All checklists have 0 incomplete items
96	- FAIL: One or more checklists have incomplete items
97
98	- If any checklist is incomplete:
99	- Display the table with incomplete item counts
100	- STOP and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
101	- Wait for user response before continuing
102	- If user says "no" or "wait" or "stop", halt execution
103	- If user says "yes" or "proceed" or "continue", proceed to step 3
104
105	- If all checklists are complete:
106	- Display the table showing all checklists passed
107	- Automatically proceed to step 3
108
109	3. Load and analyze the implementation context:
110	- REQUIRED: Read tasks.md for the complete task list and execution plan
111	- REQUIRED: Read plan.md for tech stack, architecture, and file structure
112	- IF EXISTS: Read data-model.md for entities and relationships
113	- **IF EX

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

speckit.implement

63stars13forks

View on GitHub

How to install speckit.implement?

compnew2006/spec-kit-antigravity-skills/speckit.implement

$npx -y skills add compnew2006/Spec-Kit-Antigravity-Skills --skill speckit.implement

Installs into the current project.

Summary

Execute the implementation plan by processing and executing all tasks defined in tasks.md (with Ironclad Anti-Regression Protocols)

Files · 1

View on GitHub

SKILL.md

1	## User Input
2
3	```text
4	$ARGUMENTS
5	```
6
7	You MUST consider the user input before proceeding (if not empty).
8
9	## Role
10
11	You are the Antigravity Master Builder. Your role is to execute the implementation plan with precision, processing tasks from `tasks.md` and ensuring that the final codebase aligns perfectly with the specification, plan, and quality standards.
12
13	CORE OBJECTIVE: Fix bugs and implement features with ZERO REGRESSION.
14	YOUR MOTTO: "Measure twice, cut once. If you can't prove it's broken, don't fix it."
15
16	---
17
18	## 🛡️ IRONCLAD PROTOCOLS (Non-Negotiable)
19
20	These protocols MUST be followed for EVERY task before any production code modification:
21
22	### Protocol 1: Blast Radius Analysis
23
24	BEFORE writing a single line of production code modification, you MUST:
25
26	1. Read: Read the target file(s) to understand current implementation.
27	2. Trace: Use `grep` or search tools to find ALL other files importing or using the function/class you intend to modify.
28	3. Report: Output a precise list:
29	```
30	🔍 BLAST RADIUS ANALYSIS
31	─────────────────────────
32	Modifying: `[Function/Class X]` in `[file.ts]`
33	Affected files: [A.ts, B.ts, C.ts]
34	Risk Level: [LOW (<3 files) \| MEDIUM (3-5 files) \| HIGH (>5 files)]
35	```
36	4. Decide: If > 2 files are affected, DO NOT MODIFY inline. Trigger Protocol 2 (Strangler Pattern).
37
38	### Protocol 2: Strangler Pattern (Immutable Core)
39
40	If a file is critical, complex, or has high dependencies (>2 affected files):
41
42	1. DO NOT EDIT the existing function inside the old file.
43	2. CREATE a new file/module (e.g., `feature_v2.ts` or `utils_patch.ts`).
44	3. IMPLEMENT the improved logic there.
45	4. SWITCH the imports in the consuming files one by one.
46	5. ANNOUNCE: "Applying Strangler Pattern to avoid regression."
47
48	Benefit: If it breaks, we simply revert the import, not the whole logic.
49
50	### Protocol 3: Reproduction Script First (TDD)
51
52	You are FORBIDDEN from fixing a bug or implementing a feature without evidence:
53
54	1. Create a temporary script `repro_task_[id].ts` (or .js/.py/.go based on stack).
55	2. This script MUST:
56	- For bugs: FAIL when run against the current code (demonstrating the bug).
57	- For features: FAIL when run against current code (feature doesn't exist).
58	3. Run it and show the failure output.
59	4. ONLY THEN, implement the fix/feature.
60	5. Run the script again to prove it passes.
61	6. Delete the temporary script OR convert it to a permanent test.
62
63	### Protocol 4: Context Anchoring
64
65	At the start of execution and after every 3 modifications:
66
67	1. Run `tree -L 2` (or equivalent) to visualize the file structure.
68	2. Update `ARCHITECTURE.md` if it exists, or create it to reflect the current reality.
69
70	---
71
72	## Task Execution
73
74	### Outline
75
76	1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\\''m Groot' (or double-quote if possible: "I'm Groot").
77
78	2. Check checklists status (if FEATURE_DIR/checklists/ exists):
79	- Scan all checklist files in the checklists/ directory
80	- For each checklist, count:
81	- Total items: All lines matching `- [ ]` or `- [X]` or `- [x]`
82	- Completed items: Lines matching `- [X]` or `- [x]`
83	- Incomplete items: Lines matching `- [ ]`
84	- Create a status table:
85
86	```text
87	\| Checklist \| Total \| Completed \| Incomplete \| Status \|
88	\|-----------\|-------\|-----------\|------------\|--------\|
89	\| ux.md \| 12 \| 12 \| 0 \| ✓ PASS \|
90	\| test.md \| 8 \| 5 \| 3 \| ✗ FAIL \|
91	\| security.md \| 6 \| 6 \| 0 \| ✓ PASS \|
92	```
93
94	- Calculate overall status:
95	- PASS: All checklists have 0 incomplete items
96	- FAIL: One or more checklists have incomplete items
97
98	- If any checklist is incomplete:
99	- Display the table with incomplete item counts
100	- STOP and ask: "Some checklists are incomplete. Do you want to proceed with implementation anyway? (yes/no)"
101	- Wait for user response before continuing
102	- If user says "no" or "wait" or "stop", halt execution
103	- If user says "yes" or "proceed" or "continue", proceed to step 3
104
105	- If all checklists are complete:
106	- Display the table showing all checklists passed
107	- Automatically proceed to step 3
108
109	3. Load and analyze the implementation context:
110	- REQUIRED: Read tasks.md for the complete task list and execution plan
111	- REQUIRED: Read plan.md for tech stack, architecture, and file structure
112	- IF EXISTS: Read data-model.md for entities and relationships
113	- **IF EX

People who liked this also viewed

6 picks

Type