Triage

Use this skill first when you work in any repository that points to dkstack.

Decide which sections and skills apply to the current task. Read only those.

Steps

If a feature plan exists, follow feature-plans.md.

1. Identify the type of work: design, implementation, documentation, version control, review, workflow, or mixed.
2. Select the relevant sections and skills from the lists below.
3. Read the section index or skill, then the detailed files it links to.
4. Apply the rules. Prefer the smallest set that covers the task.
5. If the task spans multiple areas, read each relevant item.

Subagents

If you can start subagents, use them for step 3 when the task spans more than one area. Do steps 1 and 2 yourself. Then read the selected sections and skills at the same time, each in its own subagent. Give each subagent a brief that is complete without your context:

• The task, and the type of work from step 1.
• One section or skill from step 2 to read, with its link.
• What to report: the rules that apply to the task, each with its link, and a word limit, for example 300 words.
• This line: "Report to me only. Do not change files, commit, push, post, approve or merge."

Then do steps 4 and 5 yourself. A report from a subagent is a claim. Check each rule that you apply at its source.

If you cannot start subagents, do the steps one at a time in the order of this skill.

Skills

• New or non-compliant repository: bootstrap
• Non-trivial change: clarify-intent
• Design or structure: apply-architecture
• Plan or resume a feature: plan-work
• Map a multi-PR objective: map-work
• Implementation: tdd-loop
• Pull request body: write-pr. Use it when you write or materially update the body. Do not use it for a review that leaves the body unchanged.
• Review: code-review
• Bug or unexpected behavior: coding/debugging.md
• Durable decision: write-adr
• Any text: writing-check
• Version number or release: release

Work route

Read the issue before you select a skill. A missing lifecycle or eligibility does not stop triage. An authorized task carries permission through PR creation and review fixes. Repair unambiguous missing metadata without asking permission again; never override a human-only or conflicting designation. Classify the request. Verify chat instructions under owner instructions in chat. For an explicit instruction from the verified repository owner to implement a named issue, follow the owner-directed transition in work.md: fill missing non-conflicting tracker metadata, establish readiness, re-read tracker state and claim before implementation. Do not infer approval from issue authorship or a request to triage. Do not request repeated approvals for in-scope steps after an authenticated implementation instruction. Check implementation readiness in work.md before implementation. Run preflight before a tracker write. One pull request uses plan-work. More than one pull request uses map-work, then that session stops.

Scale

The ladder is a guide, not a gate. Use the smallest set of skills. A small task uses one or two skills. It does not go through every step.

One pull request, whether small or medium, uses plan-work. A large objective can also use plan-work when it fits one coherent pull request. More than one pull request uses map-work to define the issue graph before any child implementation. Do not create children only because a task has many commits or files.

• Bug fix: tdd-loop, then code-review.
• Feature: start with clarify-intent and apply-architecture. For a multi-PR objective, use map-work, then stop that session. For one-PR work, use plan-work, tdd-loop, then code-review. Use writing-check when the change has text that people or agents read. Use release only when the task is a release.
• Release: release, after the change is reviewed.

Handoffs:

• A review finding goes back to the implementation step.
• A design finding goes back to the architecture step.

One agent can do all the steps. Many agents can share the steps. A skill does not make one role into one agent.

Section map

• Design or structure changes: architecture/index.md
• Code changes: coding/index.md and tdd/index.md
• Commits or branches: version-control/index.md
• Version numbers or releases: versioning/index.md
• Documentation, comments, or messages: writing/index.md
• Any text: writing/index.md
• Issues, pull requests, review, merge or release: workflow/index.md

Stewardship

Routine work does not read stewardship. Read it when a human asks for the analysis, or when the task has one of these signals:

• A new public interface.
• A changed module boundary or a new dependency.
• A workaround that avoids the current architecture.
• The same knowledge appears again.
• Two principles conflict.
• A trade-off affects compatibility, performance or security.
• An ADR no longer matches the code or the current decision.

Do not add a phase, a checklist or a report for ordinary work. The page holds the rules.

Rules

• Do not read every file. Read only what the task needs.
• If two dkstack rules conflict, follow the more specific rule. If a project rule conflicts with a dkstack rule, follow the precedence rules in AGENTS.md.
• To decide between two designs that both work, use the easier to change rule in architecture/index.md.
• If no section clearly applies, read architecture/index.md and coding/index.md.
• After you finish, dkstack remains the source of truth.