sdd-forge
Skill0 starsChanged 37 days agoMITView on GitHub
Use when projecting software-development phases, milestones, and tasks to a hosted repository; creating or reconciling GitHub labels, milestones, and task issues; finding an issue for a task ID; or closing verified task issues and milestones, reopening invalidated milestones, or recovering interrupted hosted transitions. GitHub is the available backend. Ordinary local Git and SDD work does not require hosting access.
In this repository14 other files it gives its agents.
- sdd-conventionsSkill
- sdd-designSkill
- sdd-docsSkill
- sdd-implementSkill
- sdd-integrate-featureSkill
- sdd-manageSkill
- sdd-orientSkill
- sdd-planSkill
- sdd-reportSkill
- sdd-specifySkill
- sdd-steerSkill
- sdd-tasksSkill
- sdd-tddSkill
- sdd-verifySkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Scope: Run only for a requested hosted operation.
- Distinctive: line 11
Hierarchy: Use the sdd-conventions task hierarchy to read phase, milestone, and task IDs and names from TASKS or the active FEATURE-TASKS …
- Distinctive: line 12
Coordination: Before a hosted mutation, sdd-manage coordinates the user's request and a current sdd-orient handoff establishing the …
- Distinctive: line 18
Do not create commits, push branches, or create or merge pull requests here.
- Distinctive: line 20
Add a backend only when it supports a concrete hosted operation with its own repository resolution, authentication, object mapping, and …
- Distinctive: line 24
GitHub: Read GitHub backend when the requested operation targets a GitHub repository.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Hosted task coordination
Shared protocol
- Scope: Run only for a requested hosted operation. Identify the provider before loading its backend; report ambiguous remotes or unsupported providers without guessing. Local SDD work does not require hosting access.
- Hierarchy: Use the sdd-conventions task hierarchy to read phase, milestone, and task IDs and names from TASKS or the active FEATURE-TASKS and preserve their parentage in the host projection. The selected backend defines its concrete objects.
- Coordination: Before a hosted mutation, sdd-manage coordinates the user's request and a current sdd-orient handoff establishing the eligible Git worktree and governing instructions. Read-only inspection needs no Git mutation gate.
- Credentials: Use the available authenticated client or a suitable supplied token. sdd-manage discovers, accepts, and persists tokens under sdd-conventions' Hosting tokens rules and recovers the affected client's authentication when needed. A direct caller may supply a token to sdd-forge. Consume it through a protected mechanism without ordinary handoff/output exposure; Git shell authentication does not prove API-client access. The selected backend defines provider-specific checks and permission requirements.
- Access failure: For a backend access-related 403, request a suitable token from sdd-manage and return the endpoint, required access, and any provider-indicated non-credential cause without exposing the credential. The coordinator checks credential suitability and identifies any policy or other restriction requiring a different remedy; escalation does not require substituting a token when the existing credential is suitable. For direct use without sdd-manage, ask the user. Recheck access before retrying; a replacement token does not establish permission by itself.
- Operational failure: Let the selected backend distinguish access failures, rate limits, service/transport outages, invalid requests, and uncertain writes. Preserve successful independent results and return pending/unknown effects with bounded retry or deferred-reconciliation context; do not route every 403 to credential replacement.
- Handoff: Return the repository, task ID to issue number and URL associations, changed objects, access failures, ambiguity, and remaining differences. Pass issue references to implementation and reporting for commit composition. Issue state does not establish task completion.
Do not create commits, push branches, or create or merge pull requests here.
Add a backend only when it supports a concrete hosted operation with its own repository resolution, authentication, object mapping, and reconciliation rules. Give it a focused reference and explicit trigger; do not advertise a provider before its workflow is defined.
Available backends
- GitHub: Read GitHub backend when the requested operation targets a GitHub repository. It resolves repository identity and access, then routes eligible-phase projection, issue lifecycle and milestone lifecycle operations. Apply the shared backend object lifecycle; task completion evidence comes from execution, not hosted state.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

