facts-implement

Name: facts-implement
Author: av

85installs9forks

How to install facts-implement?

av/facts/facts-implement

$npx -y skills add av/facts --skill facts-implement

Installs into the current project.

Summary

Operate on @spec facts — implement them in code, then tag @implemented. Use when asked to implement facts, implement the spec, build from the fact sheet, make facts true, or work through unimplemented requirements.

Files · 1

View on GitHub

SKILL.md

1	# facts-implement
2
3	You are a fact-driven implementer. Your job is to take `@spec` facts and implement them in code — systematically, in a single session. This is the `@spec → @implemented` lifecycle transition.
4
5	Tip: Short CLI aliases are available and recommended for high-frequency operations: `ll` (list --light), `at <id> <tag>` (quick --add-tag), `rt <id> <tag>` (quick --remove-tag), `rm`, and `ls`. All extra arguments are forwarded. See `facts --help` or `facts skills show facts`.
6
7	## Goal
8
9	Each `@spec` fact is a precise, actionable requirement. Implement all `@spec` facts, using subagents to parallelize independent work where possible. Mark completed facts by transitioning them from `@spec` to `@implemented`. If you cannot complete all facts, report exactly what remains and why.
10
11	Important: Only implement `@spec` facts. `@draft` facts are not yet refined — they need the `facts-refine` skill first. Untagged facts are already true. If you see facts without lifecycle tags that aren't implemented, classify them or suggest running `facts-discover` first.
12
13	## Process
14
15	### 1. Load the full spec
16
17	Run `facts list` to see the entire specification. Read and understand all facts — you need the full picture to make good ordering and grouping decisions, even though you will only implement unimplemented facts.
18
19	Read the `## domain` section first if it exists (it lives in the main `.facts` file) — it establishes the project's vocabulary. Use these entity names when reasoning about implementation order and dependencies between facts.
20
21	### 2. Identify remaining work
22
23	Run `facts check` to see which command-facts pass and which fail. This also validates the fact sheet structure (lint errors abort check early).
24
25	Run `facts list --tags "spec"` to see facts ready to implement. This is your implementation target.
26
27	Cross-reference: a `@spec` fact may already pass its validation command. If `facts check` shows it passing, verify the implementation is complete and transition it — do not re-implement.
28
29	### 3. Plan
30
31	Read through the unimplemented facts and decide on an implementation order. Use your judgment — consider dependencies between facts, section grouping, and what will unblock the most progress. There is no fixed ordering formula; you understand the codebase and the spec.
32
33	Group facts that can be implemented independently into parallel batches. Facts that depend on each other must be sequential.
34
35	### 4. Implement
36
37	For each fact:
38
39	1. Read the label — it states what must be true
40	2. Write the code that makes it true
41	3. If it has a validation command, that command is the test — run it to confirm (exit 0 = done)
42	4. If it has no validation command, you must verify it manually: read the code that should make this fact true, confirm the behavior matches, and be confident before proceeding. Do not skip manual facts or batch them as "N manual verified" — check each one individually
43	5. Transition it from `@spec` to `@implemented`:
44
45	```
46	facts edit <id> --remove-tag "spec" --add-tag "implemented"
47	```
48
49	Completion = tagging, not adding. When you finish implementing a fact, tag it `@implemented` — that is how you record completion. The `@spec` fact already describes the behavior; a second fact restating it from an implementation angle adds noise, not signal. Similarly, if you notice a code branch lacks coverage, the right response is a test, not a fact. Facts specify behavior; tests verify code paths.
50
51	Use subagents to implement independent facts in parallel. Each subagent should:
52	- Receive the specific facts it is responsible for (IDs, labels, commands)
53	- Have enough context about the overall spec and codebase to make good decisions
54	- Run validation commands and tag facts as implemented
55	- Report back what it completed and any issues encountered
56
57	### 5. Verify
58
59	After all implementation work is done, run:
60
61	```
62	facts check
63	```
64
65	All command-facts should pass.
66
67	Behavioral review: Go back through every fact you implemented — especially manual facts — and verify that your implementation captures the full behavioral intent, not just the literal label. A fact that says "duplicate messages are silently dropped" is not satisfied by code that deduplicates but logs a warning on every duplicate. Read the fact, read your code, confirm the behavior matches.
68
69	For rewrites or migrations, this step is critical. The fact sheet may not capture every nuance of the original implementation. If you notice the original code handles an edge case that no fact describes, add a fact for it rather than silently dropping the behavior:
70
71	```
72	facts add "the new behavioral fact you discovered" --section relevant/section --tags "spec"
73	```
74
75	Then implement it before moving on.
76
77	**Domain mainte

People who liked this also viewed

6 picks

Type

tddSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026501k181k
test-driven-developmentUse when implementing any feature or bugfix, before writing implementation codeSkillsJul 2026175k259k
qaSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
verification-before-completionUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidenceSkillsJul 2026153k259k
webapp-testingToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser lSkillsJul 2026120k163k
playwright-best-practicesUse when writing Playwright tests, fixing flaky tests, debugging failures, implementing Page Object Model, configuring CI/CD, optimizing performance, mocking APIs, handling authentication or OAuth, teSkillsJul 202664k338

facts-implement

85installs9forks

View on GitHub

How to install facts-implement?

av/facts/facts-implement

$npx -y skills add av/facts --skill facts-implement

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# facts-implement
2
3	You are a fact-driven implementer. Your job is to take `@spec` facts and implement them in code — systematically, in a single session. This is the `@spec → @implemented` lifecycle transition.
4
5	Tip: Short CLI aliases are available and recommended for high-frequency operations: `ll` (list --light), `at <id> <tag>` (quick --add-tag), `rt <id> <tag>` (quick --remove-tag), `rm`, and `ls`. All extra arguments are forwarded. See `facts --help` or `facts skills show facts`.
6
7	## Goal
8
9	Each `@spec` fact is a precise, actionable requirement. Implement all `@spec` facts, using subagents to parallelize independent work where possible. Mark completed facts by transitioning them from `@spec` to `@implemented`. If you cannot complete all facts, report exactly what remains and why.
10
11	Important: Only implement `@spec` facts. `@draft` facts are not yet refined — they need the `facts-refine` skill first. Untagged facts are already true. If you see facts without lifecycle tags that aren't implemented, classify them or suggest running `facts-discover` first.
12
13	## Process
14
15	### 1. Load the full spec
16
17	Run `facts list` to see the entire specification. Read and understand all facts — you need the full picture to make good ordering and grouping decisions, even though you will only implement unimplemented facts.
18
19	Read the `## domain` section first if it exists (it lives in the main `.facts` file) — it establishes the project's vocabulary. Use these entity names when reasoning about implementation order and dependencies between facts.
20
21	### 2. Identify remaining work
22
23	Run `facts check` to see which command-facts pass and which fail. This also validates the fact sheet structure (lint errors abort check early).
24
25	Run `facts list --tags "spec"` to see facts ready to implement. This is your implementation target.
26
27	Cross-reference: a `@spec` fact may already pass its validation command. If `facts check` shows it passing, verify the implementation is complete and transition it — do not re-implement.
28
29	### 3. Plan
30
31	Read through the unimplemented facts and decide on an implementation order. Use your judgment — consider dependencies between facts, section grouping, and what will unblock the most progress. There is no fixed ordering formula; you understand the codebase and the spec.
32
33	Group facts that can be implemented independently into parallel batches. Facts that depend on each other must be sequential.
34
35	### 4. Implement
36
37	For each fact:
38
39	1. Read the label — it states what must be true
40	2. Write the code that makes it true
41	3. If it has a validation command, that command is the test — run it to confirm (exit 0 = done)
42	4. If it has no validation command, you must verify it manually: read the code that should make this fact true, confirm the behavior matches, and be confident before proceeding. Do not skip manual facts or batch them as "N manual verified" — check each one individually
43	5. Transition it from `@spec` to `@implemented`:
44
45	```
46	facts edit <id> --remove-tag "spec" --add-tag "implemented"
47	```
48
49	Completion = tagging, not adding. When you finish implementing a fact, tag it `@implemented` — that is how you record completion. The `@spec` fact already describes the behavior; a second fact restating it from an implementation angle adds noise, not signal. Similarly, if you notice a code branch lacks coverage, the right response is a test, not a fact. Facts specify behavior; tests verify code paths.
50
51	Use subagents to implement independent facts in parallel. Each subagent should:
52	- Receive the specific facts it is responsible for (IDs, labels, commands)
53	- Have enough context about the overall spec and codebase to make good decisions
54	- Run validation commands and tag facts as implemented
55	- Report back what it completed and any issues encountered
56
57	### 5. Verify
58
59	After all implementation work is done, run:
60
61	```
62	facts check
63	```
64
65	All command-facts should pass.
66
67	Behavioral review: Go back through every fact you implemented — especially manual facts — and verify that your implementation captures the full behavioral intent, not just the literal label. A fact that says "duplicate messages are silently dropped" is not satisfied by code that deduplicates but logs a warning on every duplicate. Read the fact, read your code, confirm the behavior matches.
68
69	For rewrites or migrations, this step is critical. The fact sheet may not capture every nuance of the original implementation. If you notice the original code handles an edge case that no fact describes, add a fact for it rather than silently dropping the behavior:
70
71	```
72	facts add "the new behavioral fact you discovered" --section relevant/section --tags "spec"
73	```
74
75	Then implement it before moving on.
76
77	**Domain mainte

People who liked this also viewed

6 picks

Type