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
Platform-specific bundles can stay small and still be explicit.
115
-
For example, a typical .NET repo baseline can install `mcaf-dotnet` as the entry skill, `mcaf-dotnet-features`, `mcaf-solution-governance`, `mcaf-testing`, exactly one of `mcaf-dotnet-xunit`, `mcaf-dotnet-tunit`, or `mcaf-dotnet-mstest`, plus `mcaf-dotnet-quality-ci`, `mcaf-dotnet-complexity`, `mcaf-solid-maintainability`, `mcaf-architecture-overview`, and `mcaf-ci-cd`.
116
-
In that setup, `mcaf-dotnet` knows when to open the more specific .NET skills, the repo-root lowercase `.editorconfig` is the default source of truth for formatting and analyzer severity, and `AGENTS.md` records the exact `dotnet build`, `dotnet test`, `dotnet format`, `analyze`, and coverage commands. Nested `.editorconfig` files are allowed when they serve a clear subtree-specific purpose, such as stricter domain rules, generated-code handling, test-specific conventions, or legacy-code containment.
117
-
For .NET code changes, the task is not done when tests are green if the repo also configured formatters, analyzers, coverage, architecture tests, or security gates. Agents should run the repo-defined post-change quality pass before completion.
118
-
If the repo standardizes on concrete tools, install the matching tool skills as well. Typical open or free .NET additions include `mcaf-dotnet-format`, `mcaf-dotnet-code-analysis`, `mcaf-dotnet-analyzer-config`, `mcaf-dotnet-stylecop-analyzers`, `mcaf-dotnet-roslynator`, `mcaf-dotnet-meziantou-analyzer`, `mcaf-dotnet-cloc`, `mcaf-dotnet-coverlet`, `mcaf-dotnet-profiling`, `mcaf-dotnet-quickdup`, `mcaf-dotnet-reportgenerator`, `mcaf-dotnet-resharper-clt`, `mcaf-dotnet-stryker`, `mcaf-dotnet-netarchtest`, `mcaf-dotnet-archunitnet`, and `mcaf-dotnet-csharpier`. `mcaf-dotnet-codeql` stays available, but should be chosen only when its hosting and licensing model fits the repository.
119
-
Every `mcaf-dotnet*` tool skill should include a `Bootstrap When Missing` section so agents can detect, install, verify, and first-run the tool without guessing.
115
+
The `.NET` skill bundle is maintained outside this repository at [managedcode/dotnet-skills](https://github.com/managedcode/dotnet-skills).
116
+
Install the `.NET` skills you need from that repository, then document the exact `dotnet build`, `dotnet test`, `dotnet format`, `analyze`, and coverage commands in the consuming repo’s `AGENTS.md`.
117
+
For `.NET` code changes, the task is not done when tests are green if the repo also configured formatters, analyzers, coverage, architecture tests, or security gates.
118
+
Agents should run the repo-defined post-change quality pass before completion, and any external `mcaf-dotnet*` tool skill should still include a `Bootstrap When Missing` section so agents can detect, install, verify, and first-run the tool without guessing.
120
119
121
120
### 2.5 Context Rules
122
121
@@ -214,7 +213,7 @@ Root `AGENTS.md` stays current with:
214
213
- commands (`build`, `test`, `format`, `analyze`, `coverage` if used)
215
214
- global skills and when to use them
216
215
- self-learning rules
217
-
- non-trivial task planning rules, including root-level `<slug>.plan.md` usage
216
+
- non-trivial task workflow rules, including root-level`<slug>.brainstorm.md` and`<slug>.plan.md` usage
218
217
- testing discipline
219
218
- done criteria for tests, coverage, and quality gates
220
219
- design and maintainability rules
@@ -261,7 +260,8 @@ If the same mistake happens twice, the framework expects the rule to be made dur
261
260
- Every MCAF repo has a root `AGENTS.md`.
262
261
- Multi-project solutions use local `AGENTS.md` files at project roots.
263
262
- Agents read root and local `AGENTS.md` before editing code.
264
-
- Non-trivial tasks use a root-level `<slug>.plan.md` as the working plan.
263
+
- Non-trivial tasks start with a root-level `<slug>.brainstorm.md`, then move into a root-level `<slug>.plan.md`.
264
+
- Brainstorms capture thinking, options, trade-offs, and the chosen direction before implementation starts.
265
265
- Plans include ordered implementation steps, explicit test steps, testing methodology, and final validation commands.
266
266
- Skills are preferred over improvised workflow when a skill matches the task.
267
267
- Numeric maintainability limits live in `AGENTS.md`, not in framework prose.
@@ -349,9 +349,23 @@ Before heavy coding:
349
349
3. align test expectations
350
350
4. identify the right skills
351
351
352
-
### 7.2 Plan
352
+
### 7.2 Brainstorm
353
353
354
-
For non-trivial work, create a root-level `<slug>.plan.md` and keep it current.
354
+
For non-trivial work, start with a root-level `<slug>.brainstorm.md` and keep it concise.
355
+
The brainstorm records:
356
+
357
+
- the problem to solve
358
+
- scope and constraints
359
+
- relevant context and assumptions
360
+
- candidate approaches or options
361
+
- trade-offs, risks, and open questions
362
+
- the recommended direction that will become the plan
363
+
364
+
Brainstorm first, think through the task, then convert the chosen direction into a working plan.
365
+
366
+
### 7.3 Plan
367
+
368
+
For non-trivial work, create a root-level `<slug>.plan.md` after the brainstorm direction is chosen, and keep it current.
355
369
The plan records:
356
370
357
371
- goal and scope
@@ -367,15 +381,15 @@ The plan records:
367
381
Before implementation starts, run the full relevant test baseline.
368
382
If anything is already failing, add each failing test to the plan with its symptom, suspected or confirmed root cause, and intended fix path.
369
383
370
-
### 7.3 Implement
384
+
### 7.4 Implement
371
385
372
-
- Use the Ralph Loop for non-trivial work: execute one planned step, run the relevant checks, update the plan, then move to the next step.
386
+
- Use the Ralph Loop for non-trivial work: brainstorm first, turn the chosen direction into a plan, execute one planned step, run the relevant checks, update the plan, then move to the next step.
373
387
- implement code and tests together
374
388
- keep changes small and reviewable
375
389
- fix failing tests deliberately, one by one, and track them in the plan until they are closed
376
390
- use the architecture map and nearest local `AGENTS.md` to stay in scope
377
391
378
-
### 7.4 Verify
392
+
### 7.5 Verify
379
393
380
394
Run verification in layers:
381
395
@@ -385,7 +399,7 @@ Run verification in layers:
385
399
4. analyzers, formatters, and any configured architecture, security, mutation, or other quality gates
386
400
5. coverage comparison against the pre-change baseline
387
401
388
-
### 7.5 Update Durable Context and Close the Task
402
+
### 7.6 Update Durable Context and Close the Task
389
403
390
404
After implementation:
391
405
@@ -429,6 +443,6 @@ Adoption is complete when:
429
443
- the right skills are installed
430
444
- multi-project boundaries have local `AGENTS.md`
431
445
- commands and docs reflect the real repo
432
-
- non-trivial work is guided by a root-level `<slug>.plan.md` and the Ralph Loop
446
+
- non-trivial work is guided by root-level `<slug>.brainstorm.md`, `<slug>.plan.md`, and the Ralph Loop
433
447
- tool-specific skills document real bootstrap and install steps when the tool is missing
0 commit comments