Add overview course for Constructor Studio skills - #15
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughRepository branding and course materials are migrated from “Cyber Fabric” to “Constructor Fabric,” updating README and course URLs, rebranding and rewriting course content across modules, and adding a new Constructor Studio v1 overview with six role-specific lesson scripts and production guidance. ChangesConstructor Fabric Course Branding Migration and Studio Overview
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
courses/constructorfabric-all-course-content.md (1)
1702-1704:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winReplace remaining “Cyber Fabric” references with “Constructor Fabric” for branding consistency.
These lines still use the old brand name inside otherwise rebranded modules, which conflicts with the course migration objective and can confuse learners.
Also applies to: 1808-1810, 2430-2432, 3461-3463
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@courses/constructorfabric-all-course-content.md` around lines 1702 - 1704, Replace every remaining instance of the old brand string "Cyber Fabric" with "Constructor Fabric" in the course content (preserve capitalization and surrounding punctuation), specifically update the occurrence shown in the diff and the other instances called out (the phrases at the other locations). Search for the exact token "Cyber Fabric" in the document and perform a global replace, then run a quick pass to ensure context (sentences mentioning linking requirements, specifications, code/tests, and CI traceability) reads correctly after substitution.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@courses/constructor-studio-draft.md`:
- Around line 4-5: Replace the two legacy repo links
"https://github.com/constructorfabric/cyber-constructor" and
"https://github.com/constructorfabric/cyber-constructor-kit-sdlc" with the
canonical repo names used elsewhere:
"https://github.com/constructorfabric/studio" and
"https://github.com/constructorfabric/studio-kit-sdlc"; update the visible repo
name labels (e.g., `cyber-constructor` → `constructorfabric/studio`,
`cyber-constructor-kit-sdlc` → `constructorfabric/studio-kit-sdlc`) and run a
quick grep for any other occurrences of the old repo names to keep
learner-facing docs consistent.
In `@courses/constructorfabric-all-course-content.md`:
- Line 3: The markdown has heading-level jumps and stray spaces inside emphasis
markers (e.g., the "Module overview" heading and other listed headings), causing
markdownlint MD001/MD037 warnings; fix by making heading levels consistent
(adjust number of leading # to follow the surrounding hierarchy for "Module
overview" and the other flagged headings) and remove spaces inside emphasis
markers (change "* text *" or "_ text _" to "*text*" or "_text_") across the
mentioned occurrences so the document conforms to markdownlint rules.
- Line 1392: The markdown link text and its href are inconsistent: the visible
text reads "cyber-constructor-pilot-kit-sdlc" while the href points to
"cyber-pilot-kit-sdlc"; update the link so the display text matches the target
URL (or vice versa) within the markdown link element (the GitHub repository link
in the document) so both the rendered text and the href use the same repository
name.
- Around line 918-919: Split the merged list item "remain.5. Expected
improvement" into two separate, properly punctuated list entries: "Name the
existing tools that remain." and "Expected improvement: State one measurable or
observable benefit." Also fix the ungrammatical phrase "because Constructor
Fabric to make sure..." to a correct form such as "because Constructor Fabric
ensures..." (search for these exact fragments to locate occurrences — apply the
same fixes at the other occurrence noted around lines 2948–2949).
In `@courses/studio-overview.md`:
- Line 43: The course description in courses/studio-overview.md contradicts the
strict validation boundary declared in
courses/constructor-studio-draft-content.md (which states “Constructor Studio
v1.0.0 only”); update the studio-overview wording to match the validated scope
by explicitly stating the course targets Constructor Studio v1.0.0 and will use
the learner-facing terms (Constructor Studio, cfs, cf and workflow skill names
like cf-write-docs, cf-sdlc-doc-prd, cf-sdlc-implement) so the framing does not
imply reuse beyond the validated version boundary.
---
Outside diff comments:
In `@courses/constructorfabric-all-course-content.md`:
- Around line 1702-1704: Replace every remaining instance of the old brand
string "Cyber Fabric" with "Constructor Fabric" in the course content (preserve
capitalization and surrounding punctuation), specifically update the occurrence
shown in the diff and the other instances called out (the phrases at the other
locations). Search for the exact token "Cyber Fabric" in the document and
perform a global replace, then run a quick pass to ensure context (sentences
mentioning linking requirements, specifications, code/tests, and CI
traceability) reads correctly after substitution.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a004f052-2d6f-45b7-b610-74cf21e4b10b
📒 Files selected for processing (4)
README.mdcourses/constructor-studio-draft.mdcourses/constructorfabric-all-course-content.mdcourses/studio-overview.md
|
|
||
| --- | ||
|
|
||
| ## Lesson 1. Overview for Mixed Audience |
There was a problem hiding this comment.
Why we call it Lesson?
For me it should be an overview - a story - like 5 min video at YouTube/Vimeo.
Not lessons
|
|
||
| By the end of the lesson, viewers should understand what Constructor Studio is, why teams use it, how it fits into normal software delivery, and why human review remains the final control. | ||
|
|
||
| ### Role-Specific Proof Points and Examples |
There was a problem hiding this comment.
I do not like the overall flow at all.
It must be a story, like:
Start with the problem - 30 sec
- there are mid and big size development organizations
- they got significant boost in code and content development with help of LLMs and Agentic tools
- this boost brings new challenge for existing processes, overall control, standartization, etc, especially if ...
Proposed solution - Studio - single environment for different org roles collaboration - Product Managers, Architects, Developers, etc
Explain how it works in 3 min
- There are many tools like X doing Y, but Studio is designed for Z
- Here is how it works ...
There was a problem hiding this comment.
🧹 Nitpick comments (1)
courses/studio-overview.md (1)
48-48: ⚡ Quick winClarify what "router-level workflow names" means.
The constraint says not to mention these in scripts, but the production team may not know what qualifies as a router-level workflow name versus a learner-facing skill. Consider adding an example or brief definition so the constraint is unambiguous.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@courses/studio-overview.md` at line 48, Update the constraint text that currently says "Do not mention router-level workflow names in learner-facing video scripts" to define what a router-level workflow name is and provide an example contrast with a learner-facing skill; specifically, add a short parenthetical or sentence that explains "router-level workflow names" are internal routing/engine identifiers (e.g., internal workflow IDs or system step names like "onboarding_router_v2" or "assign_route_task") and show a brief example of a learner-facing skill name (e.g., "Completing Your First Project") so teams can clearly distinguish which terms are disallowed in scripts and which are acceptable.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@courses/studio-overview.md`:
- Line 48: Update the constraint text that currently says "Do not mention
router-level workflow names in learner-facing video scripts" to define what a
router-level workflow name is and provide an example contrast with a
learner-facing skill; specifically, add a short parenthetical or sentence that
explains "router-level workflow names" are internal routing/engine identifiers
(e.g., internal workflow IDs or system step names like "onboarding_router_v2" or
"assign_route_task") and show a brief example of a learner-facing skill name
(e.g., "Completing Your First Project") so teams can clearly distinguish which
terms are disallowed in scripts and which are acceptable.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0cc9ffaa-b314-4fe3-9f5d-ad24703946bb
📒 Files selected for processing (1)
courses/studio-overview.md
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
courses/constructorfabric-all-course-content.md (1)
1352-1352:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix typo in repository name.
"cybereare-frontx" contains a typo and should be "cyberware-frontx" (or possibly "frontx" based on other references).
✏️ Proposed fix
-| Ware UI, docs, and standards | cybereare-frontx, DNA | Inspect these when you want to understand UI, development principles, guidelines, and instructions for multi-tenant SaaS platform and application development. | +| Ware UI, docs, and standards | cyberware-frontx, DNA | Inspect these when you want to understand UI, development principles, guidelines, and instructions for multi-tenant SaaS platform and application development. |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@courses/constructorfabric-all-course-content.md` at line 1352, There is a typo in the repository name string "cybereare-frontx" within the table row labeled "Ware UI, docs, and standards"; update that token to the correct repository name (replace "cybereare-frontx" with "cyberware-frontx" or the canonical "frontx" if other references use that form) so it matches existing repo references and project conventions.
♻️ Duplicate comments (4)
courses/constructorfabric-all-course-content.md (3)
918-919:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix merged list item that breaks readability.
Line 918 contains a merged list item: "Name the existing tools that remain.5. Expected improvement" should be split into two separate entries with proper formatting.
✏️ Proposed fix
-Name the existing tools that remain.5. Expected improvement\ +Name the existing tools that remain.\ +**5. Expected improvement**\🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@courses/constructorfabric-all-course-content.md` around lines 918 - 919, Split the merged list item "Name the existing tools that remain.5. Expected improvement" into two separate, properly formatted list entries: one for "Name the existing tools that remain." and a new one for "Expected improvement" (e.g., prefix both with list markers like "-" or "1."/"2." consistent with surrounding list style). Ensure punctuation/spacing is corrected so each item appears on its own line and matches the surrounding markdown list formatting.
2948-2949:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix ungrammatical sentence construction.
The phrase "because Constructor Fabric to make sure that confusion is reduced" is grammatically incorrect. The infinitive "to make sure" doesn't fit after "because Constructor Fabric".
✏️ Proposed fix
-Furthermore, the wording should reflect the products and the architecture -of the Github repositories because Constructor Fabric to make sure that -confusion is reduced. +Furthermore, the wording should reflect the products and the architecture +of the GitHub repositories to ensure Constructor Fabric concepts are +clearly communicated and confusion is reduced.Note: Also corrected "Github" to "GitHub" (proper capitalization).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@courses/constructorfabric-all-course-content.md` around lines 2948 - 2949, Replace the ungrammatical fragment "because Constructor Fabric to make sure that confusion is reduced" with a correct clause and fix GitHub capitalization; for example change the sentence to "of the GitHub repositories so that confusion is reduced" (or "to ensure that confusion is reduced") by locating the phrase "because Constructor Fabric to make sure that confusion is reduced" in the document and updating it accordingly.
1392-1392:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix repository link text mismatch.
The display text shows "cyber-constructor-pilot-kit-sdlc" but the actual URL points to "cyber-pilot-kit-sdlc". Based on line 1348 and other references in the document, the correct repository name appears to be "cyber-pilot-kit-sdlc".
🔗 Proposed fix
-**Repository: **[https://github.com/constructorfabric/cyber-constructor-pilot-kit-sdlc](https://github.com/constructorfabric/cyber-pilot-kit-sdlc) +**Repository: **[https://github.com/constructorfabric/cyber-pilot-kit-sdlc](https://github.com/constructorfabric/cyber-pilot-kit-sdlc)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@courses/constructorfabric-all-course-content.md` at line 1392, Fix the mismatched repository link text: update the Markdown link whose URL is https://github.com/constructorfabric/cyber-pilot-kit-sdlc so the display text reads "cyber-pilot-kit-sdlc" (matching the URL and other references) instead of "cyber-constructor-pilot-kit-sdlc"; ensure any other occurrences in this document that reference the same repo use the consistent "cyber-pilot-kit-sdlc" display text.courses/studio-overview.md (1)
30-30:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winVersion boundary needs explicit v1.0.0 statement.
Line 30 states "Constructor Studio v1" generically, but the validation contract in other course files specifies "Constructor Studio v1.0.0 only." To avoid implying the scripts apply to all v1.x versions beyond the validated scope, update this line to explicitly reference v1.0.0.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@courses/studio-overview.md` at line 30, The document currently refers to "Constructor Studio v1" ambiguously; update that phrasing in the sentence that reads "Constructor Studio v1" to explicitly state "Constructor Studio v1.0.0" so the script pack aligns with the validation contract used elsewhere (replace the exact phrase "Constructor Studio v1" with "Constructor Studio v1.0.0").
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@courses/constructorfabric-all-course-content.md`:
- Around line 1591-1592: Update the mismatched repo display text so it matches
the URL: replace the label "cyberware-csharp" with
"constructorfabric-core-csharp" (or alternatively update the URL to match the
intended "cyberware-csharp" repo) in the markdown entry that currently shows the
link <https://github.com/constructorfabric/constructorfabric-core-csharp>,
ensuring the visible text and the target URL are consistent.
- Line 1205: The link text for "ConstructorFabric Core" is pointing to the wrong
repo: the anchor text currently references constructorfabric/cyberware-rust
while the href targets constructorfabric/constructorfabric-core; update the
markdown so the display text and the href are consistent by changing the anchor
text (or href) to reference constructorfabric/constructorfabric-core wherever
"ConstructorFabric Core" appears (specifically the mismatched link entry),
leaving spacing unchanged.
---
Outside diff comments:
In `@courses/constructorfabric-all-course-content.md`:
- Line 1352: There is a typo in the repository name string "cybereare-frontx"
within the table row labeled "Ware UI, docs, and standards"; update that token
to the correct repository name (replace "cybereare-frontx" with
"cyberware-frontx" or the canonical "frontx" if other references use that form)
so it matches existing repo references and project conventions.
---
Duplicate comments:
In `@courses/constructorfabric-all-course-content.md`:
- Around line 918-919: Split the merged list item "Name the existing tools that
remain.5. Expected improvement" into two separate, properly formatted list
entries: one for "Name the existing tools that remain." and a new one for
"Expected improvement" (e.g., prefix both with list markers like "-" or
"1."/"2." consistent with surrounding list style). Ensure punctuation/spacing is
corrected so each item appears on its own line and matches the surrounding
markdown list formatting.
- Around line 2948-2949: Replace the ungrammatical fragment "because Constructor
Fabric to make sure that confusion is reduced" with a correct clause and fix
GitHub capitalization; for example change the sentence to "of the GitHub
repositories so that confusion is reduced" (or "to ensure that confusion is
reduced") by locating the phrase "because Constructor Fabric to make sure that
confusion is reduced" in the document and updating it accordingly.
- Line 1392: Fix the mismatched repository link text: update the Markdown link
whose URL is https://github.com/constructorfabric/cyber-pilot-kit-sdlc so the
display text reads "cyber-pilot-kit-sdlc" (matching the URL and other
references) instead of "cyber-constructor-pilot-kit-sdlc"; ensure any other
occurrences in this document that reference the same repo use the consistent
"cyber-pilot-kit-sdlc" display text.
In `@courses/studio-overview.md`:
- Line 30: The document currently refers to "Constructor Studio v1" ambiguously;
update that phrasing in the sentence that reads "Constructor Studio v1" to
explicitly state "Constructor Studio v1.0.0" so the script pack aligns with the
validation contract used elsewhere (replace the exact phrase "Constructor Studio
v1" with "Constructor Studio v1.0.0").
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4ecfa525-56ae-4207-b521-19caee00ce1d
📒 Files selected for processing (4)
README.mdcourses/constructor-studio-draft.mdcourses/constructorfabric-all-course-content.mdcourses/studio-overview.md
✅ Files skipped from review due to trivial changes (2)
- README.md
- courses/constructor-studio-draft.md
| | 1:10-1:45 | Tools like OpenSpec and similar systems can help teams produce structured specs. That is useful. But generating more documents is not the same as keeping an organization aligned, consistent, and reviewable across teams. | Show a “generate specs” machine producing clean documents, then zoom out to messy handoffs between PM, architecture, development, and QA. | Generation is not governance | | ||
| | 1:45-2:20 | Constructor Studio is designed for that organizational layer. It gives teams a shared environment for AI-assisted delivery, where product work, architecture work, coding work, and QA work can stay connected. | The scattered files move into one shared delivery map with role lanes. | One shared delivery flow | | ||
| | 2:20-3:05 | Studio is not only for one person writing better prompts. It is for collaboration between roles and between teams. Product Managers shape requirements. Architects turn intent into decisions and design. Developers implement from approved context. QA checks behavior against traceable evidence. | PM, Architect, Developer, and QA lanes connect through shared files. | Teams, not solo prompting | | ||
| | 3:05-3:45 | The basic idea is simple: work is routed into the right workflow, with the right context, and with checks that make the result easier to inspect. Instead of one long chat, the team gets a repeatable path from intent to implementation and review. | A single chat thread transforms into a guided path: intent, design, feature, code, tests, review. | Right workflow, right context | |
There was a problem hiding this comment.
I'm not sure I got the idea about single chat. I think it's not the case even for small organizations
| | 1:45-2:20 | Constructor Studio is designed for that organizational layer. It gives teams a shared environment for AI-assisted delivery, where product work, architecture work, coding work, and QA work can stay connected. | The scattered files move into one shared delivery map with role lanes. | One shared delivery flow | | ||
| | 2:20-3:05 | Studio is not only for one person writing better prompts. It is for collaboration between roles and between teams. Product Managers shape requirements. Architects turn intent into decisions and design. Developers implement from approved context. QA checks behavior against traceable evidence. | PM, Architect, Developer, and QA lanes connect through shared files. | Teams, not solo prompting | | ||
| | 3:05-3:45 | The basic idea is simple: work is routed into the right workflow, with the right context, and with checks that make the result easier to inspect. Instead of one long chat, the team gets a repeatable path from intent to implementation and review. | A single chat thread transforms into a guided path: intent, design, feature, code, tests, review. | Right workflow, right context | | ||
| | 3:45-4:25 | Studio is also customizable. An organization can adapt templates, rules, workflows, validation, and codebase conventions instead of throwing away its existing process. The default SDLC kit gives teams a starting point, not a prison. | A default workflow adapts into several company-specific variants. | Fit your process | |
There was a problem hiding this comment.
The 'prison' term sounds aggressive
| | 1:45-2:20 | Constructor Studio is designed for that organizational layer. It gives teams a shared environment for AI-assisted delivery, where product work, architecture work, coding work, and QA work can stay connected. | The scattered files move into one shared delivery map with role lanes. | One shared delivery flow | | ||
| | 2:20-3:05 | Studio is not only for one person writing better prompts. It is for collaboration between roles and between teams. Product Managers shape requirements. Architects turn intent into decisions and design. Developers implement from approved context. QA checks behavior against traceable evidence. | PM, Architect, Developer, and QA lanes connect through shared files. | Teams, not solo prompting | | ||
| | 3:05-3:45 | The basic idea is simple: work is routed into the right workflow, with the right context, and with checks that make the result easier to inspect. Instead of one long chat, the team gets a repeatable path from intent to implementation and review. | A single chat thread transforms into a guided path: intent, design, feature, code, tests, review. | Right workflow, right context | | ||
| | 3:45-4:25 | Studio is also customizable. An organization can adapt templates, rules, workflows, validation, and codebase conventions instead of throwing away its existing process. The default SDLC kit gives teams a starting point, not a prison. | A default workflow adapts into several company-specific variants. | Fit your process | |
There was a problem hiding this comment.
I'd have a section that Studio doesn't change your technological stack and works on top of your favorite AI tools - claude code, github copilot, cursor and such. This is important, because teams do not want to change the wheels just because of one more tool
Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs, cf-explore, cf-brainstorm Signed-off-by: ainetx <viator@via-net.org>
Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs Signed-off-by: ainetx <viator@via-net.org>
Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs Signed-off-by: ainetx <viator@via-net.org>
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs Signed-off-by: ainetx <viator@via-net.org>
Removed 'for a Mixed Audience' from the Constructor Studio overview section. Signed-off-by: ainetx <viator@via-net.org>
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs Signed-off-by: ainetx <viator@via-net.org>
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs
| | 0:35-1:10 | Without a shared operating model, speed can turn into fragmentation. Teams may use different templates, lose decision history, skip review evidence, or produce documents that no longer match the codebase. | Show separate team islands with inconsistent docs and unclear handoffs. | Fragmentation risk | | ||
| | 1:10-1:45 | Constructor Studio is a proposed solution for that layer. It is an open-source, customizable environment that helps organize collaboration across Product Managers, Architects, Developers, DevLeads, and QA engineers. | The islands connect into one shared operating layer. | Shared operating layer | | ||
| | 1:45-2:25 | Studio differs from individual or project-centered specification tools because it is focused on organizational delivery control. The goal is not just to create one more spec. The goal is to keep intent, decisions, implementation, tests, and review evidence connected. | Compare “project spec” with “organization workflow”: the second shows cross-role links. | Beyond project specs | | ||
| | 2:25-3:05 | The mechanism is straightforward. Studio uses workflows and concrete skills for different kinds of work: brainstorming, exploration, PRD writing, design, ADRs, implementation, reverse engineering, and change impact analysis. | Role lanes call specific skills only after the problem is introduced. | Workflows by role | |
There was a problem hiding this comment.
Role lanes call specific skills only after the problem is introduced
I did not get the idea
| | 1:10-1:45 | Constructor Studio is a proposed solution for that layer. It is an open-source, customizable environment that helps organize collaboration across Product Managers, Architects, Developers, DevLeads, and QA engineers. | The islands connect into one shared operating layer. | Shared operating layer | | ||
| | 1:45-2:25 | Studio differs from individual or project-centered specification tools because it is focused on organizational delivery control. The goal is not just to create one more spec. The goal is to keep intent, decisions, implementation, tests, and review evidence connected. | Compare “project spec” with “organization workflow”: the second shows cross-role links. | Beyond project specs | | ||
| | 2:25-3:05 | The mechanism is straightforward. Studio uses workflows and concrete skills for different kinds of work: brainstorming, exploration, PRD writing, design, ADRs, implementation, reverse engineering, and change impact analysis. | Role lanes call specific skills only after the problem is introduced. | Workflows by role | | ||
| | 3:05-3:40 | Traceability is the control point. Canonical Provenance Trace IDs can connect documents and code so teams can reason about consistency. Validation can check structure, references, and configured rules. Human review remains the final authority. | A chain connects PRD, DESIGN, FEATURE, code, tests, and approval. | Traceable evidence | |
There was a problem hiding this comment.
Canonical Provenance Trace IDs (or just CPT ID)
| | 1:45-2:25 | Studio differs from individual or project-centered specification tools because it is focused on organizational delivery control. The goal is not just to create one more spec. The goal is to keep intent, decisions, implementation, tests, and review evidence connected. | Compare “project spec” with “organization workflow”: the second shows cross-role links. | Beyond project specs | | ||
| | 2:25-3:05 | The mechanism is straightforward. Studio uses workflows and concrete skills for different kinds of work: brainstorming, exploration, PRD writing, design, ADRs, implementation, reverse engineering, and change impact analysis. | Role lanes call specific skills only after the problem is introduced. | Workflows by role | | ||
| | 3:05-3:40 | Traceability is the control point. Canonical Provenance Trace IDs can connect documents and code so teams can reason about consistency. Validation can check structure, references, and configured rules. Human review remains the final authority. | A chain connects PRD, DESIGN, FEATURE, code, tests, and approval. | Traceable evidence | | ||
| | 3:40-4:20 | Adoption does not require a process reset. Teams can start with the default SDLC kit and then customize document templates, checklists, workflows, and codebase rules to match existing governance. | Default kit expands into organization-specific process gates. | Start standard, adapt | |
There was a problem hiding this comment.
Adoption does not require a process reset
->
Adoption does not require a process, tech stack or favorite tools reset.
| | 0:35-1:10 | Without a shared operating model, speed can turn into fragmentation. Teams may use different templates, lose decision history, skip review evidence, or produce documents that no longer match the codebase. | Show separate team islands with inconsistent docs and unclear handoffs. | Fragmentation risk | | ||
| | 1:10-1:45 | Constructor Studio is a proposed solution for that layer. It is an open-source, customizable environment that helps organize collaboration across Product Managers, Architects, Developers, DevLeads, and QA engineers. | The islands connect into one shared operating layer. | Shared operating layer | | ||
| | 1:45-2:25 | Studio differs from individual or project-centered specification tools because it is focused on organizational delivery control. The goal is not just to create one more spec. The goal is to keep intent, decisions, implementation, tests, and review evidence connected. | Compare “project spec” with “organization workflow”: the second shows cross-role links. | Beyond project specs | | ||
| | 2:25-3:05 | The mechanism is straightforward. Studio uses workflows and concrete skills for different kinds of work: brainstorming, exploration, PRD writing, design, ADRs, implementation, reverse engineering, and change impact analysis. | Role lanes call specific skills only after the problem is introduced. | Workflows by role | |
There was a problem hiding this comment.
I think we must not use PRD and ADR in speech, only Product Requirements Document and Architecture Decision Records
| | 1:45-2:25 | A PM can use `cf-brainstorm` to explore options before committing to scope. The point is not to get a pretty answer. The point is to surface alternatives, risks, missing questions, and decision criteria early. | Branching options appear, then collapse into a chosen direction with open questions. | Explore before scope | | ||
| | 2:25-3:05 | When the direction is ready, `cf-sdlc-doc-prd` helps create or review a PRD using structured expectations. `cf-write-docs` supports broader product writing when the document is less formal. | Two paths: formal PRD and flexible product document. | PRD and docs | | ||
| | 3:05-3:40 | Studio also helps with review. `cf-explain` can make dense material easier to understand, and PRD-specific workflows can validate whether the requirement is clear enough for architecture, development, and QA. | A dense PRD becomes a concise summary plus review notes. | Review before handoff | | ||
| | 3:40-4:25 | This improves collaboration because downstream teams receive something more stable than a chat transcript. Architects can reference the PRD. Developers can implement against it. QA can design tests against visible intent. | One PRD feeds architecture, implementation, and QA lanes. | Stable handoff | |
There was a problem hiding this comment.
more stable than a chat transcript
->
more stable than a chat transcript or an unstructured requirements document
| | 2:25-3:05 | When the direction is ready, `cf-sdlc-doc-prd` helps create or review a PRD using structured expectations. `cf-write-docs` supports broader product writing when the document is less formal. | Two paths: formal PRD and flexible product document. | PRD and docs | | ||
| | 3:05-3:40 | Studio also helps with review. `cf-explain` can make dense material easier to understand, and PRD-specific workflows can validate whether the requirement is clear enough for architecture, development, and QA. | A dense PRD becomes a concise summary plus review notes. | Review before handoff | | ||
| | 3:40-4:25 | This improves collaboration because downstream teams receive something more stable than a chat transcript. Architects can reference the PRD. Developers can implement against it. QA can design tests against visible intent. | One PRD feeds architecture, implementation, and QA lanes. | Stable handoff | | ||
| | 4:25-5:00 | For Product Managers, the value is not more documentation for its own sake. The value is clearer intent that survives the path from idea to design, code, tests, and release decisions. | End with a single requirement connected across the delivery chain. | Intent that survives | |
There was a problem hiding this comment.
I think we need to focus more on that traceability and linking system, visualize it:
-
Studio maintains traceability system that allows to understand what parts of the requirements where covered by the design and how exactly it can be implemented. It helps AI to update needed parts of the design or code if requirements changed or identify the gaps
-
Product Managers can link new requirements, or specific paragraphs within them, to requirements defined elsewhere by using stable IDs. This makes it possible to build a graph of connected requirements that shapes the final product scope.
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs
| |---|---|---|---| | ||
| | 0:00-0:35 | Architects often sit in the middle of the AI acceleration problem. Product intent is changing faster. Code is changing faster. Documentation is being generated faster. But architecture still needs coherence. | Product docs, code changes, and design notes move quickly around an architect. | Speed needs coherence | | ||
| | 0:35-1:10 | The risk is hidden drift. A Product Requirements Document may imply one architecture. Existing code may support another. A design document may become stale as implementation moves ahead. | Show Product Requirements Document, design, and code slowly separating from each other. | Hidden drift | | ||
| | 1:10-1:45 | Constructor Studio gives Architects a way to work from evidence instead of memory. Before deciding, they can collect context from documents, folders, code, and existing architecture material. | Evidence cards collect from repo, docs, and previous decisions. | Evidence before design | |
| |---|---|---|---| | ||
| | 0:00-0:35 | Architects often sit in the middle of the AI acceleration problem. Product intent is changing faster. Code is changing faster. Documentation is being generated faster. But architecture still needs coherence. | Product docs, code changes, and design notes move quickly around an architect. | Speed needs coherence | | ||
| | 0:35-1:10 | The risk is hidden drift. A Product Requirements Document may imply one architecture. Existing code may support another. A design document may become stale as implementation moves ahead. | Show Product Requirements Document, design, and code slowly separating from each other. | Hidden drift | | ||
| | 1:10-1:45 | Constructor Studio gives Architects a way to work from evidence instead of memory. Before deciding, they can collect context from documents, folders, code, and existing architecture material. | Evidence cards collect from repo, docs, and previous decisions. | Evidence before design | |
| | 3:05-3:45 | In existing systems, Architects can also use `cf-sdlc-reverse-engineer` to reconstruct design understanding from code, and `cf-sdlc-change-impact-analysis` to estimate what a proposed change may touch. | Brownfield code turns into a design map and impact links. | Brownfield needs maps | | ||
| | 3:45-4:25 | The important point is control. Studio does not make architecture automatic. It helps keep requirements, decisions, constraints, codebase evidence, and downstream features visible to reviewers. | Architecture chain connects Product Requirements Document, Architecture Decision Record, DESIGN, FEATURE, code, and review. | Visible decisions | | ||
| | 4:25-5:00 | For Architects, Constructor Studio is a way to slow the right things down: not delivery speed, but unreviewed assumptions. The result is faster collaboration with fewer invisible architecture gaps. | End with design decisions anchored to evidence and downstream work. | Fewer invisible gaps | | ||
|
|
There was a problem hiding this comment.
I think we also need to address another common challenge for architects: architecture is typically a tradeoff between business requirements, technical constraints, future extensibility, operational costs, security, and performance.
-
Architects need to consider many different inputs to make the right decisions. Studio helps keep all of those inputs accessible and provides capabilities such as architecture document templates, validation rules, and other mechanisms that support consistent, well-informed decision-making.
-
Studio inherits modern architecture documentation practices by separating Design documents from Architecture Decision Records. Design documents define how the system should work, while ADRs capture why specific decisions were made. This separation reduces AI context size by isolating the pure Design content needed for code generation from ADRs, which preserve architectural history and rationale but are not required in the code generation context.
| | 2:25-3:05 | When the direction is ready, the Product Requirements Document workflow helps create or review requirements using structured expectations. `cf-write-docs` supports broader product writing when the document is less formal. | Two paths: formal Product Requirements Document and flexible product document. | Requirements and docs | | ||
| | 3:05-3:40 | Studio also helps with review and traceability. Requirements, and even specific paragraphs inside them, can use stable IDs that link to requirements defined elsewhere. That creates a graph of connected requirements that shapes the final product scope. | Requirement paragraphs receive stable IDs, then connect into a visible requirement graph. | Linked requirements | | ||
| | 3:40-4:25 | This improves collaboration because downstream teams receive something more stable than a chat transcript or an unstructured requirements document. Architects can see which requirements are covered by design, developers can see how they can be implemented, and QA can design tests against visible intent. | One Product Requirements Document feeds architecture, implementation, and QA lanes with trace links. | Stable handoff | | ||
| | 4:25-5:00 | For Product Managers, the value is not more documentation for its own sake. The value is clearer intent that survives change: when requirements move, Studio helps identify design or code that may need updates and gaps that need review. | End with changed requirement IDs highlighting affected design and code nodes. | Intent that survives | |
There was a problem hiding this comment.
We should also mention phase tags for requirement stories.
Studio provides a simple phase-tagging system that groups requirements by delivery phase. This helps architects understand the full product direction in advance by seeing both current requirements and upcoming functionality, while allowing development teams to stay focused on the current delivery scope.
| |---|---|---|---| | ||
| | 0:00-0:35 | Developers feel the AI boost directly. Code can be generated faster. Tests can be drafted faster. Bug explanations can arrive faster. But faster editing can also create faster confusion. | Code, tests, and fixes appear quickly in an editor. Some lose links to requirements. | Faster code, faster confusion | | ||
| | 0:35-1:10 | The problem is not that AI writes code. The problem is code without enough context: unclear requirement links, missing design decisions, weak tests, or changes that reviewers cannot trace back to intent. | A pull request appears with unanswered questions around it. | Context is the bottleneck | | ||
| | 1:10-1:45 | Constructor Studio helps developers start from approved inputs instead of a vague chat summary. Work can begin from Product Requirements Document, design, Architecture Decision Record, or feature artifacts that explain why the change exists. | Editor opens next to linked FEATURE and DESIGN files. | Code from intent | |
| | 2:25-3:05 | For unfamiliar code or bugs, `cf-explore` helps developers understand the area before changing it. That matters because random edits in unknown code create review risk and regression risk. | A bug report links to targeted code exploration before the fix. | Explore before fixing | | ||
| | 3:05-3:45 | Tests become part of the same story. Instead of writing tests only against implementation details, developers can connect tests back to feature intent and expected behavior. | FEATURE intent generates code and tests side by side. | Tests follow intent | | ||
| | 3:45-4:25 | Before review, `cfs` can run repeatable checks for the configured project surface. These checks do not replace human judgment, but they give reviewers a cleaner evidence packet. | Terminal checks pass, then a reviewer inspects the linked evidence. | Checks before review | | ||
| | 4:25-5:00 | For DevLeads, the value is consistency across a team. More work follows a visible chain from intent to code to tests, and less knowledge is trapped in private prompts or one-off chats. | Multiple developer lanes converge into one reviewable team flow. | Reviewable team work | |
There was a problem hiding this comment.
Other valuable features:
- Gap analysis between requirement and real implementation, with help of traceable requirements IDs
The Workspaces is not covered:
- Allows to oversee other repositories with the specs and code to trace consistency, make gap analysis and traceabilty between different parts of the system - documentation, libraries & components source code - API contracts, front, backend components, mobile app, etc.
| | 2:25-3:05 | `cf-coding` can support automated test authoring when the expected behavior is clear. The goal is not to generate tests blindly, but to write tests against visible intent and requirement links. | Test cases connect back to feature behavior and requirements. | Test against intent | | ||
| | 3:05-3:45 | Repeatable checks add another signal. If references, structure, or configured traceability fail, QA can see that early. Passing checks do not prove quality, but failing checks expose review risk. | Validator catches a broken reference before QA approval. | Checks expose risk | | ||
| | 3:45-4:25 | This changes collaboration. QA is no longer only at the end of a code diff. QA can inspect the same delivery chain that Product, Architecture, and Development used to create the change. | QA joins the shared PM, Architect, Developer workflow map. | QA inside the flow | | ||
| | 4:25-5:00 | For QA engineers, Constructor Studio provides better context before testing, stronger evidence during review, and a clearer path from requirement to behavior to automated tests. | End on requirement, feature, code, test, and approval connected. | Better context, better tests | |
There was a problem hiding this comment.
Need to mention real example - Studio allows to review requirements and check where certain requirements being tested - unit tests, integration tests, end-to-end tests, security tests, performance tests, etc. Studio provides workspace management for multi-repository management and gap analysis capabilities
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: 1.2.0 Studio-Workflows: cf-write-docs
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: skill=1.0.0, project=1.4.0, package=1.3.7 Studio-Workflows: cf-write-docs
Signed-off-by: ainetx <viator@via-net.org> Co-authored-by: Constructor Studio <291158726+constructor-studio[bot]@users.noreply.github.com> Studio-Generated-By: Constructor Studio Studio-Source-Repo: https://github.com/constructorfabric/studio Constructor-Fabric: https://github.com/constructorfabric Studio-Version: skill=1.0.0, cli=1.3.7, project=1.4.0 Studio-Workflows: cf-write-docs
|
|
||
| This course addresses practitioners who work at the intersection of AI-assisted requirements and design generation, coding, and structured software delivery: | ||
|
|
||
| - **Product-minded engineers** who translate business requirements into structured design and want to preserve intent through implementation. |
|
|
||
| It helps development teams keep requirements, design, plans, code, and review evidence aligned through inspectable artifacts, structured workflows, deterministic checks, and traceability across the delivery lifecycle. | ||
|
|
||
| Constructor Studio is most useful for developers, architects, technical leads, QA, DevOps who need more than one-shot generation and need to control full project lifecycle - initial development, new feature implementation, later re-achitecture, etc. |
There was a problem hiding this comment.
and product managers and (in the future UX designers)
|
|
||
| ### 4.4 Generating Host Integrations | ||
|
|
||
| Description: This module explains how Constructor Studio projects workflows into AI coding tools. Learners regenerate integrations and learn when regeneration is required. |
There was a problem hiding this comment.
better explain which integrations you are talking about.
also above "Host Integrations" term was introduced but not explained
|
|
||
| ### 5.2 Planning Work with `/cf-plan` | ||
|
|
||
| Description: This module teaches how to decompose work into phase files and checkpoints. Learners understand that planning produces execution artifacts rather than doing the underlying implementation. |
There was a problem hiding this comment.
better specify somewhere on top - which project/artefact a student will work on.
or it's a student duty to define project?
Summary by CodeRabbit