You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DevFlow can use project-owned style packs after the business design is clear. A style pack is not a shared DevFlow template; it is repository-owned material that helps agents preserve local implementation style through rules, golden examples, anti-patterns, and review checklists.
133
+
134
+
Recommended project locations:
135
+
136
+
```text
137
+
devflow-style-packs/
138
+
.devflow/style-packs/
139
+
.ai/style-packs/
140
+
docs/devflow/style-packs/
141
+
```
142
+
143
+
Recommended shape:
144
+
145
+
```text
146
+
<style-pack-name>/
147
+
style-pack.yaml
148
+
rules.md
149
+
examples/
150
+
anti-patterns.md
151
+
review-checklist.md
152
+
```
153
+
154
+
Use style packs with `df-glue-coding` after DDD, CQRS, API, security, validation, and persistence constraints are already respected. Keep project-specific examples in the project repository, not in this public DevFlow repository.
Copy file name to clipboardExpand all lines: skills/df-glue-coding/SKILL.md
+10-6Lines changed: 10 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
name: df-glue-coding
3
-
description: "Glue Coding workflow for AI implementation that should reuse local project material without blindly copying old structure. Use after domain ambiguity has been resolved or declared thin, and before implementation planning or coding, when a task resembles existing CRUD pages, list/form/detail screens, imports/exports, endpoints, adapters, command handlers, projections, tests, configuration, refactors, migrations, modernization, or other repeatable project patterns. The skill discovers local reference code, examples, docs, AGENTS.md rules, and nearby production implementations, classifies them as target patterns, legacy patterns, anti-patterns, or behavior evidence, preserves the right conventions, and limits new code to the intended delta."
3
+
description: "Glue Coding workflow for AI implementation that should reuse local project material without blindly copying old structure. Use after domain ambiguity has been resolved or declared thin, and before implementation planning or coding, when a task resembles existing CRUD pages, list/form/detail screens, imports/exports, endpoints, adapters, command handlers, projections, tests, configuration, refactors, migrations, modernization, or other repeatable project patterns. The skill discovers local style packs, reference code, examples, docs, AGENTS.md rules, and nearby production implementations, classifies them as target patterns, legacy patterns, anti-patterns, or behavior evidence, preserves the right conventions, and limits new code to the intended delta."
3. Nearby production code: similar pages, endpoints, handlers, adapters, projections, tests, fixtures, migrations, exports, imports, jobs, or config. For refactors, classify whether each candidate is a target pattern, legacy pattern, anti-pattern, or behavior evidence.
@@ -42,23 +42,24 @@ Do not store project-specific sample code in this skill. Concrete samples belong
42
42
-`refactor_glue`: current code is being migrated away from an old pattern toward a target pattern
43
43
2. If `domain_blocked`, return to `df-ddd-event-storming-design`. Use discovered code only as evidence for questions and candidate language.
44
44
3. Search local material before planning implementation. Prefer `rg --files` and targeted `rg` searches.
45
-
4. Select the closest pattern and record why it fits:
45
+
4. If a style pack is available and applicable, select it before choosing source examples. Use `references/style-packs.md` for discovery locations, recommended structure, and usage rules.
46
+
5. Select the closest pattern and record why it fits:
46
47
- same user workflow or business capability
47
48
- same framework or layer
48
49
- same file organization
49
50
- same dependency, request, validation, error, transaction, auth, or test style
50
51
- same lifecycle, command, event, projection, or read-model shape
51
-
5. Identify what must be preserved:
52
+
6. Identify what must be preserved:
52
53
- file and module structure
53
54
- naming and imports
54
55
- component or API composition
55
56
- request/response mapping
56
57
- validation and error semantics
57
58
- persistence, ordering, pagination, transaction, concurrency, or side-effect behavior
58
59
- test style and fixture shape
59
-
6. Identify the delta:
60
+
7. Identify the delta:
60
61
- fields, labels, columns, filters, routes, endpoints, DTOs, events, commands, policies, invariants, read-model fields, adapter mappings, or business rules that differ from the pattern
61
-
7. Pass the selected pattern and delta to `df-implementation-planning` or `df-ddd-to-tdd-handoff`.
62
+
8. Pass the selected style pack, selected pattern, preserved conventions, and delta to `df-implementation-planning` or `df-ddd-to-tdd-handoff`.
62
63
63
64
## Refactor Mode
64
65
@@ -104,18 +105,21 @@ Keep this concise. Do not paste long source files into the response; cite file p
104
105
- Do not skip DDD when a CRUD-looking request hides business meaning.
105
106
- Do not copy code before stating the selected pattern and delta.
106
107
- Do not invent a new project structure while a good local pattern exists.
108
+
- Do not ignore an applicable project-owned style pack after the business design is confirmed.
107
109
- Do not treat legacy code or anti-patterns as target patterns during refactors.
108
110
- Do not refactor behavior-preserving code without characterization coverage unless the user explicitly accepts the risk.
109
111
- Do not treat stale or unrelated examples as authoritative; prefer current production code when reference material conflicts with the repository.
110
112
- Do not preserve a pattern blindly when it violates confirmed domain rules, security, validation, persistence, or public contracts.
111
113
- Do not turn Glue Coding into test avoidance. Behavior changes still need `df-tdd-skill` unless the task is documentation-only or explicitly non-executable.
112
114
- Do not add project-specific samples to this skill. Put reusable samples in the project repository and mention them from `AGENTS.md` or local docs.
115
+
- Do not treat style packs as business truth. They preserve implementation style after DDD, API, security, validation, and persistence constraints are already respected.
113
116
114
117
## Material Flywheel
115
118
116
119
Before handoff or completion, ask whether the task revealed reusable material:
117
120
118
121
- a new or improved code pattern worth adding to `reference/`, `examples/`, `docs/patterns/`, or `.ai/patterns/`
122
+
- a style pack rule, golden example, anti-pattern, or review checklist entry worth adding to `devflow-style-packs/`, `.devflow/style-packs/`, `.ai/style-packs/`, or `docs/devflow/style-packs/`
119
123
- a rule that belongs in `AGENTS.md` or project docs
120
124
- domain knowledge or a pitfall that belongs in local knowledge notes
121
125
- a persistent spec or decision that belongs in `.ai/tracks/`
Style packs are project-owned reference material that help agents preserve a repository's implementation style after the business design is clear.
4
+
5
+
They are not shared DevFlow templates and should not live inside this public skill unless they are generic examples. Concrete project examples belong in the target repository.
6
+
7
+
## When To Use
8
+
9
+
Use a style pack when:
10
+
11
+
- DDD, CQRS, API, or workflow decisions have already clarified what behavior should exist.
12
+
- The task maps to a repeated implementation shape such as commands, events, aggregates, projections, controllers, jobs, imports, exports, tests, migrations, or adapters.
13
+
- Multiple valid code styles could implement the same behavior, and local consistency matters.
14
+
- A refactor is moving code from a legacy pattern toward an explicitly selected target pattern.
15
+
16
+
Do not use a style pack to override confirmed business rules, security requirements, validation semantics, persistence constraints, or public contracts.
17
+
18
+
## Discovery Locations
19
+
20
+
Search project-owned material in this order:
21
+
22
+
1. Explicit user-provided paths or names.
23
+
2.`AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, and local workflow docs that name style packs.
24
+
3.`devflow-style-packs/`
25
+
4.`.devflow/style-packs/`
26
+
5.`.ai/style-packs/`
27
+
6.`docs/devflow/style-packs/`
28
+
7.`docs/patterns/`, `examples/`, `reference/`, and `references/`
29
+
30
+
If a style pack conflicts with current production code, prefer current production code unless the task is explicitly to migrate toward the style pack.
31
+
32
+
## Recommended Shape
33
+
34
+
```text
35
+
devflow-style-packs/
36
+
<style-pack-name>/
37
+
style-pack.yaml
38
+
rules.md
39
+
examples/
40
+
<golden-example files>
41
+
anti-patterns.md
42
+
review-checklist.md
43
+
```
44
+
45
+
`style-pack.yaml` should describe the scope, applicable task types, primary examples, verification commands, and known exclusions.
46
+
47
+
`rules.md` should contain concise rules that affect implementation choices, naming, layering, error handling, transaction boundaries, tests, or projection behavior.
48
+
49
+
`examples/` should contain complete golden examples or small focused excerpts. Prefer one high-quality realistic example over many empty scaffolds.
50
+
51
+
`anti-patterns.md` should describe shapes agents must avoid, especially legacy structures that look similar but should not be copied.
52
+
53
+
`review-checklist.md` should list the style-specific checks reviewers expect before handoff.
54
+
55
+
## How Agents Should Use A Style Pack
56
+
57
+
1. Select the closest applicable style pack and record why it fits.
58
+
2. Read only the relevant rules, examples, anti-patterns, and checklist entries.
59
+
3. Classify each discovered example as `target_pattern`, `legacy_pattern`, `anti_pattern`, `behavior_evidence`, or `unknown`.
60
+
4. State the conventions that must be preserved and the exact delta required by the task.
61
+
5. Pass the selected style pack, target examples, preserved conventions, and delta to implementation planning.
62
+
6. During verification, report which style pack was used and whether the implementation still matches its review checklist.
63
+
64
+
## Good Style Pack Material
65
+
66
+
- It is owned by the project that uses it.
67
+
- It shows complete naming, layering, dependency direction, tests, and verification style.
68
+
- It explains why a pattern exists when the reason is not obvious.
69
+
- It contains negative examples or explicit "do not copy" notes for attractive legacy shapes.
70
+
- It is small enough for an agent to read before coding.
71
+
72
+
## Poor Style Pack Material
73
+
74
+
- Empty fill-in templates that encourage mechanical copy/paste.
75
+
- Long source dumps without selection guidance.
76
+
- Project-private information inside a public skill repository.
77
+
- Stale examples that contradict current production code without saying they are migration targets.
78
+
- Rules that duplicate business decisions already owned by DDD, API design, security policy, or persistence constraints.
Copy file name to clipboardExpand all lines: skills/df-implementation-planning/SKILL.md
+4-3Lines changed: 4 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ description: "Write a concrete, small-step implementation plan before coding. Us
5
5
6
6
# Implementation Planning
7
7
8
-
Use this skill to turn a requirement, confirmed DDD handoff, Glue Coding pattern selection, bug investigation result, or refactor goal into a plan that another agent can execute.
8
+
Use this skill to turn a requirement, confirmed DDD handoff, Glue Coding pattern selection, selected style pack, bug investigation result, or refactor goal into a plan that another agent can execute.
9
9
10
10
Do not edit production code while using this skill.
11
11
@@ -16,6 +16,7 @@ Do not edit production code while using this skill.
16
16
- behaviors that must not change
17
17
- public contracts
18
18
- data, persistence, ordering, pagination, security, or side-effect risks
19
+
- selected style pack, golden examples, style-specific anti-patterns, and review checklist items to preserve
19
20
- selected glue target pattern, local conventions, legacy behavior evidence, anti-patterns to remove, and project material that must be preserved
20
21
- user-owned worktree changes to avoid
21
22
3. Identify behavior slices.
@@ -27,7 +28,7 @@ Do not edit production code while using this skill.
27
28
- completion standard
28
29
5. Keep each task small enough to complete and verify independently.
29
30
6. Mark steps that require `df-tdd-skill`, `df-spring-web-boundaries`, or `df-systematic-debugging`.
30
-
7. For glue-style work, include the selected target pattern and the exact delta each task is allowed to change.
31
+
7. For glue-style work, include the selected style pack when one exists, the selected target pattern, and the exact delta each task is allowed to change.
31
32
8. For refactor glue work, separate characterization, target-pattern migration, and cleanup steps. Do not plan to copy legacy structure unless it is explicitly classified as the target pattern.
32
33
9. State whether user confirmation is required before execution.
33
34
@@ -87,6 +88,6 @@ Use `templates/implementation-plan.md` when a file artifact is useful. In chat,
87
88
- Do not omit commands when the project has discoverable test commands.
88
89
- Do not plan a fix before a reproducible failure and root-cause evidence exists for unclear bugs.
89
90
- Do not mix behavior change and broad cleanup in the same step.
90
-
- Do not invent new structure for glue-style work when a selected local target pattern must be preserved.
91
+
- Do not invent new structure for glue-style work when a selected style pack or local target pattern must be preserved.
91
92
- Do not plan refactors that treat legacy code or anti-patterns as the target pattern without explicit justification.
92
93
- Do not assume approval for risky scope expansion; call it out.
Copy file name to clipboardExpand all lines: skills/df-verification-before-completion/SKILL.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,7 +22,7 @@ Answer every item:
22
22
9. If TDD was required, is there RED/GREEN/REFACTOR evidence?
23
23
10. If DDD modeling was required, were conclusions confirmed before persistence?
24
24
11. If Spring Web boundaries changed, were endpoint contracts and service boundary scans covered?
25
-
12. If Glue Coding was required, which local target pattern was used, which delta was implemented, and should any new rule, knowledge, pattern, or track be persisted? For refactors, which legacy patterns or anti-patterns were avoided, and what characterization evidence protected behavior?
25
+
12. If Glue Coding was required, which style pack or local target pattern was used, which delta was implemented, and should any new rule, knowledge, pattern, style pack material, or track be persisted? For refactors, which legacy patterns or anti-patterns were avoided, and what characterization evidence protected behavior?
0 commit comments