TeamBoostWORKFLOW LIBRARY

Command-line workflows / Project coordinators

Scope matrix

Review subproject scope under its actual parent

Resolve a subproject’s parent and identity before filtering or proposing edits that depend on that relationship.

Resolve a child through its actual parent and stable reference. Renaming a subproject and changing its parent are separate operations with different interface support.

Opens the current invite-request page. Access is subject to approval; this example is not imported automatically.

Make the operation boundary visible

Scope planning matrix

Illustrative case: two subprojects are named “CLI,” but only one belongs to the project requested by the operator.

Conditions to establish, not permissions granted here
BoundaryEvidence neededDecision if missing
WorkspaceRequested membership is accessibleStop if the workspace is inaccessible
Parent projectVerified project ID matches the requestResolve ambiguity before filtering
Subproject editInstalled help supports the proposed fieldDo not invent a relationship-write field
01

Resolve the parent

Owner role · Coordinator

Evidence: The requested project is identified from scoped discovery.

02

Read matching subprojects

Owner role · CLI user

Evidence: Results are compared with their actual parent references.

03

Respect the edit boundary

Owner role · Editor

Evidence: The proposal uses supported fields and does not invent parent reassignment.

Decision to make: Use the verified parent and stable subproject reference; do not assume a rename also moves the parent.

Filled illustrative planning example

Invented planning text. Adapt it to your evidence and confirmed owners.

Synthetic inventory: CLI-A belongs to Platform API; CLI-B belongs to Tooling. The request concerns Tooling, so only CLI-B is eligible. Renaming CLI-A would not make it a child of Tooling.

Keep identity and editable scope separate

The saved interface evidence supports reading the parent relationship, not assuming every relationship can be changed.

Confirmed child reference

Keep separate
A different child with the same name.
Why the boundary matters
Parent context determines which CLI subproject belongs to the request.

Supported rename proposal

Keep separate
Parent reassignment through an undocumented update.
Why the boundary matters
Changing a label does not establish a move between projects.

Questions about this workflow

Is the title a unique identifier?

No. Confirm the stable ID and parent context.

Can I move it using the update command?

Do not assume that. The inspected package documents parent reassignment as unavailable.

Does this create tasks in the product?

No. The brief is a manual planning resource. Use the product access link to check onboarding and the workflows available in your account.

Put the outline to work

  1. Confirm which parent project the requester means before searching for the child named CLI.
  2. Compare each child’s stable reference and parent relationship, then record the one that matches the requested scope.
  3. Review only supported editable fields; explain that the inspected update interface does not establish a parent-move operation.

From a useful outline to team work

Explore TeamBoostAI for your team

This manual brief helps an authorized TeamBoost CLI user keep identity, query scope and review evidence explicit. Check the installed interface and account access before using a source-backed command. Confirm the workflows available in your account before adopting this outline.

Request TeamBoostAI access

Opens the current invite-request page. Access is subject to approval; this example is not imported automatically.