From bc
Group normalized requirements and test cases by feature and order them into a logical onboarding sequence. Reads optional feature_order from .buddy-council/sources.json. Produces the structure consumed by demo-feature and assess-feature.
How this skill is triggered — by the user, by Claude, or both
Slash command
/bc:build-onboarding-planThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Group normalized requirements and test cases by feature, then order the features into a sensible learning sequence.
Group normalized requirements and test cases by feature, then order the features into a sensible learning sequence.
Invoked once at the start of an onboarding journey, after fetch-requirements, fetch-test-cases, and normalize-artifacts have produced cross-linked canonical artifacts. The result is persisted in feature_order of the progress log and consumed by the demo and assessment skills.
requirements: array of normalized requirement objects (canonical schema)test_cases: array of normalized test case objects (canonical schema)feature_order from .buddy-council/sources.jsonCreate a feature-keyed map:
groups[requirement.feature].requirements.groups[test_case.feature].test_cases.Skip features that should not appear in onboarding:
"Document Identification", "Referenced Documents", "Glossary")status of "Deprecated", "Deferred", or "Removed"In priority order:
.buddy-council/sources.json contains a top-level feature_order: ["Feature A", "Feature B", ...], use that order. Features in the array but not in the data → drop with a warning. Features in the data but not in the array → append at the end in source order with a note.feature_order field on first run. Subsequent resumes use the persisted order, not a recomputation, to keep the journey deterministic.For each feature, produce an ordered list of small demo steps:
A feature's plan looks like this in memory:
{
"name": "Patient Monitoring",
"purpose": "<1-2 sentence synthesis of feature intent from requirement descriptions>",
"requirement_ids": ["CWA-REQ-85", "CWA-REQ-86"],
"test_case_ids": ["TC-1234", "TC-1235", "TC-1236"],
"steps": [
{
"step_index": 0,
"requirement_id": "CWA-REQ-85",
"title": "<short title>",
"explanation": "<plain-language explanation>",
"dos": [
{ "tc_id": "TC-1234", "rule": "DO: enter a valid patient ID before pressing Save" }
],
"donts": [
{ "tc_id": "TC-1235", "rule": "DON'T: leave the patient ID empty — system rejects with validation error" }
]
}
]
}
When the agent first writes the progress log, populate features[] from this plan:
status: "pending" for allrequirement_ids, test_case_ids filled from the planassessment: null, user_notes: [], completed_at: nullDo NOT serialize the full steps array into the log — it can be reconstructed from a fresh fetch on resume. The log stores only what's needed to resume position and grade outcomes.
Return:
{
"feature_order": ["FeatureA", "FeatureB", "..."],
"features": [ { "<feature plan as shown above>" } ],
"warnings": ["<any skipped or reordered features>"]
}
purpose to a literal title like "<Feature Name> (no description in source)" rather than guessing.feature_order makes resumes deterministic.feature_order lists a feature that doesn't exist in the data, the user should know.Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub omar-hegazy-integrant/buddy-council-plugin --plugin bc