Skip to content

Commit 8254376

Browse files
KSemenenkoKSemenenko
committed
Add ManagedCode.Tps SDK workspace and site catalog
1 parent da595a9 commit 8254376

162 files changed

Lines changed: 16784 additions & 2 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.codex/skills/dotnet-mcaf-agile-delivery/SKILL.md‎

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
---
2+
name: dotnet-mcaf-agile-delivery
3+
version: "1.0.0"
4+
category: "Core"
5+
description: "Apply MCAF agile-delivery guidance for backlog quality, roles, ceremonies, and engineering feedback. Use when defining how the team plans, tracks work, and turns feedback into durable improvements."
6+
compatibility: "Requires repository access only when the repo stores delivery docs or governance guidance."
7+
---
8+
9+
# MCAF: Agile Delivery
10+
11+
## Trigger On
12+
13+
- the team needs backlog, ceremony, role, or feedback-loop rules
14+
- delivery process is vague, too heavy, or living only in chat
15+
- recurring team pain needs to become durable repo guidance
16+
17+
## Value
18+
19+
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
20+
- reduce ambiguity through explicit planning, verification, and final validation skills
21+
- leave reusable project context so future tasks are faster and safer
22+
23+
## Do Not Use For
24+
25+
- repo governance that belongs in `AGENTS.md`
26+
- feature planning for one specific feature doc
27+
28+
## Inputs
29+
30+
- the current delivery pain point
31+
- backlog, role, ceremony, and feedback mechanisms that already exist
32+
- where the team stores durable agreements, if anywhere
33+
34+
## Quick Start
35+
36+
1. Read the nearest `AGENTS.md` and confirm scope and constraints.
37+
2. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.
38+
3. Return the `Required Result Format` with concrete artifacts and verification evidence.
39+
40+
## Workflow
41+
42+
1. Keep delivery artefacts concrete:
43+
- backlog
44+
- roles
45+
- ceremonies
46+
- engineering feedback
47+
2. Prefer lightweight agreements over process theatre.
48+
3. When a pain point repeats, turn it into a rule, doc, or skill update.
49+
4. Pull only the references that match the current process problem.
50+
51+
## Deliver
52+
53+
- concrete delivery guidance
54+
- durable team agreements
55+
- feedback loops that update docs, skills, and rules
56+
57+
## Validate
58+
59+
- the process guidance fixes a real delivery problem
60+
- roles and rituals are explicit enough to use
61+
- recurring pain is converted into a durable artifact, not more chat
62+
63+
## Ralph Loop
64+
65+
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
66+
67+
1. Brainstorm first (mandatory):
68+
- analyze current state
69+
- define the problem, target outcome, constraints, and risks
70+
- generate options and think through trade-offs before committing
71+
- capture the recommended direction and open questions
72+
2. Plan second (mandatory):
73+
- write a detailed execution plan from the chosen direction
74+
- list final validation skills to run at the end, with order and reason
75+
3. Execute one planned step and produce a concrete delta.
76+
4. Review the result and capture findings with actionable next fixes.
77+
5. Apply fixes in small batches and rerun the relevant checks or review steps.
78+
6. Update the plan after each iteration.
79+
7. Repeat until outcomes are acceptable or only explicit exceptions remain.
80+
8. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.
81+
82+
### Required Result Format
83+
84+
- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`
85+
- `plan`: concise plan and current iteration step
86+
- `actions_taken`: concrete changes made
87+
- `validation_skills`: final skills run, or skipped with reasons
88+
- `verification`: commands, checks, or review evidence summary
89+
- `remaining`: top unresolved items or `none`
90+
91+
For setup-only requests with no execution, return `status: configured` and exact next commands.
92+
93+
## Load References
94+
95+
- read `references/agile-delivery.md` first
96+
- open `references/roles.md` only for a narrower topic
97+
98+
## Example Requests
99+
100+
- "Define a lighter delivery model for this team."
101+
- "Turn repeated feedback pain into repo guidance."
102+
- "Fix our backlog and ceremony chaos."

‎.codex/skills/dotnet-mcaf-agile-delivery/references/agile-delivery.md‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
# Agile Delivery
2+
3+
Agile delivery in MCAF is lightweight and outcome-driven.
4+
5+
## Goals
6+
7+
- keep the backlog visible and current
8+
- turn work into small reviewable increments
9+
- keep feedback loops short
10+
- convert repeated process pain into durable repo guidance
11+
12+
## Default Operating Model
13+
14+
- Maintain one shared backlog that the whole delivery team can see.
15+
- Keep work items small enough to review, test, and ship without hidden side work.
16+
- Define readiness before implementation and completion before closure.
17+
- Use short planning and feedback loops instead of large ceremony-heavy process.
18+
- Record lasting process rules in the repo, not only in chat or meetings.
19+
20+
## Backlog Rules
21+
22+
- backlog items describe a user or system outcome, not just a task label
23+
- scope, acceptance, and constraints are visible before implementation starts
24+
- if an item is too large to review coherently, split it before coding
25+
26+
## Team Cadence
27+
28+
- planning chooses the next smallest meaningful slice of value
29+
- standups or async updates surface blockers and PR review needs
30+
- retrospectives or equivalent feedback loops must produce concrete follow-up actions
31+
32+
## Durable Artifacts
33+
34+
- work agreements and recurring rules belong in docs or `AGENTS.md`
35+
- feature behaviour belongs in feature specs
36+
- architecture decisions belong in ADRs
37+
- repo workflow rules belong in skills only when they are reusable

‎.codex/skills/dotnet-mcaf-agile-delivery/references/roles.md‎

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
# Agile/Scrum Roles
2+
3+
- We prefer using "process lead" over "scrum master". It describes the same role.
4+
5+
This section has links directing you to definitions for the traditional roles within Agile/Scrum. After reading through the best practices you should have a basic understanding of the key Agile roles in terms of what they are and the expectations for the role.
6+
7+
- [Product Owner](https://scrumguides.org/scrum-guide.html#product-owner 'Product Owner')
8+
- [Scrum Master](https://scrumguides.org/scrum-guide.html#scrum-master 'Scrum Master')
9+
- [Development Team](https://scrumguides.org/scrum-guide.html#developers 'Developers')

‎.codex/skills/dotnet-mcaf-devex/SKILL.md‎

Lines changed: 103 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,103 @@
1+
---
2+
name: dotnet-mcaf-devex
3+
version: "1.0.0"
4+
category: "Core"
5+
description: "Apply MCAF developer-experience guidance for onboarding, F5 contract, cross-platform tasks, local inner loop, and reproducible setup. Use when the repo is hard to run, debug, test, or onboard into."
6+
compatibility: "Requires repository access; may update docs, task runners, devcontainer guidance, or local setup conventions."
7+
---
8+
9+
# MCAF: Developer Experience
10+
11+
## Trigger On
12+
13+
- the repo is hard to run, test, debug, or onboard into
14+
- local setup differs too much across contributors
15+
- the inner loop is slow or undocumented
16+
17+
## Value
18+
19+
- produce a concrete project delta: code, docs, config, tests, CI, or review artifact
20+
- reduce ambiguity through explicit planning, verification, and final validation skills
21+
- leave reusable project context so future tasks are faster and safer
22+
23+
## Do Not Use For
24+
25+
- production deployment or pipeline policy
26+
- pure documentation cleanup with no developer workflow impact
27+
28+
## Inputs
29+
30+
- the current local setup and first-run path
31+
- actual build, run, debug, and test commands
32+
- pain points in onboarding or the inner loop
33+
34+
## Quick Start
35+
36+
1. Read the nearest `AGENTS.md` and confirm scope and constraints.
37+
2. Run this skill's `Workflow` through the `Ralph Loop` until outcomes are acceptable.
38+
3. Return the `Required Result Format` with concrete artifacts and verification evidence.
39+
40+
## Workflow
41+
42+
1. Find the slowest or most fragile part of the inner loop:
43+
- clone and setup
44+
- build
45+
- run and debug
46+
- test
47+
2. Standardize tasks before optimizing them.
48+
3. Prefer one documented way to run the full solution locally.
49+
4. Pull only the references that match the local-dev problem you are fixing.
50+
51+
## Deliver
52+
53+
- lower-friction local workflow
54+
- better onboarding
55+
- reproducible build, run, test, and debug paths
56+
57+
## Validate
58+
59+
- a newcomer can follow the docs without hidden setup knowledge
60+
- the inner loop is explicit and reproducible
61+
- cross-platform or containerized guidance is used only where it helps
62+
- local development uses real services, containers, or sandbox environments instead of fakes or stubs
63+
64+
## Ralph Loop
65+
66+
Use the Ralph Loop for every task, including docs, architecture, testing, and tooling work.
67+
68+
1. Brainstorm first (mandatory):
69+
- analyze current state
70+
- define the problem, target outcome, constraints, and risks
71+
- generate options and think through trade-offs before committing
72+
- capture the recommended direction and open questions
73+
2. Plan second (mandatory):
74+
- write a detailed execution plan from the chosen direction
75+
- list final validation skills to run at the end, with order and reason
76+
3. Execute one planned step and produce a concrete delta.
77+
4. Review the result and capture findings with actionable next fixes.
78+
5. Apply fixes in small batches and rerun the relevant checks or review steps.
79+
6. Update the plan after each iteration.
80+
7. Repeat until outcomes are acceptable or only explicit exceptions remain.
81+
8. If a dependency is missing, bootstrap it or return `status: not_applicable` with explicit reason and fallback path.
82+
83+
### Required Result Format
84+
85+
- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`
86+
- `plan`: concise plan and current iteration step
87+
- `actions_taken`: concrete changes made
88+
- `validation_skills`: final skills run, or skipped with reasons
89+
- `verification`: commands, checks, or review evidence summary
90+
- `remaining`: top unresolved items or `none`
91+
92+
For setup-only requests with no execution, return `status: configured` and exact next commands.
93+
94+
## Load References
95+
96+
- read `references/developer-experience.md` first
97+
- open `references/onboarding-guide-template.md` only when relevant
98+
99+
## Example Requests
100+
101+
- "Make this repo easier to onboard into."
102+
- "Document a sane local run and debug loop."
103+
- "Fix the dev setup drift across machines."

‎.codex/skills/dotnet-mcaf-devex/references/developer-experience.md‎

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
# Developer Experience
2+
3+
Developer experience is the cost of doing normal engineering work in the repo.
4+
5+
## Essential Tasks
6+
7+
- build
8+
- run
9+
- debug
10+
- test
11+
- understand where to make a change
12+
13+
## Targets
14+
15+
- a new engineer can get to a first working result quickly
16+
- the local inner loop is documented and reproducible
17+
- common tasks use one obvious command path
18+
- local setup does not depend on tribal knowledge
19+
20+
## Team Rules
21+
22+
- standardize the core commands before optimizing them
23+
- reduce manual setup steps wherever possible
24+
- document local dependencies and how to start them
25+
- prefer one clear path for multi-service startup over per-service guesswork
26+
- fix onboarding friction in the repo, not by telling people in chat
27+
28+
## Common Smells
29+
30+
- different engineers use different hidden startup sequences
31+
- tests only work in CI
32+
- local debugging requires remote-only dependencies
33+
- onboarding docs are stale the week after they are written

‎.codex/skills/dotnet-mcaf-devex/references/onboarding-guide-template.md‎

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
# Onboarding Guide Template
2+
3+
Use this shape for a repo onboarding guide.
4+
5+
## Include
6+
7+
- project purpose
8+
- prerequisites
9+
- setup steps
10+
- build, run, and test commands
11+
- common failure cases
12+
- where architecture and workflow docs live
13+
14+
## Quality Rule
15+
16+
If a new engineer still needs chat help after following the guide, the guide is incomplete.

0 commit comments

Comments
 (0)